Thoughts about architectural changes in Plasma 6

[Marco Martin]

On Fri, May 14, 2021 at 1:24 AM David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> 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.

yeah, that would need a new name

> The common base also potentially means we don't want Applet::busy and
> such in here.

busy per se is not terrible.. I can imagine containments that could
depend on remote loading of stuff.. i just wonder if would be better
to "just slap your own busywidget inside if you need it", for any
applet, so this in particular, not bad to have, but not really
necessary either (iirc there are some plasmoids even in workspace
which do the spinner themselves mostly because developer didn't knew
about it)

> and I want all the screen management gone.

that i'm not sure of.. I would move from integers to connector names,
but would still consider a containment->screen() somewhat necessary?
I didn't spend much time yet on thinking about screen management, how
would you do it?

> > * 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.

I do like the clear separation, to me is a lot about be a development
aid as a strict enforcement against going to poke graphical object in
the scene in areas that should just be "model", and have all the
qqickview/item related stuff obviously grouped in a single place, a
different library, even if is in the same git repo.
on the proposed architecture, having the qml part separed so far gives
only one drawback, is that Applet should ideally have a
PlasmoidRepresentation member, which if separed it can just be a
generic QObject, which is not optimal, but but functionally not really
incident.

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

That's a good point, i'm not sure about using subclasses for it..
I also don't exclude the future need to have arbitrary new kind of
representations,
I don't have examples, i just want  to consider the possibility.
I would probably prefer to support to explicitly to support putting
explicitly null as the representation.

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

though would be two different mainfiles in the package depending if
it's loaded as containment or as an applet?
yeah, if there is a fallback when ie a containment specific mainfile
isn't found it may work.. kinda like it

-- 
Marco Martin