- 17 Dec, 2017 1 commit
-
-
Matthias Clasen authored
This is just a bandaid solution to make scale 3 work. If people seriously want to go for scales larger than that, we need a better solution.
-
- 15 Dec, 2017 1 commit
-
-
Matthias Clasen authored
Quietly do nothing when there is already an ongoing operation. This matches the behavior of the ewmh code, and is much nicer than a crash. https://bugzilla.gnome.org/show_bug.cgi?id=789054
-
- 14 Dec, 2017 1 commit
-
-
Chun-wei Fan authored
_gdk_win32_data_to_string() is only available when G_ENABLE_DEBUG is defined, so as in gdkproperty-win32.c, use GDK_NOTE on the parts where we assemble and output the debug messages.
-
- 08 Dec, 2017 2 commits
-
-
Jonas Ådahl authored
This way the window manager can handle destruction while having the transient-for relationship still valid. https://bugzilla.gnome.org/show_bug.cgi?id=791062
-
Jonas Ådahl authored
In order to map a window with the correct initial parent-child relationship when a modal dialog is set up to be a child of an imported foreign window, the relationship must be set up before the window is mapped. In order to do this, if a window is not yet mapped, postpone the relationship setup until when the window is eventually mapped. https://bugzilla.gnome.org/show_bug.cgi?id=791062
-
- 03 Dec, 2017 1 commit
-
-
Руслан Ижбулатов authored
Ensure that surfaces allocated in the impl are destroyed in finalize() https://bugzilla.gnome.org/show_bug.cgi?id=787089
-
- 30 Nov, 2017 6 commits
-
-
Carlos Garnacho authored
After a pointer emulating GDK_TOUCH_END event triggering a fake leave notify with GDK_CROSSING_TOUCH_END mode, pointer_under_window will be unset, which will make the next motion/touch_update event to trigger an enter notify event again. Up till there, that's fine, however the motion event is just consumed in favor of the just synthesized enter notify event. This is unexpected to clients like spice-gtk that will only update coordinates from motion events, sending both enter and motion is more consistent with X11 and will make them happy. https://bugzilla.gnome.org/show_bug.cgi?id=791039
-
Carlos Garnacho authored
It is unlikely that popup windows will contain anything that requires this (popup menus being more interested in redirecting keyboard focus to themselves). OTOH popup implementations that just grab the keyboard are commonplace enough, it makes sense not to trigger inhibition for these. https://bugzilla.gnome.org/show_bug.cgi?id=789268
-
Руслан Ижбулатов authored
No idea why it's here, the hash table can store any kind of data, there's no reason why it wouldn't be able to store an old X string type. Might be a holdout from the old days, when strings were handled in a special way (stored directly in the clipboard?). https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
This prevents GTK from throwing a bunch of warnings when it tries to get drag source window -> screen of that window -> ipc widget for that screen, and then tries to attach a signal handler to that widget. Specifically, this happens when we get a DnD move from another application. https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
1) Ensure that any DELETE requests from the target are sent to GDK, even if both the source and the target are in the same process and it is therefore possible to use a shortcut and call the handler directly in GTK layer 2) Ensure that target GDK doesn't do anything when GTK asks it to send a DELETE request, just report back immediately (the code up the stack does not check for successfullness when request is DELETE, so not giving it any data is OK). The source code already synthesizes a DELETE request, so that side is also taken care of. https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
We need to know the target atom value to know when we need to do something with side-effects (since side-effects are expressed via special target values). Previously, the code side-stepped that by looking at the data type (which was rather unique for the one side-effect target that we supported, signalled by the TARGETS target), but for the DELETE target that seems to be no longer an option, hence the new field to carry this information past the convert_selection() routine. This prevents GDK from throwing a warning when trying to convert a DELETE target, which has no format or data objects set. The side-effects for the DELETE target happen earlier, in GTK layer. By the point it gets to change_property(), it's a no-op. https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
- 29 Nov, 2017 3 commits
-
-
Christophe Fergeau authored
-
Christophe Fergeau authored
The wayland backend currently never emits GDK_SELECTION_CLEAR events. GtkClipboard uses this signal in order to clear the clipboard owner when the selection is set to something outside the application. This commit ensures the wayland backend emits GDK_SELECTION_CLEAR before setting the clipboard owner to NULL, as this means we lost the selection. Signed-off-by:
Christophe Fergeau <cfergeau@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=790031
-
Christophe Fergeau authored
Signed-off-by:
Christophe Fergeau <cfergeau@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=790031
-
- 27 Nov, 2017 1 commit
-
-
Alex Ivanov authored
This makes gtk+ fall back to reading ~/.config/gtk-3.0/settings.ini on systems with Wayland, but without dconf (do those exist?). https://bugzilla.gnome.org/show_bug.cgi?id=790201
-
- 25 Nov, 2017 8 commits
-
-
Руслан Ижбулатов authored
-
Руслан Ижбулатов authored
To do that, run the message loop for one second or until the side-effect of running the selection request handler is achieved (as opposed to running it until the event is no longer queued). The disavantage of this method is that if the event handling is somehow missed (due to a variety of reasons - after all, it's not a straight path from an event being queued to property_change() being called), this will loop for one second. Since we do process events during that time, this will not hang the application, but might still restrict some of the functionality. https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
Handle WM_CANCELMODE and do nothing in response to it when DnD is active. Otherwise pass it to DefWindowProc, which will call ReleaseCapture() on our behalf. This prevents us from losing mouse capture when alt-tabbing during DnD (this includes the feature of Windows Explorer where dragging stuff over a window button in the taskbar causes that window to receive focus, i.e. keyboardless alt-tabbing). https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
Without this patch layered windows are only updated when they are moved by the user or then their contents changes. This patch adds opacity changes to the list of things that make GDK update a window. Without this windows that don't redraw and are not moved by the used (DnD drag indicator windows, for example) don't change their opacity. https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
Руслан Ижбулатов authored
Massive changes to OLE2 DnD protocol, which was completely broken before: * Keep GdkDragContext and OLE2 objects separate (don't ref/unref them together, don't necessarily create them together). * Keep IDataObject formats in the object itself, not in a global variable. * Fix getdata() to look up the request target in its format list, not in the global hash table * Create target GdkDragContext on each drag_enter, destroy it on drag_leave, whereas IDropTarget is created when a window becomes a drag destination and is re-used indefinitely. * Query the source IDataObject for its supported types, cache them in the target (!) context. This is how GTK+ works, honestly. * Remember current_src_object when we initiate a drag, to be able to detect later on that the data object is ours and use a shortcut when querying targets * Make sure GDK_DRAG_MOTION is only sent when something changes * Support GTK drag cursors * Ensure that exotic GTK clipboard formats are registered (but try to avoid registering formats that can't be used between applications). * Don't enumerate internal formats * Ensure that DnD indicator window can't accept drags or receive any kind of input (use WS_EX_TRANSPARENT). * Remove unneeded indentation in _gdk_win32_dnd_do_dragdrop() * Fix indentation in gdk_win32_drag_context_drop_finish() * Remove obsolete comments in _gdk_win32_window_register_dnd() * Check for DnD in progress when processing WM_KILLFOCUS, don't emit a grab break event in such cases (this allows alt-tabbing while DnD is in progress, though there may be lingering issues with focus after dropping...) * Support Shell ID List -> text/uri-list conversion, now it's possible to drop files (dragged from Explorer) on GTK+ applications * Explicitly use RegisterClipboardFormatA() when we know that the string is not in unicode. Otherwise explicitly use RegisterClipboardFormatW() with a UTF8->UTF16 converted string * Fix _gdk_win32_display_get_selection_owner() to correctly bail when selection owner HWND is NULL (looking up GdkWindow for NULL HWND always succeeds and returns the root window - not the intended effect) * More logging * Send DROP_FINISHED event after DnD loop ends * Send STATUS event on feedback * Move GetKeyboardState() and related code into _gdk_win32_window_drag_begin(), so that it's closer to the point where last_pt and start_pt are set * Use & 0x80 to check for the key being pressed. Windows will set low-order bit to 1 for all mouse buttons to indicate that they are toggled, so simply checking for the value not being 0 is not enough anymore. This is probably a new thing in modern W32 that didn't exist before (OLE2 DnD code is old). * Fixed (hopefully) and simplified HiDPI parts of the code. Also adds managed DnD implementation for W32 GDK backend (for both OLE2 and LOCAL protocols). Mostly a copy of the X11 backend code, but there are some minor differences: * doesn't use drag_window field in GdkDragContext, uses the one in GdkWin32DragContext exclusively * subtracts hotspot offset from the window coordinates when showing the dragback animation * tries to consistently support scaling and caches the scale in the context * Some keynav code is removed (places where grabbing/ungrabbing should happen is marked with TODOs), and the rest is probably inert. Also significantly changes the way selection (and clipboard) is handled (as MSDN rightly notes, the handling for DnD and Clipboard formats is virtually the same, so it makes sense to handle both with the same code): * Don't spam GDK_OWNER_CHANGE, send them only when owner actually changes * Open clipboard when our process becomes the clipboard owner (we are doing it anyway, to empty the clipboard and *become* the owner), and then don't close it until a scheduled selection request event (with TARGETS target) is received. Process that event by announcing all of our supported formats (by that time add_targets() should have been called up the stack, thus the formats are known; just in case, add_targets() will also schedule a selection request, if one isn't scheduled already, so that late-coming formats can still be announced). * Allow clipboard opening for selection_convert() to be delayed if it fails initially. * The last two points above should fix all the bugs about GTK+ rising too much ruckus over OpenClipboard() failures, as owner change *is allowed* to fail (though not all callers currently handle that case), and selection_convert() is asynchronous to begin with. Still, this is somewhat risky, as there's a possibility that the code will work in unexpected ways and the clipboard will remain open. There's now logging to track the clipboard being opened and closed, and a number of failsafes that try to ensure that it isn't kept open for no reason. * Added copious notes on the way clipboard works on X11, Windows and GDK-W32, also removed old comments in DnD implementation, replaced some of them with the new ones * A lot of crufty module-global variables are stuffed into a singleton object, GdkWin32Selection. It's technically possible to make it a sub-object of the Display object (the way Wayland backend does), but since Display object on W32 is a singleton anyway... why bother? * Fixed the send_change_events() a bit (was slightly broken in one of the previous iterations) * Ensure that there's no confusion between selection conversion (an artifact term from X11) and selection transmutation (changing the data to be W32-compatible) * Put all the transmutation code and format-target-matching code into gdkselection-win32.c, now this code isn't spread across multiple files. * Consequently, moved some code away from gdkproperty-win32.c and gdkdnd-win32.c * Extensive format transmutation checks for OLE2 DnD and clipboard. We now keep track of which format mappings are for transmutations, and which aren't (for example, when formats are passed as-is, or when a registered name is just an alias) * Put transmutation code into separate functions * Ensure that drop target keeps a format->target map for supported formats, this is useful when selection_convert() is called, as it only receives a single target and no hints on the format from which the data should be transmuted into this target. * Add clear_targets() on W32, to de called by GTK * Use g_set_object() instead of g_ref_object() where it is allowed. * Fix indentation (and convert tabs to spaces), remove unused variables https://bugzilla.gnome.org/show_bug.cgi?id=786509
-
-
-
Руслан Ижбулатов authored
Instead of using a boolean to indicate a modal operation being in progress, use a set of flags, and allow these to be set and unset independently. Specifically, this allows WM_CAPTURECHANGED handler to only act when a drag-move or drag-resize modal operation is in progress, and ignore DND (which can also cause WM_CAPTURECHANGED to be posted). This avoids a crash due to assertion failure when OLE2 DND code tries to end a modal operation that was already ended by the WM_CAPTURECHANGED handler. https://bugzilla.gnome.org/show_bug.cgi?id=786121
-
- 23 Nov, 2017 1 commit
-
-
Руслан Ижбулатов authored
Decrement the counter for each removed element, otherwise we skip one element every time we remove one. Also, no need for continue here.
-
- 22 Nov, 2017 2 commits
-
-
Daniel Boles authored
-
Bastien Nocera authored
-
- 13 Nov, 2017 1 commit
-
-
Benjamin Otte authored
This mask was forgotten to update when the last 2 event masks were added, probably because it looks like it's already maxed.
-
- 04 Nov, 2017 1 commit
-
-
Chun-wei Fan authored
Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
-
- 31 Oct, 2017 1 commit
-
-
Daniel Boles authored
-
- 30 Oct, 2017 2 commits
-
-
Lukas K authored
-
Simon McVittie authored
Otherwise, builds that include the Wayland backend fail. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=789630Signed-off-by:
Simon McVittie <smcv@debian.org> Reviewed-by:
Emmanuele Bassi <ebassi@gnome.org>
-
- 28 Oct, 2017 1 commit
-
-
Matthias Clasen authored
This reverts commit f2ba6ca4. This change was causing problems with several X servers, see https://bugzilla.gnome.org/show_bug.cgi?id=780101
-
- 27 Oct, 2017 3 commits
-
-
Matthias Clasen authored
The same value we use in gtk_widget_get_scale_factor.
-
Olivier Fourdan authored
According to the documentation, gdk_monitor_get_geometry() reports the monitor geometry in ”application pixels”, not in ”device pixels”, meaning that the actual device resolution needs to be scaled down by the scale factor of the output. x11 backend does that downscaling, whereas Wayland backend did not, causing a discrepancy depending on the backend used. https://bugzilla.gnome.org/show_bug.cgi?id=783995
-
Simon McVittie authored
This state flag is used in several places in GTK+, for example to ignore RESIZE_INC hints if tiled. Setting it is also necessary for backwards compatibility with applications that changed their behaviour when tiled, such as GNOME Terminal and its MATE fork. Signed-off-by:
Simon McVittie <smcv@debian.org> https://bugzilla.gnome.org/show_bug.cgi?id=789357
-
- 26 Oct, 2017 3 commits
-
-
Drew DeVault authored
If the compositor prefers server-side decorations and the client doesn't customize the title bar, we disable client-side decorations and let the compositor know. Otherwise, we continue to use client-side decorations. Signed-off-by:
Drew DeVault <sir@cmpwn.com> https://bugzilla.gnome.org/show_bug.cgi?id=781909
-
Olivier Fourdan authored
Under Wayland, an xdg_surface.configure with size 0x0 means it's up to the client to set its size. When transitioning from maximized state to un-maximized, the Wayland compositor will send such an 0x0 configure so that the client can restore its original size. However, the original size was already constrained, so re-applying size constrains can lead to a smaller size when using size increments. Avoid this caveat by not applying size constrains when we are restoring the original size. https://bugzilla.gnome.org/show_bug.cgi?id=777072
-
Matthias Clasen authored
We were unnecessarily spewing warnings when blank cursors were getting a new scale set. Standardize on "none" as the name for blank cursors, and avoid the warning. https://bugzilla.gnome.org/show_bug.cgi?id=775217
-
- 25 Oct, 2017 1 commit
-
-
Andrea Azzarone authored
Some clients (e.g. gnome-online-accounts) quickly unmap and map a window. With some backends the backend surface will be replaced causing the application to crash because the GL context is still using the old surface. Clearing the GL context when a window is withdrawn fixes this. https://bugzilla.gnome.org/show_bug.cgi?id=789141
-