They range from the trivial-but-was-in-KDE3 pattern based wallpaper plugin to Jonathan's weather wallpaper which automatically changes the wallpaper to reflect the weather. It of course uses the weather DataEngine, allowing Jonathan to concentrate on the business of making a neat wallpaper concept come to life.
To support his efforts, I added DataEngine support to the Wallpaper class so that using DataEngines is as easy from a Wallpaper as it is from a Plasmoid. Feeling I was on a Wallpaper role, I made a few other additions to the Wallpaper support:
- Wallpapers can now get their configuration sync'd to disk just like Plasmoids and Containments can, so even if the application crashes or some other disaster befalls the system you don't lose your new wallpaper settings.
- Wallpapers can mark themselves as needing to be configured, much how Plasmoids can.
- Plasma::Wallpaper now includes multi-threaded wallpaper rendering built in; this used to be part of the Image wallpaper plugin and people writing plugins were starting to copy this code wholesale. So into libplasma it goes.
- There is on-disk caching of rendered Wallpapers if the plugin indicates it would be a good idea to do so (it makes no sense, however, if the wallpaper is going to change a lot). This means the next start-up is a lot faster: it just loads a perfectly rendered paper instead of loading an image from disk and then scaling it or whatever first.
- The slide show wallpaper now pops up a progress dialog while scanning the contents of a directory so that things don't just "freeze up"; this caused an annoying bug that Thiago hit upon, but he sleuthed it down and I fixed it with a one-liner. Rejoicing was to be had.
- I added a small tool, plasmawallpaperviewer, that lets you load and configure wallpaper plugins. This is much more convenient for development than restarting plasma-desktop every time you want to see how your plugin is coming along. plasmawallpaperviewer joins plasmaengineexplorer and plasmoidviewer as part the handy group of developer tools that come with the Plasma workspace.
Which reminds me of a topic I've been meaning to blog about for a while: if you are writing an application that has plugin support and those plugins are non-trivial, work with the rest of the application (making regressions in the framework hard to pin down without further examination) and/or you want people to write lots and lots of them, be absolutely sure that you include a small driver application that exists only to load and interact with those plugins.
Not only is it much faster to start a small application like that than a full feature killer application, it also serves to isolate the plugin at runtime. You know that anything that's going wrong is either a problem in the testing app (though given how small these apps tend to be, bugs tend to be found and killed quickly and easily), in the framework code or in the plugin itself. Plugin writers will be able to trust that any problems they see are likely behaviours of their plugin and not some odd interaction in the context of a larger sea of plugins.
Speed and ease are what help people make good plugins and lots of them. In Plasma we have a tool for people writing Plasmoids, another for DataEngines and now one for Wallpapers. KRunner is already a good tool for testing AbstractRunner plugins, so we don't need a separate tool for that species.
Adding the ability to write plugins in dynamic languages is also a pretty good plan, and with Plasmate we will be stepping it up with an ultra-simple Plasmoid and DataEngine creator. Plasmate won't be released with 4.3, but it should make it into 4.4, especially if some of the SoC proposals for it get accepted.
Anyways ... wallpapers. The other four wallpapers that might be seen in 4.3 are an interactive mandelbrot generator, a world map (and yes, it uses Marble! :), "virus" which simulates your wallpaper being eaten up by small colonies of breeding pixel munchers and finally a plugin that loads and displays E17 Edje content (so you don't have to be jealous of their pretty wallpapers anymore ;).
While wallpapers aren't exactly critical features, they can be a lot of fun. Sure, it's not "big picture" stuff, but that's ok ... sometimes fun and cool is enough. We have lots of seriousness elsewhere to make up for it. ;)
I'm sure someone will ask about per-desktop wallpapers and drop-an-image-and-it-gives-you-the-option-to-make-that-wallpaper in the comments; I doubt it'll be in 4.3. Both are features that get asked about here and there, but it's not up there in importance enough for anyone to have stepped up and written a patch for either one. Hint, hint. :)

19 comments:
How about the good old feature of configuring wallpapers per desktop (in addition of per activity), or even connecting activities to desktops so that plasmoids even switch with them?
Personally I use desktops to seperate my daily work into communication work, document work, project work, etc. For each type of work (and thus desktop), I have different documents opened, may need different plasmoids and also have a different wallpaper.
Hmm, geolocation... Are you using GeoClue? If not, may I ask why?
@ingwa: geoclue pulls in a number of unwanted dependencies. thankfully there are nice free software libraries out there for gps, host.ip, etc. so that our work is actually very minimal to get this going.
the engine is, according to sloccount, all of 381 LOC at the moment. not exactly a huge investment ;)
@eva: per-desktop activities is implemented in the code, we just don't have a UI to turn it on yet due to the feature needing more polish and a global plasma config dialog needing to be made (we do have a list of what needs to be in that config dialog on techbase)
What about having multiple wallpapers in each desktop? That was an old feature in KDE 3.x series.
How about this to be integrated into kde?
http://insitu.lri.fr/~roussel/videos/metisse/facades/uifacades.mov
seems very natural to move important or frequently used icons/buttons into a plasmoid from a kde application and use it as a flexible frontend to the application itself
perDesktop activities _does_ have an interface: zoom out and there's a checkbox to activate it (KDE 4.3).
moreover, it now works. i have never been able to get the hack previously mentioned (entry in plasma_desktop.rc) to work; it kept screwing up my configuration, whatever i tried.
now activities may change from one desktop to the other after zooming out and in, but everythign else works great.
thanks a lot for this useful feature,
phani.
It's great to hear about the improvements around wallpapers. the "plasmawallpaperviewer" sounds very useful but where in SVN is it? and is there any chance of a opensuse package soon? (yes these days i'm very lazy).
Wallbuntu* should _so_ switch to KDE 4.
* http://www.phoronix.com/scan.php?page=news_item&px=NzE4MQ
The location finder would work perfectly for the multitude of weather based Plasmoids/Applets/Widgets/Gadgets/Gizmos (I forget which one you prefer) so that'd be great.
I've just had a look at Enlightenment wallpapers and it appears that some are more than just gaudy so hopefully some more will be inspired by this enclusion.
I assume the per desktop activities will allow for per desktop wallpapers, that would be quite nice,
@aaron: Can you tell me which dependencies you are particularly disturbed by? I have investigated geoclue and will hack it to e.g. not use gconf for its settings. And I have buy-in for this from the developers. But are there more?
hi aaron. do dual monitor (3300x2160) wallpapers somehow fit into the plasa concept?
@ingwa: I looked up GeoClue, its documentation says: "Internally it's implemented with GLib and GObject (as is the C wrapper library). Several included providers also use Libxml2, and the master provider uses GConf". So that's a sizeable amount of GNOME dependencies.
@phani: indeed, that's already in now. cool. i saw the patches flying but haven't checked the status of the corona box in a couple weeks. :)
@bjacob: the wallpaper viewer is in kdebase/workspace/plasma/tools/wallpaperviewer
it'll be part of 4.3 pre-release packages.
@ingwa: gconf is a big one, and i haven't seen any movement on the geoclue front to fix this issue.
the API would need to be bridged via a Plasma::DataEngine anyways to be useful to our javascript and other non-C++ widgets anyways. turns out there's very little effort to make this happen without geoclue and we get a nice API to work with as a bonus.
should geoclue become useful for kde, we can use it in the DataEngine and not change anything in the widgets. so it's all upside for us, including not waiting an eternity for geoclue to be modified to our needs (or not)
@Goliath23: they can work, but it's something nobody has worked on yet.
@SlashDevDsp:
http://insitu.lri.fr/~roussel/videos/metisse/facades/uifacades.mov is very cool! Not sure how useful it would be in real life, but it's very interesting research.
I've just have idea. What do you think about plasmoid layers in stand of wallpapers engines. Each layer could be in one of three modes:
background - only to display not interactive
locked - like now locked plasma desktop
unlocked - like now in plasma too
Wallpaper could be just plasmoid at background bottom layer
There is one advantage with GeoClue and that is that it communicates via dbus. This will let marble use it quiet easily, for instance. Will the Plasma data providers be possible to access from non-plasmoids also?
@k: that would tie wallpapers to QGraphicsScene which we don't actually want; but more importantly, what you're describing is the difference between a plasmoid and a containment. it turns out, however, that when you promot a plasmoid to a containment (active background), you often (though not always) also want a wallpaper.
@ingwa: "There is one advantage with GeoClue and that is that it communicates via dbus."
this is, of course, completely academic for us until there is a release of geoclue that no longer depends on things like corba and gconf.
"This will let marble use it quiet easily, for instance."
sure :)
"Will the Plasma data providers be possible to access from non-plasmoids also?"
you need to link to libplasma, but DataEngines are not tied, API-wise, to Plasma::Applet or anything else like that. we're very careful about high integration while maintaining loose coupling in libplasma.
if linking against libplasma isn't an option for you, then no, that won't help you much.
i have considered a number of times putting the dataengines out in their own process, however, with a dbus interface to them so they can be shared universally by any app that wants it.
it would be rather trivial to accomplish, really.
@jospoortvliet
@aaron, please take a look at the video i posted in an earlier comment and this site :)
It came out in 2006 - source code is available here: http://insitu.lri.fr/metisse/facades/
and I think its possibly the best way forward to create plasmoids? by directly running a kde application frontend and dragging and dropping the icons/text or video output from the kde application into a plasmoid frame and everything works and you can save the state of the plasmoid as a facade according to the video and reload it - seems like the core plasmoid functionality with user customisation at the max.
I believe the Xorg guys are looking into it? but i believe it should be integrated at the window manager level.
Post a Comment