Integrate window controls into viewswitcher on Wayland #19685
Conversation
vtyrtov
commented
Nov 7, 2025
vtyrtov
commented
- Hide GtkHeaderBar and integrate window control buttons into viewswitcher module
- Add minimize, maximize/restore, and close buttons with GTK symbolic icons
- Apply GTK theme styling to buttons (override darktable theme)
- Enable window dragging from entire TOP panel on Wayland
- Add dynamic icon update for maximize/restore button based on window state
- Wayland-only implementation using conditional compilation
- Hide GtkHeaderBar and integrate window control buttons into viewswitcher module - Add minimize, maximize/restore, and close buttons with GTK symbolic icons - Apply GTK theme styling to buttons (override darktable theme) - Enable window dragging from entire TOP panel on Wayland - Add dynamic icon update for maximize/restore button based on window state - Wayland-only implementation using conditional compilation
ProblemOn Wayland darktable window shows dual titlebars - GTK HeaderBar and darktable's own top panel - which looks redundant and takes vertical space. SolutionThis PR integrates window control buttons (minimize, maximize/restore, close) directly into darktable's viewswitcher module, eliminating the redundant headerbar while maintaining CSD support. 
Changes
Testing
Note on Panel VisibilityWhen top panel is hidden ( Question for reviewers: Is this acceptable, or should window controls remain visible when panel is hidden? |
|
Thanks, but I would not put the maximize or minimize buttons. At least this should follow the current user's setting or not displayed at all. Shouldn't we have some kind of fly over effect the buttons? As is they seem dead.
For me it is acceptable as I don't use the close button but only |
|
@TurboGit thanks for the feedback! I'll address these points:
Will update the PR shortly. |
- Read gtk-decoration-layout to respect user's button preferences - Create only buttons specified in settings, in correct order - Add hover and active state effects for visual feedback - Implement double-click on panel to maximize/restore window - Keep single-click for window dragging
|
Updated the implementation based on feedback: Respect user preferences - Now reads Visual feedback - Added hover and active state effects to buttons so they respond visually to user interaction. Double-click to maximize - Implemented standard titlebar behavior - double-click on the panel now maximizes/restores the window, single-click still drags. 
|
|
Apart from testing, is there a reason this could not be used on all platforms, not just wayland? I remember there was a request a while back for Windows where this would allow more control over dark mode (or some other benefit). It would be nice to be consistent as well. The testing part was the reason I didn't want to burn my fingers at the time, but now that we have wayland testers, I'd be happy to look at it under Windows and maybe some Mac users could have a go as well (I'm still not clear how fragmented that platform is; intel vs apple cpus etc; @zisoft). Is @TurboGit fully on wayland now or still able to test X11/Xwayland? |
|
@dterrahe : I'm fully on Wayland now. On Debian, GNOME 49 don't ship the |
Agreed, maybe we can do that for X11 also. |
Do they still ship/allow installation of Xwayland? |
Not sure when I run darktable with
But I have xwayland package installed. Maybe due to the fact that I'm using the proprietary NVidia driver. So all in all, this is not currently an option for me. EDIT: My bet is that xwayland works only if there is support for an xsession. |
Personally, for me too, but we have to take into account that there are inexperienced users who are not used to the keyboard shortcuts in darktable. They may accidentally hide the top panel with the wrong shortcut (FB, Reddit and Pixls are full of such stories where users ask what happened and how to fix it), and that they may not know about In summary, I am against a UI where the user can accidentally lose the close button of the program without having a global menu through which he can quit. |
|
I don't disagree, but don't we already face this situation when the user accidentally presses F11? For that case, this could actually be an improvement. I haven't tried this PR, but would there still be a difference between full screen and maximize?
So you're saying they may have messed up configuring xwayland on a stand-alone basis? Sounds like a distribution bug to me. Would that not hit many programs that don't support wayland at all (i.e. need xwayland)? Not investigated too much but first google result seems to suggest xwayland is part of the long term strategy https://linuxiac.com/gnome-50-ends-the-x11-era-after-decades/ Again, I'm not arguing (at all!!) that we should not focus on making wayland work well; I know that is the highest priority. I'm just worried that if @TurboGit is no longer able to test whether any of those fixes break X11 that we then leave a large chunk of the installed base behind. Because who else does all the testing he does? Testing on Xwayland is not the same as testing on X11, but it would be better than nothing. |
I suggest doing it the way it is done in VSCode. You can disable the titlebar in the settings and then the buttons will be displayed in the top panel. Before the latest changes, this could be done by third-party GNOME extensions, but switching to Wayland transfers the titlebar to the application. |
Maximize (system tray remains visible) Fullscreen |
I've been paying attention to these complaints on the aforementioned social platforms. I can say that there have been complaints about missing panels, but I haven't seen any complaints about unexpected fullscreen mode (F11). Maybe it's because in all browsers F11 turns on fullscreen mode and this is familiar to users? However, hmm, no. Maybe it's not even about shortcuts. In fact, clicking anywhere on the outer edge of the panel is equivalent to clicking on the triangle. So it's very likely that users can just click there without realizing it. Sometimes I also misclick and accidentally close panels... |
But if the top panel is hidden with Ctrl+H, ctrl+shift+T or Tab, you're stuffed. We can try to protect atechnical users a little more, but personally I wouldn't want to force power users to always waste real estate on a button because others press keys randomly. For Tab we already have a first-use confirmation dialog. This could be extended to the other ways of hiding the top panel. We could also show a toast immediately after it was hidden explaining how to get it back. Even this could be a nuisance to those that use Tab to quickly have an undisturbed view of the image (but they can use "full preview"). |
Yes, ok, so? If the top panel is accidentally (see my comment above, these are real situations) closed by the user, where will the close button be displayed? |
Which is why "B" is the first key I press when starting with a clean darktablerc ;-) I've never fully understood why those arrows are on the outside of the panels, rather than on the inside where you can also drag the edge to resize. So dragging would resize and clicking would fully collapse (only to be enabled when in collapsed state there's still an arrow visible to expand again, so not after pressing B). The reason this always felt "wrong" to me, is that scrollbars along the edge of the screen (in maximized or full screen mode) are supposed to be reachable by "throwing" your mouse as far left or right as possible. Which is why "scroll side panel" is less efficient; if you want to scroll the panel, just throw your mouse and scroll. If you're holding it above the panel somewhere, you must intent to manipulate the thing under the mouse. |
If the user deliberately turns off the titlebar, then he will read where the buttons will be located (warned). In the same VS Code, in this scenario, there are no window control buttons in Wayland at all (unless a third-party GNOME extension like Unite is installed). You can make a full-fledged Wayland CSD header by moving the filter panel there (which is present in almost all views). But this will require separate maintenance, and if done, then together with the redesign, which is discussed in other topics. |
Nowhere, the user has closed the top panel, he will have to reopen it. Not a big nuisance, people closing the top panel are already aware of that since to access the other views (map, darkroom, print...) it is needed to reopen it... or to use the proper shortcut and it is the case for closing darktable ( |
But what we should be concerned about is not the visibility of the system tray. :)
The user have to, yes, but he has nothing to rely on and cannot repeat his experience from other programs. He does not have a familiar global menu from which he can exit the program and find the "help on shortcuts" item there. I would really like to live in an ideal world where all users are power users or at least understand what they just did. The reality is different. Also, our UX feature that a misclick a couple of pixels on the outer edge of a panel closes the panel also helps a lot (no). We expect all users to start getting acquainted with darktable from the user manual and look at the shortcut cheat sheet by pressing h, right? Unfortunately, this is a vain expectation...
Ctrl+Q is not a universal shortcut to close an app. Common OS-level shortcuts for closing a window or application are Alt+F4 on Windows or Cmd+Q on macOS. In fact, we should finally add a global application menu to darktable that will be in the same panel as the close button (be it titlebar on Windows or CSD header on Wayland), and get rid of what is currently the top panel with view switcher. To summarize my arguments, I am strongly against the current proposal in this PR. We need to start doing the right things and design UX without surprises. The view switcher is a legacy of menuless design that is extremely inefficient in using screen real estate and is only needed because we don't have a menu through which we can switch views and learn which shortcut does it. |
|
Ok, so let's restart the discussion for for 5.6. We have many other things to fix (especially if we want minimal support for Wayland) for the 5.4 release and we are getting close to the release. |
4 participants
