As people might also want a sorted list, the user should be able to
select whether or not the list is sorted or not.

-> gnome-panel

Okay, so they're sorted in libwnck, so we yould need the option there.
Moving to libwnck because havoc is better at coming up with reasons
why options like this are a bad idea :-)

I originally intended it to work like a stack 
(the order that wnck_screen_get_windows() returns the windows 
will make it work this way). 

It's currently sorted in an arbitrary but fixed order, the 
only feature of the current order is that windows 
in the same app appear next to each other, and the order 
does not change over time.

I don't think it should be an option, it should just be whatever 
user-tests best, or whatever Windows does, or some other reasonable
default. To make it an option we'd need evidence that for some 
subset of users the default is significantly problematic or less good
than an alternative.

UI team input welcome.

Any UI team input?

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

#86185 has additional suggestions to look at

Oh, I like the suggestion on #86185 (group by workspace, and by
startup-time within a workspace). Unlike other suggestions, it is:

a) not configurable (which in my mind is a bonus; making it
configurable sounds to me like treating the symptoms, not the problem
itself) 

b) simply, visibly mapped to a familiar concrete concept (workspaces) 

For whatever my blessing is worth, I give it for this idea. If you'd
like, Havoc, make a patch to have the task list work like this, and
I'll run it through my testing lab at Ximian. 

Yeah, I kind of like the sound of that too.  IIRC the Windoze task
list orders from left-right (or top-bottom) in the order that windows
were opened as well... of course it doesn't have workspaces so I can't
comment on how it handles those :)

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

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

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

See also bug 143785.

It looks like all dups are asking for order of creation as well, FWIW.  Bug
143785 is a little different in that it requests allow users to be able to
easily move the tasks around in the list (similar to tab reordering in epiphany).

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

It may be worth considering using most-recently-used ordering (which can be
accomplished via the _NET_WM_USER_TIME property).

Advantages:
  - It would also the current buggy grouping method to be disposed of and
    replaced by grouping the LRU (least recently used) windows.  (See also bug
    59692)
  - It allows the user to be able to know exactly how many times they have to
    hit tab with the alt-tab popup to change to a given window
  - New windows with DEMANDS_ATTENTION set would be first in the tasklist,
    making them easier to notice (since DEMANDS_ATTENTION windows always
    appear at the front)
Possible Disadvantage:
  - The tasklist order would by dynamic instead of static.

Either way, both ordered-by-launch-time and ordered-by-most-recently-used time
would be a lot better than the current method.

Federico pointed out the following on desktop-devel-list:

  A well-known Windows developer says they considered an MRU order for the
  Windows task bar, but people found it confusing that the order changed:
 
  http://weblogs.asp.net/oldnewthing/archive/2004/04/08/109775.aspx#110379

So, perhaps my idea wasn't so great after all.  :/  I guess that leaves
ordered-by-launch-time...

Order by launch time shouldn't need to use USER_TIME because one of the lists of
windows set on the root window by the WM is defined to be in map order IIRC.

Yeah, you're right.  _NET_CLIENT_LIST is defined to have initial mapping order
according to the EWMH.  Cool.

Hello all,

Is there a patch which can be applied for the mentioned issue? I cannot find it.
Can you please provide me a link?

Thank you very much.

No.  As far as I know, no patch for this exists.  (It certainly isn't referenced
in this bug anyway.)

Changing version

Wow, no wonder everyone kept requesting this.  I just coded it up, and it's
really nice.  :)

My patch doesn't try to fix window grouping (as far as I'm concerned, it's
unfixable; there's tons of bugs on it and I don't even know anything that sounds
like sane behavior), so I just punt and group windows the same as currently (and
turn off grouping on my machine, as always).

There is one thing that needs mentioning and fixing besides just mapping order,
though.  Current, libwnck sets things up in two rows (if possible), and orders
windows from left to right on the first row and then left to right on the
second.  Thus, we get an order like this:
   a  b  c
   d  e  f
But this sucks because new windows are added to a new column, which results in
big reshuffling.  In this example, if we add a new window, the location of d
changes drastically:
   a  b  c  d
   e  f  g
So, I instead order things like this:
   a  c  e
   b  d  f
And when a new window is added, we get:
   a  c  e  g
   b  d  f

Since things go by mapping order (with the patch), one knows exactly where each
window in the tasklist is and can remember it instead of searching for it. 
Anyway, I'll attach the patch in a minute.

Created attachment 35996 [details] [review]
Fix ordering of windows in tasklist

Comment on attachment 35996 [details] [review]
Fix ordering of windows in tasklist

g_list_position (window_list, 
+			       g_list_find (window_list, task1->window));

seems pretty crazy-slow to have in a sort function that could be called over
and over.

pos1 == pos2 is more of a g_assert (pos1 != pos2) type thing isn't it?

