Seeing activities' icons would make it faster to choose an Activity from the menu.
Works for me (KDE 4.8.3).
Woks for me too (KDE 4.9 RC2)
Does only work for icons set by the user. Default icons (the colored balls) are not shown. This is pretty ugly as it looks like something is broken. Re-close if you don't agree, but I think the menu should either show ALL icons or NONE.
Short comments: a) this is not a kwin issue, for it just relies on KActivities::Info::icon() for _all_ activities. b) MORE IMPORTANT: that and KActivities::Info::name() are STILL SYNC DBUS calls in usermanager.cpp / void Workspace::activityPopupAboutToShow() :-\
moving to KActivities, see comment #4
> this is not a kwin issue, for it just relies on KActivities::Info::icon() for _all_ activities. Plasma just conveniently provides identicons for the activities that have no icons. So, no other user sees them. I don't really think this code (libplasma-dependant) should be in KActivities. On the other hand, I do agree it is not really a kwin issue. > that and KActivities::Info::name() are STILL SYNC DBUS calls in usermanager.cpp / > void Workspace::activityPopupAboutToShow() This is a KWin implementation issue - the name() method wouldn't be sync if it were used in a long-lived Info class instance. When doing the { Info activity(id); activity.name(); ... } it is not giving it the time to fetch the name from the service before it is requested. KActivities now provide a data model that lists activities. It should be used in kwin at some point. Anyhow, since we survived with it for a few releases now I think we should wait for this change for after 4.10
(In reply to comment #6) > This is a KWin implementation issue - the name() method wouldn't be sync if > it were used in a long-lived Info class instance. When doing the The comment is older than the kactivity changes ;-P And yes - the activity implementation in kwin is still rather a mess. Needs a complete review & cleanup (too much code doubling from the virtual desktops, too many TODOs. Too much commented desktop cloning code) I ever wanted to call on action for this. Any plans for this WE?
Ah, damn, the new mail was about Martin changing the component :D About the plans - hmh, not sure how pleasant would be to unify the code between activities and VDs since they do have slight differences in kwin behaviour.
I didn't really mean to "unify" the code, but esp. to get the activty management in shape (ie, get rid of "//TODO do i need this" comments), see what's left and eventually merge some shared basics. The next step would then be to figure whether VD and activities should actually remain the way they are or whether activities should become some sort of advanced VD (as they are now) - implementing an extended version of the NETWM spec and VD more like a viewport (with static desktop and floating windows) - but that would first have to pass kcd anyway.
Can't this be closed? Works for me on 4.10.5
Still valid as far as I can see (kde 4.11.5) : user-chosen icons are visible, but not software-generated patterns. If this is an issue of the software-generated icons being implemented by plasma but not kwin nor kactivities, it seems to me that the fix is to move plasma's implementation over to KActivities::Info::icon() ? Otherwise users will keep getting confused with activity icons showing in one place but not another.
Can you please look at the image and tell me if you see this bug? http://i42.tinypic.com/2i0t402.jpg I do not mean to get this closed, I just would like to know if I am missing something.
The bug is about the popup menu entry (rightlick a window titlebar)
Okay, I see it too.
'Coloured balls' do not exist any more. Closing this.