Thoughts about architectural changes in Plasma 6

[Marco Martin]

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
* I would still keep the distincion between libplasma not depending
from qml and plasmaquick
* 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 {...}
    }

    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 {...}
    }

For the desktop containment, ContainmentLayoutmanager's
AppletContainer may be a subclass of PlasmoidContainer, if possible it
would remove a level on the nesting of items over the applet full or
compact representation, currently
container->AppletInterface->qml from the shell package->actual
full/compact representation.
It would become Plasmoidcontainer->qml provided from shell->actual
full/compact representation

Alternatively, the qml that the shell package provides with the Dialog
and what not, could be itself be an instance of PlasmoidContainer,
maing the hyerarchy container(from Containment)->PlasmoidContaner
provided from shell->actual full/compact representation
(probably liking more the latter).

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