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>