This is necessary to give back focus to the Broadway elements when
content is embedded in an IFrame.
Signed-off-by: Mickael Istria <mistria@redhat.com>
The @filename@ directive will use the full path of the file being parsed
for enumeration types; we should use @basename@, instead, as it improves
the reproducibility of the build by using only the file name.
Some of the flags got lost in the meson transition or were demoted from
error flags to warning flags.
This commit reintroduces them.
It also includes fixes for the code that had warnings with those flags.
The big one being -Wshadow.
Setting it as qdata on the object doesn't save any memory since we use
the user_data as the event target, which every event has set these days.
This way is also faster since just reffing the object doesn't do any
locking.
g-ir-scanner incorrectly evaluates macro definition that include
references to other macro definitions. Provide a correct value as an
annotation.
Differences in generated gir files:
```diff
@@ -19017 +19017 @@
- <constant name="PRIORITY_REDRAW" value="20" c:type="GDK_PRIORITY_REDRAW">
+ <constant name="PRIORITY_REDRAW" value="120" c:type="GDK_PRIORITY_REDRAW">
@@ -74229,3 +74229,3 @@
</constant>
- <constant name="PRIORITY_RESIZE" value="10" c:type="GTK_PRIORITY_RESIZE">
+ <constant name="PRIORITY_RESIZE" value="110" c:type="GTK_PRIORITY_RESIZE">
<doc xml:space="preserve">Use this priority for functionality related to size allocation.
@@ -106786,3 +106786,3 @@
<constant name="TEXT_VIEW_PRIORITY_VALIDATE"
- value="5"
+ value="125"
c:type="GTK_TEXT_VIEW_PRIORITY_VALIDATE">
```
See !472
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
(See !436 for the original MR)
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
See !426 for the gtk3 MR
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
See !437
Build the .rc files for Windows so that one can track the version info
more easily for Windows, as well as giving GTK+ apps a default icon.
Also, move back the manifest embedding for the themed Windows print
dialog back into gtk-win32.rc.body.in, so that we just have one way of
embedding this manifest file, making things easier for ourselves, as
this is supported in the later Visual Studio compilers as well, which is
2013 and later.
As per the spec:
> The back buffer can
> either be reported as invalid (has an age of 0) or it may be
> reported to contain the contents from n frames prior to the
> current frame.
So a buffer age of 1 means that the buffer was used in the last frame.
We were handling buffer_age==1 the same as buffer_age==0, i.e. we
returned the full damage for the surface.
[1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
When we decide to fall back because the settings portal
is not present, adhere to that decision elsewhere. And
treat the fontconfig-timestamp like the other special-cased
settings, with G_TYPE_NONE.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
As GSettings now supports session-specific defaults, GNOME Classic
no longer uses a separate schema and the decoration layout is always
determined by the regular schema.
This essentially reverts commit add67b516c (although the code was
moved since then).
https://gitlab.gnome.org/GNOME/gtk/merge_requests/400
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows us to
convert any supported image to BMP or PNG, and therefore we should
announce that we always provide/accept BMP and PNG along with other
formats.
But that's not how it works. GDK has built-in serializers and
deserializers for all pixbuf formats (where it just invokes GdkPixbuf
API) and will use them automatically to read or write GdkTexture
objects (internally wrapping GdkPixbuf objects where necessary). The
encoding and decoding of images is handled
by GdkContent(De)Serializers, backend has nothing to do with it.
Therefore W32 GDK backend should only offer formats that it can
actually do conversion for by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
This leverages the normal input context switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input context
switching code, which, not being able to create the desired context
(which is and empty string), falls back to looking at current
keyboard layout (currently that code is still a FIXME).
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of switching to
the appropriate IM context at runtime. At least, the kinds of context
that specify languages for which they are used automatically by default
(once locale matching is implemented), and the IME context.
Loading other kinds of IM context might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of using the IME context that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit d64467b334 changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
GLib master propagates argument types in g_clear_pointer(), which causes
the usual function pointer casts to GDestroyNotify to trip compiler
warnings. Additionally, this commit changes some cleanup functions where
appropriate (wl_data_source_destroy ->
gtk_primary_selection_source_destroy for struct
gtk_primary_selection_source).
GtkEntryCompletion can rapidly release and claim ownership of the
primary selection. This generates multiple XFixesSelectionNotify events,
first stating that no one owns the selection, then another stating that
we own the selection. The notification that no one owns the selection
causes GtkEntryCompletion to deselect the text, breaking inline
autocompletion.
This fixes it by ignoring any XFixesSelectionNotify with a timestamp
earlier than our clipboard timestamp.
Fixes#14
file_uri_deserializer splices a memory stream, as opposed to
string_deserializer, which uses a converter and filter stream. This
commit fixes erroneous use of GMemoryOutputStream as
GFilterOutputStream.
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
Change GdkDrag::action to GdkDrag::selected-action, which is
more clearly different from actions, and follows the existing
name of the struct field and getter.
This lets us drop the ::action-changed signal for the
property change notification. But, can just as well move
the signal class handers which just update the cursor
to the ::action setter. No need to do this in the backends.
Rename gdkdnd.h to gdkdrag.h, to go along with gdkdrop.h
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
Also update the cursor surfaces of every seat when an output changes
scale. This could for example happen when a monitor scale is changed via
Settings.
This functionality is similar to Linux's memfd. It creates anonymous shared memory without touching the filesystem, which allows it to work in Capsicum capability mode (sandbox).
* There's no GdkDragContext->dest_surface anymore.
Add dest_window field to GdkWin32DragContext,
and use that instead.
* Remove unused function prototypes
* Add more comments
* Rename variables and fields from 'window' to 'surface'
where appropriate
* Fix header indentation a bit
* Try to ensure that uninitialized/unknown handle variables
and fields are set to INVALID_HANDLE_VALUE instead of NULL,
as there may be cases where NULL is a valid handle value.
This might be foreign Windows and we don't want to create surfaces for
those.
Also, stop using GdkDragContext.dest_surface, that variable is meant to
go away.
In particular, this patch removes:
gdk_surface_get_events()
gdk_surface_set_events()
gdk_surface_get_device_events()
gdk_surface_set_device_events()
Event masks so far still exist for grabs.
GdkDragContext => GdkDrop
This is all in preparation of separation of the drag and drop.
Also, don't check for GDK_DRAG_PROTO_XDND anymore - it's the only
possible value for the protocol on the target side.
Use the new method of connecting to the xevent signal instead.
Also, don't consume the xevent, there might be other code listening for
it. And we don't use PropertyNotify in the generic code path anymore, so
it'll just be ignored there.
* Remove clipdrop->dnd_target_state, it's not used anymore
* Remove non-functioning _gdk_dropfiles_store(), store dropfiles
list in GdkWin32Drop instead
* Fix multiple comment typos
* Fix _gdk_win32_get_clipboard_format_name_as_interned_mimetype() to
leave names that look like mime/types alone
* Refactor _gdk_win32_add_w32format_to_pairs() to populate
GdkContentFormatsBuilder directly, instead of making a GList
* Rename context -> drag (still using GdkDragContext type,
but [almost?] all variables and comments say "drag" now)
* Rename GdkDropContext -> GdkDrop
* Rename some parameter names for clarity
* Rewrite local protocol to look more like OLE2 protocol
instead of mirroring the structure of the X11 API.
* Add handle_events field to GdkWin32DragContext,
to shut off event handling (temporary fix until GTK is patched up)
* Remove _gdk_win32_drag_context_find() - the drag object is stored
in GdkDrop instead. Use _gdk_win32_find_drag_for_dest_surface()
to get it initially.
* Remove target_ctx_for_window, droptarget context is stored
in the surface instead.
* Call gdk_drag_context_set_cursor() just like wayland backend does
(slightly broken for now)
* Clean up the action choosing code (filter source actions by using
keyboard state, pass that to GTK, get all actions supported by GTK in
response, match them up with filtered source actions, return the
result, falling back to COPY in case of multiple actions)
* Check drag_win32->protocol instead of the use_ole2_dnd variable where
possible
* Remove protocol checks from functions that are only used by the local
protocol
* Use event state to manufacture the keyboard state for WM_MOUSEMOVE
* Change function names printed by GDK_NOTE to name the actual
functions, not their theoretical generic GDK stack ancestors
* Consistently use drag_win32 and drop_win32 variables instead of a mix
of that and win32_drag/win32_drop
* Return FALSE from button handler to ensure that GTK gets the button
event to break implicit grab
* Emit leave event on failed idroptarget_drop() calls
Instead of looking at the list of contexts, just look at the current
drop context. There is only one, after all.
Then remove the is_source argument from gdk_drag_context_find().
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
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip appearing for a non-foreground surface, causing said surface to rise
above other surfaces, some of which maybe foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
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.
And make the GdkCairoContext as abstract.
The idea of this and thje following commits is to get rid of all
Cairo code in gdksurface.c (and $backend/gdksurface-$backend.c)
by moving that code into the Cairo context files.
In particular, the GdkSurfaceClass.begin_frame/end_frame()
functions (which are currently exclusively used by the Cairo code
should end up being moved to GdkDrawContextClass.begin/end_frame().
This has multiple benefits:
1. It unifies code between the different drawing contexts.
GL lives in GLContext, Vulkan in VulkanContext and Cairo in
CairoContext. In turn, this makes it way easier to reason about
what's going on in surface-specific code. Currently pretty much
all backends do things wrong when they want to sync to drawing
or to the frame clock.
2. It makes the API of GdkSurface smaller. No drawing code (apart
from creating the contexts) needs to remain.
3. It confines Cairo to the Drawcontext, thereby making it way
more obvious when backends are still using it in situations
where it may now conflict with OpenGL (like when doing the dnd
failed animation or in the APIs that I'm removing in this
branch).
4. We have 2 very different types of Cairo contexts: The X/win32
model, where we have a natively supported Cairo backend but do
double buffering ourselves and use similar surfaces and the
Wayland/Broadway model where we use image surfaces without any
Cairo backend support and have to submit the buffers manually.
By not sharing code between those 2 versions, we can make the
actual code way smaller. We also get around the need to create
1x1 image surfaces in the Wayland backend where we pretend
there's a native Cairo surface.
This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.
The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
We can't freeze the frame clock on commit, but only after-paint,
otherwise the frameclock will resume in the paint stage.
So freeze the frame clock at the end of the frame if we are waiting for
a frame callback.
Note; The diff is only lage because of indentation changes due to
avoiding early returns in favor of a branch.
Instead of going through an ancillary script to strip away the
`WL_EXPORT` annotation from the generated code, we should bump up the
required version of Wayland, and use the `private-code` argument for
wayland-scanner, which does the right thing for us.
* Previous commit had misleading info. The code was
added to begin_paint() instead of end_paint(). Though
that did not affect its performance in any visible way.
* Company advised to move the code to an "after_paint" signal
handler, so that it works on all renderers, not just Cairo.
This change caused high fluctuation in FPS values in fishbowl
when it is put in a situation where it cannot achieve 60fps
(such as using Cairo renderer at ultra-high resolution).
This seems to be deliberate and not a bug.
There is no easily apparent way of being notified when frame updates
happene exactly, so we just query frame info at the end of each paint.
If we query too often (faster than DWM refresh rate), we just get
the same values twice in a row, but that is, hopefully, highly unlikely.
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.
That way, we can store the right region there: The actual painted area
instead of the exposed area (which is way too small).
Also, the GL context is the only user of this data, so storing it there
seems way smarter.
This error message is printed into the journal if a GTK app can't
connect to eithre Wayland or X11. Make it at least mention who is not
capable of connecting to a server.
Unrelated, we might want to improve our error reporting when a GTK app
can't start, so that debugging issues with system startup / login get
easier to resolve.
Instead of calling gdk_surface_invalidate_region(), just
gdk_surface_queue_expose() and rely on the renderer computing the diff
from the previous rendering.
This ensures that the frame clock gets updated with correct presentation
times even if nothing was drawn.
This is necessary for benchmarking but would also be relevant for videos
that want to sync to the frame clock but draw frames a lot less.
This commit ensures that each GdkSurface impl remembers the
cursor that GDK sets for it, and that this cursor is set
each time WM_SETCURSOR is called for that sufrace's HWND.
This is needed because W32, unlike X, has no per-window cursors -
the cursor on W32 is a global resource, and we need to keep track
of which cursor should be set when pointer is over which surface
ourselves (WM_SETCURSOR exists exactly for this reason).
This commit also makes GDK remember the surface that has an implicit
grab (since implicit grabs are gone from the upper levels of the toolkit),
and ensures that crossing events are correctly synthesized and the grab
is broken when surface focus changes. This fixes a bug where opening
a new window (by clicking something in some other, pre-existing window)
will make that new window not get any mouse input due to the fact
that the mouse-button-down event from that click caused an implicit
grab on the pre-existing window, and that grab was not released afterward.
Instead of now-unused GdkWin32Cursor class (a subclass of GdkCursor),
add a stand-alone GdkWin32HCursor class that is a wrapper around
HCURSOR handle.
On creation it's given a display instance, a HCURSOR handle and a boolean
that indicates whether the HCURSOR handle can or cannot be destroyed
(this depends on how the handle was obtained).
That information is stored in a hash table inside the GdkWin32Display
singleton, each entry of that table has reference count.
When the GdkWin32HCursor object is finalized, it reduces the reference
count on the table entry in the GdkWin32Display. When it's created,
it either adds such an entry or refs an existing one.
This way two pieces of code (or the same piece of code called
multiple times) that independently obtain the same HCURSOR from the OS
will get to different GdkWin32HCursor instances, but GdkWin32Display
will know that both use the same handle.
Once the reference count reaches 0 on the table entry, it is freed
and the handle (if destroyable) is put on the destruction list,
and an idle destruction function is queued.
If the same handle is once again registered for use before the
idle destructior is invoked (this happens, for example, when
an old cursor is destroyed and then replaced with a new one),
the handle gets removed from the destruction list.
The destructor just calls DestroyCursor() on each handle, calling
SetCursor(NULL) before doing that when the handle is in use.
This ensures that SetCursor(NULL) (which will cause cursor to disappear,
which is bad by itself, and which will also cause flickering if the
cursor is set to a non-NULL again shortly afterward)
is almost never called, unless GTK messes up and keeps using a cursor
beyond its lifetime.
This scheme also ensures that non-destructable cursors are not destroyed.
It's also possible to call _gdk_win32_display_hcursor_ref()
and _gdk_win32_display_hcursor_unref() manually instead of creating
GdkWin32HCursor objects, but that is not recommended.
Add a new W32 backend-specific message filtering mechanism.
Works roughly the same way old event filtering did, but without
events (events are GDK/X11 concept that never really made sense
on W32), so there's no functionality for 'altering' events being
emitted. If an event needs to be emitted in response to a message
do it yourself.
Implemented like this, it should give better performance than
if we were to use GLib signals for this, since W32 sends a LOT
of messages (unlike X11, which doesn't send events as often)
all the time, and invoking the signal machinery on *each* message
would probably be bad.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection
is mostly gone, and the word "selection" does not reflect the
functionality of this object too well.
Clipboard is now handled by a separate thread, most of the code for
it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses
clipdrop as a backend.
The DnD source part is also put into a thread.
The DnD target part does not spin the main loop, it just
emits a GDK event and returns a default value if it doesn't get a reply
by the time the event is processed.
Both clipboard and DnD use a new GOutputStream subclass to get data
from GTK and put it into a HGLOBAL.
GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext,
anticipating a similar change that slated to happen to GdkDragContext.
OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0
to make GDK use the old LOCAL and DROPFILES protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
With the previous approach we would spend most of the time waiting for
the swapchain to be filled again because it seems the compositor takes
care of 2 images at once from time to time.
This is not visible in profiles because waiting for a frame is a
read/poll/whatever operation that does not take CPU. It's only
noticeable because the app becomes less responsive.
If G_ENABLE_CONSISTENCY_CHECKS is defined (i.e. if our buildtype is
'debug'), add a opengl debug callback that prints all debug messages
with a severity higher than SEVERITY_NOTIFICATION as a warning to the
console.
Set the display for each event that we put.
Also reorganize the dnd_event_put() function a bit, giving it a surface
directly instead of setting it by implication.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
dest_surface is going to always be NULL for source contexts.
Previously we used to put the root window there to pass this check,
but root windows are gone (and root surfaces never existed to begin
with), so we have to adapt.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
This affects gdk_device_query_state() for the virtual device. It has
no window, and is forced to query the display itself, and display
defaults its scale to 1 even for HiDPI desktops. Use the same
"query scale of a NULL monitor" trick that we use in other places
to get the global desktop scale.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
A side effect of vkQueuePresentKHR is the Vulkan implementation calling
wl_surface_commit() on the corresponding Wayland surface. Thus, before
this, we must synchronize the surface state (e.g. opaque region, window
geometry, etc) that changed since last time. Prior to this commit this
was done after calling vkQueuePresentKHR(), causing the surface state to
always correspond to the previous buffer state. As of this commit this
is now done before calling vkQueuePresentKHR(), thus before
wl_surface_commit().
A side effect of eglSwapBuffers* is the EGL implementation calling
wl_surface_commit() on the corresponding Wayland surface. Thus, before
swapping buffers, we must synchronize the surface state (e.g. opaque
region, window geometry, etc) that changed since the last buffer swap.
Prior to this commit, this was done after eglSwapBuffers*, causing the
surface state to always correspond to the previous buffer state. As of
this commit this is now done before swapping the buffers, thus before
wl_surface_commit().
If you want transparent region, you can just render them transparent.
If you want input shaping, use gdk_surface_input_shape_combine_region().
Also remove gtk_widget_shape_combine_region().
