summaryrefslogtreecommitdiff
path: root/src/frames
Commit message (Collapse)AuthorAgeFilesLines
* frames: Disable XDND support on the frame windowSebastian Keller2023-04-281-0/+8
| | | | | | | | | | | | All X11 surfaces created by gtk4 claim to support XDND via the XdndAware property. This was leading some clients, e.g. Qt, to consider the frame window as drop target instead of the client window. Avoid this issue by removing the XdndAware property again after gtk has created the surface. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2715 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2978>
* frames: Use cairo renderer on GTK framesCarlos Garnacho2023-04-241-0/+2
| | | | | | | | | Going for the default GL renderer is known to trigger rendering artifacts using the NVidia proprietary driver. Since we don't have too many expectatives about frames being flashy (not to the point of mandating GL), resort to the cairo renderer in the mean time. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2976>
* x11: Always initialize all fields of XEvents sent via XSendEventSebastian Keller2023-04-171-1/+1
| | | | | | | | The X server ignores the send_event and serial in incoming XEvents, so they were not initialized when calling XSendEvent in a few places. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2641 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2964>
* frames: Forward _NET_WM_STATE during frame initializationCarlos Garnacho2023-04-141-5/+48
| | | | | | | | | | | | | | | | | Ensure the frame window is created at the right fullscreen state before showing it and assigning it to the client window. A peculiarity of this property on frame windows is that it is typically single-handedly updated from the Mutter side, in synchronization with client window state. It can only differ during creation, since GTK still likes to apply its own state. Also, the only relevant property seems to be _NET_WM_STATE_FULLSCREEN, since the others are less relevant to the role of the frames client, and get applied to the MetaWindow as a whole, instead. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2712 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2961>
* frames/content: Use gtk_widget_compute_point()Jonas Ådahl2023-04-051-7/+8
| | | | | | The non-graphene-point variant is deprecated. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2949>
* frames/window-tracker: Select StructureNotifyMask X11 eventsMarco Trevisan (Treviño)2023-04-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | The window tracker is filtering XEvents manually as it only requires a subset of the ones that Gdk listens to in the root window, and this is nice, but we were restricting the set a bit too much because due to this we were not notified when an xsettings manager was available, and thus in case gsd-xsettings was launched after meta-window-tracker (a normal scenario under X11), no xsetting was actually applied to the decoration windows. As per this, the default settings were used for everything and never updated, until a restart of the window-tracker. In order to be able to monitor the XSettings changes at startup, we also need to select the StructureNotifyMask as gtk always do by default. See also: https://gitlab.gnome.org/GNOME/gtk/-/blob/4.11.1/gdk/x11/gdkscreen-x11.c#L947-950 Fixes: #2580 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2948>
* frames: Select SubstructureNotifyMask tooJonas Ådahl2023-03-041-1/+2
| | | | | | | | | | | | | | | This is the mask that lets us receive among other events the rather important CreateNotify, that tells us about new winows. This has went by rather unnoticed except for cases where multiple windows show up very quickly directly after the frames client spawned, because the drag icon surface cache eventually already did select that particular mask. Make things more reliably by explicitly setting the mask for the events we rely on to function. This fixes flaky stacking tests that map multiple X11 windows in a row. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2894>
* frames: Fix code typoCarlos Garnacho2023-02-281-1/+1
| | | | | | | | We are picking the wrong fallback frame title string in a branch. Fixes: 6df9eab88 ("frames: Handle _NET_WM_VISIBLE_NAME") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2875>
* frames: Handle WM_NAMECarlos Garnacho2023-02-271-0/+64
| | | | | | | | This is the most ancient form of "window titles", not guaranteed to be UTF-8, take the usual precautions before using this string and keep it as a last resort. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2872>
* frames: Handle _NET_WM_VISIBLE_NAMECarlos Garnacho2023-02-271-6/+53
| | | | | | | This is occasionally set by Mutter, in order to hint about remote X11 clients, etc. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2872>
* frames: Minor refactorCarlos Garnacho2023-02-271-8/+21
| | | | | | | Move extraction of UTF8_STRING properties to a helper, as we'll want to use it for several properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2872>
* frames: Rename functionCarlos Garnacho2023-02-271-4/+4
| | | | | | | There's different levels of "title" we'll want to poke, make this function name a bit more specific. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2872>
* frames: Intern some Atoms in the MetaFrame structCarlos Garnacho2023-02-271-17/+32
| | | | | | | Start with the ones we handle through PropertyNotify events, since we want to expand further on those. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2872>
* frames: Quit immediately on SIGTERMCarlos Garnacho2023-01-201-4/+2
| | | | | | | | | | | | | | | Restarting a X11 window manager is a busy process, trying to leniently quit the main loop may result in old and new instances each having a frames client up and running, and the window handover to be less clean than it should due to the frames client that is about to exit still being able to react to the batch of events resulting from the window manager switch that is already undergoing. In order to avoid extending this transition period any long, make the frames client exit() the process immediately when SIGTERM is gotten from the parent process. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2796>
* frames/window-tracker: Stop using deprecated APIFlorian Müllner2023-01-201-1/+1
| | | | | | | GTK deprecated gtk_widget_show() in favor of gtk_widget_set_visible() and gtk_window_present(). Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2783>
* frames: Avoid default NULL frame titleCarlos Garnacho2023-01-181-1/+1
| | | | | | | The default GtkWindow title if NULL is set is obtained from g_get_prgname(), prefer an empty string here. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
* frames: Push error traps around various X11 callsCarlos Garnacho2023-01-122-24/+68
| | | | | | | It is a possibility that these requests result in an error, so handle the possible fallout. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
* frames: Handle lack of WM_DELETE_WINDOW in WM_PROTOCOLSCarlos Garnacho2022-12-101-9/+71
| | | | | | | It is expected that we XKillClient() those clients that do not handle WM_DELETE_WINDOW messaging. Fixes closing glxgears. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2756>
* Revert "x11: Move Motif WM hints to a separate header"Carlos Garnacho2022-12-092-3/+18
| | | | | | | | | | | | | | | | Since we use XCB in the Mutter side, but Xlib in the frames client, we cannot share the same struct definition since both libraries will expect different type lengths (respectively, 32-bit ints vs. longs). Revert the changes that made both executables share the same struct, since not both of them can get it right (and retrieve correctly the struct with the contained flags) in reading the Motif WM hints. This reverts commit 2fb3c5a4f577aea9a4fc721807eb1ca4a49b8990. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
* frames: Add CSS class on initGeorges Basile Stavracas Neto2022-12-092-1/+2
| | | | | | | | | | | | Adding the 'default-decoration' CSS class to MetaFrameHeader after it is set as the headerbar makes it not account for the minimum size correctly sometimes. This is a bit racy though - if the window opens very quickly, it works as expected. Adding the CSS class before the widget is used guarantees it'll always report the correct size though, so do that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2753>
* frames/window-tracker: Trivial style cleanupGeorges Basile Stavracas Neto2022-12-051-1/+1
| | | | | | A space of indentation was missing. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
* frames: Add default-decoration CSS classGeorges Basile Stavracas Neto2022-12-052-0/+3
| | | | | | | | Add this CSS class both to the header bar itself, since it is what actually contains the window controls, and to MetaFrameHeader too, since it's what's directly attached to the window. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
* frames/window-tracker: Initialize color scheme properlyGeorges Basile Stavracas Neto2022-12-051-3/+10
| | | | | | | | | | | | Previous commit added support for setting the GTK4 theme setting according to the color scheme setting. That's cool. What it didn't add, though, was initializing the GTK4 theme setting to the proper value. That means if the desktop starts at dark style, you'd still get a light titlebar. Fix that by updating the GTK4 theme setting on init as well. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
* frames/window-tracker: Reinstate dark titlebar supportGeorges Basile Stavracas Neto2022-12-052-0/+29
| | | | | | | | | | | | | Merge request !2541 [1] introduced support for integrating Mutter frames with the dark style. This was lost after moving frames into a separate client. Bring that back. Don't depend on gdesktop-enums as it brings GTK3 into the header chain. [1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2541 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2739>
* x11: Move Motif WM hints to a separate headerCarlos Garnacho2022-12-052-18/+3
| | | | | | | | | | | | These are now referenced on the frames client side (in order to track deletable state from the client window) and the mutter side (pretty much everything else, like figuring out if a window wants WM decorations). It makes sense to make this a separate header, so that we don't need to doubly define these flags/structs. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
* frames: Fix check of Motif WM hintsCarlos Garnacho2022-12-051-3/+5
| | | | | | | | | | | | | | | We use this for tracking the deletable state of the client window, but forgot to check that the MWM_HINT_FUNCTIONS hint is set in hints.flags before checking hints.functions. This resulted in windows that do not specify this flag (and thus should go with the defaults) in being mistakenly removed the close button, as the functions flags would be typically 0 in that case. Fixes issues with Chromium and Electron applications missing the close button, since Chromium does this on X11. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
* frames: Double check _MUTTER_NEEDS_FRAME property changesCarlos Garnacho2022-12-041-2/+6
| | | | | | | | | | | | | | | | | | | | Recalculating window features is a busy thing on the Mutter side, the different properties being (re)set will overwrite the current state and cause some side work. Between that is the rewriting of the _MUTTER_NEEDS_FRAME property on the window being recalculated, which throws the frames client off, by thinking the window does actually require a new frame. It is not sufficient to trust that PropertyNewValue means the property or the value are new, also double check that the window did not have in fact a frame, and avoid the busy work if it did. Besides the busywork that can be easily avoided, this also fixes the window close button state being stuck if the window changed its deletable state, since the frame being respawn managed to miss the property change. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
* x11: Add frame synchronization to window framesCarlos Garnacho2022-12-011-1/+1
| | | | | | | | | | | | | | | | | | | There's two meanings of "frame" there! Since SSD frames are now rendered by an external client, and there are no actual mechanism that ensures the frame did already get painted when the client did respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be artifacts when resizing windows. In order to get always the best visual result, we should actually synchronize rendering with both the client window and the window frame window. This commit adds these mechanisms, so a sync alarm update is expected on both windows until further resizes are allowed, this ensures window and frame stay in sync, even after moving rendering elsewhere. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
* frames: Add new X11 frames clientCarlos Garnacho2022-12-0110-0/+1263
This small X11 client takes care of creating frames for client windows, Mutter will use this client to delegate window frame rendering and event handling. The MetaWindowTracker object will keep track of windows created from other clients, and will await for _MUTTER_NEEDS_FRAME property updates on those (coming from Mutter), indicating the need for a frame window. This process is resilient to restarts of the frames client, existing windows will be queried during start, and the existence of relevant properties checked. Mutter will be able to just hide/show SSD-decorated windows while the frames client restarts. The frames are created through GTK4 widgets, the MetaWindowContent widget acts as a replacement prop for the actual client window, and the MetaFrameHeader wraps GtkHeaderBar so that windows can be overshrunk, but otherwise a MetaFrame is a 100% true GTK4 GtkWindow. After a frame window is created for a client window, the _MUTTER_FRAME_FOR property will be set on the frame window, indicating to mutter the correspondence between both Windows. Additionally, the pixel sizes of the visible left/right/top/bottom borders of the frame will be set through the _MUTTER_FRAME_EXTENTS property, set on the frame window. In order to make the frame window behave as the frame for the client window, a number of properties will be tracked from the client window to update the relevant frame behavior (window title, resizability, availability of actions...), and also some forwarding of events happening in the frame will be forwarded to the client window (mainly, WM_DELETE_WINDOW when the close button is clicked). Other than that, the frames are pretty much CSD GTK4 windows, so window drags and resizes, and window context menus are forwarded for the WM to handle. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
View Lorry Controller Status