[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: multi-screen management
From: Jeremy Whiting <jpwhiting () kde ! org>
Date: 2010-08-18 18:17:53
Message-ID: AANLkTimj2-uKgXkN+R2BMCWP1jk5ovaX-4=ds6sY+k2z () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Aug 18, 2010 at 11:05 AM, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Tuesday, August 17, 2010, Chani wrote:
> > so... we had planned to have a little tool for managing the containments
> of
> > multiple screens, in 4.5 - but there wasn't time. multiscreen has
> > improvements, but also regressions - well, *a* regression - you can't
> > access the containment of a screen that's not plugged in. the same
> applies
> > to the per-desktop view stuff (they have a lot in common).
>
> is there a list of use cases that must be serviced? your email has lots of
> "how to do X" in it, but it seems to skip the "why we want to do X".
>
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.
>
> > When a screen is disconnected (or in PDV, a desktop removed) the
> associated
> > containment and view (for each running activity) should be automatically
> > stopped - and resumed again when the screen/desktop returns. We can
> migrate
> > panels, but not desktops, and it doesn't make sense to leave something
> > running and inaccessible (having to manually stop it would also be
> Wrong).
>
> it does make sense to leave something running if one can switch to it,
> though.
> if the switcher UI allows the user to do that, then it's probably fine.
>
Umm, is there a glossary somewhere of plasma terms? I've no clue what PDV,
or such mean.
> > * I don't like how I ended up with two authorities on where a containment
> > belongs: there's both the lastScreen/lastDesktop settings in the
> > containment, and the place that running containment has in
> > plasma-desktop's Activity class. that ought to be rethought.
>
> they are two different kinds of issues, though, and are orthoganal to each
> ther. it may be possible to nicely merge the two, but they would still be
> two
> different sets of data and decisions.
>
I agree, lets tackle these one at a time and decide what to do with each.
>
> > * Might it be easier to leave the config in plasma-desktop-appletsrc, and
> > have the startup loading skip containments assigned to nonexistant
> > screens/desktops?
>
> possibly, yes..
>
> > * Once this is implemented, I believe panels should behave the same way,
> > instead of migrating. It's more consistent that way. thoughts?
>
> i think it will annoy the users who previously sent in bug reports about
> the
> panel not showing up on their laptop screen after being migrated to another
> screen.
>
> panel migration addresses a real world issue people run into regularly.
> there's a bug in it that i will try and track down (i actually finally
> ended
> up with hardware capable of replicating it with.. ), but otherwise i don't
> think much needs to be done with panels. they are already movable between
> screens.
>
thanks,
Jeremy
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic