Titlebar Buttons

This issue was closed, that’s why I opened the discussion here.

I was thinking about that many people may be uncomfortable with only being able to close windows by button, without the obvious possibility to hide or maximize windows. It would be nice to add the option to turn on this three buttons in the settings, this should increase accessibility and make the usability friendlier.

Does that make sense?

How can you hide and maximize windows currently?

  1. Use gestures - Which is convenient only for touch control.
  2. Use right click and then choose Hide or Maximize - Which requires an additional click, and it’s not so accessible.

Won’t that hurt GNOME HIG?

Of course, more buttons on header bars would reduce the space, which may not be cool to adapt to mobile screen sizes. But on mobile you are not need a Hide and Maximize buttons, yes, and in the Close button, on Android and iOS apps doesn’t have Close button.
On desktop won’t be any problems with reducing precious space.

Plus, this could be a cool reference to the classic GNOME from 00’s, where were Hide, Maximize and Close buttons together.

Here’s mockup:

I was thinking about where to put this setting, it seems to me that this setting could be in Multitasking or Accessibility tab.
Also, “Extended” title may be as “Classic”.

5 Likes

This is a mockup, where these options are located in Accessibility.

It actually doesn’t: The menu opens on press and the action triggers on release, so if you hold the mouse button while moving to the item, you don’t have to click again.

(Not disputing that a menu is less convenient than a toplevel button, just clarifying)

1 Like

Hm, it really works.

Btw, I wanted to try to recreate my mockup in real code, because it shouldn’t be that hard to do. Just need to copy the code from the “General” (Hot Corner/Active Screen Edges) settings, but with circle switches like the in “Muilti-Monitor” setting. And also change the images and text, but I don’t know how to make so that switches will change titlebar buttons.

But it didn’t work, Builder gives an error and don’t run Settings :frowning:, so I can’t check it.

Oh, this guy maked it!

https://gitlab.gnome.org/Teams/Design/whiteboards/-/issues/87#note_1525164

Now we can only hope that GNOME dev approve this feature.

1 Like

Minimize is against HIG.

If you want a clear screen, go to a new workspace. If you want a window to be out of your focus, send it to another workspace. They are unlimited number of workspaces there.

Still, this is accessibility feature.

In GNOME, the philosophy is (AFAIK),

  • Maximize: Double click on HeaderBar or TitleBar.
  • Minimize: Don’t use it. If you need to do something else temporarily, just change workspace.

This makes a lot of sense and this is exactly how I use my GNOME setup.

Also, if someone does want to have Window Control Buttons on TitleBars and HeaderBars, GNOME Tweaks already lets you do that.

Having said that, I do know that a lot of people like to have Window Controls and they do not want to install another app just to change a basic setting.

So, I agree with having an option to enable Window Control Buttons in the official Settings app even though I keep it turned off by choice.

It actually doesn’t: The menu opens on press and the action triggers on release, so if you hold the mouse button while moving to the item, you don’t have to click again.

This doesn’t work for a touchpad and any program with a custom context menu on the header bar (e.g., Firefox)

1 Like

You can also drag the window to the top, or use super-up, to maximise

Windows can be hidden by dragging to another workspace, or super-h

[citation needed]

Obviously a11y is important, and should be taken seriously, but you can’t just declare something you want to see as an a11y feature

I’m more interested in whether the GNOME devs are ready to merge this feature, or not. After all, Andrii is working on the MR, it would be a shame if these efforts were in vain.

2 Likes

Someone doing work unprompted isn’t a reason for something to get merged — However unfortunate it may be to discard work.

If you want to see this added, you need to convince the relevant maintainers (and designers, etc) that it is something we need.

Without wanting to speak for others, if you really want an instant answer to ‘GNOME devs are “ready” to merge’: No, likely not — Especially if you don’t argue your case.

1 Like

I made the mockup and Andrii decided to implement the idea in a working feature, because my GNOME Builder doesn’t work :sleepy:
I read people’s opinions from various sources where I showed the mockup, to find out if someone like the idea and if the layout okay. After various critiques, I refined the mockup many times.
Most people like this idea, some people want individual switchers for Hide and Maximize buttons, like in Tweaks.
And of course, some people don’t like the idea of adding this option, because they will don’t use it.

In general, many people would rather have this feature instead of not, even if they will don’t use it, because some people may need it, like High Contrast or Large Text options.

If evaluate the effectiveness of this feature, it will probably be 9 of 10. Many people search on the Internet, how to minimize or maximize windows in GNOME, especially if it is a distro with non modded GNOME, I was searching for this as well. Which means it’s in demand.
If you evaluate the difficulty of adding this feature, it’s 1 of 10. It’s not hard to add it, GNOME has natively supported the Hide and Maximize buttons for a long time.

Some questions remain, where to add this option, in Multitasking or in Accessibility? I prefer Accessibility.

Of course, Andrii’s MR is not ready yet, so it is impossible to objectively assess how it will work, there are bugs, etc. Although there is this fork for MR, I don’t mind checking it out, but GNOME Builder still doesn’t work for me :cry:

Hi, @DartDeaDia . Could you tell how the user should restore hidden windows? Does it require using a GNOME Shell extension, such as “Dash to Panel”, to provide an area to track running applications? If yes, then, shouldn’t those features be bundled together, not separately? “Dash to Panel” README suggests using Tweak Tool to enable the buttons. There is also an extension dedicated to that.

I’m using App Icons Taskbar extension by andrew.zaech, but for GNOME could to make a visible dock on the desktop.
https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/171

Are hidden windows not showing in the window overview?

Of course, it’s showing. You can test this by turning on this titlebar buttons in Tweaks.
I did different tests on how it works, is there a problems with adaptability, surprisingly, it’s already working pretty well, but there is something I don’t like.

For example, Tour has Hide and Maximize buttons, it doesn’t look aesthetically pleasing. I think this needs to be improved so that such “Welcome” windows will not have Hide and Maximize buttons, even if it turned on.

For example, Contrast doesn’t have Maximize button, possible such a “titlebar buttons disabling” option is already exists.
Contrast

For the hide option: one problem less.

I agree about the “Welcome” windows, especially the maximize option which is the most useless (the window is optimized for its size).

Some questions remain, where to add this option, in Multitasking or in Accessibility? I prefer Accessibility.

Multitasking seems more appropriate to me since all users can use these controls.

I think that adding a minimize button does not fit with current GNOME workflow, with vanilla gnome, users will be confused if there is a minimize button that makes the window disappear without a taskbar. So for the minimize button it’s about changing the whole workflow not just adding the button. For the maximize button I see that there is nothing against the current workflow, so it’s easy to add and I really see no reason for removing it other than having less buttons in the headerbar.