That's very interesting news beacuse the transmission for my plasmoid is
going to be easy
when these apis are released . I would like to discuss a bit more about:
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?
Sorry, I hadnt that in my mind(I didnt describe it correctly).
I dont want to access activity's widgets.
I just want to show the widgets' explorer in order to add widgets in an
activity
(just like the activities manager panel for which I think already exists
a qdbus call)
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.
In my use case when the user shows the widgets explorer, he wants to add
a widget in the activity.
So for my use case from the plasmoid I show the widgets explorer and
unlock the widgets in order for
the user to add widgets in the activity.
I think that widgets explorer must be improved. Widgets explorer acts
both as (widgets viewer and
widgets adder to activitys). This is why I think the lock/unlock widgets
was introduced in order to
protect the user from changing his widgets without want to.
An improvement for this could be in the widgets explorer from UI point view.
a) The widgets explorer shows a button for lock/unlock widgets
--The button can be in its current view
or -- it is shown on screen when the widgets explorer is shown and
hidden otherwise
b) When the user drags a widget from the widgets explorer it means that
wants to add it, so automagically
the widgets must go to unlock state.
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.
These are big design decisions for which I dont have the knowledge to
help. My use case is that
I use window previews in the plasmoid, for some this is unacceptable but
there are a lot of users
out there that like this feature. Of course before things are broken I
will have to implement the
KWin effect version for my plasmoid ... :)
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.
The qdbus approach was just an idea from a novice programmer.
DataEngine+Service works
as good with no issues.
For Activity Templates I think a decision must be made around:
( "Should plasmoids be able to expose Activity Templates???" ) For me
the answer is yes..
Because of the activities data engine I think that the decision around
"Can a plasmoid be an activity manager?" the kde community has answered yes
"In what level a plasmoid can be an activity manager? Only Basic?
Feature Complete?"
Answering the above leads in the decision for activity templates.
A data engine for activities templates wouldnt be bad at all.
I run into this when I wanted the user to be able to add an activity for
a specific activity template
and I couldnt find an easy way.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
