Project

General

Profile

Bug #11270

Bring back "minimize" and "maximize" buttons in titlebars by default

Added by elementar over 1 year ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
02/22/2016
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
segfault: bugfix/11270-add-minimize-maximize-buttons-to-GNOME-apps
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

Gnome Shell-native applications, such as Gedit, Files, Calculator, Videos, System Monitor, Settings, Document Viewer, Archive Manager, Disks, etc, have only ONE titlebar button in the top right: the X or Close button. Minimize/Maximize functions are accessed by right clicking on the titlebar.

Other applications, such as Tor Browser, Pidgin, Terminal, KeepassX, Icedove, Libreoffice and most of the Audio and Video applications, have THREE titlebar buttons in the top right: Minimize, Maximize and Close.

This means the window behaviour and layout is inconsistent across different applications, and introduces a barrier to entry for Tails novices. The window layout and behaviour should be consistent.

Toggling the settings for Tweak Tool > Windows > Titlebar buttons > Maximize/Minimize does nothing to change this problem.

In any case it should be consistent by default.

The windows can be made more consistent by running:

gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close'

Perhaps this should be in a startup script?


Related issues

Related to Tails - Bug #13461: The Desktop icons are sometimes not displayed since the upgrade to Stretch In Progress 07/12/2017
Duplicated by Tails - Bug #11367: Make it easier to minimize windows Duplicate 04/25/2016

Associated revisions

Revision a41060d8 (diff)
Added by segfault over 1 year ago

Set button layout to minimize,maximize,close.

Will-fix: #11270

Revision 133e6bf1
Added by anonym over 1 year ago

Merge remote-tracking branch 'segfault/bugfix/11270-add-minimize-maximize-buttons-to-GNOME-apps' into devel

Fix-committed: #11270

History

#1 Updated by segfault over 1 year ago

  • Status changed from New to Confirmed
  • QA Check set to Ready for QA
  • Type of work changed from User interface design to Code

Funny, I didn't see this ticket before but I just wanted to open a ticket for exactly this. I've seen multiple users struggle with minimizing nautilus or gedit.

I just created a branch with a fix in my repository:
https://gitlab.com/segfault_/tails.git bugfix/11270-add-minimize-maximize-buttons-to-GNOME-apps

It could be argued that this should be fixed in upstream (GNOME), but I think many of our users are in another position than most other GNOME users. Most GNOME users use GNOME as their main desktop environment and are able to customize it to their needs. Most Tails users don't use Tails as their main operating system and they are not able to customize it persistently. We should aim to make Tails as usable as possible for users who mainly use other operating systems. And both Windows and OS X have a minimize and maximize button in the title bar.

#2 Updated by intrigeri over 1 year ago

It could be argued that this should be fixed in upstream (GNOME), but I think many of our users are in another position than most other GNOME users. We should aim to make Tails as usable as possible for users who mainly use other operating systems.

FWIW, I agree.

And both Windows and OS X have a minimize and maximize button in the title bar.

Wrt. the maximize button: why not, I don't care much.

Wrt. the minimize one: why not, but I'm slightly concerned that this (+ the habits that go with it) relies upon the windows list ("task bar"), that we currently have since we run GNOME Shell in Classic mode, but it's not obvious that we'll have it forever (e.g. we may decide to move to the regular GNOME Shell for Tails 3.x or earlier, and GNOME Classic might become less well supported if enterprise desktop distros move to the regular Shell experience). So, in a sense, not making it obvious how to minimize windows is a nice first step towards 1. shipping something closer to regular GNOME SHell; 2. training users to interact with windows with other means than the "minimize" feature. And on the contrary, re-introducing the minimize button 3 months after we released Tails 2.0 would feel like a step backwards, and some debt we might have to deal with later (as any delta we decide to create).

I have a few more arguments in favour of keeping things as-is:

  • this can be changed in GNOME Tweak Tools;
  • adding widgets makes UX worse for everyone who doesn't need them; this problem was not raised during the 2.0 testing phase (beta, RC), and it was just filed a couple weeks ago, so I doubt many users have problems with the current situation; with this in mind, I'm not convinced the pros/cons ratio of the proposed change is favorable.

Now, I'm not sure myself what's best, I won't research the subject further, and I could live with re-adding those buttons. This is just additional points I feel should be taken into account before we make this change in a hurry :)

#3 Updated by sajolida over 1 year ago

I'm also not sure what to do... I acknowledge the inconsistency but I also know that GNOME's native applications are the ones in which more UX and design is put on by GNOME, so they are most likely more aligned with "the way forward" in GNOME.

But then we have an option to add the buttons when missing but not to remove them in non-native applications, so I tend to be more aligned with intrigeri's position (= status quo), as I would otherwise propose to consistently remove them.

