Version: (using KDE 4.2.96) OS: Linux Installed from: Debian testing/unstable Packages Hello, sometimes, whenever I close or minimize an application to systray, its "task" does not disappear from the taskbar and stays there forever unless I restart plasma-desktop. If I reopen the same application (or restore for systray), a new task for it appears and the old dangling one stays. I have seen this annoying bug in 4.2.96, 4.2.98 and now 4.3.0. This is very confusing for users and it is definitely a regression from the 4.2.x series. Unfortunately, I don't know exact steps how to reproduce the bug. It just happens (typically after a couple of hours of KDE usage).
I can confirm I have seen this behaviour on 4.4trunk too.
i know how much fun it is to see if plasma developers can guess what your settings and system setup are, but try and provide all relevant information so we can attempt to replicate and fix this. please provide: * your tasks widget settings * which application(s) you are "minimizing to the system tray" * exactly how you are "minimizing to the system tray" (closing the associated window?)
So far I have only experienced this issue with two apps IIRC: - Kate (it first shows the Session dialog, and when you click "Open new session", it closes and then it finally opens the real Kate window), at that point I had two taskbar items, one for the "ghost" "Kate - Choose Session" initial dialog, and one for the real thing. - Gwenview (I just opened a picture (clicking on Dolphin); and after some time I clicked another picture on Dolphin too. Some time later when I closed one of the Gwenview windows (I don't really remember If I closed the second one), I noticed the "ghost" entry was there) -- My taskbar configuration is the default one as I oftenly remove my config to test Plasma bug-reports. So, that means: ShowTooltips: true Force row: false Max rows:2 Grouping: by program name Only when taskbar is full: true Sorting: alpha Filters: all disabled --- Yesterday I updated to: Qt: 4.5.2 (KDE-Qt git commit f9802f2bbbd23137acb5f80d1f131fa6b1a85752 Date: Fri Jun 12 15:06:29 2009 +0200) KDE: 4.3.62 (KDE 4.3.62 (KDE 4.4 >= 20090728)) kdelibs svn rev. 1005722 / kdebase svn rev. 1005722 on ArchLinux i686 - Kernel 2.6.30.1 and so far I haven't experienced the bug yet. I will update the report if I see it again. Regards
> i know how much fun it is to see if plasma developers can guess what your > settings and system setup are, but try and provide all relevant information > so we can attempt to replicate and fix this If I knew how to reproduce it, I would have told you. It is NOT easily reproducible. > * your tasks widget settings [Containments][3][Applets][7][Configuration] showOnlyCurrentDesktop=true showOnlyCurrentScreen=true > * which application(s) you are "minimizing to the system tray" KTorrent, Firefox (quiting the app) > * exactly how you are "minimizing to the system tray" (closing the associated window?) Yes (default KDE "close to systemtray" behaviour I guess). This happened with Firefox too when I quitted it (a couple of times).
@Dario: so in your case it wasn't minimizing to the tray, but just closing a window and then the associated entry in the taskbar wasn't being cleaned up? @Modestus: when you say "default KDE "close to systemtray" behaviour I guess" do you mean that you've selected that option in kmenueditor or that the application just came configured that way (or you set "use system tray icon" in ktorrent's configuration)? as for quitting firefox, when that happened did you have firefox minimizing to the system tray or was it just regular firefox (no system tray icon for it) and after quitting it an entry remained for it in the tasks widget?
> the application just came configured that way (or you set "use system tray > icon" in ktorrent's configuration)? The latter. i.e. when closing (with X in the top right corner) the main window, KTorrent task is supposed to disappear from the taskbar and "minimize" to system tray. However, sometimes it does not happen and dangling task remains there. In such a case when I "restore" KTorrent main window from the systray, a new task for it appears in the taskbar. Hence I end up having two tasks with KTorrent icons and label. However, while the new task is fine and fully functioning, the old dangling "task" does not actually control the KTorrent window as it does not react to mouse clicks. > just regular firefox (no system tray icon for it) and > after quitting it an entry remained for it in the tasks widget? The latter. I quit Firefox, the task for it sometimes remains (the icon and text). However, it does not react to mouse clicks as in case of KTorrent. What I want to say, it does not appear to matter if the application stays running (KTorrent) or not (Firefox) for this dangling task to appear.
@Aaron: indeed, I'm just closing normal windows (which do not have systemtray icon associated) and the taskbar entry remains there. BTW, I just did a bit of testing using different grouping&sorting configuration trying to reproduce the bug with Kate Session Chooser and so far I couldn't create the same situation..
This bug has just happened with konqueror. More information: dangling task appears on all desktops even if I have showOnlyCurrentDesktop=true enabled and konqueror was on Desktop 2 originally.
This happened to me with Konsole, temporary solution remove task manger from panel and re-add. KDE 4.3
*** Bug 202729 has been marked as a duplicate of this bug. ***
Seen this so far with Firefox and with its download window. Just closed the application, nothing fancy. Settings are "Just show app from current desktop and current screen". As reported the dangling entry appears on all desktops, but when you right click on the entry "To desktop" claims it is just shown on desktop where the app has originally been shown.
*** Bug 203032 has been marked as a duplicate of this bug. ***
I've had the same bug. Some times one application is shown into the taskbar even if it has been closed. I remember it has happened with konsole, kate and firefox. Last time I've seen this bug was two or three days ago. My task manager settings are "only show tasks from the current screen" for both two taskbars (one on each monitor).
I just wanted to say I have not experienced this bug yet after the update I mentioned in comment 3 a week ago ... (oh, and.. if I missed this detail: I have only one monitor... )
Just to confirm that this is happening on Kubuntu 9.04/KDE 4.3. It also happened one time with the kmix icon on the tray..
Like Dario: I didn't have this bug on this last week. Probably in trunk it has been fixed :-)
I've had it again... now is the turn of a gimp panel which is on my taskbar but gimp is not running :-(
Err.. now using: Qt: 4.5.2 (KDE-Qt git commit 5b7a2eb42acfdea07c6075556cb43e2c95852145 Date: Tue Jul 28 14:10:47 2009 -0300) KDE: 4.3.63 (KDE 4.3.63 (KDE 4.4 >= 20090805)) kdelibs svn rev. 1009010 / kdebase svn rev. 1009010 on ArchLinux i686 - Kernel 2.6.30.4 It appeared again. I was closing a KWrite window and then I clicked a icon launcher (separate icon widget, not using a folderview) of Dolphin. Two entries appeared. (I can't recall if two real Dolphin windows appeared two and then I closed one and the entry remained there, or just only Dolphin window appeared, but there were two taskbar entries from the start)....
Up to date Kubuntu Karmic is in use with KDE 4.3.0. At my case sometimes after desktop switching I notice a task title (on the task manager) from another desktop. Say, desktop 1 has Krusader running, I switch to desktop 4, and Krusader title still exists. After switching to desktop 1 I see... two task titles. After closing the task extra title still exists (on all desktops), but isn't connected to any task. The only way to eliminate this extra title is to restart X. The issue isn't related with concrete application (Krusader in my example) - it may be, say, KMail, synaptic, ...
Created attachment 36145 [details] before Krusader closing
Created attachment 36146 [details] after Krusader closing
*** Bug 203817 has been marked as a duplicate of this bug. ***
It happens for me too. Fedora 11, KDE 4.3 (from updates-testing).
I've had this problem too with icons that don't work (in this case knode). I've also had windows on other desktops show up on the current desktop (often happens when opening X11 pgplot windows), when I have the option selected to only show applications on the current desktop. Today I had the same konsole window appear twice on the task bar. Both buttons controlled the same window. This is with Fedora 10 KDE 4.3 testing, x86-64. I had fewer problems like this with KDE 4.2.
It hasn't happened since latest updates to KDE4.3 under Kubuntu 9.04, at least on my laptop.
The same: under Kubuntu Karmic (testing 9.10) after upgrading of a set of kde/workspace/plasma-related packages from version suffix ubuntu7 to ubuntu10 I don't see the duplication any more. P.S. Tasks' titles order (is "Manual" mode) is still not keeping between desktop switching. But this is another story.
I also observe this behavior a lot with kmail. Thanks.
I constantly observe this behavior with comix and sometimes with konversation on KDE 4.3 on Gentoo.
*** Bug 205530 has been marked as a duplicate of this bug. ***
re comment #2: I'm not sure what all settings you may need. It'd be handy if DrKonqi could extract the settings you think you'd need for, say, 80% of bug reports, and then we could easily attach that output to the bug.
Just reproduced with 4.3.1.
*** Bug 206100 has been marked as a duplicate of this bug. ***
FYI, I believe this bug is a less fatal case of Bug 203558
*** Bug 208417 has been marked as a duplicate of this bug. ***
I confirm the bug on a recent kubuntu 9.04 32 bit, with latest kde 4.3.1 (as shipped in the kubuntu ppa repos) and no particular configuration tweaks. Taskbar set up to only show tasks from current desktop and grouping by program name. I am seeing this most frequently with emacs and firefox. I believe it happens only when you have more than one window of an application open. If it is too hard to fix soon, please temporarily add an option to soft-restart the taskbar. Now you need either to log-out/log-in again or to remove the taskbar and then re-add it.
when am I see this bug fix in OpenSuse ? thanks
*** Bug 203923 has been marked as a duplicate of this bug. ***
*** Bug 208707 has been marked as a duplicate of this bug. ***
I can confirm that I have the same problem. Arch linux x86_64, KDE 4.3.1. Seems to happen randomly, most frequently with firefox, thunderbird and kate, but these are the programs that I use most often. Please fix this soon, I've had the problem for months and it is the only thing left that causes me problems in KDE. Thanks.
I wonder if applications that can modify their window title may help triggering this bug.
This bug strikes back on my laptop, after latest updates to Kubuntu karmic koala. It was gone for some long time. Running Kubuntu Karmic Koala with latest updates on a Dell Studio XPS 16.
Confirmed on Qt 4.5.3 + KDE 4.3.2 with KTorrent.
*** Bug 209600 has been marked as a duplicate of this bug. ***
Comment on bug 209600 says taskbar entries probably stay when the application crashed.
Just updated to KDE4.3.2 on Karmic; bug's still there.
I don't see this with only crashed applications but mostly normal exits. Maybe it makes it more likely.
The way I have experienced this, the taskbar entry suddenly duplicates itself while the program is still running. The program can then be controlled by _both_ entries. However, after closing the program one of the entries remains 'dead' in the taskbar.
@Thomas Zell That's exactly how I'm experiencing it. However, I haven't experienced it in a while now.
Darn... some days ago I was about to that a comment about I hadn't seen this bug for a while, however today it reappeared: It is a Dolphin window the ghost one. - I open a Dolphin window and pointed to network:/, I created a network share (smb) and after the assistant finished it opened another Dolphin window. Then I set FolderView to show network:/. I browsed to some folder inside the smb share recently added (using the folderview folder preview) and I clicked some folder. At this point I started closed the other Dolphin windows and I noticed the ghost one. Now using: Qt: 4.6.0 (Qt git branch 4.6 commit c5c58c2368f71c5d0067c9389c8ad04c41b66db5 Date: Wed Sep 9 15:09:34 2009 +0200) KDE: 4.3.72 (KDE 4.3.72 (KDE 4.4 >= 20091015)) kdelibs svn rev. 1036211 / kdebase svn rev. 1036211 on ArchLinux i686 - Kernel 2.6.30.6 Regards
Created attachment 37667 [details] Screenshot of a dangling empty task
Seen a similar behavior but with an empty space as a task. Using ArchLinux, KDE 4.3.2 and taskbar configured to show only the tasks from the current desktop.
Created attachment 37668 [details] Another screenshot of an empty task.
Happens also with kopete chat windows, whenever they need to flash while on another desktop. kdebase4-workspace-4.3.2-5mdv2010.0 kopete-4.3.2-1mdv2010.0 etc. from Mandriva Cooker 2010.0 x86_64
From bug 211146: --- "... For example, I've had multiple instances of a pdf reader open, and after I've closed them all, it sometimes still happens that one of the entries for the (now closed) windows appears in the task manager. It is also shown on all virtual desktops, not only the original one, even if I have configured task manager to only show windows on current desktop. ..."
*** Bug 211146 has been marked as a duplicate of this bug. ***
For me, this problem doesn't only happen when closing windows, but sometimes when the window is still open. At the moment, for example, my firefox window is shown thrice; when I minimize it, all three instances are shown as minimized (same for demands-attention); when I switch viewports (using compiz), two of the instances stay in the taskbar; the same happens when closing the window.
Created attachment 38027 [details] Screenshot of multiple firefox instances Screenshot of multiple firefox instances All that is on KDE 4.3.2, Fedora 11 packages.
If anyone really wants this bug to be fixed we need a reproducible test case or spot an error in commits made to the relevant plasma module during 4.3.0 development cycle. Otherwise KDE 4.4 will be released with this bug.
Not all bugs have reproducible test cases...
Created attachment 38028 [details] Another Instance of Firefox having 2 taskbar entries while only 1 program is running I can also confirm that programs can have multiple taskbar entries which both control 1 instance of a program. When you close the program, one of the instances is left behind forever until logout or reattaching the taskbar plasmoid. I have spent a good hour trying to reproduce this bug, to no avail. After giving up, it happened almost straight away and I couldn't figure out what caused it, so I thought I'd screenshot and upload as well.
*** Bug 212407 has been marked as a duplicate of this bug. ***
This bug happened again to me just now with emacs on an up-to-date kubuntu 9.10 system. I started a new application and the emacs taskbar entry duplicated itself. When I closed emacs one of the duplicates remained as a "dead" entry. Removing and re-adding the task manager widget removes the dead entry.
Artem S. Tashkinov wrote: > https://bugs.kde.org/show_bug.cgi?id=202199 > > > > > > --- Comment #58 from Artem S. Tashkinov <t artem mailcity com> 2009-11-02 13:45:13 --- > If anyone really wants this bug to be fixed we need a reproducible test case or > spot an error in commits made to the relevant plasma module during 4.3.0 > development cycle. > > Otherwise KDE 4.4 will be released with this bug. > > I believe it can be hard to find a reproducible test case, since what happens seems frequent but rather random (as if it was caused by a race or something like that). As a strategy, I would suggest that if this bug cannot be fixed in time, the taskbar in kde 4.4 is enriched with: 1) A "reset" entry in its menu, so that it can be restarted without having to logout/login or removing/readding it from/to panel. 2) Possibly some instrumentation to help spot the issue. E.g. on reset, the taskbar could save in some log some data useful to correct the issue. Would at least 1) be possible? Sergio
Sergio presents some useful ideas. Another would be a periodic check that the process shown by button is still running, and the removal of a button if it is not. This would be papering over the problem, but information could be logged to help diagnose the issue.
I would recommend to exclude some options to find the problem. 1) try to deactivate option "Only when the taskbar is full" at grouping 2) change the number of rows to 1 If nothing helped then try 3) choose grouping option "Do not Group" My personal guess is that the problem is in the grouping.
For me this bug happens for both emacs (for which I've chosen "do not group") as well as other applications (such as firefox) which I allow to group.
I haven't encountered this problem since I switched my taskbar settings to group "manually" and sort "manually". I also only show tasks on the current desktop. However, it has only been a few days so might be a bit soon to tell. If it comes back then I'll post back here, but otherwise that might be a clue as to where to look for the problem.
I've switched to: No Grouping Max rows: 2 Sort: alphabetical Filter: Only current desktop. And I haven't seen the problem yet. Although it may be a false hope, as it sometimes takes a while to kick in. As an aside, is there a user-friendly way for us to send all the required information ? E.g. in Debian the "reportbug" tool knows to append the xorg.conf and last log file when submitting a bug on the X server. Maybe some plasma-reportbug tool that could dump the configuration and perhaps also some form of private info about the inner state ?
For me, it seems to be caused by a window on another viewport setting the demands_attention hint (with 'only current desktop' on). Everytime a window sets demands_attention, I get a new ghost window instance. This is 100% reproducable for me ATM.
@Danny: nice information. I have tried to reproduce the bug with a sample applications setting the demand attention hint, but I failed. - What are your taskbar settings ? - Does this happen when the window is on every other virtual desktop/viewport ? Thanks
(In reply to comment #70) > @Danny: nice information. I have tried to reproduce the bug with a sample > applications setting the demand attention hint, but I failed. > - What are your taskbar settings ? - 1 row - group by program name - group only if taskbar is full - show only windows of current desktop 'show only windows of current screen' and 'show minimized only' are turned off > - Does this happen when the window is on every other virtual desktop/viewport ? No, it doesn't happen then.
Rephrasing the last question: - Does the bug appear when the window is on viewport 1 OR viewport 2 or viewport N and you are in ANOTHER viewport (I didn't said about the window being on ALL the desktops/viewports). The question was if the bug appeared regardless of in which viewport/desktop the window demanding attention was. Sorry about the confusion. Thanks for the information
(In reply to comment #72) > Rephrasing the last question: > - Does the bug appear when the window is on viewport 1 OR viewport 2 or > viewport N and you are in ANOTHER viewport (I didn't said about the window > being on ALL the desktops/viewports). The question was if the bug appeared > regardless of in which viewport/desktop the window demanding attention was. > Sorry about the confusion. > Thanks for the information Yes, it does. I just tried with activating firefox by clicking a link from VP1. No matter whether Firefox was on VP2 or VP4, the problem would happen. Strangely enough, I can not reproduce the problem using wmctrl to set the demands_attention hint manually. FWIW, I can reliable reproduce it when activating firefox by clicking a link in another application (which is on another viewport). I can also reliably reproduce it by receiving a message in pidgin.
(In reply to comment #73) > > > Yes, it does. I just tried with activating firefox by clicking a link from VP1. > No matter whether Firefox was on VP2 or VP4, the problem would happen. > > Strangely enough, I can not reproduce the problem using wmctrl to set the > demands_attention hint manually. FWIW, I can reliable reproduce it when > activating firefox by clicking a link in another application (which is on > another viewport). I can also reliably reproduce it by receiving a message in > pidgin. Hmm, I have attempted to reproduce this using your settings and method but have been unable to get it to work. I open thunderbird on desktop 1, firefox on desktop 2. This is with other stuff open on other desktops as well. I click a link in thunderbird and it opens in firefox, jumping to the 2nd desktop when I click it. No bug occurs, is there anything that I am doing wrong?
I have this bug with Skype Chat , but this is KDE 4.3.2
(In reply to comment #74) > (In reply to comment #73) > > > > > > Yes, it does. I just tried with activating firefox by clicking a link from VP1. > > No matter whether Firefox was on VP2 or VP4, the problem would happen. > > > > Strangely enough, I can not reproduce the problem using wmctrl to set the > > demands_attention hint manually. FWIW, I can reliable reproduce it when > > activating firefox by clicking a link in another application (which is on > > another viewport). I can also reliably reproduce it by receiving a message in > > pidgin. > > Hmm, I have attempted to reproduce this using your settings and method but have > been unable to get it to work. > > I open thunderbird on desktop 1, firefox on desktop 2. This is with other stuff > open on other desktops as well. I click a link in thunderbird and it opens in > firefox, jumping to the 2nd desktop when I click it. No bug occurs, is there > anything that I am doing wrong? Seemingly not. I could reproduce it absolutely reliably yesterday, but today I can't reproduce it with demands_attention windows anymore :(
Pidgin still seems to be a reliable reproducer, though...
*** Bug 213552 has been marked as a duplicate of this bug. ***
I thought I'd add that I've not experienced this problem in over a week since switching sorting and grouping of taskbar entries to "manual". I'm fairly confident the bug could be around there. Thanks.
*** Bug 214434 has been marked as a duplicate of this bug. ***
This situation happens to me multiple times per day. KDE 4.3.1 qt 4.5.3 gentoo amd64 Regarding comment #35 (Sergio): I agree. It does only seem to happen to me when I have multiple windows open fo r an application. Example: kopete, gimp and VirtualBox Regarding comment #47 (Thomas Zell): This is also exactly what I'm experiencing. Regarding comment #65 (Michal): I'll disable grouping and see.
*** Bug 216916 has been marked as a duplicate of this bug. ***
With manual grouping selected this issue hasn't occurred in over two weeks.
*** Bug 217244 has been marked as a duplicate of this bug. ***
*** Bug 217585 has been marked as a duplicate of this bug. ***
I can confirm that it doesn't happen with manual grouping and sorting.. But i noticed something more. Not sure if it's possible at all but using Oxygen theme it seems not to happen (automatic grouping + sorting are enabled). Tho' with Air theme it happens. Can it depend on theme?
@ comment 86 It didn't happen to me before I switched to Oxygen the other day, so don't think that has anything to do with it.
*** Bug 217707 has been marked as a duplicate of this bug. ***
I found a simple way to reproduce this behavior using the latest snapshot: Make a window visible on all desktops, switch desktops and close it somewhere. All desktops that where showing the window now list it in their taskbar. Some programs seem to erase their entry. When trying this with Kopete you can remove the Icon, by opening Kopete from the tray and closing it again, then one taskbar is cleaned up, I can´t get 2 Kopetes in the taskbar. Other programms (Kontact, opera, tvtime) just stay. After a crash windows also don´t disappear, couldn´t figure out a way of reproducing that precisely. I´ve set the taskbar to no grouping, manual sorting and only showing the windows of the current desktop. I don´t know if that´s the same bug or if this is something different than what was posted before in this report.
*** Bug 218366 has been marked as a duplicate of this bug. ***
comment on how to reproduce from another report: When a window from another virtual desktop gets closed, the taskbar entry does not go away. How to reproduce: Open a dolphin window on the first virtual desktop, go to virtual desktop 2, kill the dolphin window from konsole. -> the taskbar entry on desktop #1 is still there, but dolphin is killed. My setting is to only show tasks from the current desktop.
Weird. I do have the taskbar problem, but I cannot seem to be able to reproduce it with the two above recipes. Also it looks like I am encountering the problem with different frequency on different machines, the slower ones being more sensitive.
I don't really know how libtaskmanagers internals work but I suspect that it might has something to do with kwin, rather than libtaskmanager. Can anyone who has time test if it does occur with other window managers (like compiz)? I don't have time to test this myself, sorry.
*** Bug 218486 has been marked as a duplicate of this bug. ***
(In reply to comment #93) > I don't really know how libtaskmanagers internals work but I suspect that it > might has something to do with kwin, rather than libtaskmanager. Can anyone who > has time test if it does occur with other window managers (like compiz)? I > don't have time to test this myself, sorry. I am seeing that behaviour with compiz, so it's not kwin related. Also, the only interfaces between the taskbar and the WM are _NET_CLIENT_LIST and _NET_WM_DESKTOP (kwin) / the window position (compiz), I don't see how anything can be broken there. Also, it only seems to happen if automatic grouping is enabled (comment #86), which points even more into libtaskmanager's direction.
According to the reporter of bug 218800, this seem to happen on KDE SC 4.3.80 (4.4beta1) too
*** Bug 218800 has been marked as a duplicate of this bug. ***
I must say that I have never been receiving this bug on 4.2.x or 4.3.x versions, though I have been using most betas from opensuse factory. Yesterday I have upgraded from 4.3.1 (with some opensuse backports I suppose) to 4.4beta1 (from opensuse factory too) and this started to happen very often - currently I have kopete message and skype windows ghosts sitting in my taskbar. Taskbar options: grouping=no grouping sorting=alphabetically filters=only show tasks from current desktop=true, other filters=false
ok, I was able to reproduce this. This happens when some event comes to a window which is located on non-current desktop, then I go to that desktop and close this window - the closed window taskbar ghost remains alive on the original desktop. This can be simulated with kopete message window. You will need a friend who will send you message on your demand or 2 jabber accounts on same kopete instance. I have 2 jabber accounts (1 for gmail, 2nd for jabber.ru) 1. Open jabber2 contact in kopete contact list 2. Send message to it from name of jabber1 - at this moment you will have one kopete message window with 2 tabs 3. Detach one tab and put it to desktop2 4. Send 2nd message from message window in current desktop1 - it should come to the detached message window on desktop2 and would make it blink on current desktop1 taskbar 5. Goto to desktop2 and close message window 6. Return to desktop1 and see message window ghost in taskbar. I suppose "Only show tasks from current desktop" options should be enabled (I have it enabled, but did not test without it though).
By the way, I would be happy if there were an option to disable this taskbar blinking when something happens with the task from another desktop - I think notification area is a better place for that.
resolved in r1063320
please backport to 4.3 too!
there is no more release planned for 4.3. The next official kde release will be kde 4.4.
*** Bug 219600 has been marked as a duplicate of this bug. ***
A 4.3.5 release will likely happen.
still present in 4.3.85 (KDE 4.3.85 (KDE 4.4 Beta2)) "release 203" from opensuse factory - not sure if "r1063320" fix should be in here or not. After upgrading from beta1 things became much better and this seemed to be fixed - I did not receive dead windows for 2 days (I did get tons of them on beta1 rather quickly), but now got again eclipse ghost taskbar item and also can reproduce issue with 2 kopete chats.
@Armin Berres: a 4.3.5 release is not currently planned. I don't know if that is going to change (http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule) @anton: the commit that fixed this issue was not included in beta2 (by a difference of some hours) Regards
*** Bug 219978 has been marked as a duplicate of this bug. ***
*** Bug 220440 has been marked as a duplicate of this bug. ***
*** Bug 221557 has been marked as a duplicate of this bug. ***
http://dot.kde.org/2010/01/26/kde-sc-435-released
*** Bug 207033 has been marked as a duplicate of this bug. ***
*** Bug 288369 has been marked as a duplicate of this bug. ***