Version: unspecified (using Devel) OS: Linux The task bar starts displaying the entries in two ( 2 ) rows instead of one ( 1 ) and with gaps between the entries, after I use KDE for a while. I've specifically configured the Taskbar to only use one row. I'm using Mageia Cauldron on this machine: Pentium 4, 2.4 GHz CPU. 2.5 GB of RAM. An ATI Radeon HD 2600 card. One 160 GB Hard-disk and two smaller ones of 80 GB or so. A 19״ LCD Screen by ViewSonic. A standard built-in AC’97 sound-card. I'm using the taskbar with a different activity per desktop (in case that matters). Reproducible: Always Steps to Reproduce: 1. Start KDE with my configuration. 2. Wait a while for a few windows to open and close. Actual Results: Displays in two rows and the icons are small. Expected Results: Display in one row.
Can confirm this here with 4.7 rc1. The task manager widget completely ignores the "force row" setting. It seems that the task manager doesn't keep track of how many windows are closed but simply allocates enough space for all the windows that are and were on the workspace. If you keep opening and closing windows often enough if can even go to 3 or more rows making it unusable with smaller taskbar heights.
Created attachment 61610 [details] Screenshot showing the described behaviour As a picture says more than a thousand words... My setting is single row enforced, as you can see the selectors are arranged in two with a space between 2 of them.
Still in 4.7 (gaps + max row size)
*** This bug has been marked as a duplicate of bug 224447 ***
I can confirm this bug. It started with KDE 4.7, i have never had it before. I use "Force row settings" and 1 Maximum rows. After a while of normal usage without any task grouping or anything, it changes to using two rows. If i change the "Maximum rows" setting it always displays one more row than "Maximum rows" setting. If i change to a new virtual desktop it works normaly, if i change back to the previous desktop it happens again. I don't think its the same as bug 224447.
(In reply to comment #5) > I can confirm this bug. It started with KDE 4.7, i have never had it before. > > I use "Force row settings" and 1 Maximum rows. > After a while of normal usage without any task grouping or anything, it changes > to using two rows. > > If i change the "Maximum rows" setting it always displays one more row than > "Maximum rows" setting. > > If i change to a new virtual desktop it works normaly, if i change back to the > previous desktop it happens again. > > I don't think its the same as bug 224447. I agree that I don't recall seeing this bug before KDE 4.7 (which bug 224447 appears to be older than), and it seems like a different bug. Regards, -- Shlomi Fish
(In reply to comment #6) That is indeed the case. The row-setting was successfully applied ever since the setting got introduced until 4.7. So definitely not a duplicate of bug 224447
Created attachment 62595 [details] Wrong and messed up rows in taskbar
This seems a new bug. At least for me it happens only now in 4.7 (Arch Linux). I have 1 row maximum set in options but sometimes with lot of windows (I don't how to reproduce) taskbar get 2 rows. If then I set 2 as maximum, it get 3! If I move all windows to another virtual desktop, they appear ok there, but taskbar on first remains with wrong row number.
I had this bug without any "force row" setting. I had just "maximum row count" set to 1. No idea if it's related to #224447, but it might be related to #276226 (some of the entries now do appear to the right). Also, the bug happens for me usually after suspend/resume, not right after login.
Re-opening per the comments that this is a new bug, which is exhibited only starting from KDE-4.7 and is unreleated to https://bugs.kde.org/show_bug.cgi?id=224447 .
I am bitten by this as well, although I have set it to a max number of two rows. Similar fate: this has gotten much worse since 4.7.0 (I believe I was bitten by the not-so-duplicate bug, before). I am using "Show only windows of the current desktop", if that makes any difference. Note that killing plasma-desktop and then restarting it fixes the issue for a little while.
(In reply to comment #12) Yeah, I already have a sript "plasma restart" that i use once every couple of hours or so, depending on how much I use the laptop during that time... I just wish I knew where to look, because the fix might be trivial :(
As the others, I have the same bug since 4.7.0. It seems that a "new space" in the taskbar is generated when a window "flash" in the taskbar when the window is on an other desktop (for example, I have it when my psi-im window flash for new message on desktop 1 when I'm on desktop 2. If I'm on desktop 1, it does not create extra space in the taskbar). But not only. At least, I can reproduce with this case, but it seems that there is other cases. But I just noticed that this bug can be mitigated by unchecking "Show only tasks of current desktop". I have always displayed all windows in the taskbar (ugh, it's messy !), but no more blank space is created in the taskbar.
Related bug https://bugs.kde.org/show_bug.cgi?id=278891
I can confirm this bug with KDE 4.7.1 and today I figured out a way to force this bug in my case: 1. Open Firefox (it's the default web browser KDE and system wide) 2. From within another application (e.g. Mendeley) open an url so initially a new instance of Firefox is launched until the old instance and the new instance are merged into one with an additional tab 4. a gap in the taskbar has appeared "before" (left of) the old instance Today I got it as far as four (5!) empty rows. Settings force 1 row. Deleting the taskbar and recreating it restored the "correct" layout.
(In reply to comment #16) > I can confirm this bug with KDE 4.7.1 and today I figured out a way to force > this bug in my case: > > 1. Open Firefox (it's the default web browser KDE and system wide) > 2. From within another application (e.g. Mendeley) open an url so initially a > new instance of Firefox is launched until the old instance and the new instance > are merged into one with an additional tab > 4. a gap in the taskbar has appeared "before" (left of) the old instance > > Today I got it as far as four (5!) empty rows. Settings force 1 row. Deleting > the taskbar and recreating it restored the "correct" layout. Thanks for sharing this. I now tried to reproduce it this way and was unable to, but I was able to reproduce it in a slightly different way: 1. Start a new KDE session. 2. Invoke a konsole in virtual desktop #3. 3. Start konversation from it. 4. Switch to virtual desktop #1. 5. Start a konsole there. 6. Type "firefox -no-remote" and start a mostly new profile. 7. Switch to desktop #3 and to konversation. 8. Click a URL in konversation. 9. It will open in Firefox. 10. In Firefox quit using File -> Quit. 11. Switch to virtual desktop #3. 12. Voila! There's a gap. So thanks for that and I hope the KDE developers will be able to reproduce the problem using one or more of the two recipes here.
*** Bug 283208 has been marked as a duplicate of this bug. ***
*** Bug 281965 has been marked as a duplicate of this bug. ***
*** Bug 283181 has been marked as a duplicate of this bug. ***
hey all here all a speaking about taskbar widget.. but this behavior also happends in smooth tasks widget... is it really a taskbar widget problem.. or even a panel problem? i can reproduce above step's.. i always work on four different desktop's and switch a lot between them.. also have a lot apps open.. and after closing apps on fourth desktop, switching back to first and again to fourth desktop, a empty smooth tasks entry is showed... thomi
it looks like KWin problem.
(In reply to comment #22) > it looks like KWin problem. If this is a kwin problem, why restart of plasma-desktop solve it?
I don't know.
Still present in 4.7.2 :(
*** Bug 276877 has been marked as a duplicate of this bug. ***
For me it's present from 4.6.90. Also, plasma segfaults if I try [for example] to add launcher on it (see the duplicate mark above).
(In reply to comment #22) > it looks like KWin problem. I think that it is layout manager problem.
I just want to point out one other way in which this issue manifests itself in the taskbar: With grouping enabled in the standard task manager, these blank spaces can be added to a grouping. I had Virtualbox and two VMs open, so all three windows (the main UI plus the two guest windows) were placed in one group, and the indicator in the group label showed that there were three items in the group. Then I shut down one of the VMs, which closed one of the guest windows. When the window closed, the group indicator remained at 3, and clicking on the entry in the taskbar which shows the "stack" of all the windows in the group showed the two actual remaining windows in one row, plus a blank row underneath which I assume contains the one empty label. At this point I shut down my second VM. When the guest window closed, the group indicator went down to 2, and clicking on the label for the group showed that it contained the one remaining window plus one blank label. Closing the final Virtualbox window then caused the group label to disappear, replaced by a single blank label.
*** Bug 283949 has been marked as a duplicate of this bug. ***
The bug is in libtaskmanager, that's why it shows with Smooth tasks, too.
Workaround (only workaround!). You can tray this: http://kde-apps.org/content/show.php/Icon+Tasks?content=144808 (Icon Tasks). As I started using this yesterday everything seems to be ok. Maybe after longer using there will be the same mess, but still when you get only icons it's easier to work without killing plasma. It's a little similar to Flexible tasks or Smooth tasks, but (imo) much better. It's work around for people who don't need to see app name on task bar or people, who can't stand this mess. If I get any problems I'll report that. This app is also much more configurable that traditional KDE.
(In reply to comment #31) > The bug is in libtaskmanager, that's why it shows with Smooth tasks, too. The problem could not be _only_ libtaskmanager, since displaying two rows instead of one is clearly a UI bug. libtaskmanager might be responsible for these placeholder entries. I had a short look into the class, row and column computation is really freaky...
(In reply to comment #17) > (In reply to comment #16) > > 1. Open Firefox (it's the default web browser KDE and system wide) > > 2. From within another application (e.g. Mendeley) open an url so initially a > > new instance of Firefox is launched until the old instance and the new instance > > are merged into one with an additional tab > > 4. a gap in the taskbar has appeared "before" (left of) the old instance > > Thanks for sharing this. I now tried to reproduce it this way and was unable > to, but I was able to reproduce it in a slightly different way: > > 1. Start a new KDE session. > 2. Invoke a konsole in virtual desktop #3. > 3. Start konversation from it. > 4. Switch to virtual desktop #1. > 5. Start a konsole there. > 6. Type "firefox -no-remote" and start a mostly new profile. > 7. Switch to desktop #3 and to konversation. > 8. Click a URL in konversation. > 9. It will open in Firefox. > 10. In Firefox quit using File -> Quit. > 11. Switch to virtual desktop #3. > 12. Voila! There's a gap. Hmm, one thing both sequences of actions have in common seems to be the removal of a taskbar entry from a non-active virtual desktop. Moreover, the entry removed seems to be one that has never been viewed (this should be easy to verify or disprove, but I don't have time for it right now). Torbjörn K's actions (comment #16) causes a Firefox window to appear on a non-active virtual desktop where there's already an FF window. As the two FF taskbar entries are grouped, one disappears. Shlomi Fish (comment #17) removes an FF window on a non-active virtual desktop by stopping the program. Observe also that both procedures also never involve actually viewing the window that is to be removed (which, as mentioned, may or may not be relevant).
(In reply to comment #34) I'll copy list of steps to reproduce this bug from a duplicate one. Maybe this will be helpfull. I am using KDE 4.7.2 from openSUSE packages. I've simple taksmanager widget on my only panel, that is configured as follows: - force row settings - checked - show tooltips - checked - highlight windows - checked - maximum rows - 1 - grouping - do not group - sorting - alphabetically - only show tasks from current screen - checked - only show tasks from current desktop - checked - only show tasks from current activity - checked - only show tasks that are minimized - unchecked I'm using only one activity (only one is configured). I'm using 9 virtual desktops in 3x3 grid. I'm using Akregator on my 3rd desktop (it is forced on 3rd desktop by Kwin special application setting). My focus stealing-prevention policy is set to "medium" and focus is "click to focus". After using one VD and switching to another using systray - taskbar on original desktop gets broken. Reproducible: Always Steps to Reproduce: 1. set up akregator to display tray icon, make this tray icon always visible 2. set up at least 2 virtal desktops 3. force akregator on second virtual desktop 4. run akregator 5. make sure at least one taskmanager widget is available on current setting and is is configured as in bug details 6. switch to 1st virutal desktop 7. open 5 konsole instances 8. click on akregator systray icon, you should be moved to 2nd VD 9. click on akregator systray icon, akregator should get hidden 10. switch to 1st virtual desktop, taskbar should have one empty rectangle at begining 11. repeat 8-9-10 to make this effect more visible Actual Results: Taskbar have one empty places. Expected Results: Taskbar does not have one empty places.
*** Bug 284345 has been marked as a duplicate of this bug. ***
The steps in bug #278891 are even easier to reproduce. Here's a YouTube video demonstration: http://www.youtube.com/watch?v=f8FA1yGM0gA (Note: the above bug is valid, but was marked as invalid because too many people used the notes to voice their anger over the situation, and it was closed.)
*** Bug 284438 has been marked as a duplicate of this bug. ***
I'm getting ghost spaces using a single desktop, although I use twin-view and multiple activities. Arch Linux, KDE 4.7.2
I also see this behaviour, but sometimes, additionally to a gap showing up in the task bar, I see two windows' taskbar entries above each other!
Created attachment 64963 [details] New crash information added by DrKonqi plasma-desktop (0.4) on KDE Platform 4.7.2 (4.7.2) using Qt 4.7.4 - Unusual behavior I noticed: Crashed when I tried to change row settings in task bar -- Backtrace (Reduced): #7 TaskManager::Task::classClass (this=0x0) at ../../../libs/taskmanager/task_x11.cpp:74 #8 0xa968c093 in TaskManager::LauncherItem::associateItemIfMatches (this=0xb3436e8, item=0xa9caec8) at ../../../libs/taskmanager/launcheritem.cpp:91 #9 0xa968715c in TaskManager::GroupManager::addLauncher (this=0x9bd3418, url=..., icon=..., name=..., genericName=...) at ../../../libs/taskmanager/groupmanager.cpp:634 #10 0xa9699db6 in TaskManager::ToggleLauncherActionImpl::toggleLauncher (this=0xa1c4b20) at ../../../libs/taskmanager/taskactions.cpp:377 #11 0xa9699e96 in TaskManager::ToggleLauncherActionImpl::qt_metacall (this=0xa1c4b20, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xbfa68488) at ./taskactions_p.moc:220
*** Bug 285155 has been marked as a duplicate of this bug. ***
Hi Mr. Collins, (In reply to comment #37) > The steps in bug #278891 are even easier to reproduce. Here's a YouTube video > demonstration: > http://www.youtube.com/watch?v=f8FA1yGM0gA > > (Note: the above bug is valid, but was marked as invalid because too many > people used the notes to voice their anger over the situation, and it was > closed.) I was indeed able to reproduce them now (here on KDE-4.7.2 on Mageia Linux 2). I previously wasn't able to from the video alone. I'm copying the description here: [QUOTE] Reproducible: Always Steps to Reproduce: 1) Log in to a clean desktop session with no programs displayed in the task manager (if necessary). 2) Enable System Settings -> Workspace Behavior -> Screen Edges -> Switch desktop on edge: Only When Moving Windows. 3) Launch Dolphin on desktop 1. 4) Drag Dolphin to desktop 2. 5) Close Dolphin. 6) Go back to desktop 1 and launch another instance of Dolphin. You will notice a space to the left of Dolphin's taskbar entry. Actual Results: A blank space is created on the first desktop's taskbar. Expected Results: No blank space to be created. My task manager settings are thus: Force row settings: no Show tooltips: yes Highlight windows: no Maximum rows: 2 Grouping: Manually Sorting: Manually Only show tasks from the current screen: no Only show tasks from the current desktop: yes Only show tasks from the current activity: yes Only show tasks that are minimized: no [/QUOTE]
I'm seeing the gaps (and consequently more rows than configured) on a normal X display (no TwinView), and without using any activities.
I'm getting blank spaces without dragging windows around or anything. These ghost spaces appear on a random basis, simply by using my desktop normally. There are none at startup, and they begin appearing after some time of normal use, pushing valid entries in the taskbar forward (thus increasing the number of rows). Should I file a new bug for this different behaviour or is it the same? Please, and politely :), fix this annoying bug - it makes the desktop look seriously broken.
Personally I'd recommend either changing description of this bug or filing a new one, as likely the gaps are the reason of the excess rows.
To workaround this bug without re-logging-in, once remove and add a TaskManager widget again. This is really messy task IMHO. To reduce this task, I wrote a Plasma script like below. ------------------------------------------------------------------ // Configuration targetPanelId = 0 widgetBeforeTasks = 'pager' // The main logic to manipulate panels p = panelById(panelIds[targetPanelId]) if (p) { pagerIndex = -1 oldTasks = 0 for (i = 0; i < p.widgetIds.length; ++i) { w = p.widgetById(p.widgetIds[i]) if (w.type == 'tasks') { oldTasks = w } else if (w.type == widgetBeforeTasks) { pagerIndex = w.index } } if (oldTasks && pagerIndex != -1) { oldTasks.remove() wTasks = p.addWidget('tasks') wTasks.index = pagerIndex + 1 wTasks.writeConfig('showOnlyCurrentDesktop', true) wTasks.writeConfig('maxRows', 1) } } ------------------------------------------------------------------ Note that I'm using only one panel, and place the TaskManager next to the Pager. showOnlyCurrentDesktop and maxRows = 1 are my preference ;) I also wrote a wrapper script like below. ------------------------------------------------------------------ #!/bin/bash qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /path/to/scriptInTheAbove.js ------------------------------------------------------------------ I call this script using a short-cut key, then execute it. Now I can workaround the bug more easily than before.
Thanks for your reply. Ok, then, since I don't have permission to change the title, I filed a new bug: Bug 285178.
Some update about the state of this (unfortunately annoying) bug: * Plasma developers are aware of the regression, and were able to reproduce it. Unless you have new findings, no further reports or test cases are needed. * The bug is not easily fixed by reverting a single change, because the taskbar "launcher" feature and other features resulted in large dependend changes for libtaskmanager 4.7. * There are workarounds mentioned in comment #14 and comment #32. The author of referred "Icon Tasks" plasmoid works together with Plasma developers to get his changes and fixes merged with the upstream plasmoid. * Some other (not less severe) regressions, such as bug 275469, bug 275286, bug 274020, bug 278869, bug 280659, are all related to those changes in taskmanager for 4.7. * The bugs are still present in 4.7.3 release (unless some magic happens this weekend...) Stable distributions are invited to offer older versions of libtaskmanager and depending code until those issues are fixed. Crash bug 275286 got a hotfix for 4.7.3, but the effectiveness of the change has not been confirmed yet. (Title changed as suggested by Leonardo, also to make it easier to search for)
*** Bug 285178 has been marked as a duplicate of this bug. ***
(In reply to comment #49) Thanks for the update. Too bad it is taking so long to fix this nasty bug. FYI: the workarounds you mention are not acceptable as such. The one mentioned on comment #14 does not work. The other in comment #32 simply suggests to use something else which is not quite the same thing as the KDE taskbar. The workaround in comment #47 fails to execute here with Error: TypeError: Result of expression 'wTasks' [undefined] is not an object. at line 21 ... and even if it worked it is a way of temporarily (and manually!) fixing the mess after it happens. So any relief on the severity of this bug due to existing workarounds is not based on reality.
Hi, For me, it's fixed in 4.7.3
It works properly in trunk.
Hi Guillaume, (In reply to comment #53) > It works properly in trunk. What distro are you using?
My bad, I meant to reply to comment #52
Gentoo (~amd64). I updated yesterday. After this upgrade, I have no more empty spaces created in my taskbar so far.
(In reply to comment #56) > Gentoo (~amd64). > I updated yesterday. After this upgrade, I have no more empty spaces created in > my taskbar so far. Maybe Gentoo has provided a previous and not buggy version of libtaskmanager?
No : its a plain non-patched libtaskmanager. See here : http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/libtaskmanager/ It's 4.7.3, no patches applied in ebuild
If it offers anything, I upgraded to 4.7.3 on my Slackware box a few days ago, and have not been able to repro this behavior since.
(In reply to comment #58) > No : its a plain non-patched libtaskmanager. > See here : > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/libtaskmanager/ > It's 4.7.3, no patches applied in ebuild That's good! And why the commit (including the fix) has not been announced in any of the 200 bug reports about it? :)
I'm looking at the recent commits in https://projects.kde.org/activity and I just find this one that could be related: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/4fb69cc9bcda8974a220fe681116a866c03adb2f But it's from 30 days ago. Sure I miss something.
(In reply to comment #56) > Gentoo (~amd64). > I updated yesterday. After this upgrade, I have no more empty spaces created in > my taskbar so far. I'm also on Gentoo/AMD64, and I still had this problem after upgrading libtaskmanager (and all its dependencies) to 4.7.3 and restarting plasma-desktop. However, after also upgrading plasma-workspace to 4.7.3 and restarting plasma-desktop yet again, the symptoms seem to be gone.
Interesting, the problem still exists for me. I'm on Kubuntu 11.10, using the "Kubuntu Updates" PPA with its latest KDE version 4.7.3. The (AFAIK) relevant packages are all at version 4.7.3-0ubuntu0.1~ppa1, such as kde-workspace, libplasma*, plasma-dataengines-workspace, plasma-widgets-workspace, and others. An easy way to reproduce is using Thunderbird (and possibly Firefox) with the FireTray extension: have the TB window open in one virtual desktop, then click the TB systray icon twice while in another virtual desktop (first for minimizing the TB window, then for opening it again, this time in the current vdesktop). Go back to the first vdesktop and find a gap.
(In reply to comment #63) > Interesting, the problem still exists for me. I'm on Kubuntu 11.10, using the > "Kubuntu Updates" PPA with its latest KDE version 4.7.3. > > The (AFAIK) relevant packages are all at version 4.7.3-0ubuntu0.1~ppa1, such as > kde-workspace, libplasma*, plasma-dataengines-workspace, > plasma-widgets-workspace, and others. > .... I am running ZevenOS-Neptune here (Debian based) and also had to upgrade kdelibs* packages for the bug to go away. So I suggest you also install them and see if you can still reproduce your bug (I cannot reproduce it here)
(In reply to comment #64) > (In reply to comment #63) > > Interesting, the problem still exists for me. I'm on Kubuntu 11.10, using the > > "Kubuntu Updates" PPA with its latest KDE version 4.7.3. > > > > The (AFAIK) relevant packages are all at version 4.7.3-0ubuntu0.1~ppa1, such as > > kde-workspace, libplasma*, plasma-dataengines-workspace, > > plasma-widgets-workspace, and others. > > .... > > I am running ZevenOS-Neptune here (Debian based) and also had to upgrade > kdelibs* packages for the bug to go away. So I suggest you also install them > and see if you can still reproduce your bug (I cannot reproduce it here) These packages were all updated automatically via the PPA, so they're also at 4.7.3-0ubuntu0.1~ppa1 (Kubuntu versioning). Still no luck, but thanks. :)
*** Bug 285869 has been marked as a duplicate of this bug. ***
*** Bug 285868 has been marked as a duplicate of this bug. ***
hey i have this kde version: 4.7.3-0ubuntu0.1~ppa1 and tested now "Task Manager".. and seems that the ghost spaces are gone.. In "Smooth Task" there are still ghost spaces, after few minutes or switching desktops... task manager v1.0 smooth tasks v0.99.1 thomi
No more ghost spaces for me too since upgrade to 4.7.3-0ubuntu0.1~ppa1
Huh, comment #68 and comment #69 are exactly right: in the official "Task Manager" widget the ghost spaces are gone. In "Smooth Tasks" they remain a problem. (Same versions as in comment #68 for both widgets.) But I'm confused, I thought this bug was widget-independent, in libtaskmanager or someplace generic.
If I understood well, there is a workaround in Task manager.
smooth tasks is a third party add-on; we can not be responsible for that code. all we can do is make sure our code is indeed properly fixed.
(In reply to comment #72) > smooth tasks is a third party add-on; we can not be responsible for that code. > all we can do is make sure our code is indeed properly fixed. That is understood. But what you're saying is: a work-around for the official task manager is considered a fix of a more generic problem that each of the third-party add-ons has to work around as well. You sure?
no, that's not what i'm saying. this is fixed in libtaskmanager, but i can not vouch for any other plasmoid that may have _different_ bugs in its code. moreover, libtaskmanager is not meant to be used by external parties; it does not offer binary nor source compatibility. anything that is not a part of thePlasmsa Workspaces proper uses it at its own risk. so yes, i am pretty sure about what i say here.
Empty entries still appears in KDE 4.7.3 in Fedora 16 with default task manager widget.
No empty entries since 4.7.3 using IconTasks
No empty spaces... maybe due to the fact that plasma crashes every 30 -60 minutes, when changing desktops/windows. Using CTRL+F10 (Preset Windows - All desktops) to navigate. No clear way to reproduce it.