what happens when a plasmoid gets created?
backing up a bit: what is a plasmoid in the first place? it's a native plasma applet. since we also support superkaramba themes and in 4.1 will have MacOS dashboard widget support (the code is there, we're just waiting on a release of webkit which will happen in the first part of '08), we needed a way to disambiguate between these guest widgets and plasma widgets which use the plasma framework fully. superkaramba themes in kde4 can straddle that fence somewhat, and i'd not be surprised to see other widget types be supported in the future either.
ok, so that's a plasmoid. now, what happens when we create one? here's the general play-by-play as seen by an applet written in c++:
creation: the constructor is called. this is when a reasonable default size should be set with setSize. it is still in a bit of a limbo situation at this point, however. it doesn't have an associated containment nor has its configuration been set up yet. so other than setting some basic flags and a default initial size, nothing else should be done here.
basic configuration: now some basic configuration data is read and applied for the plasmoid: geometry, location, containment. the plasmoid itself doesn't actually do anything here, as this is automatic.
initialization: the init() method is now called and the applet can now read any special configuration data unique to the applet and set up resources such as SVGs that are necessary for proper operation and display. configuration dialogs and other on demand pieces should probably not be created here, as that will only slow down start up.
it is important to remember that any applet may appear 0, 1 or more times in the same or different containments. to accomodate this, there is both a per-instance configuration object (fetched via the config() method) as well one that is shared by all instances of the same kind of applet (accessed via the globalConfig() method).
via kconfig's nested groups, plasmoids can create as many config groups as needed or desired. example code might look like:
the choice of colors above is probably not the greatest as an example, actually, since Plasma::Theme provides access to a KColorScheme which matches and compliments the plasma svg theme in use.
backing up a bit: what is a plasmoid in the first place? it's a native plasma applet. since we also support superkaramba themes and in 4.1 will have MacOS dashboard widget support (the code is there, we're just waiting on a release of webkit which will happen in the first part of '08), we needed a way to disambiguate between these guest widgets and plasma widgets which use the plasma framework fully. superkaramba themes in kde4 can straddle that fence somewhat, and i'd not be surprised to see other widget types be supported in the future either.
ok, so that's a plasmoid. now, what happens when we create one? here's the general play-by-play as seen by an applet written in c++:
creation: the constructor is called. this is when a reasonable default size should be set with setSize. it is still in a bit of a limbo situation at this point, however. it doesn't have an associated containment nor has its configuration been set up yet. so other than setting some basic flags and a default initial size, nothing else should be done here.
basic configuration: now some basic configuration data is read and applied for the plasmoid: geometry, location, containment. the plasmoid itself doesn't actually do anything here, as this is automatic.
initialization: the init() method is now called and the applet can now read any special configuration data unique to the applet and set up resources such as SVGs that are necessary for proper operation and display. configuration dialogs and other on demand pieces should probably not be created here, as that will only slow down start up.
it is important to remember that any applet may appear 0, 1 or more times in the same or different containments. to accomodate this, there is both a per-instance configuration object (fetched via the config() method) as well one that is shared by all instances of the same kind of applet (accessed via the globalConfig() method).
via kconfig's nested groups, plasmoids can create as many config groups as needed or desired. example code might look like:
KConfigGroup cg = config();
KConfigGroup colors(&cg, "Colors");the choice of colors above is probably not the greatest as an example, actually, since Plasma::Theme provides access to a KColorScheme which matches and compliments the plasma svg theme in use.
10 comments:
I like that about Plasma returning a theme to compliment the desktop theme. It's one of those small things that usually go by unnoticed but in the end cause everything to come together.
Will plasmoids eventually be draggable to/from the panels and desktop? One note on the desktop toolbox - people may want to use that corner of the screen to activate something else, perhaps an expose-like feature of their window manager. Please make it configurable eventually. KDE3 was great that way - almost any behavior could be set up with configuration options, and that sets KDE apart from Gnome. don't loose that.
> Will plasmoids eventually be draggable
> to/from the panels and desktop?
that's the idea.
> One note on the desktop toolbox - people
> may want to use that corner of the
> screen to activate something else,
> perhaps an expose-like feature of their
> window manager.
how would the desktop toolbox interfere with that, exactly?
Would it be possible to see a screencast of the zoom out feature. I would like to understand it but at the moment can only equivicate it with what I know so when zoom out is used I see an expose looking screen but with no other desktops. Is there something I am missing or are there some features not implemented (time-line mayB). MayB the zoom out feature is so that widgets can be placed off screen and so not clutter the workspace and be called upon like how OSX brings them forward but instead of them being brought forward they are moved to the sides of the screen, I still don't exactly know but you've convinced me there's a cunning plan.
hm, why notmake that plasma toolbox button an plasmoid (u know, a button-plasmoid) too? that way users could decide where the button is, (maybe you could make a dbus command to display the toolbox at a given position, then the button would invoke that dbus command), or could just don't use that button too (for example, to just have a complete empty desktop without buttons only showing a background image.
i understand that you think that this button in that corner doesn't annoy you, but there are people who actually feel annoyed by such a thing :/
i hope i could help a bit, bye bye. find me on irc, i'm litb :)k
Hi Aaron,
I am using the latest kde4 snapshot for opensuse 10.3. kde4 works fine. I only have a problem with the plasmoids on the desktop. there are definitely lagging. so when I for example want move the plasmoid it takes some seconds for the plasmoid to actually move. any idea what could be the problem. (same with closing the plasmoid)
thanks for the great work so far!
DITC
@litb:
That actually sounds like a pretty good compromise to me.
Are the plasmoids isolated in their own process space? The reason I ask is that I've noticed a buggy plasmoid bringing the whole desktop down. (insert all acknowledgements about beta testing and development code).
Derek
@derek kite
No, Plasmoids are all executed in process, so we will always have the situation where a buggy (native code) Plasmoid brings down the entire desktop. Plasmoids written in Javascript/ Python/ Ruby/ whatever are immune to this, though, and also have the advantage that they are significantly easier to download and install.
@Dave Taylor: yeah, i'll eventually do a screencast on that for sure =) there are a handful of features that may not make it into 4.0 that i want to have done before doing it though ... but as soon as its ready i'll cast it =)
@litb: "why notmake that plasma toolbox button an plasmoid"
keeps the rest of the code a lot cleaner. i don't like special casing too many things, and want to keep the corona->containment->applet hierarchy as clean as possible
"but there are people who actually feel annoyed by such a thing "
i'm not arguing that. i'm actually asking for *why*. if it's just a matter of "i'm not used to it" then i'm not overly motivated to introduce more code to address that. if there is a functionality issue, then i need to understand that issue so as to create a proper fix.
so far the complaints have been light on the details. i find that the best way to get those details is to not do anything until someone provides them ;)
@anonymous: "there are definitely lagging"
that's because of compositing. i don't know what the interplay is exactly at this point, but it happens with both compiz and kwin4 with composite enabled. disable compositing and things get really smooth. =/
@derek kite: the anonymous answer is correct; and the reason for things being in process is that out-of-process means a LOT more overhead (a LOT) and makes visual effects and harmony pretty much impossible. it also isn't a cure all for stability problems, as the systray can attest to.
Post a Comment