Still I'm not convinced by intrigeri's arguments as:

  • We're considering removing Tweak Tool (#11237).
  • I don't expect people annoyed by this to scream and shout on our user channel whn discovering 2.0. Having the issues raised only weeks after 2.0 doesn't mean that it's not affecting many people; for me it just means that it's not affecting them badly.

Also, GNOME 3 is relatively new and things are still moving quite a bit regarding core elements, so I'd be curious about looking out for discussion or design documents in the GNOME sphere about these elements. The issue is affecting them as well and I would be surprised if we couldn't find past discussions about this elsewhere.

Anyway, I know that polishing UI and consistency is important but here the problem might be common but I don't think it's that serious and the solution is not clear. So don't expect me to spend a lot of time on this myself but I'm happy to follow up and I won't block decisions that are properly justified.

#4 Updated by segfault over 1 year ago

I forgot to add myself as a watcher, so I only saw your replies just now.

Wrt. the minimize one: why not, but I'm slightly concerned that this (+ the habits that go with it) relies upon the windows list ("task bar"), that we currently have since we run GNOME Shell in Classic mode, but it's not obvious that we'll have it forever (e.g. we may decide to move to the regular GNOME Shell for Tails 3.x or earlier, and GNOME Classic might become less well supported if enterprise desktop distros move to the regular Shell experience)

I think we should not move to regular GNOME Shell, even if enterprise distros move. My argument is the same as above: GNOME 3 might bring some nice UX once users get used to it. But most Tails users only use Tails occasionally and thus will have a hard time getting used to new desktop concepts. IMO users expect something like a taskbar and if at some point we feel that GNOME Classic is not well supported anymore, I think we should consider switching to one of the many other desktop environments which still offer taskbars: KDE, xfce, LXDE, Cinnamon, Mate

this can be changed in GNOME Tweak Tools;

But we don't support storing these changes persistently. So users would have to do this everytime they boot Tails and want to minimize a window.

adding widgets makes UX worse for everyone who doesn't need them

I think the UX regression of having another button next to the existing close-button is far less than the annoyance of not knowing how to minimize this one window, while you can minimize all the other windows. Also, because the buttons are present on other windows, I think even the UI inconsistency outweights this point.

this problem was not raised during the 2.0 testing phase (beta, RC), and it was just filed a couple weeks ago, so I doubt many users have problems with the current situation; with this in mind, I'm not convinced the pros/cons ratio of the proposed change is favorable.

