I agree---this is a change from the Gnome that shipped with Ubuntu Hoary to Dapper, and it's driving me absolutely nuts.  (I'm referring specifically here to what happens if you have a tab like "Firefox (50)" and the list that pops up if you click on it---if I've got 50 windows, opened over a span of weeks, I want them organized chronologically, because many of them will have -identical- names since many websites serve the same page title with -every- page---and the titles chosen are (from my perspective) random anyway.  Hence, alphabetical ordering turns -my- strategy of spatiotemporal ordering (e.g,. older windows are higher in the list) into an effectively -random- order.

(I don't want to have to remember the exact name of a page from some site I've never seen before that I -just- visited---I want to know it's the bottommost page in the list!  Otherwise, I often have to resort to experimentally opening a dozen pages in the list (after first spending a minute or two scanning them all) just to figure out where the page went that I was -just- looking at.)

This bugs me so much that I'm seriously considering holding off on upgrading my desktop from Hoary to Dapper or beyond, because when I upgraded my laptop to Dapper, I spent most of a week on the road wanting to throw it out the window while trying to keep dozens of pages---all with random, nonsensical, or identical names---straight.

To make it clearer, the current behavior is roughly equivalent to telling someone who arranges windows in some particular layout on their desktop, "Every time you create a window, Gnome will rearrange -every- window on the desktop to be the same size and will tile them alphabetically across the desktop, with no way to turn this off."  I'll bet that the vast majority of Gnome users would leave immediately, having been driven mad by this sort of gratuitous behavior.

FWIW, I filed questions about this at http://ubuntuforums.org/showthread.php?t=307793 and especially http://gnomesupport.org/forums/viewtopic.php?p=54819 and they may help explain the reasoning here.  I find it amazing that this isn't configurable; was there any discussion about -why- this change was done in any changelog or the like, and was it a deliberate change or just a random accident from some attempt to sort other things in the UI as well?

If there is -any- workaround for this (or even if someone knows what I should change & recompile, if I must be reduced to having my own private patch for this), I'd be grateful.  Thanks!

(I've grepped for "sort" in the entire gnome-panel source tree, and none of the uses there seem directly related, and I've looked through the source of wncklet/window-list.c (which doesn't actually have the word "sort" in it at all), but my perusal so far hasn't found where this list is getting sorted.
OTOH, this is a lot of code, and it's the very first time I've ever looked at it.)

FWIW, some users prefer the current behavior. Yay for the "no perfect solution" problem.
I'd hate to introduce a setting for this...

(In reply to comment #2)
> FWIW, some users prefer the current behavior. Yay for the "no perfect solution"
> problem.
> I'd hate to introduce a setting for this...
> 

That's why I originally asked the ordering to be configurable, not simply reverted to the original. Being able to choose between two options is better than either one of them by its own.
Although these days, it looks like Gnome thinks less configuration is better, not more...

(In reply to comment #3)
> That's why I originally asked the ordering to be configurable, not simply
> reverted to the original. Being able to choose between two options is better
> than either one of them by its own.
> Although these days, it looks like Gnome thinks less configuration is better,
> not more...

The thing is, for the tasklist, nearly everything should be configurable to have everyone happy. Sort order in grouped windows, sort order, show icons, show text, size of buttons, etc.

(In reply to comment #4)
> (In reply to comment #3)
> > That's why I originally asked the ordering to be configurable, not simply
> > reverted to the original. Being able to choose between two options is better
> > than either one of them by its own.
> > Although these days, it looks like Gnome thinks less configuration is better,
> > not more...
> 
> The thing is, for the tasklist, nearly everything should be configurable to
> have everyone happy. Sort order in grouped windows, sort order, show icons,
> show text, size of buttons, etc.
> 

So what's the harm in that? I cannot imagine making something configurable would cause any harm or make the software worse in any way. If someone likes the default setting just fine, or doesn't even understand what the configuration does, he/she can leave it alone.
The only thing I see for not fixing this is that the developers might be too busy fixing more critical bugs.

(In reply to comment #5)
> So what's the harm in that?

http://ometer.com/free-software-ui.html

See also http://ometer.com/features.html.

I still think having the possibility of configuring grouping methods would not hurt anything, provided that it does not create too much extra work for the developers to actually code.

If people think the user interface of the Gnome Panel becomes too complicated, crowded, or even scary to use, the configuration doesn't need to be implemented in the user interface at all. It could be a variable setting in some configuration file in the /etc directory or something. Normal, non-power, users wouldn't need to know it exists.

I'm all for avoiding confusing Linux newbies and people who just want a working OS, not a cool hacker toy, but simplicity does not always mean minimalism, and having few features is not the be-all and end-all.

This is particularly the case when talking about features or configuration options that were there previously, but some developer felt the need to intentionally remove.

(In reply to comment #7)
> I still think having the possibility of configuring grouping methods would not
> hurt anything, provided that it does not create too much extra work for the
> developers to actually code.

I think window grouping itself provides way too much extra work for us, due to being throughly buggy and utterly impossible to make "just work".  We can fix individual bugs in isolation, usually, but almost always at the expense of introducing new bugs elsewhere.  It seems to me that the design is simply wrong.  I've asked Havoc and a few of the usability folks about it (a few years ago when I looked into all of it), and they couldn't figure out how to fix the mess either.  It seems to me that adding configuration options would just make the mess worse (though maybe it'd get messy enough that someone will come along with a rewrite like gimme and we can ditch the current tasklist altogether?).  As I've said on other bugs, I'm in favor of nuking window grouping entirely.  Sorry if that sounds harsh, but I really don't see how to fix the big picture, which I really think needs to be done first.  What'll even sound more harsh to you is that I no longer feel grouping is worth my time to even attempt to fix it (an opinion Havoc shared), but I really don't want to make it worse in case I do get such time or someone else comes along.

Of course, that's just my opinion.  If Vincent feels differently, I'll defer to him since he's the gnome-panel maintainer and it's more of a gnome-panel issue than an interaction with metacity kind of issue.

If the reasons for not implementing the new configuration options are technical rather than philosophical, then I can agree and relate to your position.

If window grouping were to be removed entirely, would the windows then simply appear in the taskbar separately? If so, and they appeared in the order they were originally opened, then that's fine with me - it's almost what I wanted all along.

I'd really like to argue for making it possible to -not- sort, as the original requestor asked for.  It seems to me there are two issues here:

(a) "But then everything should be configurable."  This is a strawman argument.  This particular bug report is asking about a -single- behavior, and one that -used to exist-.  It's not asking for the whole world on a platter, and it's not necessary to make everything possible configurable just to fix this one issue.  By invoking this strawman, you're trying to blow up any possible issue into complete insolubility.

(b) "The code is too incomprehensible to modify."  This could be true, but it's hard to believe that it's impossible to know how to do this.  The code -used- to do this, and, as far as I can tell, the -removal- of a single call to qsort should fix it.  The problem is, where is that call?  If it's -that- incomprehensible, how was this change made in the first place?

Let me offer some suggestions here about these two items:

(a) There's no need to complicate the UI to make this configurable; I'm thinking an entry in the same place used by gconf-editor.  Surely adding a single item there and thus a single flag isn't a huge problem and is both quick and easy to do.  The setting can be documented somewhere, and presumably will be findable via websearching anyway.

(b) Since the current behavior changed (as far as I can tell, and I've done a bunch of searching on this) with neither notification in the changelog -nor- discussion online about what the right thing is for it to be doing, it looks to me like a bug, e.g., it's a change in behavior that was neither discussed nor documented.  Was this in fact an intentional change?  If so, who changed it, and where's the commit?  That should yield enough information to revert it, or make it conditional, or something like that.  (I spent an hour or two looking through the code when I first discovered this, but it wasn't obvious where this behavior was implemented because it's the first time I've ever seen this code.  I suppose I could attempt to check changes between Hoary [where this works the way I'd like it to work] and Dapper [where it doesn't], but that's an awfully large changeset.)

And remember---some users do NOT want gratutious reordering of windows because they CANNOT change the window titles (e.g., web pages, etc), and thus have ONLY a spatial or temporal means of keeping track of similarly- or identically-named windows.  Sorting them with no option to avoid this behavior makes it impossible to navigate, and it's so irritating that it's caused me to hold off on upgrading to Dapper on all but the single machine where I discovered this behavior.  (Alas, I'll probably be forced to upgrade very soon, since Hoary is obsolete.  But I'm not happy about it.)

Thanks for listening.  If there's something I can do to help (short of "figure out everything about the code and submit a complete patch"), please let me know.

(In reply to comment #10)
> And remember---some users do NOT want gratutious reordering of windows because
> they CANNOT change the window titles (e.g., web pages, etc), and thus have ONLY
> a spatial or temporal means of keeping track of similarly- or identically-named
> windows.

It turns out that I hadn't thought of dynamically changing window titles when I half-heartedly supported this change (see bug 335654 comment 2).  I'm guessing those in favor of this change just don't deal with dynamically changing window titles, at least not with grouped items (I *always* turn off window grouping personally).  Because of changing titles, I strongly feel we should revert this change.  See also bug 171804 comment 7 from Liam which argues this.

Some related usability rationale for reverting can be found in a similar issue.  When I suggested MRU order for sorting ungrouped tasklist items, Federico pointed out a usability study by Microsoft where they had tried precisely this and found that users were really confused by it due to the order of items changing often (see tail end of http://mail.gnome.org/archives/desktop-devel-list/2004-October/msg00383.html).

Vincent: Okay to revert, or can you think of some counter usability rationale?

Looks like some users want alphabetical ordering, while others (including me) want spatio-temporal ordering. I think this means that the user should be able to choose between the two. Either with a nice GUI configuration window, or some option hidden deep inside the /etc directory or something.

This isn't worth a configuration option at all, IMO.

(In reply to comment #11)
> Vincent: Okay to revert, or can you think of some counter usability rationale?

To be honest, I don't care that much since I'm not using a tasklist. I'm not sure the argument of reordering works here, though. If you open a new window that will appear in that group, and then close another window of that group, it *will* reorder things in the sense that the last item won't be last anymore and the one that was 3rd might become the 2nd.

You could argue that it's like the tasklist buttons, except it's not: the tasklist buttons are always visible, so you don't expect them to move around, while the grouped windows are hidden in a menu.

(In reply to comment #14)
>
> To be honest, I don't care that much since I'm not using a tasklist.

Awesome, I'll take that as permission to revert then.  Can I also change the default to "Never group windows" too if you never use the tasklist?  Grouping *sucks*.  (I'd prefer to nuke it entirely as I've beaten to death elsewhere, but don't think that'd go over too well yet.  I've thought that we should at least change the default for years, though.)

> I'm not sure the argument of reordering works here, though. If you open a new
> window that will appear in that group, and then close another window of that
> group, it *will* reorder things in the sense that the last item won't be last
> anymore and the one that was 3rd might become the 2nd.

I think the thing that matters most is the relative ordering of open windows.  Sure, adding more windows or closing windows changes the absolute ordering (which is unavoidable) by adding to or deleting what's at the end of the list, but I think that's much different and better than the alphabetical rearrangement:
- Change in position due to opening/closing feels like a user-initiated action rather than a random action, and thus won't surprise users
- The preservation of relative ordering of open windows makes sure the changes that only the minimum amount of change necessary occurs, which I believe will assist in finding the appropriate entries in the popup more quickly (if accessed often).

> You could argue that it's like the tasklist buttons, except it's not: the
> tasklist buttons are always visible, so you don't expect them to move around,
> while the grouped windows are hidden in a menu.

I think it is like the tasklist buttons.  It's just that users would be surprised/confused _frequently_ by the tasklist buttons changing (due to them always showing), and only occasionally being surprised by the grouped window order changing (since they will only be shown when the user clicks on the group button).

(In reply to comment #15)
> (In reply to comment #14)
> >
> > To be honest, I don't care that much since I'm not using a tasklist.
> 
> Awesome, I'll take that as permission to revert then.  Can I also change the
> default to "Never group windows" too if you never use the tasklist?

I've changed the default in the window list applet preferences. I'm not sure the default in libwnck matters that much, but feel free to change it there too.

In fact, we already have a bug about reverting this: bug 171804.

*** This bug has been marked as a duplicate of 171804 ***

So, has the ability to NOT sort alphabetically been added in any way?  I just tried booting Gutsy (and I'm not sure how to tell which of the various patches to this might be in that release), and it has the following behavior:
(a) No grouping, unless I find the relevant UI switch and throw it.  I can live with that, by leaving the switch thrown.  (I don't recall the name of that switch, since I booted a LiveCD a few days ago when I was playing with this.)
(b) Windows are STILL sorted alphabetically!  And I can't find any way to turn this off.  I've been waiting for this alphabetical-sorting to be reverted for about two years now (it was okay in Hoary, and all Ubuntu releases since then have had the involuntary sorting), and I'd really love to stop waiting...

Thanks!

[Filing this here as well since this bug was marked as a duplicate of #171804.]

Since this change has -still- not been reverted, and for the benefit of those following this bug, please see the last couple of comments in bug 171804 where I show a painless of way of getting what you want.  (This bug was marked a duplicate of that bug, but I don't know if that means that anyone who was following this bug will see comments made to that one.)