RFC: wallpaper and containment handling in 4.2

[Marco Martin]

On Friday 11 July 2008, Aaron J. Seigo wrote:
> hi all...
>
> here is my proposal for wallpapers and containments in 4.2:
>
> * the "desktop settings" dialog from DefaultDesktop will move into the
> plasma binary for the time being. this will provide the separation needed
> to make it more generic. it does not belong in Containment or any of its
> subclasses because it will be used to swap between Containment plugins
>
> * the settings dialog will be provided by the View (DesktopView, PanelView,
> etc)
>
> * the settings dialog will allow selecting both between Containment types
> for the current Activity associated with the view as well as selecting the
> Wallpaper plugin for the Containment. this really only requires one more
> combobox in the current dialog (to pick between Containments)
>
> * a wallpaper plugin API will be defined. the api (a QObject subclass) will
> be kept very simple and will provide the following properties:
>
> 	QRectF boundingRect -> the geometry to paint into, public read/write
> 	Plasma::FormFactors formFactors -> the form factors this wallpaper allows,
> public read, protected write; defaults to "All"
>
> the following signals:
>
> 	void update(const QRectF &exposed area) -> used to connect to the
> Containments update() method
>
> the following methods:
>
> 	void paint(QPainter *painter, const QRectF &exposed area) (public,
> virtual) QWidget *configuration(QWidget *parent) (public, virtual)
>
> * Wallpapers should be ScriptEngine-able
>
> * Containment will support loading and using a wallpaper plugin. assuming a
> wallpaper plugin is used, the wallpaper's paint method will be called from
> the Applet::paint method. there will be a setWallpaper(const QString
> &pluginName) method for setting the paper
>
> * Containment subclasses will be able to define whether or not they support
> arbitrary wallpaper plugins, no wallpaper plugins or a specific set of such
> plugins (by category? by KServiceTypeTrader syntax? hmm...)
>
> * we will need a way to migrate all the applets from one Containment to
> another, destroy the first and set the geometry (and screen and desktop) of
> the second one in its place
>
> * Containments will be able to provide, via their .desktop file, the name
> of a preview picture that we can use, for instance, as an overlay on top of
> the wallpaper preview in the configuration dialog
>
> i await your comments, criticisms and ideas for improvement.

there is a thing that i've not wel understood:
if the wallpaper drawing code is plugin based, it basically means that it 
could not be always true that the wallpaper is a picture, it could be also 
something procedurally generated, composition of multiple pictures, who knows 
what...
and this flexibility i think it's very neat.
but in this case it's also needed a way for the configuration dialog to choose 
what plugin load, and for every plugin a different set of options should be 
displayed, a wallpaper plugin would have the usual image selector, something 
else could have other things..
so the plugin would have also a method that returns its configuration widget 
to be embedded in the desktop setting dialog? or the plugin provide the 
entire dialog itself?
uhm...

Cheers,
Marco Martin