We were trying to start search when the user types anything,
but this is annoying more often than helpful, and interferes
with the location entry. So, stick with explicitly enabled
search (via the search button or Alt-S) for now.
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.
This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
When the Wayland compositor vanishes, all applications connected will
receive a SIGPIPE as soon as they try to use wl_display_dispatch().
Do not use g_error() to terminate the applications when this occurs,
g_error() means an error in the application while here it's not truly
the case.
Use g_warning() and exit() instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=745289
Although gtk_list_box_row_grab_focus() is not a public function
it can be easily called by gtk_widget_grab_focus() with a row argument
which has been removed from the list box and has box == NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=744879
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
https://bugzilla.gnome.org/show_bug.cgi?id=745263
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.
Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
Don't try to paint onto an error surface. This happens for example when
gdk_cairo_set_source_pixbuf() is called with a pixbuf that is too big
for Cairo to handle.
Spotted by Christian Boxdörfer
If a scrollbar is not shown (because of policies, or because it isn't
necessary), it doesn't make sense to start fade animations on its window
on captured motion events.
