Notes from "Async and representation"

[Sebastian Kügler]

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.

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.

> 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 plasmoidprotocol.(h|cpp) 
tries to do both, AppletInterface and Applet, which duplicates code from both. 
It should do, however:
(0) hold the QML ui in small and expanded representation
(1) forward some properties of Applet (location)

It does (0) now in a slightly different way than the scriptengine's 
appletinterface, and it only does (1) partly. One notably missing thing is 
configuration. Systray plasmoids are at this point not configurable, for two 
reasons: the configuration loading mechanism isn't included in the plasmoid 
protocol (that's yet another thing which I think we would end up duplicating).

So maybe the following would work:

The plasmoid protocol provides items which each:
- are backed by an Applet (which we put maybe into an invisible Containment, 
  or use it without?). same plasmoid or Plasmoid attached properties.
- QQuickItem* compactRepresentation() (or even the root item)
- QQuickItem* configurationUI() (which uses the plasmoid.configuration stuff)
- QQuickItem* expandedRepresentation() (optional, content for the popup)

I'm interested in what you can come up with. :)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9