The filters now return TRUE/FALSE and no longer a GdkFilterReturn. They
also don't conform to the GdkFilterFunc typedef anymore but instead take
the arguments that they need.
This is not needed because GTK must be run in the main thread these days,
which is the same one that runs the main loop. So when this function is
called, the main loop is awake.
https://bugzilla.gnome.org/show_bug.cgi?id=550989
This uses the new method without GDK_ACTION_ASK:
Either it is a single action (queryable via gdk_drag_action_is_unique())
or it is not and then the drop target has to make a decision
(potentially by asking someone).
The ultimate goal of this patch series is to split GdkDragContext into
GdkDrop + GdkDrag classes for the destination and source side of a dnd
operation.
The refactoring is meant to work something like this:
1. Introduce GdkDrop as a base class
2. Make all drop related code (like GdkEvent) use GdkDrop instead of
GdkDragContext. Move/duplicate APIs to allow that.
3. Port all drop contexts in the backends from GdkDragContext to GdkDrop
4. Delete all APIs in GdkDragContext that aren't needed anymore.
5. Make GdkDragContext no longer a GdkDrop subclass
6. Rename GdkDragContext to GdkDrag
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
According to the old new thing[0], we should use the instance handle
of the GDK/GTK DLL when registering GDK-specific types in the system.
Using the instance handle for the whole application in these circumstances
is not an error, but can potentially clash with the types registered
by the application itself.
Also, extract window class icons from the GDK/GTK DLL, not from the
application executable.
[0]: https://blogs.msdn.microsoft.com/oldnewthing/20050418-59/?p=35873
The argument is eventually passed to g_conv(), so it should
be the charset, not the mime/type. Without this change the
contentype converter will fail to convert UTF-8 strings to, say,
CP-1251 later on.
Includes implementation for Wayland and X11, which are the only backends
implementing the Startup Notification Protocol, returns NULL otherwise.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
Similar to what has been done recently for DESKTOP_AUTOSTART_ID [1],
we need to get rid of this call to g_unsetenv() in the displays'
backends for X11 and Wayland, so that it's guarantee to happen any
thread is created, while still being accessible when needed.
Let's stash the value of this environment variable when loading the
GDK library, and provide a private method so that it can be retrieved
from the displays' backend when implementing gdk_display_make_default().
[1] https://gitlab.gnome.org/GNOME/gtk/commit/22269902
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/979
It's quite old, but mostly harmless (both "message == WM_KEYUP"
and "message = WM_KEYUP" evaluate to not-FALSE, and message
value is not used after that line).
The check survived from GTK2 when that function could still return
GdkPixmap and GdkFont objects and was accompanied by this comment:
/* We may receive events such as NoExpose/GraphicsExpose
* and ShmCompletion for pixmaps
*/
This is the API used by GtkMenu to properly position menus on the screen
without requiring GTK to query the menu window's position or the work
area of where the window is positioned. It makes it possible to position
popup windows properly when using Wayland.
Make this API available to external users so custom popup windows can be
positioned properly as well.
Related: https://gitlab.gnome.org/GNOME/gtk/issues/997
Application is not expecting that.
Bug found due gdk_seat_grab() failure on Lock Screen. When user
Unlock the screen, the application is visible but does not receive
enter-event any more on X11/GNOME.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1485968
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1571422
Signed-off-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab surface,
so if the grab is issued on a child gdk surface, those won't match and
we would emit more focus_out events than focus_in.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the surface and releases the grab when it
leaves the surface would get uneven numbers of focus_in/focus_out
events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native surfaces to emit crossing events when needed that
get called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk
_wayland_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Closes https://gitlab.gnome.org/GNOME/gtk/issues/792
Instead of tracking offers in GdkWaylandSelection objects, track the
pending offer in the GdkWaylandSeat and pass it to the GdkDragContext
once we get an enter event.
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
Broke up a long line, added an empty one, indented another one, and re-aligned
a large amount of function parameter names that got misaligned in some past
refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
This commit adds support the stable version of the xdg-shell protocol.
Support for the last version of the unstable series is left intact, but
will not receive new features.
The stable version is prioritized above the older version.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
Now that all Cairo contexts are ported to managing cairo surfaces
themselves, the old fallback code that didi the managing is no longer
needed.
Also clarify the behavior of gdk_cairo_context_cairo_create() wrt the
vfunc by doing the early exit and the clipping outside of it.
* Remove DC refcounting (we trust GDK to always do
begin_frame/end_frame calls in pairs)
* Now that there's no GDK-provided double-buffer up the stack,
double-buffering is implemented here
(though it's disabled by default - in my tests it didn't provide
any visual improvements, but did decrease performance).
* For some reason delaying window resizes until the point where
we need to blit the double-buffer into the window leads
to visual glitches, so doulbe-buffered windows are resized
in begin_frame, same as non-double-buffered ones.
* New code to clear the paint region, for all drawing modes.
Hopefully, it isn't duplicated anywhere up the stack.
* GL has its own context now, so remove any GL-related comments.
* Layered windows are still used (because cairo actually works
better with them)
* A bit more code re-use for layered windows
* Some functions that were local to gdksurface-win32.c are made
usable for the whole backend
* Drag-indicator drawing is temporarily commented out to match
a similar change in X11 backend
We used to pass 2 regions to GdkDrawCotnext.end_frame() but code was
confusing what they meant. So we now don't do that anymore and only pass
the region that matters: The frame region.
This makes the previous gdk_draw_context_is_drawing() function public
under a new name.
I decided against the old name because we use the term "frame" for a
drawing operation, so I wanted to have this boolean flag reuse the term.
As they require a draw context and the draw context is already bound to
the surface, it makes much more sense and reduces abiguity by moving
these APIs to the draw context.
As a side effect, we simplify GdkSurface APIs to a point where
GdkSurface now does not concern itself with drawing anymore at all,
apart from being the object that creates draw contexts.
Also, split it into its own file - which was the original reason for
looking at this code, the rewrite was an unintentional side effect.
This changes the context to create surfaces on demand.
So whenever the compositor holds onto a surface while GDK wants to
render, it just creates a new surface. If the compositor releases
surfaces, we will retain one for the next frame to be rendered, but free
all extra ones.
This way, we should get to a stage where we have exactly as many
surfaces as needed and never allocate/free any.
Also, don't implement SurfaceClass.ref_cairo_surface() anymore. This
means calls to it will crash now. But as they only happen in the generic
GdkCairoContext implementation, we shouldn't be affected by that.
Plus, once all backends have been ported, that call is going away
anyway.
