This patch introduces support for using the newly introduced
monitor objects in the XRandR protocol. These objects are meant
to be used to denote a set of rectangles representing a logical
monitor, and are used to hide details like monitor tiling and
virtual gpu outputs.
This uses the new objects instead of crtc/outputs objects when
they are available to create the monitor lists. X server 1.18
is required on the server side for randr 1.5.
https://bugzilla.gnome.org/show_bug.cgi?id=749561
Load themed cursors from the same places they are loaded on freedesktop systems,
but use W32 API functions to do so (works for .cur/.ani cursors instead of X
cursors).
Refactor the code for cursor handling. Prefer loading cursors by name.
Do not load actual cursors when loading the theme. Find the files and remember
the arguments/calls for loading them instead. Keeping HCURSOR instance in the
hashmap would result in multiple GdkCursors using the same HCURSOR. Given that
we use DestroyCursor() to off them, this would cause problems (at the very
least - DestroyCursor() would fail).
Store GdkCursor instances in a cache. Update cached cursors when theme changes.
Recognize "system" theme as a special (and default) case. When it is set,
prefer system cursors and fall back to Adwaita cursors and (as a last resort)
built-in X cursors. Otherwise prefer theme cursors and fall back to system and
X cursors.
Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes
it use the system default "arrow", which is not the intended behaviour when
a non-system theme is selected.
Ignore cursor size setting and query the OS for the required cursor size, as
Windows (almost) does not allow setting cursors of arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=749287
In particular this means that cursors are disposed of by the way of
g_object_unref(), not DestroyCursor (which is documented to not to be
used on certain kinds of cursors, and we can't tell which is which).
It should also alleviate any concerns about destroying cursors that
are still in use by other windows, except for cases where we would
somehow get our hands on a HCURSOR that someone else is using and we
make a GdkCursor out of it and later unref and finalize it while it
is still in use.
It also removes the need to call CopyCursor(), which makes animated
cursors into non-animated ones as a side-effect (supposed to be a bug,
but try explaining that to MS). Now cursors should be animated (if
the are set up as such in the OS).
https://bugzilla.gnome.org/show_bug.cgi?id=697477
Some features need certain globals to initialize. In order to deal with
these dependencies, add a way to postpone closures that depend on a
certain set of globals, that later will be invoked when required
globals are all received.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Instead use asynchronous round trips that is synchronized in the end of
the initialization. This makes it easier to track state, as we won't
dispatch arbitrary Wayland messages while processing globals.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Only "wait" and "all-scroll" are not implemented properly. OS X does not
seem to have a proper interface to either cursor. Approximations are used
instead; see the code.
See bug 749178.
The ordering of globals in connection setup under weston
is different from mutter, and we end up creating a the
dnd window before any outputs are present. Don't cause
a critical warning in that case.
Even when the program itself calls gdk_set_program_class(). There's
currently no way for this function to be called without breaking gdk's
--class command line option, because you cannot call it before
gtk_init().
https://bugzilla.gnome.org/show_bug.cgi?id=747634
This is purely to support gdk_cursor_new_from_name().
In particular, its counterpart, gdk_cursor_new_for_display(), will not
be affected, because there's no GDK_LEFT_PTR_WATCH cursor type,
and because i don't have a fallback cursor bitmask for gdk/win32/xcursors.h
We interpret buttons 4-7 as old-school scroll events, so it does
not make sense to add these to the mask. Also fix an off-by-one
in the loop here, buttons_mask is 1-based.
We now have proper checks for gdk_screen_is_composited() and a proper
implementation for gdk_screen_get_rgba_visual() for Windows, so we
can remove the comments in this file stating that they aren't
available for Windows.
I was getting really weird values for scale for the blank cursor used
when hiding the cursor in a GtkEntry when typing, this was caused
by gdk_wayland_device_update_window_cursor sending random values
when the returned buffer was NULL.
We fix this by just not sending any buffer or scale updates in this
case.
Requires Vista and newer.
* Create surfaces with cairo_win32_surface_create_with_format
* Provide an rgba visual that can be distinguished from the system visual
* Make rgba visual the best available visual
* Enable alpha-transparency for all windows that we control
* Check for appropriate cairo capabilities at configure time
(W32 - 1.14.3 newer than 2015-04-14; others - 1.14.0)
* Check for composition support before enabling CSDs
* Re-enable transparency on WM_DWMCOMPOSITIONCHANGED
Windows that were created while composition was enabled and that were CSDed
as a result and will look ugly (thick black borders or no borders at all) once
composition is disabled.
If composition is enabled afterwards, they will return back to normal.
This happens, for example, when RDP session is opened to a desktop where a GTK
application is running. For W7/Vista windows will only re-gain transparency after
the RDP session is closed. For W8 transparency will only be gone momentarily.
Windows that were created while composition was disabled will not be CSDed
automatically and will use SSD (WM decorations), while windows that are CSDed
manually will get a thin square border.
If composition is enabled afterwards, these windows will not change.
This is most noticeable for system menus (popup menus are often generated
on the fly, system menus are created once) and some dialogues (About dialogue,
for example).
https://bugzilla.gnome.org/show_bug.cgi?id=727316
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
Add two new requests to the gtk_surface interface: set_modal and
unset_modal. The server will currently not do anything special with
input focus, and its up to the client to ignore events on the parent
surface.
This commit bumps the gtk_shell interface version to 2. By connecting to
a Wayland server with another gtk_shell interface version any features
depending on the gtk_shell protocol will not be available.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
cairo_rectangle_int_t was replaced by GdkRectangle in commit
552c29b488, but the type of the pointing-to
property was not changed.
To avoid breaking old code that sets or gets the property with a GValue
of type CAIRO_GOBJECT_TYPE_RECTANGLE_INT, transformation functions between
CAIRO_GOBJECT_TYPE_RECTANGLE_INT and GDK_TYPE_RECTANGLE are registered on
the first call to gdk_rectangle_get_type().
https://bugzilla.gnome.org/show_bug.cgi?id=723394
gdk_wayland_drop_context_set_status() can't do much else currently besides
picking a mimetype (the first one is currently chosen). This may incorrectly
unset the mimetype chosen on .receive(), so the transfer is cancelled before
it even starts.
At the time drop_reply happens, we should have already picked a mimetype
along the way, so only cover for accepted=FALSE in order to unset it.
During drag operations from another client, we currently set no window as
the DnD source. There's paths in upper layers though that rely on it being
set, just that we don't trigger these yet.
This reverts commit 24d3f3fcb2.
Sorry, I am going to re-commit this very shortly with a new
commit message, as I found the commit message to be quite
wrong and misleading.
The current GdkScreen->is_composited() is a stub as we were having Windows
XP being supported, which does not support Desktop Window Manager (DWM),
which is used by Windows for composition.
Windows Vista and later support DWM, and it is always enabled on Windows 8/
Server 2012 and later.
Please note that as we are dropping XP support in this cycle, this is the
commit that would say goodbye to Windows XP support for GTK+-3.x, by
linking directly to dwmapi.dll. This means, we only check whether we are
on Windows 8 or Server 2012 (or later) to see whether we unconditionally
have composition enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=741849
XSetWindowBackgroundPixmap() will throw BadMatch only in the case of a
different parent window depth. Different visuals are fine and actually
expected in Gtk+ 3.16 (since we don't stick to the system default visual
but try to pick a better one).
https://bugzilla.gnome.org/show_bug.cgi?id=747524