Looks fine otherwise. Maybe WnckScreen could just store a sort key  in the
WnckWindow... ? this should be a pretty simple matter of ensuring each new
window appended has a key higher than the previous window right?

Created attachment 36386 [details] [review]
store a sort key in the WnckWindow

Wow, I didn't know wnck_task_compare was called so many times.	For some
reason, I was thinking that it would only be called when a new window was
created or destroyed (I forgot about window grouping and so I figured that'd be
the only need to rearrange the tasks in the list), and was surprised to see it
called upon something as simple as a focus change.  So, yeah, this patch gets
rid of the list searches.

So, now windows are created with a sort key and that sort key is just
incremented with each new window.  The only trick is that I need new windows
added in mapping order instead of stacking order (which required several small
changes in update_client_list) so that if wnck-applet crashes and is restarted
then the task order doesn't change.  This is probably not really that important
for most users since it shouldn't crash, but is nice for those who might want
to write patches for libwnck or gnome-panel and thus manually restart them. 
;-)

Also, pos1 == pos2 wasn't more of a g_assert (pos1 != pos2) type thing.  It can
and will happen whenever the user has two applications that are starting up but
haven't been mapped yet.  Since you asked about it, though, I added a
clarifying comment in this version of the patch.

Comment on attachment 36386 [details] [review]
store a sort key in the WnckWindow

Looks good to me.

committed.

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

Sorry for raising old issues, but I don't like the current method of sorting according to lunch time - its slightly better then arbitrary sorting, but not by much. I would really love to see a workspace grouping like suggested in bug #86185 and comment #8. 

I apologize ahead of time for mentioning forbidden words in the GNOME bugzilla, but my previous desktop was KDE which orders the task list just like that - order by workspace and lunch time in each workspace group. I understand that many people don't use "show windows from all workspaces", but with that setting enabled order by lunch time alone is very confusing - much more confusing then inserting new tasks in the middle. 

A simple example of the problem is like this: I usually put windows on workspaces according to the task they are used for (I understand this method is quite common) all mail goes on workspace 1, web is on 4, 3 is for terminals, 2 is for development and 5 is for office documents. File browsing and miscellaneous stuff usually go on workspace 6 but sometimes on other workspaces. 

Use case 1 deals with having a lot of short lived windows - I start working on a new email (or a few - I sometimes have more then one mail composer open, started at different times) it goes on workspace 1 but its task list entry could be anywhere. I usually have several new windows open to deal with a new email - file browsers, documents, maybe an image viewer/editor or few - its a real problem when I have several composers open and when I want to jump to one of them I have to scan the entire task list (usually with many similar icons) instead of focusing in one region where I know all my composers are (unlike looking for things on the workspace, I know where workspace 1 is, I don't need to look). The case with file browser windows that can be on any workspace is even more problematic - a file browser is on a specific workspace (and not the last) because its related to some task I'm doing on that workspace, so a file browser used to find something to attach to an email will usually be on the first workspace, but the task list doesn't hint at that - its just one file browser of many on the task bar and I have no idea where to look for.

Use case 2 deals with long running applications: I always have one long running application to fulfill any of the 4 major tasks - email, development, terminal and web. If the tasks list was ordered by workspace, I would know immediately where about I would find my long running application: Evolution would be the most to the left, and Firefox would be the most to the right. But because these applications crash from time to time (especially Evolution and Firefox) and need to be restarted, the lunch time ordering of the task list shuffles them all over the place.

I understand that there are several people that like lunch time based ordering, because it fits better with stack based task management (new tasks need to be completed before old tasks can be resumed), but such ordering wrecks havoc (no pun intended) with spatial based task management (several tasks are being worked on at any single time and workspaces are used to arrange tasks). For this specific feature I think that the approach of choosing a sane default and preventing customization fails because different people work best using different methodologies and optimizing the task list for one methodology to the detriment of other methodologies is not the right thing to do.

Specifically for me, I don't mind if the customization is only available as a gconf setting, or even a different task list applet that needs to be installed instead of the default one - because I wouldn't mind doing that to get a much better (for me) behavior, but I think that adding another checkbox under the "show windows from all workspaces" radio button in the task list preference dialog (that is of course disabled until "all workspaces" is selected) wouldn't be much of a problem usability wise.

(In reply to comment #30)
> Sorry for raising old issues, but I don't like the current method of sorting
> according to lunch time - its slightly better then arbitrary sorting, but not
> by much. I would really love to see a workspace grouping like suggested in bug
> #86185 and comment #8. 

Don't we have a separate open bug for that somewhere?  I had intended that we implement that part at some point too, but thought we had a separate bug for it somewhere...

Could someone do a search, and then feel free to reopen this bug if there isn't such a bug?

I did search for it - that was bug #86185, which was closed as a duplicate of this one.

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

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/2.