Version: (using KDE 4.3.3) OS: Linux Installed from: openSUSE RPMs The normal task button sort order for KDE-4.3.3 seems to be row-major. However, sometimes the user may want to predetermine the number of rows for the buttons. This is possible by using the "Force row settings" setting. However, when this checkbox is enabled, the button sort order changes from row-major to column-major, which may be very confusing to the user (as the y-position of the buttons varies greatly upon opening and closing windows). This bug is related to https://bugs.kde.org/show_bug.cgi?id=126826 .
Is this bug still valid with kde 4.4.4 or kde 4.5beta ?
Yes, this is still valid with KDE 4.5.00. Easy to test by forcing two rows, enabling manual sorting, and moving the window buttons.
SVN commit 1193863 by iwesp: Make order (row-major / column-major) independent of whether the row count is forced. As a consequence, there will be cases where multiple columns are used, but the number of used rows will be less than the specified amount. However, the number of columns used will always be minimal, so this just amounts to a better use of the available space. See <http://svn.reviewboard.kde.org/r/5776/> for the discussion. BUG: 215231 FIXED-IN: 4.6 M +0 -12 taskitemlayout.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1193863
Hi, I just noticed the behavior change when installing the beta2 and IMHO it is a regression :( My use case: I'm using "Manual Sorting" and forced row setting. I have spacial memory, meaning that I remember the location on screen where I "left the buttons". I used to move the "static" applications to the left of the task-bar and organized them there in groups with relevant applications close to each other. With the new behavior it is not possible to group the buttons at the left anymore as every new opened window moves the buttons on the second row. The change is in a way unifying the way the buttons are ordered but the two modes (forced/non-forced) can be seen as two separate use-cases. 1) Without forcing rows, you expect the buttons to start on the first row and then when the space runs out add a new row while decreasing the icon size. This means that the exact location of the button is not as relevant. 2) When forcing the row count you always have the same row height and would expect minimal button rearrangement. The old way the buttons filled up from left to right and the newest buttons where at the right and the old "static" applications stayed at the left close to each other without moving around. The new way the old buttons are at the top spread out on a wide screen which means I have to search much more and the buttons move around a lot more.
Hi, I completely second comment #4. When using horizontal forced rows, windows now jump around all the time, the total number of open windows massively influences the position of a window in the task bar. Especially in combination with a automatically fading panel, this forces the user to search for the right window a lot. I reported this problem some versions ago, and it was fixed back then, which is what got reverted now. This really is a regression, at least it should be configurable if you select manual sorting. As there is already a conditional checkbox for grouping only if the bar is full, I think it should not be a problem to also have a conditional checkbox or two radios for this issue. Greetings!
I just upgraded in a big step from 4.5.something to 4.6.3 and this bug has made KDE unusable for me, as every time I open something, all my tasks jump all over the place. Why would ANYONE prefer this method where the tasks jump all over? Is this going to be fixed?
I sure hope I'm not going to have to learn to build KDE from scratch just to fix behavior that should be correct in the first place.
Created attachment 61219 [details] Source to revert the sort order Here is a tar-ball with just the taskmanager with reverted sort order. Tested on 4.6.0-4 Build ans install the tasks directory.
Hello, Thank you so much! You are a lifesaver. I was actually trying to recompile the module but I've never used cmake as most programming I do is in PHP. =) However, I seem to have a build problem. The relevant portion of the output: [100%] Building CXX object CMakeFiles/plasma_applet_tasks.dir/applauncheritem.o Linking CXX shared module lib/plasma_applet_tasks.so CMakeFiles/plasma_applet_tasks.dir/tasks.o: In function `Tasks::createConfigurationInterface(KConfigDialog*)': /home/trip/kde/task_revert/tasks/tasks.cpp:390: undefined reference to `TaskManager::GroupManager::showOnlyCurrentActivity() const' CMakeFiles/plasma_applet_tasks.dir/tasks.o: In function `Tasks::launcherAdded(TaskManager::LauncherItem*)': /home/trip/kde/task_revert/tasks/tasks.cpp:238: undefined reference to `TaskManager::LauncherItem::url() const' /home/trip/kde/task_revert/tasks/tasks.cpp:241: undefined reference to `TaskManager::LauncherItem::genericName() const' CMakeFiles/plasma_applet_tasks.dir/tasks.o: In function `Tasks::configChanged()': /home/trip/kde/task_revert/tasks/tasks.cpp:140: undefined reference to `TaskManager::GroupManager::showOnlyCurrentActivity() const' /home/trip/kde/task_revert/tasks/tasks.cpp:141: undefined reference to `TaskManager::GroupManager::setShowOnlyCurrentActivity(bool)' /home/trip/kde/task_revert/tasks/tasks.cpp:222: undefined reference to `TaskManager::GroupManager::addLauncher(KUrl const&, QIcon, QString, QString)' CMakeFiles/plasma_applet_tasks.dir/taskgroupitem.o: In function `TaskGroupItem::dropEvent(QGraphicsSceneDragDropEvent*)': /home/trip/kde/task_revert/tasks/taskgroupitem.cpp:1106: undefined reference to `TaskManager::GroupManager::launcherExists(KUrl const&) const' /home/trip/kde/task_revert/tasks/taskgroupitem.cpp:1122: undefined reference to `TaskManager::GroupManager::addLauncher(KUrl const&, QIcon, QString, QString)' /home/trip/kde/task_revert/tasks/taskgroupitem.cpp:1115: undefined reference to `TaskManager::LauncherItem::url() const' CMakeFiles/plasma_applet_tasks.dir/applauncheritem.o: In function `AppLauncherItem::keyPressEvent(QKeyEvent*)': /home/trip/kde/task_revert/tasks/applauncheritem.cpp:91: undefined reference to `TaskManager::LauncherItem::launch()' CMakeFiles/plasma_applet_tasks.dir/applauncheritem.o: In function `AppLauncherItem::mouseReleaseEvent(QGraphicsSceneMouseEvent*)': /home/trip/kde/task_revert/tasks/applauncheritem.cpp:49: undefined reference to `TaskManager::LauncherItem::launch()' CMakeFiles/plasma_applet_tasks.dir/applauncheritem.o: In function `AppLauncherItem::updateToolTip()': /home/trip/kde/task_revert/tasks/applauncheritem.cpp:83: undefined reference to `TaskManager::LauncherItem::genericName() const' CMakeFiles/plasma_applet_tasks.dir/applauncheritem.o: In function `AppLauncherItem::contextMenuEvent(QGraphicsSceneContextMenuEvent*)': /home/trip/kde/task_revert/tasks/applauncheritem.cpp:67: undefined reference to `TaskManager::BasicMenu::BasicMenu(QWidget*, TaskManager::LauncherItem*, TaskManager::GroupManager*, QList<QAction*>)' collect2: ld returned 1 exit status make[2]: *** [lib/plasma_applet_tasks.so] Error 1 make[1]: *** [CMakeFiles/plasma_applet_tasks.dir/all] Error 2 make: *** [all] Error 2 I assume I'm missing a dependency or something, but I don't know what is missing. Do you have any thoughts? Thanks so much. - Trip On 06/21/2011 02:45 PM, Kåre Särs wrote: > https://bugs.kde.org/show_bug.cgi?id=215231 > > > > > > --- Comment #8 from Kåre Särs<kare sars iki fi> 2011-06-21 20:45:07 --- > Created an attachment (id=61219) > --> (http://bugs.kde.org/attachment.cgi?id=61219) > Source to revert the sort order > > Here is a tar-ball with just the taskmanager with reverted sort order. Tested > on 4.6.0-4 > > Build ans install the tasks directory. >
I'm not sure what you are missing, but I would suggest to install at least development packages for kdelibs and kdebase How I compile: - create a build folder in task_revert - in that folder run: cmake ../tasks -DCMAKE_INSTALL_PREFIX=/usr make sudo make install
I thank you for your help. I checked that I had everything noted on this page: http://techbase.kde.org/Getting_Started/Build/Distributions/Debian Plus I went through and found every -dev package with "kde" or "libk" in the name and installed it. Still failing to compile with the same error message. Any other ideas? Thanks. =)
I got it to compile! My problem was a line in the CMakeList.txt file: target_link_libraries(plasma_applet_tasks ${KDE4_KDEUI_LIBS} ${KDE4_PLASMA_LIBS} /usr/lib/libtaskmanager.so.4) Should have been target_link_libraries(plasma_applet_tasks ${KDE4_KDEUI_LIBS} ${KDE4_PLASMA_LIBS} /usr/lib/libtaskmanager.so) I figured that out through a random guess. I'm a very happy person right now, as my taskbar now works correctly once more. =)
can somebody _PLEASE_ reopen this bug and get the crap sorted out? that jumping around of taskbar entries drives me mad -- and to be honest i've never the seem the original bug. currently i have to patch plasma-desktop everytime and build it again, becaus even a minor version change requires a plasma-desktop package of teh same version. and due to the broken alternatives handling of libGL in debian's proprietary fglrx driver packages, i need to build it at home, where i use debian's propietary nvidia driver package which does not have that bug. i append the patch i am using -- apply with -p0
Created attachment 62262 [details] revert crappy fix. apply with -p0
i created #278679 to get the mess sorted out. hopefully, we get a solution soon.
(In reply to comment #14) > Created an attachment (id=62262) [details] > revert crappy fix. apply with -p0 Your patch doesn't work with 4.7 anymore, it needs the rows variable added, see attachment.
Created attachment 62265 [details] fixes the proposed fix for 4.7
Comment on attachment 62265 [details] fixes the proposed fix for 4.7 DOES NOT WORK! segfaults with a trap divide error
There seems to be another bug. numberOfRows() returns 0 here, which does not make sense, as there are 2 forced rows in my taskmanager. so I don't know how to write a working patch for 4.7. For now on my system I hardcoded 2 rows there.
> Your patch doesn't work with 4.7 anymore, it needs the rows variable added, see > attachment. no kde 4.7 here yet. but good to know, i was considering to create someting more sensible, ie a setting in the system settings module (although i am afraid of qt designer -- never really got on well with those graphic ui builders and qt designer in particular). lets hope, my newly created follow-up report gets the necessary attention (*hint*) so the maintainers of the plasma taskbar fix it.
Created attachment 62460 [details] taskmanager with reverted sort order Hi, Here is an updated tar file with a task manager with reverted sortorder for Plasma-desktop 4.7 (smaller and simpler than checking out all of kde-workspace)
Created attachment 62461 [details] A patch that reverts the sort order in 4.7
Reopen because of recent discussion.
*** This bug has been confirmed by popular vote. ***
I think bug 262674 is a duplicate of the current report. According to report 262674, KDE devs won't add an option about that.
> I think bug 262674 is a duplicate of the current report. According to report > 262674, KDE devs won't add an option about that. no, it isn't! this is about reverting a confusing and annoying behaviour to something sensible and useful. 262674 is about a config option -- while i surely would be prefer to have such a configuration, it's not necessarily necessary. and even if it were a duplicate, the amount of agreement only shows that there is a demand for such a change. the arguments for a "wontfix" are ridiculous and only show how the concepts of "freedom of choice" and "let the user decide" are lost on some kde developers (and kde since 4.x) in favour of a patronizing "_we_ know what's good for you" attitude.
Aaron, is there any reason for marking this bug, which "has been confirmed by popular vote", as RESOLVED WONTFIX?
Created attachment 67996 [details] A patch and sources for reverted sort order in 4.8 A patch and source files to crate a taskmanager applet with reverted column/row sort order for those that have a hard time working with the new sort order.
Created attachment 68643 [details] A patch and sources for reverted sort order in 4.8 The previous file was corrupted somehow...
This patch really needs to go to reviewboard.kde.org, otherwise it will most probably be ignored.
Revering the sort-order for "Force row settings" has been rejected already and I do not want to impose my preference on the developers. I just provide the patch and the easily-built sources for those that need it. It could be that it would get more visibility on kde-apps.org, but it requires compiling against the current taskmanager library. It would not be easy to provide binaries that work...
For the love of Spaghetti, thank you Kåre! You really are a life-saver! Your patch works like a charm on KDE 4.9.0 from the ppa:kubuntu-ppa/backports on Ubuntu Precise 12.04 LTS. Gives a warning about how "QRect rect = iconGeometry();" on line 719 isn't used ("[-Wunused-but-set-variable]"), but who cares :D! I have absolutely no idea how this kind of a regression came to be and be classified wontfix... Drove me absolutely mad and it took me a while to find this bug report too. Personally, I wouldn't call asking for this to become a supported option "imposing preferences on the developers", but oh well. It's a good thing we - well, YOU, really - CAN patch it :). Thanks again! I owe you a beer! Or an internet. Your choice ;).
(In reply to comment #29) > Created attachment 68643 [details] > A patch and sources for reverted sort order in 4.8 > > The previous file was corrupted somehow... Hi Kare, thank you very much for your patch! I installed it on top of Kubuntu 12.04.1 and it seams to work very good. I searched hard for a fix of the problem, since in 10.04 all was well (well, KDE 3 was better, but at least I could live with that version). But when I installed this crap version, I was really outraged and nearly installed some other desktop, because I am really, really disappointed with KDE! KMail also dissapointed me to extremes -- and I will not use that sh*** any more. I really, really can not understand, why this bug will not be fixed or at least an option provided for it. The official version is now totally unusual for me. OK, when you come from Windogs or such stuff and just seek something that mimics that stuff somehow, you will be fine with that -- or if you seldom open more than one window per virtual desktop, you also will be glad. But when you want use KDE for professional work -- you should step away from it. For today, your patch, Karen, saves my day! But when I see, how the (professionel) user is treated from these KDE-fellows (1. KDE 3 -> KDE 4 was a big mess 2. KMail is an even bigger one 3. Such bugs, that get ignored, because KDE seams to focus only on the Computer-Kiddies ....) -- as a professionel I want to have some consistency and not every version four things that will not work and disrupt my working style -- I will drop KDE the next possibility coming! If anybody reads this, that has some vote in the KDE-community: Please spread the word! KDE is about loosing many sympathies -- I for my side will not give my word for KDE any more, but give warning to use this stuff, because those people must have contact to real users! KDE should be for the users and ***NOT*** FOR YOUR PLEASSURE!
(In reply to comment #31) > Revering the sort-order for "Force row settings" has been rejected already On reviewboard? Else you should just ignore that this report was closed and submit your patch to http://reviewboard.kde.org, it would make quite a few users happy, and putting a patch on kde-apps.org is not a solution.
(In reply to comment #34) > On reviewboard? Else you should just ignore that this report was closed and > submit your patch to http://reviewboard.kde.org, it would make quite a few > users happy, and putting a patch on kde-apps.org is not a solution. The way I see it, yes, this has been rejected almost 2 years ago on the reviewboard already: https://svn.reviewboard.kde.org/r/5776/.
(In reply to comment #35) > The way I see it, yes, this has been rejected almost 2 years ago on the > reviewboard already: https://svn.reviewboard.kde.org/r/5776/. To HELL with review-board -- to HELL with KDE! I will switch as fast I can away from this stupid bag of people, that are not even able to prevent functionality that has been working since KDE 3 or earlier from eroding -- because they not even have a microgramm of common sense!
While comment #36 used harsh words, i cannot but agree with the arguments the same author made in comment #33. Despite a number of new features, KDE4 handled the transition from KDE3 extremely badly, at least for its serious users. While it amounted to an almost complete rewrite of the KDE3 codebase, the project apparently did not ensure it had the manpower to handle it. Perhaps predictably, most developers swarmed to the sexier parts of the project (semantic desktop crap, anyone?) with the very unfortunate consequence that existing (and important!) components actually got downgraded from the "upgrade"... Personally, i use KDE exclusively as a windows manager. I used to use korganizer but switched away from it when it started requiring semantic desktop as a dependency. OK, i use kate and okular as well. But if its window-managing aspects begin degrading by decisions such as this to refuse fixing basic functionality problems, i will certainly be forced to move to other pastures.
Dear Jürgen, while I can understand your frustration (I myself would VERY much prefer the task bar to behave differently and clearly, I am not the only one) lashing out and calling people names won't do much good either. Developers all over the world put a tremendous amount of effort and love into all the software associated with this project. No matter what - you can't satisfy everybody all the time (cf. Aaron Seigo's comment on this issue: "each way has its strengths and its challenges. [...] i'm also uninterested in having it flip-flop back and forth in implementation. the way it is currently in 4.6 seems to cover a number of user needs very well. can't please everyone, as they say."). I calm myself with keeping the scope of this project in mind! Much like in a democracy, compromises have to be made. Is it frustrating your word isn't always heard and you are "forced" to live with decisions others made and you don't agree with? Yes, very much so! But look around: Nothing is perfect. Ever. Gnome? XFCE? Fluxbox? Windows? Mac OS? They ALL have their grievances! Nobody is stopping you from exploring alternatives. Have you looked into tiling Window Managers, for example? xmonad, awesome, wmii and others do a pretty great job if you really are focused on productivity and don't mind using the keyboard! Unloading your anger isn't helping though. You HAVE a choice. Something that can't be said for many closed source use-cases. From what I can tell, Kåre's fix still works on the 4.9 branch. On this particular subject, I'd suggest to either open another issue on the reviewboard, pointing out the obvious dissatisfaction that seems to stew among the community (I have yet to find a single voice in favor of the "row first" approach - but maybe I'm just not looking hard enough), or to stop merely complaining about it! Again, like in a democracy: Nagging won't change anything. If you want to see some change, act on it! (Then again, voicing your concern this strongly is a way of acting in its own right, I suppose. What else ARE you supposed to do?) I agree that something is wrong here. With the state of KDE and its community in particular. I do think many of the decisions made during the making of KDE 4 have been "misguided" (take the disaster with Akonadi, Nepomuk and Strigi for example) and certain regressions absolutely go over my head (subjectively, power management is one of the areas that used to be pretty okay in previous releases of KDE 4 - the current state of it drives me mad). Other areas have improved significantly, though (take the network manager from a regular user's perspective). Much of this is only is subjective take on this of course. I for one hate the whole social / semantic aspect of "modern day desktops". I don't need any of it, I don't want any of it. If I'm given a choice, I'll gladly ignore it. If you make those things dependencies I can't get around I'm simply not going to use your product. This hurts both the users AND the developers.
Dear Michael, Please correct me if i am wrong but with regards to Aaron Seigo's comment, the initial implementation flip-flop was made from KDE3 to KDE4. Therefore, making the taskbar "column major" again would just reinstore the initial order of things, with which the majority of users was happy. I agree with most of the rest of your comment. I might add that when i, as a simple luser, make a comment on the bug report list, i would imagine the developers who read it will take it up to KDE's hierarchy if they think it's worth it. Asking simple users to take things to review boards and so on starts becoming complicated, especially considering that not all big projects share the same forms of governance, whereas they all have bug-tracking lists. Finally, i think we all agree that our situation is better than closed-source software. But even though we have the freedom of change, it requires time and energy to do so. It may be the solution of last resort if things get really bad but we would all prefer to find compromises. However, as you said yourself, we can find hardly anybody who prefers a "row major" situation! So one cannot help wonder why this is not being adopted as a "compromise" solution in our case!
Because there seams to be nobody of the developers interested in logical arguments, I am convinced my harsh critic was legitimate. It might not be the most polite thing to do and also not the best way to motivate people, but since I must admit that there is no way to change the minds of the necessary people, I don't need to do any politics here! I was very happy with KDE3 -- it was a great product -- but now we only have developers left with much bliss!! Enough said! Why waste any more time here!
Unfortunate for us wanting to stay, undiplomatic outbursts does not help.
(In reply to comment #41) > Unfortunate for us wanting to stay, undiplomatic outbursts does not help. All previous talking did not help either. I am sorry, if I hurt you, but still I think that some things had to be said. When all other diplomatic chitchat does not help, some truth has to be articulated. Call me crude or cruel, how you like!
(In reply to comment #38) > Gnome? XFCE? Fluxbox? Windows? Mac OS? They ALL have their grievances! That is the reason, why I am reacting this way, I did. In my opinion one of the reasons, Linux does not succeed on the desktop is, that all the Desktop systems (Gnome, KDE, ... you named some) are run by software divas. They concentrate on the sexy parts and only follow their own thinking what could be "sexy". Sometimes it is good (KDE 3) sometimes it is just sexy for the developers, but the users can not use it (Akonadi etc.) or it is just for a small number of users "good enough" (Gnome). I reacted the way, I did, because THEY should SEE what consequences their behaviour has! In most cases, the users just stay away or go away, because the software stinks. I think it is also to say, that the fish stinks and than go away. When this also does not help, than it is not my fault and not my business any more. I love Linux, but I hate many of the stinky software it runs. And I hate software divas!
Dear orionbelt2, the way I see it, up to and including KDE 4.5 "column major" was the default way of handling forced row settings (as this report say the bug was fixed in 4.6). So the behaviour didn't flip until then and was present "KDE 3 style" way into KDE 4's development cycle. What I can't really seem to understand is Aaron's comment how "the way it is currently in 4.6 seems to cover a number of user needs very well." Who are those users? If this truly were a democratic process, I'd say we put it to a vote. I'm almost certain "colum major" would get at least a two-thirds majority, seeing that only those in favour of this method seem to care about the issue at hand. I agree with your "users taking things up the ladder might be a bad idea"-bit and tried to hint at it with my statement "Then again, voicing your concern this strongly is a way of acting in its own right, I suppose. What else ARE you supposed to do?". Ideally, multiple user's discontent should be taken to heart and reconsidered. The way I see it, back when Aaron first denied Kåre's plea to re-open the bug report it was pretty much only him (Kåre) stating he was dissatisfied with the way the problem was handled. Ever since, almost two years passed and (if I counted correctly) at least 8 other people demanded this behaviour to be changed (one might even say "reverted back to its rightful state" :P). Maybe we're just not loud enough just yet ;). If this was Windows, 8 people would be a lost cause. In the FOSS-community 8 people have a LOT of power (just consider how much the team behind The GIMP has accomplished with way fewer people, if I'm not mistaken!). Has anybody actually tried to contact Aaron directly yet? Is he even in charge of that part of the project any more? Maybe he's not even aware of our struggle and will gladly reconsider :)! I'm not much into KDE politics and - as you (orionbelt2) pointed out: It requires time and energy! The fact that we're willing to invest those underlines our desire for change, doesn't it? So Aaron! Hear us out :)! This goes out to Jürgen as well: You sayt there was "no way to change the minds of the necessary people" - yet we haven't gotten an "official" statement ever since the interest in this discussion was rekindled as of late. Which (I think) is exactly why Myriam pointed out creating a new issue on the reviewboard might be a good idea. So people actually get to review it! I won't be getting into this tonight any more (long day at work), but I might just take this up myself and point at this very discussion. I won't be getting into the "software diva"-bit much, either. I see your point. I agree with it to a certain extend, too. People tend to be protective of their creations, even if it sometimes is to the detriment of others. Maybe we can still change this. Wouldn't that be something?
If folks want to bring it up again, I'm glad to throw my support behind it. I used to update KDE on every tiny release on Debian, now I don't update it at all unless I feel like patching and recompiling the module to fix the task row sorting issue (thanks again to Kåre!). I think I'm at least 4 months out of date now, and I'd really like to stay up to date. And while I'm at it, I really need to be able to disable the "scroll on taskbar changes task" functionality. Being on a laptop with a very sensitive touchpad, it's a constant problem. But that's for another bug report (which I think I vaguely recall also being WONTFIX).
(In reply to comment #44) > What I can't really seem to understand > is Aaron's comment how "the way it is currently in 4.6 seems to cover a > number of user needs very well." Who are those users? well, to me it seems to be a trivial argumentum e silentio: people don't complain, so they must be happy -- and since vastly more people do not complain compared to the small numer represented here ... :-) to be honest, i really don't think it matters if Juergen is someone calling names -- apparently none of the developers (or rather those triaging bugs) really cares for this bug. i am just happy they don't simply close it and leave us to our own devices.
(In reply to comment #45) > If folks want to bring it up again, I'm glad to throw my support behind it. > I used to update KDE on every tiny release on Debian, now I don't update it > at all unless I feel like patching and recompiling the module to fix the > task row sorting issue (thanks again to Kåre!). I think I'm at least 4 > months out of date now, and I'd really like to stay up to date. well, i am building a debian/sid amd64 package everytime kde updates -- if that matches your needs, i gladly make it available.
Yes, that is exactly what I need. I would love to have them. Thank you so much! =)
Created attachment 75414 [details] debian/sid amd64 plasma-desktop package with patch applied here's the debian amd64 package for the most recent kde in debian/sid
Created attachment 75629 [details] debian sid amd64 plasma-desktop with patch applied
Created attachment 76627 [details] debian/sid amd64 plasma-desktop package with patch applied
Created attachment 76740 [details] debian/sid amd64 plasma-desktop package with patch applied 4.9 package. just after finishing the last 4.8, debian pushed the new kde ... 4.8 patch still holds good. applies with an offset of a few lines.
As I hinted at in https://bugs.kde.org/show_bug.cgi?id=215231#c44 I took the liberty of creating a posting on the reviewboard (according to multiple suggestions): https://git.reviewboard.kde.org/r/108891/ I hope this represents what we've been trying to achieve. If there are any mistakes: Please let me know so I can fix them accordingly.
Michael Biech, I see that you corrected the Summary to "column major", but in the description it still states "row first". Al
Al: Fixed. Thanks!
i was never able to make sense from this "row major" or "column major" stuff (seem to be the same bug that has bitten several of kontrol center's confusion ... eh ... description labels ...). would someone please explain in human understandable terms where these term s come from and what they mean? i am sure, we're talking all about the same kind of behaviour, but with arcane terms like above , misunderstandings are a distinct possibility and although i don't really expect anything from this new attempt, i'd hate to see it founder just because someone of the "those annoying freaks with their ideas of freedom of choice" faction uses this as an excuse to deny it ...
Ok, as I see now, the request was (again?) rejected by review board. Thus not bother me. KDE is dead for me! I changed to Gnome. I just don't want to be in team with such egocentric developers. Bye and *** TO HELL WITH KDE ***
Created attachment 80995 [details] patch to revert sort order when rows are forced Ignoring rude comments :( Here is a patch that can be applied to the installed QML task manager :)
Created attachment 80996 [details] script that automates the patching Here is a script that can be run after install to apply patch 80995 (and two other fixes for those who want tiny taskbars with two rows) Just run the script and provide authentication when requested. Hope this helps somebody ;)
Created attachment 81121 [details] debian/sid amd64 plasma-desktop 4.10 package with patch applied patched 4.10 fro debian/sid
Created attachment 81136 [details] debian/sid amd64 plasma-desktop 4.10 package with patch applied
Comment on attachment 81136 [details] debian/sid amd64 plasma-desktop 4.10 package with patch applied debian/sid just brought 4:4.10.5-2
Created attachment 81561 [details] debian/sid amd64 plasma-desktop 4.10 package with patch applied debian/sid amd64 plasma-desktop 4.10 package with patch applied debian/sid just brought 4:4.10.5-3
Created attachment 82268 [details] script that automates the patching of 4.11.1 New patch-script for 4.11.1
*** Bug 325306 has been marked as a duplicate of this bug. ***
There is already a drop-down list for Sorting (with 5 items). What is wrong with adding an option: "Manually (column-major)" and renaming existing "Manually" to "Manually (row-major)". It is a minor change and it does not introduce confusion. It doesn't add new controls and keeps things simple (but flexible for people who need it). Would such patch pass a review?
> with adding an option: "Manually (column-major)" and renaming existing > "Manually" to "Manually (row-major)". in case you want to create a patch: please, do NOT use "row-major" or "column-major". i never understood what those cryptic terms are supposed to mean (never got an answer when asking for an explanation) and am not sure if anybody does at all, and KDE's settings are already flooded with incomprehensible or needlessly complex descriptions -- no need to add to the bad.
(In reply to comment #67) > in case you want to create a patch: please, do NOT use "row-major" or > "column-major". i never understood what those cryptic terms are supposed to > mean. I the context of this discussion, row-major = fill rows first and column-major = fill columns first. Since "force row settings" means fixed column size (equal to the number of rows), column-major sort is stable (each taskbar item has a fixed place, no matter how many new items are added). While row-major is not stable, because when taskbar gets too full, entries get shorter and the row size changes, resulting in a shift of the entries of all rows except the first one. I don't care how one calls it, but it is convenient for many people when taskbar entries have fixed positions, and such sorting option has to be added. One can call it "Manual stable", "Manual column-fill" or suggest your variant.
You might try bug 262674 comment #11 (QML does not require compilation).
I haven't updated KDE since 4.10 and am considering doing so. Does the 4.11 patch still work for 4.14 which I would have in Debian?
> --- Comment #70 from Trip Ericson <rovfan@quelorant.com> --- > I haven't updated KDE since 4.10 and am considering doing so. Does the 4.11 > patch still work for 4.14 which I would have in Debian? yep :)
Created attachment 92304 [details] Patch to revert to column-major for forced row settings Here is a one line patch for Plasma 5.3. The file to patch is /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml (no script this time) Here are two videos that describe the problem :) First is the row major where taskbar items jump around: https://youtu.be/8udr2DJKobw And the second where they jump a lot less: https://youtu.be/bk17gnu1ETo I have tested the patch both on vertical and horizontal taskbars and on the vertical one, the patch has no effect (tho it could have).
thanks very much. this was driving me to distraction with the already buggy plasma5