Version: unspecified (using KDE 4.5.95) OS: Linux In r1193863, a codepath got cleaned up concerning ordering the taskbar-entries. For me, the change is bad, as the behaviour got worse. I have the taskbar forced to 2 rows. Previously, the order of entries in there were sorted like this: 1 3 5 7 2 4 6 8 after this change, the order is like this: 1 2 3 4 5 6 7 8 the problem with this sorting method is, that on opening a new window, the new order is: 1 2 3 4 5 6 7 8 9 which means, lots of items get shuffled around on the taskbar. with the old sorting method, all items stayed in place: 1 3 5 7 9 2 4 6 8 i have fixed the behaviour now for myself by reverting the above commit, but ideally there should be a setting to choose between row-based and column-based ordering. Reproducible: Didn't try
Created attachment 62321 [details] Revert for 4.7.0 In KDE 4.7.0 there is now a second commit to be reverted. The attached patch does both. Sad how long a simple issue like this remains without so much as an official response!
"Sad how long a simple issue like this remains without so much as an official response!" how many hours do you think we have in the day? then go look at the # of bug reports. then go look at our development requirements going forward. in this case, it's been discussed multiple times and here it is (costing more of my limited time, so other issues don't get attention. unfortunate how that works.): * some people prefer one way, others another * we're not adding Yet Another Configuration Item that is hard to communicate the meaning (let alone benefit of) to the user into the config dialog which is already pretty big to satisfy a very tiny # of people a beautiful thing with plasma is that you can replace any part you want. create your perfect tasks widget and use it.
> * we're not adding Yet Another Configuration Item that is hard to communicate > the meaning (let alone benefit of) to the user into the config dialog which is > already pretty big to satisfy a very tiny # of people We don't want to have another config option added. We want you to revert the change(s) that removed the functionality of an already existing config option. How do you want to explain users that there is a config option that does nothing?
(In reply to comment #2) > in this case, it's been discussed multiple times and here it is Although I don't like really like the content of your answer, I nevertheless appreciate having an answer at all. At least now we know where we stand. Ans although I'm deeply disappointed that KDE devs considers this issue not important enough, I will accept that and find my own solutions. > a beautiful thing with plasma is that you can replace any part you want. > create your perfect tasks widget and use it. I currently intend to fork the official kde-workspace git tree, extract the plasma/desktop/applets/tasks subtree from it, apply the patches, rename things so it can become a separate applet, and release it as an alternative. Perhaps even add yet another config option for tab ordering, who knows. It should be possible to keep that applet in sync with upstream development. Won't have a lot of time to spend on this fork, so if anyone beats me to it, I'll be happy. (In reply to comment #3) > We don't want to have another config option added. Not true for everybody: comment #0 explicitely stated: "ideally there should be a setting to choose between row-based and column-based ordering." > We want you to revert the change(s) that removed the functionality of an > already existing config option. True for me personally as well, but comment #2 "some people prefer one way, others another" implies that there are really people out there who want that strange ordering. So although I cannot fathom their reason, I guess we'll have to accept that neither alternative is unanimously accepted to be superior.
> (In reply to comment #3) > > We don't want to have another config option added. > > Not true for everybody: comment #0 explicitely stated: "ideally there should be > a setting to choose between row-based and column-based ordering." > > > We want you to revert the change(s) that removed the functionality of an > > already existing config option. > > True for me personally as well, but comment #2 "some people prefer one way, > others another" implies that there are really people out there who want that > strange ordering. So although I cannot fathom their reason, I guess we'll have > to accept that neither alternative is unanimously accepted to be superior. from reading the patch: Before the change m_forceRows ("Zeileneinstellungen erzwingen" in German) could be used to select row-based or column-based ordering, after the change that option does not seem to have any effect. So before that change by the KDE devs the user had the possibility to choose. Perhaps the option should be renamed, but the change to disable that option should definitively be reverted.
"Force row settings" still does control whether the specified number of rows is used as early as possible, as opposed to when rows become too full. A change in settings only takes effect when opening or closing windows.
I think this report is a duplicate of bug 215231
no, it isn't!
I'm still not entirely sure why this was rejected? it would be a small, clean feature that would save some people a lot of usability troubles...
*** This bug has been confirmed by popular vote. ***
Still haven't created my own applet. But for KDE 4.11 the following works: change a single line in plasma/desktop/applets/tasks/package/contents/ui/main.qml like this: - flow: tasks.vertical ? Flow.TopToBottom : Flow.LeftToRight + flow: Flow.TopToBottom For me, this patch is enough to keep me happy locally, so my incentive to create a new applet hasn't increased much.
Thank you Martin for this patch! Can you tell me: What to do once this change has be done? (I restarted X without any result) I now have kde 4.12.4 and I made a similar change in this file: /usr/share/kde4/apps/plasma/packages/org.kde.systemtray/contents/ui/ I made this change: - flow: GridView.LeftToRight + flow: GridView.TopToBottom