Created attachment 22747 [details] [review]
no toggling from active to minimized window state in tasklists anymore

This is actually an issue of libwnck.

Perhaps you use sloppy focus and were annoyed by bug 90134?  If so, we
should mark it as a dup.  If not, we should cc the usability team and
get their opinion--and then cross our fingers and hope they disagree
with you :-) .

Also, please only set the ui-review keyword if you are part of the
ui-review team.  (My apologies if you really are on the team--I asked
in #usability and the person who responded didn't recognize your
name).  I'm removing that keyword.  I'm also adding the bugsquad
keyword while I'm at it.  Finally, when reassigning bugs you also need
to select the "Reassign bug to owner of selected component").  I'll do
that now.

Added CC to usability team, as suggested by Elijah Newren.

Elijah: no, I don't use sloppy focus. Unlike bug 90134, I think that clicking on
a window in the window list should *never* iconify it.

So, right now in 2.6/2.7 AFAICT, a window only iconifies if you click its window
list button while it's at the top of the Z order-- otherwise it just brings it
to the front (un-iconfiying if necessary).  So I guess one question to ask here
is, in general, why would a user bother to click a window list button if its
window was already completely visible, if not to iconify it [1]?  You couldn't
really have the button just do nothing in that case (buttons that do nothing
just generate bug reports), you'd either have to hide or disable it somehow,
which sounds pretty broken.

[1] Possible alternative answer: to put it to the bottom of the Z order.  But
that sounds less useful than iconifying it, to me.

Q: Why would a user bother to click a window list button if its
window was already completely visible?
A: If you have opened several windows, all named alike (say a dozen of
terminals) and your theme doesn't clearly show the difference between the active
and all other windows in the window list applet, you might not know which of the
windows in the window list is the active one.

My point is: If I search a particular window and incidently hit the active one
in the window list applet, I find that quite confusing with all the minimization
animation and the expectation that hitting on a window button will set the
corresponding window at the top.

But why do you want to put many functions on one control element when there
already is another control which governs the desired behavior? For minimizing
there is the minimize button. For setting the active window, there's the window
list applet. Why should the window list applet also minimize windows?

Calum:
This is nitpicking, but it actually only iconifies a window if it is the
currently focused one (although bug 136581 intends to change this behavior
slightly).  The currently focused window is identical to the top of the Z order
for click-to-focus mode, but not for sloppy or mouse focus modes.

Peter:
I can understand now the case why you want it, but:
  1) There is an alternate way to obtain the basic behavior you want
  2) This sounds more like a bug in the terminal app you're using for
     not setting it's title to something more unique.
  3) You appear to be designing for the expert user at the expense of the
     new user.

In more detail:
1) Use Alt-Esc (repeatedly hitting Escape while holding alt until the window you
want is on top).  This gives the basic behavior you want (i.e. find a different
window that you've used when you don't remember which one it is).  You could
also use alt-tab, if you remember where the window you want comes in the list of
most-recently-used windows.

2) For two examples, gnome-terminal will include the current directory so that
multiple terminals can be differentiated; web browsers include the title of the
web page they are currently viewing so that multiple web browsers on different
pages appear differently.

3) Two points:
   A) Most users won't have very many windows open, let alone several of
      the same application (yeah, it bugs me to watch these users
      too; Personally, I'm also the kind to have a zillion terminals open)
   B) Users who don't know what the tasklist are and who click on the
      tasklist entry corresponding to the activated window.  They assume it
      does something, and when they don't see anything happen, they assume
      there's some kind of magical change that just occurred.  As Calum said,
      this results in bug reports, but more importantly, it makes the user
      trust the system less.

I don't know how many unexperienced users would complain about a button in the
window list not working. Think of radio buttons. If I press on the bullet of an
already actived radio button, it stays activated. No one would expect any other
behavior.

I perceive the window list applet to be like a radio button set. Maybe it's just
me, then there's nothing to be done. But I suspect that the current behavior of
Gnome (and Windows, BTW) is unpredictable for unexperienced users (at least true
for those that I've seen).

Moving to the right component. Sorry for the spam.

Thanks for the effort and sorry for the long wait on your bug.  I'm a maintainer
now.  Anyway, we're going to stick with the current behavior.  I'll go ahead and
close the bug out.