Bug 153806

Summary:	taskbar creates two tasks when starting an application
Product:	[Unmaintained] plasma4	Reporter:	S. Burmeister <sven.burmeister>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	l.lunak
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Combines StartupTaskItem and WindowTaskItem

Description S. Burmeister 2007-12-10 23:10:00 UTC

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.

Comment 1 Jason Stubbs 2007-12-16 10:37:12 UTC

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.

Comment 2 Alex Merry 2007-12-16 11:17:53 UTC

Just a nitpick - shouldn't this be closed as WONTFIX, rather than INVALID?

Comment 3 Jason Stubbs 2007-12-16 11:52:11 UTC

I can live with that. To be honest, I wasn't sure what to pick.

Comment 4 Jason Stubbs 2007-12-16 11:56:17 UTC

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.

Comment 5 Lubos Lunak 2007-12-17 16:08:56 UTC

> 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.

Comment 6 Jason Stubbs 2007-12-18 03:29:15 UTC

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?

Comment 7 Lubos Lunak 2007-12-18 09:53:04 UTC

KStartupInfo::checkStartup() should be the call, and you can then compare id's.

Comment 8 Jason Stubbs 2007-12-18 10:32:05 UTC

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?

Comment 9 Lubos Lunak 2007-12-18 11:23:37 UTC

How do I reproduce that? That should not happen, signal about startup finished should always come after the window appearing.

Comment 10 Jason Stubbs 2007-12-18 15:34:15 UTC

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. :)

Comment 11 Jason Stubbs 2007-12-24 15:09:49 UTC

This is fixed with http://websvn.kde.org/?view=rev&revision=752367