It would be nice if we started putting comments with reasoning what this should do and similar in front of the blocks like these - it will be problematic to understand this code to future contributors

Why is this captured?

I have a bad feeling about this. When will the generated JS code be used?

how would you notice knf has been changed? only info about it is that key in kdeglobals

can we have kconf_update that are guarantee to run before plasmashell is started?

was also thinking about just using the same file and have the config to be lost on switch (that's actually what the vdg proposed initially) tough seems really too dangerous to me

i'm thinking about adding a
QObject *Applet::graphicsRepresentation() as the access to it seems to have became necessary in many places

DBus signal from the KCM.

It's how we do fonts, styles, colours etc.

can we have kconf_update that are guarantee to run before plasmashell is started?

Good question.

kconf_update also monitors for new scripts at runtime, which is another bug waiting to happen.

We might need to have some sort of:

if (exists(plasma-shell-appletsrc) {

move(plasma-shell-appletsrc   , plasma-shell-lnf-appletsrc)

}

Might be nice, but that doesn't solve the thing that's the problem.

You can't just randomly delete things owned by some other object. Knowing which objects owns what is a core part of good design.

From what I can see:

• Applet owns the DeclarativeAppletScript (member var script)
• DeclarativeAppletScript owns the AppletInterface (AppletScript set as parent)

delete the applet (which is literally the next line) and you delete this anyway.

If this solves a problem, you're solving it in the wrong place.

this in the conf update?

iirc i did that because if it was done automatically, some appletremoved signals were triggered causing loss of some configuration.
I'll see if i can find the root cause for that

plasmshell should have a slot for that invoked by the kcm?

what abouti do the config file move there in the c++ itself?
wouldn't be many lines and i am 100% sure it's executed at the right moment

i could send the notifychange signal of kglobalsettings, but it's kinda ugly, as it uses an integer as parameter to specify what changed, which is defined in kdelibs4support I can add a new enum value, but it's still a dependency on kdelibs4support.
This thing looks like it either needs a real replacement or other stuff (even file monitoring) should be used istead

I'm confused.

Should you be getting the current from the current Plasma::Applet* instances or are you loading state from the config file?

I'm doing what i can there.
every way to get items geometries is actually an hack, i think reading the config file is a bit more reliable, even if assumes how the config file is.
otherwise it could get to the applet graphics object then map its geometry with containment graphics object geometry (however implementation detail, it would introduce an error as the geometry of the margins of the framesvg applet background wouldn't be included then)

i can go for either of the approaches, none of them is perfect, but don't have strong preference there (while I do for the panel, as i think is the only way to ensure proper applets order)

yep, same thing for location and form factor i think

yes, it's always from a clean setup..
if you look back in the revision history, creating the applet with a specified id was exactly what it was doing in the early revisions.
As this would have needed some ugly changes to the desktop containment, after a discussion with Eike we decided to go this route instead, as it doesn't expose directly the config file format in the scripting.

to me this feature is very desktop specific (so much that i even thought at some point loading it in a plugin only for the desktop shell...
I would consider to just ignore l&f changes on shells different from the desktop one, and even to not to dump config for containments different than the 3 default ones

can't for panels, as their geometry is saved in the view as it should be, because they have a separate geometry setting per screen.

I hate this method.
tough, i need a way from the kcm to reset the current layout to the default.
it's quite dangerous and exporting a dbus method that effectively destroys the current config is evil...
other ideas?

You could do it like in KWin: make the KCM trigger a DBus signal which Plasmashell triggers to.

In the end it's going to be the same: one can destroy the current config through dbus, but it's not that exposed. Also I don't think it matters: if a user decides to shoot himself in the foot by manually triggering the DBus signal, let him.

I agree with Martin. If the user is crazy enough...

D-Bus was never really meant to be something that the users should be calling directly anyhow.

yeah, agree....
so,, I'm thinking about exposing 2 functions
loadLookAndFeel(qstring name)
reloadLookAndFeel(QString name)

the first is not destructive the second is (just to not have a bool parameter)
the destructive version, even if it's loadedwith the current look and feel reloads anyways, because destroys the current setup.

This seems not to be used