Plasmoid object class for QML...

[Michail Vourlakos]

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.