** Changed in: ayatana-design
Status: New => Fix Released
** Changed in: unity (Ubuntu)
Status: Incomplete => Fix Released
** Changed in: unity
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity
https://bugs.launchpad.net/bugs/923228
Title:
Left-clicking a launcher icon does at least 8 different things
Status in Ayatana Design:
Fix Released
Status in Unity:
Fix Released
Status in “unity” package in Ubuntu:
Fix Released
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!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ayatana-design/+bug/923228/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
