On Tuesday, January 15, 2013 18:43:18 Michail Vourlakos wrote: > 1) Find the single image wallpaper for every activity. (For all the
we have a solution for this in Plasma Active: a DataEngine built into the shell called org.kde.mobileactivitythumbnails. this is rather better because then we don't have to support random components rifling through the containments. it would be possible to make this a generic feature of the shells. it could be named org.kde.activities.info (or some such) and each shell could provide an implementation specific to it. > 2) Showing widgets for specific activity. hm... this is a bit problematic, as exposing this allows applets to see what else the user is currently using .. and that really is priveleged information. (privacy, etc) we *could* provide the information in the acitivities info engine, bu tonly made available to blessed components. personally, i'd rather just not have this at all though. is it realy necessary? > 3) Unlocking the widgets before showing the widgets explorer: no applet should ever touch such internal details. if we ever change how this is done, then your applet will immediately break. if we apply the above pattern to things, this could be made into a Service that comes with the dataengine. > 4) effectiveWId for the plasmoid. In order to enable window previews in > the plasmoid I used i somehow doubt this will survive the transition to wayland, as applications are walled off from knowing much about their window. perhaps they can get the system window id, though? (Martin may know the answer to that off-hand) in any case, this is one more use case for which the existing window thumbnail approach is not easily made to fit. i'll take this to a new thread. > 5) I will open a new thread for this: > I think it would be good to add to plasma-desktop some qdbus functions > for activityTemplates support. > I dont think that there is a way for a plasmoid to know which activity > templates are installed in plasma-desktop > and also add an activity for a specific plugin. I think that all this > could be exposed through qdbus without issues. the question really is whether or not this feature needs to be accessed from outside of the shell. e.g. should krunner, or some other non-shell process be able to do this? imho: no. and if we say that only the shell process, and code running within that process, can do things like load new activities, i'd much prefer a Service than a dbus API. it keeps these things within the shell process rather than exposed to the entire world, so we may have a chance to keep control over which components can and can not use it. nearly everything (with the exception of the window thumbnails) could be provided for by a DataEngine+Service pair that is created on-demand in the shell itself using Plasma::PluginLoader. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
