[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: multiple desktops and background painting
From: "Christopher Blauvelt" <cblauvelt () gmail ! com>
Date: 2008-02-06 20:05:45
Message-ID: ffa898c90802061205xa5a1acftbc1cb5da7eaef50d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Where would Desktop Icons go? Is this going to be stored per desktop?
On Feb 6, 2008 12:02 PM, Cody Tracy <fjctracy@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@kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
[Attachment #5 (text/html)]
Where would Desktop Icons go? Is this going to be stored per desktop?<br><br>
<div class="gmail_quote">On Feb 6, 2008 12:02 PM, Cody Tracy <<a \
href="mailto:fjctracy@gmail.com">fjctracy@gmail.com</a>> wrote:<br> <blockquote \
class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: \
#ccc 1px solid">Much better idea than my patch. I've been trying to finish \
it but I'm loaded<br>here at work. The patch just saved settings per \
"desktop". Having multiple<br> containments sounds like a lot of \
overhead but better for configuration. Since<br>I don't use desktop effects \
the thought of having multiple containments seems<br>like it would be a waste of \
resources.<br><br>Just my 2 cents.<br>
<div>
<div></div>
<div class="Wj3C7c"><br>On Wednesday 06 February 2008 10:50:35 Aaron J. Seigo \
wrote:<br>> hi all..<br>><br>> a feature we're going to need to support \
is per-virtual-desktop wallpapers.<br>> however, *how* to accomplish this is the \
question.<br> ><br>> in particular, this is complicated by the fact that we now \
live in the<br>> brave new world of composition managers. so when viewing the \
desktop cube<br>> or desktop grid traditional desktop wallpapers don't really \
work that well:<br> > they think they are on desktop X even though desktops 0..N \
are actually<br>> being displayed simultaneously.<br>><br>> the \
"solution" right now in composition managers such as the one in compiz<br> \
> is to provide their own wallpaper painting and people turn off their<br>> \
"native" wallpaper compositor. this is nasty and not what we want \
in<br>> plasma: plasma wants to provide cool, animated, interactive backgrounds \
in<br> > ways that window manager devs just aren't very interested \
in.<br>><br>> fair enough.<br>><br>> so here's my thought on how we \
could solve this problem:<br>><br>> optionally provide one Plasma::View \
per-virtual desktop, per-screen. (right<br> > now just have one Plasma::View \
per-screen). each View would then not only<br>> belong to a given Screen (as they \
do now) but also to a Desktop.<br>><br>> this would be queryable in the \
paintInterface, allowing the Containment to<br> > paint whatever it thinks \
appropriate for that view. in the common case, the<br>> Containment won't care \
and will just paint the same thing to each View.<br>><br>> the downside? more \
Views which means more overhead. ergo the "optional"<br> > bit. i'd \
probably make it a run-time configuration to offer per-Desktop<br>> views. in the \
"one view per screen" mode, the view will switch the Desktop<br>> it \
advertises as being associated with as the desktop itself switches<br> > (allowing \
us to provide the lower resource (though broken for<br>> compositing) \
"traditional" approach)<br>><br>> but it's the only way i can \
think of making this work properly when the<br>> same "desktop" from \
multiple virtual desktops need to be shown<br> > simultneously, such as in desktop \
grid, cube, etc.<br>><br>> this also opens the door for per-virtual desktop \
Containment views. e.g.<br>> have Containment "Work" shown on Desktop 3, \
Containment "Play" on Desktops<br> > 1 and 2 and Containment \
"Misc" on Desktop 4.<br>><br>> thoughts? concerns? \
questions?<br><br><br></div></div>_______________________________________________<br>Panel-devel \
mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/panel-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/panel-devel</a><br></blockquote></div><br>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic