Adding widgets to panel?

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20110913/5c2fa1f8/attachment.sig>