Otherwise the icon "jumps" to the cursor position with its top left when
the animation starts.
This is especially visible if the dragged item is big, like when dragging
mails in Thunderbird.
With some GL drivers, it may be the case that menus are not shown
correctly in fullscreen GL windows because DWM is deactivated in the
process.
Force WS_BORDER to be applied to the fullscreen GL window so that we have
a small 1px border when needed (by setting an envvar), so that DWM does
not get deactivated, hence enabling the menus to show. Also, when we
force WS_BORDER to be applied in this situation, we also deliberately
place the window just outside the top lefthand corner of the screen by
1px and make the window 1px larger than the screen size, so that we
effectively hide the 1px border from view.
Fixes issue #1702.
We also need to force redraw of the whole window when we are using
EGL/ANGLE during un-fullscreen, so that we do not get glitches in the
resulting window.
_gdk_win32_display_convert_selection() does not return anything,
it generates a selection notify event instead. Depending on how
successful it was, the event will have property=GDK_NONE or
property="GDK_SELECTION".
property="GDK_SELECTION" is the default return value for successful
cases, and it tells GTK to grab the data that GDK previously deposited
using selection_property_store().
The problem is that the clipboard branch of this function calls
open_clipboard_timeout(), which can't return anything meaningful (it's
normally a timeout function), and thus doesn't know whether the function
succeeded or failed. Due to my oversight, this resulted in GDK
generating two selection notification events - one from inside of
open_clipboard_timeout() (with the right property, if successful),
and one from the catch-all last line (always defaulting to "GDK_SELECTION").
This caused issue #2223, where GTK only expected exactly one
notification per request, and got confused because it was getting two.
I've looked at the code in open_clipboard_timeout(), and it seems to me
that it always generates a notification (a successful one or an
unsuccessful one). Thus the branch of the function that calls it
directly does not need to follow up with a catch-all notification and
can just return.
This seems to be fixing issue #2223, at least for me, but i'm not
entirely sure that this will not have any adverse side-effects.
Clipboard handling in GTK3 is a complicated mess.
Instead, use the standard library().
This is a meson best practice.
Fixes#2248.
Fixes -Ddefault_library=static not having any effect.
Cherry-Picked-From: bb9c07d8fe
It can be tricky to deal with both, so let's give an example of using
both gdk_event_get_scroll_direction() and gdk_event_get_scroll_deltas().
Closes: #2048
For page up/down events (Fn+up_arrow and Fn+down_arrow on macOS)
gtk_im_context_filter_keypress() currently returns TRUE when im-quartz is
used. This means these events get removed when this function is used
(happens e.g. with the Scintilla text editing library).
Adding scrollPageDown: and scrollPageUp: into GdkQuartzView seems to
resolve the issue as these seem to get called instead of the already
present pageUp: and pageDown:.
We are interested in changing the owner window, so the upper bits know
that it is not this client who owns the selection. We are still not
interested in unsetting the selection desktop-wide though, so only avoid
emitting the relevant events then.
The same reasonings than in commit 7a891eeb6d apply otherwise.
Use RemoveClipboardFormatListener() and AddClipboardFormatListener().
These APIs remove the need for us to maintain the integrity of the
clipboard chain, which turned out to be problematic for some reason
that is yet to be identified.
Fixes#2215Fixes#442
This should just be called by the upper layers (and result in
wl_data_device.set_selection, etc). We should not trigger this within
the backend otherwise.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
This should only be explicitly unset (face to the windowing) on
gdk_selection_owner_set() with a NULL window. Other circumstances
(eg. selection being taken over by another client) should just
trigger the SelectionClear event in GDK internally.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/878
The event may end up freed after delivery, ensure to keep the data we need
in order to emit the matching emulated crossed event matching a proximity
event.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
The code managing this accounting mixed seat and tablet output lists,
can't bode well. Fixes invalid reads on list elements, as there are
dangling pointers.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
This reverts commit 6d545b6d03.
Reverting as this broke multi DPI systems, where a client is expected to
render at scale = 1 if it is only visible on a scale = 1 monitor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2129
The xdg_output.done event is deprecated in xdg-output v3, so clients
need to rely on the wl_output.done event instead.
However, applying the changes on the fist wl_output.event when using
xdg-output v3 may lead to an incomplete change, as following xdg-output
updates may follow.
Make sure we apply xdg-output events on wl_output.done events with
xdg-output v3.
https://gitlab.gnome.org/GNOME/gtk/issues/2128
I was not getting any gtk+ profile markers output from the frame clock
when I was profiling an OpenGL app (gnome-hexgl). I debugged this and
it turns out that the profiling depends on getting the _NET_WM_FRAME_TIMINGS
event from the compositor, and once we switched to OpenGL rendering
this never appeared.
It turns out the reason it didn't is that the compositor only does
so if the client increases the counter tied to the window, and the
x11 gdk code has this optimization where if we do a draw pass
but nothing is actually drawn we don't update the counter.
Unfortunately the detection of whether something was draw or not
is based on some cairo surface hack that breaks when we render with
OpenGL instead. The fix is to just always update the counter if
we're drawing with OpenGL.
This was added with https://bugzilla.gnome.org/show_bug.cgi?id=148032
to make gtk compile against X11R5, see commit 3b9a31df0
That release is >20 years old now, so we can safely remove it.
The motivation for this is to remove any checks that we don't have in the
meson build.
This fixes an issue where stylus proximity in/out events emulate enter/leave events.
The emulated events didn't contain the correct slave device and therefore the
resulting device class was set incorrectly. Crossing event emulation now also
works with slave devices.
Closes#2070Fixes#2070
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2070
We clamp to 32767 when creating a new X11 GdkWindow due to larger sizes
not being supported, but still try to resize to larger when
gdk_window_resize() is called. Fix this by clamping in both places.
This fixes an issue in mutter where ridiculously sized Java windows
would not show up.
The current code only goes through the output associated to the
window's wayland surface enter/leave events. That means that to update
the scale factor the window only looks at the outputs on which it
received enter/leave events. That doesn't include a new monitor
connected to the system on which the window might be display next.
The spirit of the existing logic seems to be to go through all the
scale factor available on the current monitors of the system and pick
the highest. So fix the current behavior by looking at the monitor on
the display.
Fixes#1144.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
This idle happens on mutter around the x11 display being closed, which
has it running after it did actually happen. Ensure the window removes
this idle on dispose.
xdg-output v3 marks xdg-output.done as deprecated and compositors are
not required to send that event anymore.
So if the xdg-output version is 3 or higher, simply set the initial
value `xdg_output_done` to TRUE so we don't wait/expect that event
from the compositor.
https://gitlab.gnome.org/GNOME/gtk/issues/2053
If a client issues a `move_resize()` request while the window is
maximized or fullscreen, update the saved size for when it will be
unmaximized/unfullscreened
Related: https://gitlab.gnome.org/GNOME/gtk/issues/1044
This signal was not being emitted on macOS, a bug introduced in 941f3c38.
`emit_monitors_changed` was never set to TRUE, so the signal was never
emitted. `emit_monitors_changed` has now been removed, because its
functionality was moved to GdkDisplay.
In addition, kCGDisplayDesktopShapeChangedFlag was removed from the list of
flags that indicate a new/reconfigured monitor, because monitor removals also
include this flag, which caused removed monitors to not be removed from
GdkDisplay.
Fixes#2004.
Previously, the manufacturer property of the GdkMonitor was NULL,
and having at least PNP id at GdkMonitor.manufacturer makes it
possible to distinguish between different monitors programmatically.
open() in text mode should never be used without an encoding because it defaults
to the locale encoding which is rarely what is wanted.
This fixes the Windows build in some cases (depending on the locale/paths used)
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1737
Don't export any functions taking or returning MacOS types in
gdkquartz.h, gdkprivate-quartz.h, or any header that either includes.
The GdkQuartz internal functions are moved to a new header
gdkinternal-quartz.h, the functions used by quartz-specific
Gtk files are moved to another new header gdkquartz-gtk-only.h, and
the key and event enums to a new header gdkkeys-quartz.h.
The xdg_output interface has a `name` property that reflects the output
name coming from the compositor.
This is the closest thing we can get to a connector name.
Fixes: #1961
The documentation for get_monitor_plug_name() says that we're returning
the name of the connector for the monitor, but we switched it to using
the model name.
The migration from GdkScreen's monitor API to GdkMonitor left out a way
to get the connector's name of a monitor. While there's no real
guarantee that the connector's name is stable, some system components
used it to uniquely identify a monitor until the next plug in/out event.
Since GTK 3 is API stable, we can only add a private setter and getter
functions pair, without a property.
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
The “xdg-output” protocol provides clients with the outputs size and
position in compositor coordinates, and does not provide the output
scale which is already provided by the core “wl_output” protocol.
So when receiving the wl_output scale event, we should update the scale
regardless of “xdg-output” support, otherwise the scale will remain to
its default value of 1 and the surface will be scaled up by the
compositor to match the actual output scale, which causes blurry fonts
and widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1901
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
GdkWindow::set_startup_id() is NULL on Win32 and would cause a segfault
if called.
While the documentation of the main caller of set_startup_id(),
gtk_window_set_startup_id(), mentions that it's not implemented on
Windows it can still be automatically called via Glade and simply doing
nothing on Win32 is going to be less disruptive than a segfault.
A g_object_ref() call was missing, sometimes causing crashes during
drag-and-drop operations. The matching g_object_unref() is at
gdk/gdkdnd.c:261.
The logic in this function is still wrong--it finds the wrong GdkWindow under
some circumstances--but this commit fixes the crash.
Part of #1840.
And update the surface accordingly (eg. scale on hidpi). The mechanism
that did that for wl_pointer has been made generic so it can be shared
with tablets too.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1675
_gdk_wayland_cursor_get_buffer was not initializing
its out variables in the 'not found' case. This
was showing up in protocol traces as garbage hotspots
being sent to the compositor.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1328
Previously, the GDK backend for Wayland would deduce the logical size
of the monitors from the wl_output size and scale.
With the addition of fractional scaling which advertises a larger scale
value and then scale down the client surface, the computed logical size
of the monitors in GDK would be wrong and confuse applications which
insist on using the monitor size and position (like Firefox).
The xdg-output protocol aims at describing outputs in a way which is more
in line with the concept of an output on desktop oriented systems by
presenting the outputs using their logical size and position appropriately
transformed.
Add support for the optional xdg-output protocol so that the size and
position of the monitors as reported by GDK is correct even when using
fractional scaling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1828
Since commit 3b2f9395, the frame time may be set into the future, so
only ensure monotonicity, and don't store the offset. This prevents the
frame time from becoming out of sync with g_get_monotonic_time().
Fixes#1612
The autotools build uses relative filenames here while with meson
we get absolute paths. Switch to basename so we get the same result
for both and don't break reproducible builds with absolute paths
in public headers.
This will ensure that the version info is easily visible from the
GDK/GTK+ DLLs, and ensure that the print dialogs will have a more modern
look and feel.
...on Visual Studio builds, as it seems that the linker is optimizing
that symbol out (hence it is not exported in the DLL). This is to
ensure that the introspection files for GdkWin32 build.
Add private API to GDK to move these variables from the environment into
static scope. Also move the DESKTOP_STARTUP_ID validation here to reduce
code duplication.
Use constructors to read them as early as possible; however, do not
unset them until first requested. This avoids breaking gnome-shell and
gnome-settings-daemon, which want to use the DESKTOP_AUTOSTART_ID in
their own gnome-session clients.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1761
The event received in `gdk_wayland_window_show_window_menu()` can
come from widgets with a GdkWindow. In those cases the coordinates
are relative to the widget, not the root window.
This results in a misplaced window menu.
Properly calculate the coordinates by iterating to the toplevel
window as suggested by Carlos Garnacho.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/684
The main one is gdkversionmacros.h which resulted in
GDK_MAJOR_VERSION, GDK_MINOR_VERSION and GDK_MICRO_VERSION not being included
in the Gdk-3.0.gir.
Noticed while diffing girs with the meson port.
The previous version of this patch sent an update message to the
NSOpenGLContext in a GdkGLContext::update vfunc, but that vfunc does not
exist any more.
See: #517
Current problems:
* other widgets in a GL-painted window are low-resolution on Retina
display
* something wrong with paint updates; gdkgears demo only updates every
couple of seconds but reports ~30fps
See: #517
We currently ask for anything above 3.2 GL contexts, but we're still
using GLSL 1.50 shaders all over the place. If a GL driver supports GL
3.2+ and GLSL 1.50 only then we'd be in trouble, but the chances of that
happening are really small.
ImmIsIME() doesn't work (always returns TRUE) since Vista.
Use ITfActiveLanguageProfileNotifySink to detect TSF changes,
which are equal to IME changes for us.
Also make sure that IMMultiContext re-loads the IM when keyboard layout
changes, otherwise there's a subtle bug that could happen:
* Run GTK application with non-IME layout (US, for example)
* Focus on an editable widget (GtkEntry, for example)
* IM Context is initialized to use the simple IM
* Switch to an IME layout (such as Korean)
* Start typing
* Since IME module is not loaded yet, keypresses are handled
by a default MS IME handler
* Once IME commits a character, GDK will get a WM_KEYDOWN,
which will trigger a GdkKeyEvent, which will be handled by
an event filter in IM Context, which will finally re-evaluate
its status and load IME, and only after that GTK will get
to handle IME by itself - but by that point input would
already be broken.
To avoid this we can emit a dummy event (with Void keyval),
which will cause IM Context to load the appropriate module
immediately.
Gdk sometimes misses crossing events on popups, so the cached toplevel
may be NULL. If it is, find the toplevel under the pointer and set it.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/623
The use of the startup ID is now twofold, we reply back with it to end any
corresponding startup notification, but we also use it on
gtk_surface1.request_focus to acknowledge that the activation might raise
the corresponding window.
We should preserve the startup ID for the second to work properly, so avoid
clearing it here. It is inconsequential if the underlying
gtk_shell1.set_startup_id request happens multiple times on no longer existing
startup IDs, so don't bother preventing that from happening.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1754
This is named gdkconstructor.h to avoid any possible conflicts. This fixes
the current usages of G_HAS_CONSTRUCTORS, as that header is not installed
by glib.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1029
Should fix most if not all other cases where system-caused changes to
the NSWindow result in the Gdk coordinates not mapping correctly to the
AppKit coordinates.
Transform GdkQuartzMonitor geometry to Gdk coordinate system.
Move computation of Display geometry from GdkQuartzScreen to
GdkQuartzDisplay and use AppKit coordinates.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1593
So dialogs, pop-ups, etc. behave as expected when parent is in
full-screen.
Tiling is allowed for normal windows and splash screens and disallowed
for others.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1627
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>
There're two issues in GdkQuartzView's NSTextInputClient implementation
causes this bug.
1. The -(NSRange)selectedRange should not return [NSNotFound, 0] if
there's no selection. The accented character window will not show
if returned NSRange's location is NSNotFound. Instead of that, the
NSRange's location should be the caret position in the text input
buffer.
2. The accented character window will invoke
-(void)insertText:replacementRange: with non-empty replacement
range, to replace non-accented character with accented character
after user select it from accented character window. This case is
not implemented in original code. Here I use another gobject data
to pass the information to input module and convert it into
'delete-surrounding' event.
Besides these, there's another bug cause gtk_im_context_filter_keypress()
return wrong value while user press and hold a key. When user press
and hold a key, the accented character window will consume the
repeating key down event. Is this case, gtk_im_context_filter_keypress()
should return TRUE, indicate the key press is filtered by input
method module. But it will return FALSE because
gtk_im_context_filter_keypress() assume that every key press event
will generate some text from input method module.
Fixes#1618
And notify the shell about it. This is done through the
gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
on the way to the activated application is already in place to transfer
the startup ID, so the other side just has to reply with
gtk_surface1.request_focus.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This uses the gtk_surface1.request_focus request added in gtk-shell v3,
the given startup ID may be used by the compositor in order to determine
when was the request started, and whether user input happened in between.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
To avoid confusion, have the NMake Makefiles output the built introspection
files in the same location where the binaries are built for the project
files, according to the Visual Studio version, platform and configuration
where the build is carried out.
Also make generating the introspection NMake snippet portion more robust to
source additions and removals by checking on Makefile changes too.
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
The cache key is just the name of the cursor, so if a previously added
cursor had e.g. scale == 1, if we ask for a new cursor with scale == 2,
we might still fetch the scale == 1 cursor from the cache. Avoid this by
making sure the scale of the cached one is correct.
If it isn't, load the cursor as normal, and update the cache entry with
the new properly scaled cursor.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1183
CGDisplayModeGetWidth returns 0 if mode is NULL; that happens if the
CGDisplay is offline or mirroring another monitor and it leads to a
divide-by-zero crash.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1565
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
We need to call g_strdup() on the name that we pass in for notifying the
GDK_SETTING event so that when we do gdk_event_free() later we will not
get a crash (stack corruption) that results from attempting to g_free()
something that is not dynamically allocated.
and convertPointFromScreen:, making them handle all MacOS versions
so that all of the if-deffing happens in the function definitions.
This happens to fix issue 1518 because it turns out that contrary
to the annotation in the 10.14 nNSWindow.h, convertPointToScreen and
convertPointFromScreen originate in 10.14, not 10.12.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1518
G_GNUC_END_IGNORE_DEPRECATIONS terminates the if statement and does not
consider the following block to be part of the if. So that block was
always taken irregardless of the pattern.
Fixes#1280
We don't want to set ParentRelative when:
- the parent window is NULL
In that case we are unsure about the depth, so better err on the side
of caution and avoid a BadMatch by accepting ugly output.
- the cairo pattern is in an error status
This should never happen - unless you start up in OOM - but better
be safe than sorry.
Might help with the spurious crashes in #1280.
Fixes#1280, tray icons not drawing background. This is a magic pattern only
usable for gdk_window_set_background_pattern() that sets the underlying
X window's background to ParentRelative.
Handling more flags, handling them correctly, and emitting the requisite
signals.
Change screen layout to use CGGetActiveDisplayList instead of NSScreens,
eliminating the latency between updating screens and recomputing the
root window.
Moving the initialization of the GdkQuartzMonitors to GdkQuartzDisplay from
the now-obsolete GdkQuartzScreen. Use QuartzDisplayServices for
monitor enumeration and to populate the GdkMonitor properties. This is
better aligned with acting on the Quartz Services callbacks for monitor
changes and with Cairo which also uses CoreGraphics for drawing.
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.
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.
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.
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.
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
According to the XEmbed specification, a window should be created
"elsewhere" and then reparented into the target parent window. Instead,
GTK+ creates the window directly in desired target parent window. This
allows some races to occur.
Another program that does not follow XEmbed is tabbed. XEmbed requires
an _XEMBED_INFO property on the to-be-embedded window, but tabbed does
not check for this property. Thus, as soon as GTK+ creates its window,
tabbed starts managing this window and now GTK+ setting up the window
races with tabbed starting to manage the window.
If tabbed is fast enough to map the window, GTK+ never sees a MapNotify
event, because it did not yet select StructureNotifyMask on its window.
This results in a black window inside of tabbed.
Note that this cannot really be fixed in tabbed, since XEmbed says that
the _XEMBED_INFO property must be already present when the window
appears. Thus, patching tabbed to wait for _XEMBED_INFO to appear is not
something that the spec requires/allows.
Instead, this commit changes GTK+ so that it directly sets the right
event mask when the window is created. This means that there is no more
race between tabbed mapping the window and GTK+ selecting
StructureNotifyMask.
Note that the proper fix would be to do as XEmbed requires: Create the
window elsewhere and then reparent it into the target window. However,
that would require a more invasive patch, so this commit only takes the
"easy approach" of fixing this one race. Hopefully, all the other races
that can occur during window setup are harmless, because the
embedder/socket will hopefully watch for PropertyNotify events as
needed.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/757
See-also: https://github.com/awesomeWM/awesome/issues/2385
Signed-off-by: Uli Schlachter <psychon@znc.in>
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
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. The conversion between formats happens
at GTK level in GtkClipboard or, if GtkClipboard is not used, with
gtk_target_list_add_image_targets() to announce all supported image
formats, and with gtk_selection_data_set_pixbuf() to convert from
any GdkPixbuf formats to the format requested by the selection, and
with gtk_selection_data_get_pixbuf() to convert from the selection
format to GdkPixbuf, if supported.
GDK simply does not play any role in this. 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).
This leverages the normal input module 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 module
loading code, which, not being able to load the desired module
(which is and empty string), falls back to looking at current
keyboard layout.
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of loading appropriate
input modules at runtime. At least, the kinds of modules that specify
languages for which they are loaded automatically by default, and the
IME module.
Loading other kinds of input modules might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of loading the IME input module 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.
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
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 359df028be 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.
For building the introspection dumper program on Visual Studio, leave out
the G_LOG_DOMAIN as g-ir-scanner does not like it when it constructs the
compiler command line for Visual Studio.
Also ensure that we are looking for the freshly-built libraries by looking
for the .lib's from the output directories of the Visual Studio project files.
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.
gdk_win32_window_set_transient_for() behaves incorrectly when
called in sequence with the same arguments. This fix ensures it
always operates correctly.
In some cases this function gets called multiple times with the
same arguments, e.g. when tooltips are shown.
See issue #1214
The enum is duplicated in the spec for the manager and the decoration
object. We should be using the right ones. In practice they have the
same value, so this bug didn't cause any issues.
The wl_surface is destroyed and recreated when the window is
mapped/unmapped. As we have a new wl_surface we need to create a new
server_decoration object for that surface.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
Cursor surfaces didn't listen for output scale changes, meaning they
didn't adapt their scale when an output changed scale, which could
happen for example when changing the monitor scale via Settings.
We also need to invalidate the OpenGL/ES window when we resize the
window via a mouse drag operation, so that we don't get glitches in such
situations, because they are not covered in GdkWindow's
impl_class->move_resize().
Make sure that we only force the invalidation when necessary (as it is
expensive), and clean up the gdkevents-win32.c code so that we include
gdkglcontext-win32.h in the right place instead of using an extern, as
we need to invalidate the window accordingly.
We need to force redraws of the whole window when we are using EGL/ANGLE
during maximize, restore and Aerosnap ops so that we do not get glitches
in the resulting window.
This is for adding a EGL-based renderer which is done via the ANGLE
project, which translate EGL calls to Direct3D 9/11. This is done as a
possible solution to issue #105, especially for cases where the needed
full GL extensions to map OpenGL to Direc3D is unavailable or
unreliable, or when the OpenGL implementation from the graphics drivers
are problematic.
To enable this, do the following:
-Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are
available. A sufficiently-recent ANGLE is needed for things to
work correctly--note that the copy of ANGLE that is included in
qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause
license. Note also that Visual Studio 2013 or later is required to
build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work
without without problems for GTK+ that is built with Visual Studio
2008 or later.
-Build libepoxy on Windows with EGL support enabled.
-Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building
with Visual Studio, or pass in --enable-win32-gles during configure
when building with MinGW/mingw-w64.
-Prior to running GTK+ programs, the GDK_GL envvar needs to contain
gles.
Known issues:
-Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed
extensions, notably GL_OES_vertex_array_object, but its ES 3 support is
sufficient.
-There is no autodetection or fallback mechanism to enable using
EGL/Angle automatically yet. There is no plans to do this in this
commit.
Thanks to LRN for pointing out that we should #include
"win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN
also did the autotools portion of this patch.
Further notes about the autotools --enable-win32-gles option, fom LRN:
This adds --enable-win32-gles option, which enables the
code for GLES renderer. This commit also adds tests for WGL and
EGL in epoxy. The absence of WGL is highly unlikely (it's enabled
by default), but checking for EGL when GLES is enabled is necessary,
as EGL is disabled in Windows builds of epoxy by default.
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).
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
(cherry picked from commit 3287ac96e02ff236d74db10164c5b0c1e7b2b0bf)
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 (which must be on top) appearing for a non-foreground surface,
causing said surface to rise above other surfaces, some of which may
be foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
Fixes issue #852
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 <mrgarnacho@gmail.com>
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.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/997
