Version: (using KDE Devel) OS: Linux When one starts an application the taskbar starts an empty task and the application's next to it. If the application is fully loaded the empty task disappears and the new one moves to the left. This causes the taskbar to be calculated at least twice and hence causes unneccessary repaints.
The same thing happens with kicker in kde3. It's just the animations making it more pronounced. I don't know if it's just a problem with the available APIs or a technical issue, but it's not currently possible to correlate start-up notifications with the first window that an application opens.
Just a nitpick - shouldn't this be closed as WONTFIX, rather than INVALID?
I can live with that. To be honest, I wasn't sure what to pick.
Reclosing... By the way, turning off taskbar startup notifications is a slight workaround. Also, animations have been fixed so there's _much_ less repainting going on.
> it's not currently possible to correlate start-up notifications with the first window that an application opens. This is not true. In fact, it's exactly the point of startup notification to be able to identify the first window of the launched application, so it should be perfectly possible to merge the two entries. This is valid at least as a wish.
I've already got code that does the merging but couldn't tie the startup notification to a window. Seeing that kde3 doesn't do it and not being able to find the APIs, I figured it wasn't possible. Which part of the API can be used for it?
KStartupInfo::checkStartup() should be the call, and you can then compare id's.
One other thing.. Sometimes the startup removed signal comes before the new window signal. The difference at the moment can be seen from whether the animation is a slide or a fade. I'll try keeping the startup info object around for a second to see if it can still be used, but is there a better/other way to handle it?
How do I reproduce that? That should not happen, signal about startup finished should always come after the window appearing.
Created attachment 22610 [details] Combines StartupTaskItem and WindowTaskItem I can't reproduce it either. ;) It was definitely happening the other day though... Anyway, here's a patch that should fix this bug without being too invasive. Basically, I've merged StartupTaskItem and WindowTaskItem on the applet side of things and added startupId() to Task in the taskmanager library. Anything look out of place? If not, I'll commit. :)
This is fixed with http://websvn.kde.org/?view=rev&revision=752367