playground plasmoid redux

[Aaron J. Seigo]

On Thursday 09 October 2008, Jason Stubbs wrote:
> >> This is definitely a possibility, but I'm not sure it's really possible
> >> to accomplish by October 19th. Assuming that the icon would show/hide
> >> the extender, there are issues such as the interaction between the
> >> kuiserver hide/show and knotify notifications, or how an icon adding
> >> through the Task protocol can even get access to the extender.
> >
> > the attached patch addresses this issue. (along with a couple of other
> > minor items, like removing the direct use of the Manager from the
> > TaskArea class)
>
> -    QGraphicsWidget* widget();
> +    QGraphicsWidget* widget(Plasma::Applet *host);
>
> ^^^ is the most important part of the patch, I take it? Yeah, that

yep =)

> works. My main concern is/was that strong dependencies would start
> popping up between the parts. The above change allows the entire U/I
> to be rewritten from scratch without any changes to core/ or
> protocols/ so I'm happy. :)

yeah, i tried to be careful about that very thing (and why i pass in a 
Plasma::Applet* instead of a point to SystemTray::Applet*) ... it's also why i 
removed usage of the SystemTray::Manager class from the SystemTray::TaskArea 
class, to make the "surface area" of the interface points between core and ui 
as small as possible.

> > i also realized while writing the patch that the plasmoid protocol has a
> > fatal flaw: it creates one widget per task, but the tasks are global
> > (shared between all instances of the tray). part of the solution here is
> > to actually implement configuration management which we can do more
> > easily once we have access to the applet object in question, which this
> > patch brings us one step closer to.
>
> I still haven't looked closely at the plasmoid protocol, but this
> likely comes from the fact that it was derived from the FDO protocol,
> which of course cannot have more than one widget per task.

yep; i should have time to work on it between now and 4.2 as well .. worst 
case scenario is that the plasmoid protocol sits dormat for 4.2.0 and we 
expose it to the user in 4.3. in the meantime, we can continue working on it 
ourselves.

> > (it also doesn't allow more than one of the same applet, but that's
> > another matter =)
>
> I didn't notice this, but if you are referring to typeId being used as
> the "unique" key, FDO has exactly the same problem.

no, it's a different (though similar looking) problem. the winId for FDO is the 
unique key, but for the applets the unique key is not the applet name but the 
applet id. so it's just using the wrong bit of information (which is non-
unique) as the key.

> > i think we will need to pass in a KConfigGroup to Protocol::init, and not
> > create the protocols when the manager is created but have an init on the
> > Manager class as well.
>
> I don't see exactly where you're going, yet. Looking at your patch,

ah, the idea is that some protocols will need access to configuration, and it 
needs to be parented to the systray's own KConfigGroup. the use case here is 
that the plasmoid protocol needs to track both which applets to load as well 
as give those applets somewhere to store their configuration.

> > most of the awkwardness in systray-refactor comes from parts of it being
> > written as if it were a 3rd party library to be re-used elsewhere when
> > that really isn't the case. a bit more coupling in the right places
> > between the core/ and ui/ classes will make things a lot easier.
>
> Actually, my intention was/is to split out everything other than ui/
> into a separate library. Not much has been done with the systray and
> friends in KDE4, I think mostly because the code is very hard to
> approach. Moving the internals to a separate library would allow for
> more U/I experiments. If it could be made a data engine, even better.

yes, that's all true. the same could really be said about the systray in kde3.

for 4.2 i don't think we should be too overly worried about turning this into 
a library, though ... let's target 4.3 for that.

> Seriously though, my only real concern is that I don't have time to do
> it myself due to work and that I'll be busy moving back to Australia
> (finally! yay!)

huzzah! congrats, and i hope it all works out smoothly for you..

> during the RC period through the first couple of weeks
> after release. I, personally, don't want to do much more than spend
> the next 2 months making sure that the fdo protocol is working the
> best it can be (or at least the best i can make it. :)

makes sense. btw, someone on irc was throwing around some patches that use 
xrender to render the icons off-screen and then composite them directly onto 
the tray when we have compositing available to us.

the benefit is that when we have compositing we can:

* make the icons move with the animating of the panel
* even do crazy stuff like have multiple trays

we'll still need to retain the current direct xembed fallback, of course, so 
it's not a panacea, just one more small step in the right direction.

> Just don't be surprised if you find me replying to a lot of commits. ;)

thanks for the heads up, it really helps with scheduling =))

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081010/729d8557/attachment.sig