I think this really good. I think the 1.4 behviour is really 
annoying, but that might also be because in 1.4 it often got wrong 
which application is the "active"(user perspective) at the moment. 
On the otherhand this  1.4 problem seems hard to fix, because the 
topmost window isn't nesseceryly the focused one (alway on top 
windows, push windows to back, unusual but really helpful (for 
certain task) sawfish options).

I think it is more consistent without this feature(iconify a focused 
task by clicking it) (Havoc and Co won't approve a option for it 
would they...).

Anyway this overloads the left-single-click on the button with 2 
contrasting options and is not quite the least surprise 
behaviour(expect for ppl coming from win98 and above).

I am missing this feature too, in gnome 1.4 I used it a lot.
Mostly with moving a window to another workspace.

I used this sequence :

- Iconify window by clicking on it in the window-list (or was it a
double clink??)
- Click on another workspace in pager (which is near to the window-list)
- click on the task again to drop it onto the workspace

This sequence doesn't work under gnome2 for two reasons:

- The reason as desribed in this bug-report
- Iconified windows aren't shown in other workspaces (I will file a
bug for this)

So in my opinion this feature should return in gnome2, it is very
unobtrusive and doesn't cause any confusion.(Especially with the
iconify animation used by Metacity) Therefore I see no reason to leave
this feature out.

Bug #81222 describes the second reason of the above comment.

I still think that this feature is on crack, at least if bound to 
single-left click. If it would reappear on double-left click it ok, 
but *please* don't do this on single-left click. I hated windows for 
it('95 got it right).

BTW moving windows to other workspaces could be a nice and easy 
operation, not a trickery with iconize, switch, restore. I have 
installed a nice sawfish addon that just gives me that option in the 
menu of the windows. And a keyboard binding is availible for this 
too (even in stock sawfish).
KDE has a submenu in it's tasklist to send windows to different 
workspaces, this is much more intuitiv than any tricks.

A double-click would be fine with me.

Metacity has option to move it to another workspace too in its
window-menu. 
But for me this is too cumbersom, although I probably will get used it
when no better (IMO) is possible.

AFAICT, in latest builds [when using metacity], this /is/ bound to
double-click. Can someone else confirm please?

I found that out too last weekend, but somehow it isn't consistent.

Somehow it sometime works on a double click, sometime I have to hold
the button on the second click. Sometimes I don't get it triggered at all.

I tried it many times in a row to figure it out, but it seems to work
inconsistently. 
I don't know if it the timing of the double click is too critical or
something similar.

Hmm, now this is strange, just tested it today again, and now it 
seems that now it minimizes active windows on normal click (single 
left).

I dug into the code to see what's up.
from libwnck/libwnck/tasklist.c line 1341:
        if (wnck_window_is_active (task->window))
        {
          wnck_window_minimize (task->window);
          return;
        }
This code snippet in wnck_tasklist_activate_task_window iconifies 
the active window if it is actived again. Otherwise it activates the 
window.

But this code hasn't changed since rev 1.10 (dec 2001). I don't know 
why it didn't work but now does.

I scaned the mailing list archives:
http://mail.gnome.org/archives/gnome-list/2000-June/msg00848.html
may give some hints about this problem.

But just again, I think this behavior is broken, it sould be at 
least double click to minimize the window. Now that i know the pice 
of code that does this. I'll patch my local version...

If somebody is interested in making this work only on double click i 
maybe make a patch...

BTW, this got in without a ChangeLog entry describing, no mailing 
list discussion.
Maybe i should post about this to the usability list.

I found the same piece of code, and it seemed ok to me. But the
behaviour ain't working right. It doesn't work on a single click. 
This should be a double click off course.
I dug some further but sofar I don't have a clear picture of the
code-paths involved, and where the problem might come from.

I did notice the focus changes when I click on the active task in the
list. The focus is given to the panel.
I am not sure if this is the cause, but it could be a hint.

*** Bug 82496 has been marked as a duplicate of this bug. ***

From the duplicate:
NOTE: On gnome1.4 the behaviour was as follows:

(1) To maximise a minimised app user just had to do a simple single click
on the app in the window list applet.

(2) To minimise a maximised app user just had to do a simple double click
on the app in the window list.

there is a related metacity bug. bug 4379 

*** Bug 85366 has been marked as a duplicate of this bug. ***

The simple double-click seems hard to trigger, I need to have a very
fast double-click to get the effect. 
But somehow the window uniconizes right away again.
I tested this with the latest garnome release (0.11.0)

Havoc: it appears from the feedback that this clearly isn't window
list; looks like libwnck or the WM. Can you please pick one? :) 

