After considerable discussion, we came to the conclusion
that the convenience of this API wins over the correctness
of gtk_window_present_with_time(), in particular since we
don't have a good mechanism to carry timestamps from the
events to the places where we present windows.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
Previously, those numbers stored the values relative to the margin box
of the widget. Now they store values relative to the content box,
thereby getting rid of the last remains of weird coordinate systems.
Instead of recording the way up from the target widget to the grab
widget (or toplevel) and then walking that path upwards, just walk the
parent chain and look at the cursor.
I was stuck in an X session and noticed that my resize corners
all got east or north cursors. It turns out that gnome-shell
does not properly advertise support for edge constraints under X11,
and the absence of that makes the code for determining the edge
under the cursor misbehave.
This change should fix that.
The code gets rid of the GtkTreeView and replaces it with a GtkListBox.
Most of the logic is now done via GListModel subclasses.
A big change is that this new list is now tracking updates itself and
doesn't need to be manually updated. All code that used to cause rescans
or add forgotten objects to the tree has been removed.
If objects are missing from the object tree, the logic for tracking them
needs to be added.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