I think many users have this problem many very few users will make the unproportional effort to complain about this. Especially because there are other ways to minimize the windows which users might figure out after some time (right clicking the window's menu bar and choosing "Minimize" or clicking the corresponding item in the taskbar).

GNOME's native applications are the ones in which more UX and design is put on by GNOME, so they are most likely more aligned with "the way forward" in GNOME

Like I said above, I don't think we should follow GNOME's way forward but keep to what users know and expect.

#5 Updated by sajolida over 1 year ago

  • Duplicated by Bug #11367: Make it easier to minimize windows added

#6 Updated by sajolida over 1 year ago

  • Target version set to Tails_2.4

And now we have a duplicate of this from the help desk in #11367. So I'm a tiny bit more convinced we should add these buttons :)

Marking this for 2.4 so we don't loose it from sight. If anonym has a strong opinion on this I'll let him merge or reject. Otherwise we could bring it to the monthly meeting but I'm not sure it's worth it.

#7 Updated by intrigeri over 1 year ago

If anonym has a strong opinion on this I'll let him merge or reject.

Works for me, with the additional note that if it's decided that we add these buttons, I personally won't feel committed to maintain that piece of delta e.g. on our way to Debian Stretch and newer.

I'll refrain from arguing more here on the general / strategic topic of "following GNOME's lead", what desktop interface users are expecting (or not expecting anymore) in 2016, etc. But if this pops up again in some other specific situation, I think we'll need to have this conversation e.g. on tails-dev@, before we establish too many precedents in one way or the other.

#8 Updated by sajolida over 1 year ago

I played with Ubuntu 16.04 today, and there gedit, Files and the others all have the three buttons consistently.

#9 Updated by sajolida over 1 year ago

  • Subject changed from Inconsistent titlebar button layout on different applications to Bring back "minimize" and "maximize" buttons in titlebars by default

So I search a bit for discussions within GNOME about this topic and found this:

With quotes like:

  • « They don’t make sense within the current shell design. There’s nothing to minimize to, like a dock or window list, and it’s potentially confusing, since users will not know where their windows have gone. »
  • « The minimize icon is a remnant of the GNOME 2 taskbar and has nothing to do with the GNOME 3 experience. (Really, we don't have minimization at all, we have "hiding") »

My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

Meta: I had a good time doing this research this time, but as a general dynamics, I'd really prefer if the people proposing a diversion from upstream backed it up with data gathered upstream as well about the reasons behind a given behavior. This shouldn't be the job of people initially resisting a diversion from upstream.

#10 Updated by sajolida over 1 year ago

But thanks for raising this point as I finally agree with the initial proposal :)

#11 Updated by segfault over 1 year ago

So I search a bit for discussions within GNOME about this topic and found this:

https://afaikblog.wordpress.com/2011/03/01/where-did-the-buttons-go/
https://mail.gnome.org/archives/gnome-shell-list/2011-February/msg00192.html

With quotes like:

« They don’t make sense within the current shell design. There’s nothing to minimize to, like a dock or window list, and it’s potentially confusing, since users will not know where their windows have gone. »
« The minimize icon is a remnant of the GNOME 2 taskbar and has nothing to do with the GNOME 3 experience. (Really, we don't have minimization at all, we have "hiding") »

My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

Great! Thanks a lot for the research!

Meta: I had a good time doing this research this time, but as a general dynamics, I'd really prefer if the people proposing a diversion from upstream backed it up with data gathered upstream as well about the reasons behind a given behavior. This shouldn't be the job of people initially resisting a diversion from upstream.

I agree. I should have done this research. I didn't think about it. I guess it's because I didn't expect to find arguments in my favor in upstream discussions. And I thought my arguments might be convincing on its own, but I see that it helps to understand the decisions of upstream and that their reasons actually don't apply to our situation :)

#12 Updated by intrigeri over 1 year ago

My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

Makes sense, thanks for doing the research!

#13 Updated by elouann over 1 year ago

My conclusion is that minimize should go along the windows list that we have in the bottom. Since we decided to have the windows list we should have minimize. The day we decide to remove the windows list we should remove minimize.

+1, and thanks for the researches
Tails also differs from upstream by adding links on the desktop: minimizing windows is usefull to access the Tails offline documentation, for example

#14 Updated by intrigeri over 1 year ago

  • Status changed from Confirmed to In Progress
  • Assignee set to anonym

#15 Updated by anonym over 1 year ago

  • Assignee changed from anonym to segfault
  • QA Check changed from Ready for QA to Dev Needed

segfault, when I build your branch I get this build error:

Updating the system DConf databases
unable compile /etc/dconf/db/local.d: /etc/dconf/db/local.d/00_Tails_defaults: [org/gnome/desktop/wm/preferences]: button-layout: invalid value: :minimize,maximize,close (0:expected value)
chmod: cannot access '/etc/dconf/db/local': No such file or directory
E: config/chroot_local-hooks/20-dconf_update failed (exit non-zero). You should check for errors.

Are you sure it's not supposed to be a list of strings, e.g. (untested):

[org/gnome/desktop/wm/preferences]
button-layout = ['minimize', 'maximize', 'close']

#16 Updated by segfault over 1 year ago

  • Assignee changed from segfault to anonym
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to segfault: bugfix/11270-add-minimize-maximize-buttons-to-GNOME-apps

It's supposed to be a string, but I forgot the quotes. I added them in a new commit and now the dconf update works.

#17 Updated by anonym over 1 year ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 0 to 100

#18 Updated by anonym over 1 year ago

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#19 Updated by anonym over 1 year ago

  • Status changed from Fix committed to Resolved

#20 Updated by intrigeri 3 months ago

(From a rabbit hole that lead me from #13461 to #11717 and this ticket..)

From what I've heard in a GUADEC talk, a careful design decision resulted in dropping the "minimize" button. The idea is that the user should not have no mentally/internally manage themselves the list of currently running apps: hiding windows forces them to do that. This approach is consistent with displaying one single icon in the dash for an app, regardless of whether it's started or not, and with the lack of a task bar: if I want to use a given app, I'll click its launcher, and I don't need to know if it's already started (=> go to task bar) or not (=> go to apps menu); if I don't want to use it anymore, I can simply close it (and next startup will be fast because it's in the disk cach); and if I want to keep tons of apps running at the same time (my use case!), then I can use virtual desktops. I found this explanation convincing, but I'm aware I'm very easy to convince that GNOME decisions are good ;)

All this confirms the results of the research sajolida did earlier on this ticket: having a minimize (sic; it should be called "hide") button is consistent with displaying a taskbar. They go together, and if we ever want to drop one of them, the other should go away as well.

#21 Updated by intrigeri 3 months ago

  • Related to Bug #13461: The Desktop icons are sometimes not displayed since the upgrade to Stretch added

Also available in: Atom PDF