libwnck would be my guess. The window list applet is just a thin 
wrapper arounda libwnck widget. I tacked the problem down to the 
conditions wnck_tasklist_activate_task_window is called (libwnck: 
tasklist.c). But I don't have time at the moment to debug this (and 
I'm a newbie). I think it doesn't distinguish single and double 
click. It is called every time one of the buttons is _toggled_. I'd 
say just minimize on double click would be an easy solution for this 
problem. No funky focus problems and not as annoying as on single 
click. See my above comments.

(As the anti crackrock people will not accept an option for this 
behavior it would be nice for it not to be to obstrusive, [But i 
know how to patch the code]).

The behaviour I see is click to maximize, double-click to minimize
again.  (This is Sun's RC1, though, so it's based on a snapshot from a
couple of weeks ago).

From a usability point of view, I would just add a word of caution--
having the user double-click a button to do anything kind of sucks. 
Buttons are designed to respond to a single click, and making them do
something else will mostly be undiscoverable in the first place, and
risks breaking users' expectations of buttons elsewhere on the desktop
if they do work it out.

Personally I always find that single-click to minimize/maximize works
perfectly well anyway, though (or it does when I use XP), so what do I
know...

*** Bug 86574 has been marked as a duplicate of this bug. ***

*** Bug 87792 has been marked as a duplicate of this bug. ***

*** Bug 4379 has been marked as a duplicate of this bug. ***

To me single click makes sense, if you think of the window list
buttons as toggle buttons, you toggle the button on to unminimize, and
toggle it off to minimize again. Of course it doesn't quite fly, since
the toggle really reflects whether the window is active not whether
it's minimized, but it still makes a certain amount of intuitive sense
perhaps.

Anyway, there are a lot of requests for this and I can't see it really
confusing/bothering anyone much... martin maybe elaborate on why you
find it harmful? Other than it not working right in 1.4?

Ok, I'll try.
This button have a lot of functions. Simply said it activates 
windows. But depending on WM and options that is not quite all. I'm 
using sawfish with maybe not that newbie options (don't focus new 
windows; don't raise on focus(and click to focus)).
In this setting Active(panel active == has focus) and raised 
(visible) get out of sync a lot and quite easy.
I'm using the tasklist a lot and sometimes don't pay attention 
whether a button is pressed (e.g. the window is focused) when I want 
to show and focus a window. It is annoing to me to minimize that 
window.

Yes, ok I admit this is a typical case of options make you life 
harder. Without these options a selected it would me easier for the 
developers. But I can't agree with Calum that using double click 
would risk our UI conistancy. It's broken anyway the only reason to 
have a tasklist with buttons is that other dekstops do it this way 
to and we don't have a good other idea IMHO.

Calum says that is is a lot of toggle buttons. According to the HIG:
Toggle buttons look similar to regular Buttons, but are used to show 
or change a state rather than initiate an action.

But fucosing and raising is an action to me.

So I'd prefer to have minimize on double click. This would avoid 
some surprises and dosn't add another function to the single click. 
But as I see this is not to easy because all processing is done in a 
callback connected to "toggle" of the button. I'm not sure why 
everybody says it curently minimizes on double click and I can't 
reproduce as my libwnck is patched to never minimize :-).

Do whatever seems right to you, my options maybe way of any 'sane' 
state.

Hrm. Not sure why I didn't mark this high/2.0.1 earlier but it seems
like it should be, given the frequency of requests.

I would prefere minimizing on single-click.  This is the way most
Win32 users are get used to.  

Agree it should be single-click.  User feedback from Sun Beta
is that they find the current double-click inconsistent with 
expectation and experience on other desktops (e.g. Gnome 1.4
or Windows)

Moreover, it seems hard to get double click to register.
Usually it takes several double clicks to get the window
to minimize - not sure if this is a common experience or
just on Solaris.
 

The double-clicking is hard to trigger on my machine (Mandrake) as well

Ok, it seems the decision is to have this feature on single click.
With the policy issues out of the way it's just a window manager 
interaction thing. Here are some notes I can't help in solving this 
problem because of my patched libwnck.
Let me just state (again) that the code is bound to the 'toggle' 
changed signal (single click to toggle a button). So it's current 
behavior is a bug: wnck_window_is_active (task->window) seems to 
return false most of the time(the panel hass just been activated by 
the click into the taskapplet). As i see this it's just a raceing 
condition that lets this work most of the time.

