Thoughts about architectural changes in Plasma 6

[David Edmundson]

On Thu, May 13, 2021 at 4:52 PM Marco Martin <notmart at gmail.com> wrote:
>
> Hi all,
> Since KF6 work is starting, I've been thinkig a lot how i would like
> plasma to be refatored, since now there may be a window of doing some
> incompatible changes.
> Here is a write down of this, wall of text ahead, I *hope* i explained
> things clearly enough in there
>
> # Problem
> How do we want Plasma Desktop to work in Qt6/Kf6 world? we can do just
> a straight port and things would work in a quite "easy" way, though
> there are  some architectural oldness, and still qt4-era porting
> leftovers which aren't really needed anymore.
> A thing that sould be done for sure, is splitting plsama-framework in
> at least 3 parts:
> * desktop layout loading (Corona,Containment, Applet)
> * Svg FrameSvg Theme
> * DataEngines (as a deprecated porting aid)
>
> I have experiments of this split partly done, but i want to talk here
> about the first part: loading the plasma desktop layout
>
> # Current State
> This is done mainly by those 3 classes in libplasma: corona (which
> we'll probably need to give it a less viral name :p) Containment and
> Applet, which represent the structure and the main properties common
> to all plasmoids.. imo that part is completely non-graphical. This
> part i think is pretty much perfect as it is, the kinda hairy part is
> how all of this connects with QML.
> Plasma 4 had this concept of scriptengine:
> Applet was proxied to another class called AppletScript which was
> intended to be a more limited version of the api to be exposed to
> plasmoids written in scripting engines which in plasma4 were
> javascript, python,ruby, qml only added later.
> The scriptengine is loaded as a plugin, and the qml one (the only one
> remained) proxies all Applet api once again in AppletInterface which
> is  a QQuickitem which does the qml loading of the files contained in
> the plasmoid package. That QQuickItem is exposed as a context property
> as the object "plasmoid" accessible form everywhere.
>
> # Proposed
> * the part in libplasma is pretty much ok

At a class level, I have lots of little nitpicks internally, such as:

Applet::Constraints
Applet::destroyed being overloaded and completely not matching
QObject::destroyed because of Undo being retrofitted.
The common base also potentially means we don't want Applet::busy and
such in here.
and I want all the screen management gone.

> * I would still keep the distincion between libplasma not depending
> from qml and plasmaquick

I would like to hear some justification for why we actually want do to this.
If there's a reason, that's fine, but we don't want to create problems
just because of history.

> * The whole concept of AppletScript should go, is not necessary anymore
> * "plasmoid" should be a pointer to the Applet * directly, to port
> away being a context property, it should probably be an attached one,

++++++

> a Plasmoid.* accessible from anywhere which is the Applet instance.
> * The thing that is now AppletInterface (or more in particular,
> AppletQuickItem in libplasmaquick) is still kinda needed, something
> that from an Applet interface does the loading of the correspondent
> QML and loads the QML file from the shell package with the expanded
> popup with a Dialog.
>
> # Plasmoid QML structure
> Now the QML plasmoid has as a main item, in Item which is not really
> used anywhere, but just used to attache the properties
> compactrepresentation and fullrepresentation.
>
> * What is now AppletQuickItem can become a simple QObject, having just
> the properties compactRepresentation/FullRepresentation, and this can
> become the *mandated* root item of the main qml file, which would
> instantiate the representation as needed
>
>     PlasmoidRepresentation {
>         compactRepresentation: Item {...}
>         fullRepresentation: Item {...}
>     }

++++++

I don't think there's been any problems having objects that can only
be used in some places. We've seen that in other places, and it's been
fine.
It'll become much easier to do things like having default margins and
default handling, but still overridable.

I would suggest maybe we should have a PlasmoidRepresentation which
just the one contentItem and a PlasmoidPopupRepresentation as above.
TaskManager having to have a compactRep and then fight against it
getting activated is quite silly.



>
>     all properties here are components, instantiated in actual items
> only as needed, lke today
>
> * The qml part of a containment may be loaded by the qquickview when a
> new containment without a view yet gets set as view's containment,
> while for applets loaded in the containment i can see mainly this way:
>
> The qml part of the containment gets the appletadded signal and
> instantiates a PlasmoidContainer (not much different from today where
> for simplicity most containments wrap applets in a further container
> item) component which gets assigned the Applet* pointer. Internally it
> will load the applet QML, which is the applet's PlasmoidRepresentation
> instance.
> A containment root item may be:
>
>     ContainmentPlasmoidRepresentation {
>         compactRepresentation: // Only useful for containments that
> are also used as applets like FolderView
>         fullRepresentation: ...
>         plasmoindContainer: PlasmoidContainer {...}
>     }
>

A full representation and the plasmoidContainer idea seem sensible.

I don't like having a compactRep here and building transforming API at
a plasma level to handle it.

We can just have separate folderview containment qml file and a
folderview applet qml file, and both of them can load the same QML
files to avoid duplication.

> All of this should give a *bit* of incompatibility unfortunately, but
> a lot of lines of code, and several in memory objects too, alongside
> some levels of indirection in the api

Yeah, but most the incompatibility is just shuffling things around in
the base class of each. I think it'll be worth it.

David