cc'ing plasma-devel on this one as it potentially impacts libplasma2 ... On Tuesday, September 13, 2011 12:04:27 Thomas Pfeiffer wrote: > On Tue, 13 Sep 2011 12:43:06 +0200, Aaron J. Seigo wrote: > >> Let me give an example: On my desktop I usually have a network > >> traffic > >> monitor always in sight. The reason for that is that if a web page > >> seems to take forever to load, I want to know if it does actually
> > > > ... it occurs to me that the window strip offers a live preview of > > windows. > > > > ... and we have the ability to run widgets in a window, essentially a > > "full > > screen" mode (from the user's interaction POV, not a technical > > definition at > > the programmatic level) > > > > ... which would allow one to peek at the progress in a nice little > > thumbnail > > alongside all other windows in the widget strip > > > > ... if we ordered and grouped windows in the window strip using some > > strategy > > like: > > > > [ Home screen ] [ FSP ] [ FSP ] [ App ] [ App ] > > > > where "FSP" == "full screen plasmoid", then we'd get a peek area, > > great full > > screen interaction when needed/desired and stable locations for them. > > > > they could be launched (as one can already, in fact) from the > > launcher area > > ... > > > > .. and that means we'd be able to avoid adding any new "top level" UI > > concepts, but instead just re-use the launch and peek concepts to > > accomodate > > this need. > > > > what do you think? > > That sounds like an excellent idea! Why should users differentiate > between > a widget and an application too much anyway? For a user, they are both > "things that display stuff and can be interacted with, each with a > distinct > purpose". The distinction between the two types is mostly a technical > one anyway. > > Those fullscreen plasmoids need to be carefully designed, though. If we > just > use thumbnails in the window strip, the fullscreen presentation has to > be > designed so that its thumbnail is still readable and always displays > the > important information. > Or are you thinking about rendering different content in the window > strip having just the thumbnail is the easiest (technologically) approach and allows us to immediately use this with all existing widgets. having different representations is a fair amount more work, though we have the tools down in the framework to accomplish it. so i'd like to first see how the thumbnail approach works first, and then go for additional refinements from there if needed. such a "separate, but parallel view" could be accomplished in a few ways. one is to run a second copy of the plasmoid in the strip (not overly satisfying for a few reasons, however, such as having to keep configuration between the two instances consistent). another is to add a "HUD" view that a widget can optionally provide. this would be similar to the two screen concept on Nintendo's DS portable game system: apps can paint in two predefined places. in this case, we would show thumbnails for widgets unless they provide a "HUD" display (analogous to how we already allow plasmoids to provide a separate widget for use in the PopupApplet) and then use that in the window strip. this would end up being a libplasma2 (and so probably a late-2012) feature ... > This would reduce the number of actions needed to peek at the > plasmoid to one, while still keeping the panel as such clean. So yes, > I really like that :) great :) this is achievable with a very small set of changes, and can easily fit within the next release cycle .. while already possible right now, i think to really be effective it needs some "polishing" such as the ordering/grouping in the window strip and how to integrate these entries as well as possible into the launcher with "full" applications. things for us to discuss next week in darmstadt, perhaps! > The art is to extract the underlying needs and motivations from their > open reactions, which is difficult but possible. and having your help and input in charting these tricky waters will be most welcome :) -- 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
