<br><br><div class="gmail_quote">On Wed, Aug 18, 2010 at 11:05 AM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tuesday, August 17, 2010, Chani wrote:<br>
> so... we had planned to have a little tool for managing the containments of<br>
> multiple screens, in 4.5 - but there wasn't time. multiscreen has<br>
> improvements, but also regressions - well, *a* regression - you can't<br>
> access the containment of a screen that's not plugged in. the same applies<br>
> to the per-desktop view stuff (they have a lot in common).<br>
<br>
</div>is there a list of use cases that must be serviced? your email has lots of<br>
"how to do X" in it, but it seems to skip the "why we want to do X".<br></blockquote><div><br>The usecase I hit last week was that I usually use two screens, but pulled one screen off my desktop to use for a separate machine for longer-than-short-term. Now my main desktop has one screen, with the panel on it, but there's a separate containment that had some widgets I'd like to remove or move to this screen. I'm not sure if they are "running" or whatever, but in the add widgets dialog there are checkboxes on widgets that are not on this screen or my panel.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> When a screen is disconnected (or in PDV, a desktop removed) the associated<br>
> containment and view (for each running activity) should be automatically<br>
> stopped - and resumed again when the screen/desktop returns. We can migrate<br>
> panels, but not desktops, and it doesn't make sense to leave something<br>
> running and inaccessible (having to manually stop it would also be Wrong).<br>
<br>
</div>it does make sense to leave something running if one can switch to it, though.<br>
if the switcher UI allows the user to do that, then it's probably fine.<br></blockquote><div><br>Umm, is there a glossary somewhere of plasma terms? I've no clue what PDV, or such mean.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> * I don't like how I ended up with two authorities on where a containment<br>
> belongs: there's both the lastScreen/lastDesktop settings in the<br>
> containment, and the place that running containment has in<br>
> plasma-desktop's Activity class. that ought to be rethought.<br>
<br>
</div>they are two different kinds of issues, though, and are orthoganal to each<br>
ther. it may be possible to nicely merge the two, but they would still be two<br>
different sets of data and decisions.<br></blockquote><div><br>I agree, lets tackle these one at a time and decide what to do with each.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> * Might it be easier to leave the config in plasma-desktop-appletsrc, and<br>
> have the startup loading skip containments assigned to nonexistant<br>
> screens/desktops?<br>
<br>
</div>possibly, yes..<br>
<div class="im"><br>
> * Once this is implemented, I believe panels should behave the same way,<br>
> instead of migrating. It's more consistent that way. thoughts?<br>
<br>
</div>i think it will annoy the users who previously sent in bug reports about the<br>
panel not showing up on their laptop screen after being migrated to another<br>
screen.<br>
<br>
panel migration addresses a real world issue people run into regularly.<br>
there's a bug in it that i will try and track down (i actually finally ended<br>
up with hardware capable of replicating it with.. ), but otherwise i don't<br>
think much needs to be done with panels. they are already movable between<br>
screens.<br></blockquote><div><br>thanks,<br>
Jeremy<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>