Hope this helps to fix the problem. See my earlier comments for the 
names of the functions involved.

Havoc, what's the right thing to detect that the window has been 
active before the user clicks in the panel?

I think libwnck probably needs to keep a most-recently-used list 
of windows.

Just a thought, please let me know if i am wrong here.
Should we not be handling this in wnck_task_button_press_event.
When event->button == 1, call wnck_tasklist_activate_task_window. But
on a double click though, it could be that the window would maximise
and  minimise consecutively.We may need to avoid that somehow. 

Created attachment 10151 [details] [review]
Patch fixes the min/restore on single click.

Havoc: Please let me know if the approach is correct in the patch,
and if any changes are required, I will re-work on it. Thanks.

I believe it's possible that the was_active_task pointer becomes
invalid if that task disappears before you activate it. You may need
to NULL this pointer if the task is freed.

havoc: I see one more problem here, if the user clicked on the panel
or the desktop background,the window loses focus and  the
"was_active_task" should be set to NULL.I am not getting the right
condition to do that atm :(

Maybe you need an MRU list instead of a single pointer.

I tried the MRU one you suggested. If I am right the MRU list has to
be updated in the update_active_window() in screen.c . The
wnck_task_button_toggled()  is getting called after
update_active_window(), hence the MRU list would be updated with the
panel or the desktop the user would click upon, which beats our 
purpose of having the MRU list, assuming that I am in the right
direction with the way i am supposed to implement MRU list. Please
_correct_ me on that. Just checked that wnck_window_is_active() works
fine in the button_press_event. I am setting a flag here and minimize
the window in wnck_task_button_toggled() based on its value. We also
need to take care to disable the  double click, I think.



--- libwnck/libwnck/tasklist.c  2002/08/02 23:34:27     1.11
+++ libwnck/libwnck/tasklist.c  2002/08/05 16:49:32
@@ -84,10 +84,12 @@ struct _WnckTask

   /* task menu */
   GtkWidget *menu;
   /* ops menu */
   GtkWidget *action_menu;
+
+  gboolean was_active;
 };

 struct _WnckTaskClass
 {
   GObjectClass parent_class;
@@ -1440,12 +1442,13 @@ wnck_tasklist_activate_task_window     (

       wnck_window_activate (task->window);
     }
   else
     {
-      if (wnck_window_is_active (task->window))
+      if (task->was_active)
        {
+         task->was_active = FALSE;
          wnck_window_minimize (task->window);
          return;
        }
       else
        {
@@ -1822,10 +1825,17 @@ wnck_task_button_press_event (GtkWidget

       /* FIXME we should really arrange to destroy the menu on
popdown */

       return TRUE;
     }
+   else if (event->button == 1)
+     {
+        if (wnck_window_is_active(task->window))
+             task->was_active = TRUE;
+        else
+             task->was_active = FALSE;
+     }

   return FALSE;
 }

I think you'd probably scan back in the MRU list to find a window that 
would appear in the task list (ignore docks and such in the list).

*** Bug 90019 has been marked as a duplicate of this bug. ***

Created attachment 10304 [details] [review]
Another attempt to nail this bug

Havoc: Yes, 1.4 has the bug of the double click issue we talked on
irc. I have added a timeout of 150 msecs (arrived at the value based
on trial and error basically), in button_release_event callback 
to ignore double clicks and it works fine. Please let me know if this
patch is okay.

Hi, just talked with Arvind on IRC. Don't have time to read through
all the comments to see if this has already been said, so brazenly
trudging ahead and posting.

I don't think double clicks should be treated specially. In our
standard widget "language" 3d controls like buttons, toggles, etc are
activated with single clicks, and flat things like icons that indicate
otherwise when you mouse over them are activated with double clicks.
Its ok if a user tries to double click the task bar once and finds out
that it does an unminimize followed by a minimize, or whatever. They
will learn quickly, because that is following the consistent behavior
for controls. 

What *will* be confusing is if they do double clicks and then never
quite remember if its a double click or a single click that "makes the
thing go". Its suprising how these sorts of things can actually cause
noticable hesitation every single time they want to do the operation.

This also dillutes the strength of our standard "single click to make
buttons do things" behavior across the desktop.

*** Bug 90339 has been marked as a duplicate of this bug. ***

Created attachment 10400 [details] [review]
Patch as per seth's suggestion.

Thanks, patch applied, turned out to be a really simple patch after
all that. ;-)

ok - I can verify that this is fixed so I am going to close - Dan,
hope this is ok.

closing