If the GtkPrintJob is freed too early when the surface has been created
but the job hasn't been sent to the printer, it's possible that the
file print backend tries to write to the io chaneel when it is already
closed. This produces runtime critical warnings:
GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel->is_writeable' failed
https://bugzilla.gnome.org/show_bug.cgi?id=685420
It can happen if the io channel has been closed. In that case
g_io_channel_write_chars() returns early because of a g_return macro
that checks if the io channel is writable. When returning from g_return
macros, the bytes written output parameter is not updated and the error
is not filled, so the error is not detected and the written variable is
used uninitialized. We should check the return value of
g_io_channel_write_chars() to break the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=685419
This reverts commit 666d10ec76.
This change severely broke any treeviews without horizontal
scrollbars. Basically, ellipsization never kicks in, and instead
the treeview content just extends outside the visible area,
rendering it inaccessible. This broke e.g. the control-center
keyboard shortcuts panel, the gnome-disks device list, etc etc.
In the case that the client is started directly by the compositor the
WAYLAND_SOCKET environment variable is set containing the fd to use that was
created by a socketpair.
This environment variable is consumed by a call to wl_display_connect so a
second call will not take advantage of it.
https://bugzilla.gnome.org/show_bug.cgi?id=697673
If gdk_window_flush_outstanding_moves() creates new update area
we handle this directly in the same draw to avoid flashing.
This mainly affects win32 as X11 does its exposes from moves async.
However, its important for win32 since ScrollDC seems to sometimes
invalidate (and not copy) unexected regions.
http://bugzilla.gnome.org/show_bug.cgi?674051
Rather than set the window update region and repaint this region
when we get a WM_PAINT we just directly add it to the update
region. No need to roundtrip via win32.
This lets us also make sure we do this drawing in the same update
cycle. This seems especially important on Win7, because ScrollDC
seems to act kind of weird there, not using bitblt in areas where
it seemingly could, which makes scrolling look really flashy.
http://bugzilla.gnome.org/show_bug-cgi?id=674051
On crossing events resulting from moving windows (eg. workspace switch),
deviceid equals sourceid, so make those reset scroll valuators on all
slave devices to avoid misleading jumps in scroll events
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=690275
Non-inset box-shadows are no longer ignored by the GTK+ theming engine,
outset shadows are supported.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Adds conditional code paths to GdkCssShadowValue for painting outset
shadows, and allows shadows to be applied in two passes (first outset
then inset). This can be used to draw csd shadows in outer window
borders.
https://bugzilla.gnome.org/show_bug.cgi?id=695998
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Under Wayland we don't know the absolute position of the device but there are
some API calls that expect to get an root window position. Previously we were
not assigning any value to these out parameters potentially leaving the values
undefined.
This change returns the current surface relative position of the device.
This patch can be considered a leftover of commit 6f607fc8b4 ,
replace the no longer existing function with the GDK function
meant to replace it.
This was noticeable on regular clipboard operations in quartz
Don't just look at previously remembered sizes, also look at the current
size.
This is useful for cases where the window was resized by the user or WM
and not by the application itself.
https://bugzilla.gnome.org/show_bug.cgi?id=696882
We don't want to remember sizes in the not resizable case. Also a
function named "guess_default_size" should not look at previous sizes,
it should guess.
Old code assumed the size was stored in widget.allocation. This is no
longer true as the allocation is cleared upon hide. However, we store
the last configure request, and that one tracks the last size, so we can
just use that number.
Sometimes things are so easy - once you figure them out...
https://bugzilla.gnome.org/show_bug.cgi?id=696882
