On Thursday 16 July 2009, Aaron J. Seigo wrote: > hi all ... > > spent some time on the train this morning thinking about the > zui/windows/desktops issues. > > i drew some mock ups on paper which i'll try and put into digital format > when i have some time here and post for comments/thoughts/etc.
a quick and dirty photo will do :p > in semi-summary: > > * the idea of window groups is great, death to virtual desktops > > * the window group overview could include an Activities overview as well. > the visual will help explain this but for now imagine a strip at the top of > the screen showing the existing Activities: a name above and a shrunken > version of the Activity below; switching would be moving which activity is > in the center, e.g. by scrolling through them or clicking on one. so there > would be a horizontal stripe of activity choices sitting atop a set of > horizontal window groupings, keeping things visually distinct so they don't > become overly confusing? i've read this point several times and still don't have a clear idea, yes a photo would be appreciated :) > > * arrange the desktop containments on the corona in a horizontal strip, one > row per screen hmm, it wouldn't be possible to switch a containment between screen so? not being able to access an old activity just bcause at the moment i don't have a screen around doesn't seem too convenient? or when a screen is disconnectedeverything is closed, saved and can be loaded from everywhere? > > * one possibility is to do a paint-to-pixmap-and-publish system to generate > full-size screenshots of the Activities for use in an overview mode would > let us do this with decent performance and without really caring where on > the canvas things are. this means no live updates, however, which would > sort of suck. however, if we put the containment into a "zoomed out" mode > and didn't show the applet handles when zoomed out, that might help > somewhat. way faster and not being really live well maybe is not an huge loss... what sucks a bit is that now in zoomed out mode is possible to drag applets from a containment to another, that wouldn't be possible anymore. i have kind of an idea on mapping mouse events on the pixmap to start a qdrag, but would be quite imprecise, ugly and all:) > > * the centered Activity could have action buttons (remove, save, etc), the > rest can just be buttonless; this reduces visual clutter and should make > managing the toolbuttons a lot easier (and, performance-wise, faster) > > * when in the "overview" mode, we could replace the normal view with a > small view at the top for the strip, put the control buttons right on top > of it (so no scaling issues) and another view below to be populated by the > WM groupings > > * windows in the groupings could be 'tagged' as per the suggestions from > Chani et al by pressing a "tag windows" button in the activities selector > and then clicking on windows in the groups below > > * tagged windows would be removed from or shown in the overview when > sliding through activities, and would have a coloured "halo" border showing > they are associated with the activity (perhaps by similarly "haloing" the > centered activity). this would let one keep the benefits of virtual > desktops with the benefits of activity-association > > * keyboard shortcuts for each window group could be painted above the > window column itself and could be named (just as with current virtual > desktops) > > * add/remove of both window groups and activities could use an identical > system of one add button and per-group/activity remove buttons. > > * the window preview area could be drawn by kwin itself using the same > system we do with the taskbar window previews; without kwin-composite (the > compiz or kwin-without-compositing cases) we could re-use the tasks widget > code to paint the groups of windows as buttons. when there is no kwin, the > windows would just show up in one big group? certainly not sexy, but it > would retain utility regardless of how plasma is run and degrade gracefully > in the process. essentially this means creating a full-screen version of > the tasks widget, perhaps with a special grouping strategy in > libtaskmanager just for this representation? would save a lot of code > writing, i think. > > * panels should not be shown in the overview mode, i think. later we can > perhaps add panel<->activity affinity > > * we must publish the activity stuff live in nepomuk so that applications > can adjust their content and play along too question i'm wondering since a bit: does nepomuk has some support of the Context concept or is it something still to come? > > * a widget on the panel should be there by default to swap into overview > mode > > * the new status codes marco added to Applet should be hooked into the > system tray so that widgets in other Activities can say "hey, listen to > me!" and let the user switch quickly to that activity (plasma containment + > associated windows + nepomuk data) +1 :) > i _think_ that addresses all the questions i posed, and even gets us a bit > down the "how do we actually implement this" road. > > so, executive summary: integrate activity zooming with the window zooming > creating a brand new "overview" mode, allowing associating windows with > activities as well as into groups (orthogonal but complimentary concepts) > > what do the authors of the original sets of proposals think? it's really > not many twists/turns from the original ideas proposed, i don't think? still have to figure out the interaction and the look of the thing, for now i just have those two little concerns, but i feel something cool could go out of it Cheers _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
