Bug 1443

I tested also on TDE 3.5.12 (livecd Ubuntu 10.10) - the bug is there too.

This sounds like the same "problem" I noted in bug report 1399. Tim just pushed a patch to fix some of the misconceptions users might have with the new feature. I will test this along with the other overhauls of the global config dialog.

I think that's not the same problem. I have opened only one panel - only one taskbar and the checkbox does has no effect. Other checkboxes work, as they should.

Ok. Try making the change by opening the config dialog through the taskbar handle. The popup menu will show an option named Configure Taskbar...

(Odpověď na komentář #4)
> Ok. Try making the change by opening the config dialog through the taskbar
> handle. The popup menu will show an option named Configure Taskbar...

This is exactly the way I tried to set this.
Now I tried also Control Center - both ways without success.

Ok. I'll still test when I build with the latest patch.

This is only a bug because the task bar is not reordered after sorting has been enabled; if the task bar is restarted, it orders the applications properly.

Note that if sorting was enabled, disabling it (logically) will have no effect, as there is no reason or method to "unsort" the taskbar.

I'll tell it differently: I have Sort by application name always turned on, but applications on taskbar are not ordered - from the start session, after many logins / logouts.

I too am confused how this option is supposed to function.

I understand that disabling should have no effect, but I am unable yet to figure out how to see any change after enabling. How is the taskbar restarted?

Second, upon what is the sorting based? The taskbar icon text labels are based upon the app's title bar text and not necessarily the app name. Thus, how do I know when the taskbar icons are sorted? Does the sorting take effect only when groupin is enabled?

I'm sure much of the problem is between my ears.

By default, applications is in order in which are executed. A little "shuffle" can cause groupings. In any case, in the order by applications names I expect that such Amarok will be before Chromium, which will be before Konqueror, which will be before KMail, etc. However switch has no influence on the order of applications on the taskbar.

Yes, that is the way I think too, but is that the way the code works? At this point I have no idea the code is broken --- although that could be true --- and instead the code is functioning in a manner contrary to how I think the code should work. I will try to find time to test this in my KDE3 virtual machine. Hopefully the old KDE 3.5.10 will help me see how that option functions.

Yeah - I see what the "problem":

In taskbar.kcfg is the description:
 Sort windows by application

In kcmtaskbarui.ui is the description:
 Alphabetically Sort by application name

Code works in the way that the newly opened windows instead of the end of the taskbar are included after previous windows of the application with same name. So something like "collect windows by applications". On the alphabet does not matter.

I'm still working on this...stay tuned! :-)

I looked at this in 3.5.10 and remain confused. I could not find a pattern to make this work. Based on Slavek's description, looks like this has been broken for a long time?

I'll let you gurus figure this out.

There are actually several bugs in this report, with the root bug appearing to be that TaskContainer::id can return an empty string, and in fact does so for applications such as Amarok.  This, then, makes the grouping and sorting algorithms fail.

Aha! I'm guessing this has been dormant for a long time and probably has been at least partially broken as far back as 3.5.10. :)

(In reply to comment #15)
> There are actually several bugs in this report, with the root bug appearing to
> be that TaskContainer::id can return an empty string, and in fact does so for
> applications such as Amarok.  This, then, makes the grouping and sorting
> algorithms fail.

Fundamentally this appears to be a result of the fact that certain applications (e.g. Amarok, Konsole) do not set the WM_CLASS property.  Furthermore, the instance name is set to "TQt-subapplication", which is a violation of POSIX standards: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5 and prevents the use of a workaround in Kicker.

(In reply to comment #17)
> (In reply to comment #15)
> > There are actually several bugs in this report, with the root bug appearing to
> > be that TaskContainer::id can return an empty string, and in fact does so for
> > applications such as Amarok.  This, then, makes the grouping and sorting
> > algorithms fail.
> 
> Fundamentally this appears to be a result of the fact that certain applications
> (e.g. Amarok, Konsole) do not set the WM_CLASS property.  Furthermore, the
> instance name is set to "TQt-subapplication", which is a violation of POSIX
> standards: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5 and prevents the
> use of a workaround in Kicker.

Fixes for the invalid WM_CLASS atom pushed to GIT in hashes e154d27 (Qt3) and 7e8d6ff (TQt3).  Note that these patches only partially resolve this bug report.

Alphabetisation and immediate application of GUI checkbox setting fixed in GIT hash fe30333.

Great! So how does the sorting algorithm work? How do we test and what do we see?

(In reply to comment #20)
> Great! So how does the sorting algorithm work? How do we test and what do we
> see?

The taskbar items are sorted alphabetically from A to Z, left to right when the checkbox is enabled.  When the checkbox is disabled, the taskbar items are not arranged in any specific order.  Incidentally, this implies that they could retain their existing alphabetised order, though this order would no longer be guaranteed or enforced.

Rebuilding now to test. I thought about this after I posted. I presume the taskbar icons basically insert themselves in the correct order.

Hopefully the foundation is now in place to support manual sorting (bug report 1103)!