multiple desktops and background painting

[Christopher Blauvelt]

Where would Desktop Icons go?  Is this going to be stored per desktop?

On Feb 6, 2008 12:02 PM, Cody Tracy <fjctracy at gmail.com> wrote:

> Much better idea than my patch.  I've been trying to finish it but I'm
> loaded
> here at work.  The patch just saved settings per "desktop".  Having
> multiple
> containments sounds like a lot of overhead but better for configuration.
>  Since
> I don't use desktop effects the thought of having multiple containments
> seems
> like it would be a waste of resources.
>
> Just my 2 cents.
>
> On Wednesday 06 February 2008 10:50:35 Aaron J. Seigo wrote:
> > hi all..
> >
> > a feature we're going to need to support is per-virtual-desktop
> wallpapers.
> > however, *how* to accomplish this is the question.
> >
> > in particular, this is complicated by the fact that we now live in the
> > brave new world of composition managers. so when viewing the desktop
> cube
> > or desktop grid traditional desktop wallpapers don't really work that
> well:
> > they think they are on desktop X even though desktops 0..N are actually
> > being displayed simultaneously.
> >
> > the "solution" right now in composition managers such as the one in
> compiz
> > is to provide their own wallpaper painting and people turn off their
> > "native" wallpaper compositor. this is nasty and not what we want in
> > plasma: plasma wants to provide cool, animated, interactive backgrounds
> in
> > ways that window manager devs just aren't very interested in.
> >
> > fair enough.
> >
> > so here's my thought on how we could solve this problem:
> >
> > optionally provide one Plasma::View per-virtual desktop, per-screen.
> (right
> > now just have one Plasma::View per-screen). each View would then not
> only
> > belong to a given Screen (as they do now) but also to a Desktop.
> >
> > this would be queryable in the paintInterface, allowing the Containment
> to
> > paint whatever it thinks appropriate for that view. in the common case,
> the
> > Containment won't care and will just paint the same thing to each View.
> >
> > the downside? more Views which means more overhead. ergo the "optional"
> > bit. i'd probably make it a run-time configuration to offer per-Desktop
> > views. in the "one view per screen" mode, the view will switch the
> Desktop
> > it advertises as being associated with as the desktop itself switches
> > (allowing us to provide the lower resource (though broken for
> > compositing) "traditional" approach)
> >
> > but it's the only way i can think of making this work properly when the
> > same "desktop" from multiple virtual desktops need to be shown
> > simultneously, such as in desktop grid, cube, etc.
> >
> > this also opens the door for per-virtual desktop Containment views. e.g.
> > have Containment "Work" shown on Desktop 3, Containment "Play" on
> Desktops
> > 1 and 2 and Containment "Misc" on Desktop 4.
> >
> > thoughts? concerns? questions?
>
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080206/0e0add0f/attachment.html