On Wednesday, August 18, 2010, Chani wrote: > On August 18, 2010 13:24:43 Aaron J. Seigo wrote: > > On Wednesday, August 18, 2010, Chani wrote: > > > On August 18, 2010 10:05:22 Aaron J. Seigo wrote: > > > > On Tuesday, August 17, 2010, Chani wrote:
> > in the Activity Manager panel, if there is more than one containment in > > the current activity, it is shown expanded with a snapshot of each > > containment. so, in a two screen system, the current activity would be > > represented by two screenshots next to each other instead of the one > > icon. click on one or the other would switch the current screen to be > > using that containment. > > for screens, and assuming you make snapshots work, for running containments, it turns out that its not a big deal. > that might be > feasible... but, what if the user has PVD and 6 VDs? :/ (at least VDs can > always be re- added after they're removed) have i mentioned recently how much i regret PVD? :) i don't have a good answer for this one right now; maybe we just show the screens currently visible, so when you switch desktop the snapshots show that desktop's contents? > and where would you put the delete button? how would you keep it clearly > separate from the "stop/delete this activity" button? don't need to; it would only be for the current activity and that has no buttons on it :) > > should turning off PDV just automatically remove all those other > > containments, or offer the option to do so when it is turned off? > > "Per-desktop views have been turned off and there are now several unused > > widget layouts. Would you like them to be removed automatically for you? > > This can result in a significant performance improvements. <Remove Unused > > Layouts> <Keep The Unused Layouts>" > > hmm... yes, assuming the annoying-popup factor is minimized this is a good > idea :) it should only happen when the setting is turned off; which should be a rare occurance. > hopefully users will be smart enough to realise that the 'unused' ones are > all except the one from deskop #1. we can explain it in the text, perhaps even include a little helpful picture. > > > me, I plug in an external monitor (actually a tv) a couple of times a > > > week to watch movies. I don't want the containment for it running for > > > the rest of the week, and I don't really want to manually delete or > > > close it every time. and the multiscreen tool would then need a feature > > > to manually close things instead of deleting them, too. > > > > how much weight (start up time, memory usage) does this use case incur > > right now? wallpapers on loaded on first-paint only, if there are no > > widgets then none are loaded or set up ... it might be very negligable > > and not work worrying about. > > I ought to check again. I know that in january, loading 8 activities took > something like.. 20-30 seconds..? for every plasma-desktop restart. it was > a very noticeable loading time. in the use case you noted, it's one extra containment, and it shouldn't even be loading its wallpaper. i also assume there aren't any widgets on it since it's a temporary thing in the described work flow. > > > > > * 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. > > > > > > ? > > > what two kinds of issues? > > > > 0) physical screen availability > > 1) which is the current Activity. > > uhm... I was never talking about the current activity. o.0 > I was talking about the activity keeping track of which of its containments > belong on which screen/desktop. right; but that doesn't really have anything to do with the activity, per se. an activity has containments. a containment has a screen (and possible a virtual desktop) affinity. -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
