Left-clicking a launcher icon does at least 8 different things

Bug #923228 reported by Cavia Porcellus
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Fix Released
Undecided
Unassigned
Unity
Fix Released
Undecided
Unassigned
unity (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I've been using Unity (Natty and now Oneiric) for a while now and really like it, but have found window management via the launcher to be quite problematic, namely because when there are multiple instances of a program open, a slew of things can happen. I'd like first to lay out how the currently system works and then lay out some of the problems it causes, pointing out the inconsistencies within that system along the way. Finally, I'd like to propose a simpler system for what left-clicking on a program icon on the launcher does. Apologies if this has been discussed before (or if this is the wrong place for this report), but I haven't found a conversation/bug that directly addresses the complexity and multiple inconsistencies of the current system as I hope to do.

If you left-click a program icon in the launcher the following things will happen:

Case #1 - There is no instance of a program open. Pressing the icon opens an instance of that program.

Case #2 - If there is one instance of a program running, but the focus is on another program, pressing the icon will bring it forward - whether it is minimized or not.

Case #3 - If there is one instance of a program running and it has focus, clicking the launcher icon does nothing at all.

Case #4 - If there are multiple instances of a program running and the focus is already on one instance, then all instances are shown in scale mode and the user can pick one which becomes the focus. The ones left unchosen are not brought forward - it doesn't matter if they are minimized or not, they stay where they are.

Case #5 - If there are multiple instances of a program running, the focus is not on any of them, and they are unminimized, then all instances are brought forward above all other windows, the last used one to the top. Worthy of note is what happens if you go a step further: if the one just brought into focus is minimized or closed the others return to their previous positions - either behind other programs' windows if opened, or they disappear if they were originally minimized. This is perhaps the system's most baffling behavior. You can actually do some confusing things here. (E.g. Use the top window just opened, then click on one right below it, then minimize them both. The other instances remaining that were summoned upon clicking the launcher icon and are currently on top will actually all go back to their previous state from before you initially clicked the launcher icon - even if it was hours ago!)

Case #6 - If there are multiple instances of a program running, the focus is not on any of them, and some are minimized, then the unminimized ones will be brought forward - EVEN IF the last one used was a minimized one. The same weird behavior of windows changing positions later, as seen in case #5, also applies here.

Case #7 - If there are multiple instances of a program running and all instances are minimized, they are *all* brought forward - sort of. They are all opened and displayed, but if there are any other program windows open, only a single one of them (the last one minimized) will be in front of those other programs' windows. Unlike in cases #5 and #6, if that one window is minimized/closed, the others stay sitting there, and do not return to their pre-launcher-icon-click position.

N.B. The above cases deal only with using a single workspace! There are actually several more possible cases if you have applications spread across more than one, but on the whole they stay within the same paradigm. If you have multiple instances on multiple workspaces, clicking on the icon generally deals only with instances on that single workspace. However, when you click in a way that invokes the scale view you will see all the windows from all workspaces... This in and of itself might be inconsistent, but for now let's leave how workspaces work out of it.

I will, however, include one more case, because it directly contradicts what happens in #7:

Case #8: If there are multiple instances of a program running and all instances are minimized, but you click the icon from a workspace without any of the programs running, scale is not invoked. Rather, the view is first shifted to the workspace in which the last instance was minimized and that single instance is opened – the others stay minimized.

The problems:

The main one is simple: the system is terribly confusing, especially when it comes to having multiple instances of a program open. Clicking on a launcher icon can cause at least 8 different possible things to happen – and sometimes (#5, #6), what you do next to a window can affect the position of the windows without any direct user input (i.e. without hitting the window controls in the title).

This is all largely do to several inconsistencies:
If there are multiple instances of a program open, sometimes scale is invoked (#4); sometimes all the instances are brought forward (#5); sometimes only some of them are (#6); sometimes they are brought forward, but not necessarily on top of other programs' windows (#7); sometimes only one is (#8); sometimes the last used instance brought to the very top (#5, #7, and #8), sometimes not (#6).

It is extremely difficult to pick out one instance from many – especially if one intends to use it in conjunction with another program. This is, in my opinion, a very big problem.
Here is an example where someone's workflow is totally broken by this:
A student is taking notes in LibreOffice Writer from multiple pdfs (opened with Evince). It is convenient to open all the pdfs at once, then minimize the pdfs not immediately needed. Yet if the student wants to choose another pdf, all of them may be brought forward first (depending on the focus of the current window), then another click is needed to spread out the instances to choose the correct one, then another click is needed to bring back Writer (obscured by bringing forth all the pdfs), and then many more clicks are needed to minimize the other windows that might cloud up the screen and distract the student from the immediate task.

The solution:

*Invoke scale every single time the launcher icon is clicked when there are multiple program instances open. The ones not selected stay where the user put them previously, minimized or not.*

This would have the benefit of providing a simple and consistent system, one that would still be flexible enough to pick and choose specific instances of a program when many are open. Left-clicking the launcher would only really do two things: bring up a window if there was no or one instance open, or let the user choose which one could be brought forward via scale if there were many. (I can perhaps dream of ctrl+clicking in scale to bring up several at once, but I shouldn't get ahead of myself.)

The only downside I can really think to this proposal is if you want the last window you used to pop up every single time you hit the launcher icon. Of course, that is not what happens in all cases currently, but I suppose another solution, then, would be to force this to happen (i.e. fix cases #5, #6, and #7), and only invoke scale in case #4. However, this makes choosing a window in a timely manner impossible; it also leaves a window hanging out there that might be unwanted (as it assumes the user always wants the last focused window), and still means that left-clicking a launcher icon does a slew of different things.

I've seen calls for being able to minimize by clicking a launcher icon, or opening new windows, or even moving to a window-centric form of icon display. Those certainly have merits, but my focus here is to hew as closely as possible to the current application-centric system while fixing the aforementioned inconsistencies. There is still the problem of workspace inconsistency, though I have read that it might be addressed separately. Regardless, scale could be chosen to only display windows on the current workspace or not - it really doesn't matter that much, as either way would get rid of the inconsistencies with bringing window(s) forward.

In sum:
Get rid of this weird-bringing-forward-multiple-windows-sorta-sometimes and use scale consistently!

Thank you and apologies for the length!

Tags: needs-design
Tim Penhey (thumper)
Changed in ayatana-design:
status: New → Incomplete
Revision history for this message
Bilal Akhtar (bilalakhtar) wrote :

Well ,shouldn't this be New in Ayatana Design?

tags: added: needs-design
Changed in unity (Ubuntu):
status: New → Incomplete
Changed in unity:
status: New → Incomplete
Revision history for this message
Cavia Porcellus (caviaporcellus) wrote :

I wrote the above since I was confused as to what the proper left-clicking behavior was even supposed to be. The main problem are the behaviors when there are multiple instances of a program open and the application doesn't have focus. Only the last used window should be brought forward when the launcher is left-clicked - not multiple ones as seen in cases 5-7.

I suppose I'll file a separate bug directly addressing this issue.

Changed in ayatana-design:
status: Incomplete → New
Revision history for this message
John Lea (johnlea) wrote :

@aibaraiduas; thanks for your detailed bug report ;-) The issues with what you identified as Cases #5, #6, and #7 should be fixed as part of the patch that fixes bug #959339

This fix will land in either the 'Release Candidate' release or the final release on the 26th of April. It would be much appreciated if you could re-test after this fix lands.

thanks!

John Lea (johnlea)
Changed in ayatana-design:
status: New → Fix Released
Changed in unity (Ubuntu):
status: Incomplete → Fix Released
Changed in unity:
status: Incomplete → Fix Released
Revision history for this message
Cavia Porcellus (caviaporcellus) wrote :

I just upgraded and all of those cases are indeed fixed. Thank you!!!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.