This is an (unintentional) side effect of my changes to GtkTreeView's
get_preferred_size() implementation. It seems odd to me that
GtkTreeView directly determines its own size when inside a
GtkScrolledWindow, but since it does, it should be using its natural
size, not its minimum size.
With this commit, we pick up xft settings from GSettings
as well. Among other things, this makes the Large Text
setting work. Still to do: pick up fontconfig changes without
having all clients use up inotify watches for all font
directories.
Add GInitable interface with a default implementation that always
succeeds. This allows backends to override the GInitable implementation
and add their own checks to determine if the backend can be loaded. If
a backend cannot be loaded, GDK can attempt to load the next available
backend.
Since backends may need to read any relevant options (such as the
display flag) to determine if they can be created successfully, this
patch also removes calls that attempt to create the display manager
before the options have been parsed.
https://bugzilla.gnome.org/show_bug.cgi?id=694465
The check for GDK_CURSOR_IS_PIXMAP was ineffective, since _all_
cursors have this type, from the looks of it. Instead, store
buffer ownership information separately.
These might be candidates for a future settings interface; until
then, we use GSettings directly. Note again that we are careful
to avoid a dependency on GNOME schemas.
Key repeat under X is not affected by modifiers. And on some systems
(e.g my Thinkpad), NumLock is permanently on, rendering key repeat
nonfunctional. This commit changes the Wayland backend to do
key repeat regardless of modifiers.
http://bugzilla.gnome.org/show_bug.cgi?id=695497
This make the nice 'snap off' feature of gnome-shell work
with client-side decorations. weston moves the maximized window
around, which is less ideal...
We already set it in init, so this is just redundant.
The additional window-content style class here is needed so that we can
distinguish between the full X window background and the background for
the actual window contents.
Commit 0d9d808217 fixed the hotspot issue,
but commit f2cc52fddd then optimized away
cursor changes a little too aggressively. We always need to set the
cursor on enter. Make sure we clear the current cursor on leave so we
don't think it's already set on the next enter.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
Until we figure out where we want to go with settings under
Wayland, this makes GTK+ applications a lot easier to deal
with under Wayland.
Note that we are careful to deal with the absence of schemas,
so this does not introduce a dependency on GNOME settings.
wl_pointer.set_cursor is rejected if the serial number doesn't match
the enter serial number for the wl_pointer. We passed the right serial
number when setting the cursor surface in response to the enter event.
Later set_cursor requests fail, but we can still attach new buffers to
our cursor surface, which is why the cursor changed, but the hotspot
didn't update. Clicking in the decoration results in a leave/enter pair
which triggers wl_pointer.set_cursor with the right serial. That's why
clicking the decoration sets the right cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
We need to pass the delta between the old and new hotspot
when attaching the new cursor surface, to keep the hotspot
at the same position. We can't deal with this in the compositor,
since the set_cursor call already overwrites the old hotspot,
so the information is lost by the time the attach happens.
Unfortunately, we can't query the initial hotspot from
the compositor, so the first cursor change will make the
hotspot jump.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
We were not translating event coordinates to the toplevel
window, thus the regions we determined were not right.
We were also not respecting the maximized state, and we
were unnecessarily refusing to handle events when not decorated.
https://bugzilla.gnome.org/show_bug.cgi?id=696197
If the style changes before we're realized we will delay the
style-updated signal until realize. However, we then lose
the changes bitmap. This means that gtk_widget_real_style_updated()
must treat a NULL change as "everything changed" and queue a resize.
