Notes from "Async and representation"

[Marco Martin]

On Tuesday 28 January 2014, Sebastian Kügler wrote:
> Hey,
> 
> On Tuesday, January 28, 2014 21:14:10 Marco Martin wrote:
> > New prototype, completely different direction :)  (and that's one i
> > actually like)
> > 
> > mart/AppletAttached branch.
> > the root item of an applet can still be whatever item one wants, just as
> > current master, but plasmoid becomes an attached property, so it would be
> > possible to do things like Item {
> > 
> >     Plasmoid.title: i18n("stuff")
> >     Plasmoid.onFormFactorChanged: {...}
> > 
> > }
> > 
> > besides not having a weird Applet component that may be instantiable from
> > anywhere, another advantage is that the porting can be scriptable,since
> > Property Item compactRepresentation: can be replaced with
> > Plasmoid.compactRepresentation property int minimumWidth with
> > Layout.minimumWidth and so on.
> > 
> > I would make a fullRepresentation property available as well, but to
> > fallback to consider the root object the full representation if not
> > provided. this way less porting is needed and containments' main.qml
> > won't look completely stupid.
> 
> A more logical cases would be to do it the other way around. The full
> representation is in our default cases for the panel only needed once the
> applet is opened / popup'ed from the panel. The compactRepresentation
> should be loaded first, so we can delay loading the more complex
> interfaces.

yeah, that's how i would like to do. using the root object as full 
representation btw is pretty much for retrocompatibility (and removing 
boilerplate in some cases)
then if instead Plasmoid.fullRepresentation is provided, that's not loaded 
until the popup is open, as one would expect.

> That said, I like the AppletAttached version especially for its small code
> footprint.
> 
> The AppletComponent branch seems quite large, and it's actually breaking
> everything, with the AppletAttached branch, everything still works here.
> This is pretty important since I'm feeling more and more uneasy about
> bringing in larger changes at this point.
> 
> With the AppletComponent approach, we end up with more boilerplate for easy
> cases, which we hope to offset by more flexibility (but, given the code in
> the new branch, do we actually win that much here? Even with the current
> approach, it's about one Loader away to achieve very similar results.

now the attached version grown a bit as well, since i'm using the appletloader 
class as well there for propagating Layout, but at least should be more 
readable (compactRepresentationCheck() was the evil;)

but in the end i see that you pretty much have the same feelings as i have on 
that code, it was an interesting experiment but it shown its limitations.

So i'll finish up the appletattached branch, and will update the porting 
script since luckily in that case changes are regexp-able ;)

> > in any case both if this one or the other one is chosen, the systray will
> > have to be quite refactored, but i *may* have an idea to remove
> > completely appletinterface from the systray implementation
> 
> With the systemtray, one actual problem with the design is that we "fake"
> an Applet, which isn't actually there. That means that
> 
> I'm interested in what you can come up with. :)

It came to my mind tonight while i was writing the appletattached branch:

in plasma2, containments are just qobjects that contain applets, that are 
again just qobjects, so no graphics involved there, pure model.

So, the import of the applet can have its own containment instance (not even a 
qml containment, just a dumb containment = new Plasma::Containment())

then if we manage to make its configgroup child of the systray config group, 
all should be just fine.

all the applets have already a dynamic property set, "graphicsObject" that 
is.. oh right, AppletInterface :p

so i still have to think about how to control "create the full 
representation", "create the compact representation, maybe even more than one" 
bit, since all you have there is a QObject * so you can do not much more than 
blind property reading and slot invocation.

But i think it can work... worst case scenario, the class that right now is 
called appletloader that is a superclass of appletinterface could go in 
libplasmaquick, so would become more controllable, while still not having the 
full mess of appletinterface as public api

Cheers,
Marco Martin