Plasma/Kwin cooperation to achieve efficacy of Activites spatial metaphors

[Alexis Ménard]

On Tue, Feb 10, 2009 at 6:02 PM, Lucas Murray <lmurray at undefinedfire.com>wrote:

> On Wed, Feb 11, 2009 at 12:27 AM, Jud Craft <craftjml at gmail.com> wrote:
> > It is the height of audacity to come out of the woodwork and suggest
> > design ideas for a system that I do not create myself.  Nevertheless,
> > you might actually like some of these.
> >
> > I promise it will be entertaining.  Broken into two sections, A and B.
> >  Also long.  Have a great day!
> >
> >
> > A.  Effective Communication of Activities' Design
> > ----
> > First, for KDE to effectively continue its embrace of Plasma, a good
> > campaign must be focused on explaining the benefits of the Activities
> > system to the casual user.  It doesn't help that until now it has
> > seemed mostly at cross-purposes with the old idea of virtual desktops.
> >  (I didn't say it was.  I said it _seemed_.  If it didn't, there
> > wouldn't be so much ill-will about it.)
> >
> > It doesn't help that the transitioning-between-Activities bears little
> > distinction from transitioning  between workspaces/virtual desktops.
> > It's sometimes hard for the user to figure out exactly what the big
> > deal is.  Personally, I rationalize it myself this way:
> >
> > --Virtual desktops are like having a really huge desk in your office.
> > There's plenty of room for stuff, but you have to reach around to get
> > to any of it.
> >
> > --Plasma Activities are like having _different_ desks in your office.
> > For example, one for essay writing, one for your reading, and one for
> > communication (memos, letters, in and out boxes).
>
> I see them the other way around but lets carry on...
>
> > The idea of "having more than one desk VS having a huge desk" is
> > immediately apparent to any office and home user; in fact, if you ever
> > create an in-KDE tutorial to explain how Activities work, and maybe
> > guide the user through creating one, I highly suggest you use that
> > metaphor pervasively.
> >
> > 1.  In fact, perhaps you should re-do the nomenclature and describe
> > them as "Desks"  (formerly activities) and "Desk size" (formerly
> > virtual desktop dimensions).  I could have a "Internet" desk that is
> > 2x2 screens wide, and a "Programming" desk that is 4x4 screens wide
> > for example.
> >
> > This resolves ambiguity between "just more space" and "space dedicated
> > to a special purpose".
> >
> > 2.  There should be a freaking-easy-as-dirt way to switch between
> > Activities (though I do like "Desks").  The Zooming-User-Interface
> > doesn't cut it, especially since it's at cross-purposes with the
> > traditional zoom-in/out on a surface metaphor of virtual desktops.
> > There is an inherent spatial conflict, don't ignore it.  The typical
> > office user doesn't care what your spatial metaphor is (or even what
> > they _are_), but he _will_ notice if it's inconsistent.
> >
> > A simple menu widget that when clicked, presents a list of Activites.
> > With two clicks, you can select any Activity.  (You'll assume the user
> > won't have 10+ Activities.  That's too enthusiastic).  Perhaps this
> > menu can pop up when the Cashew/Acorn-thing is clicked, as opposed to
> > strange terms like "Zoom Out", which does nothing to describe the
> > contextual novelty of the Activity idea.  Activities describe
> > different abstract spaces, not a web page.
> >
> > This same Activity Menu could be integrated into Kicker (a tab for a
> > list of all current activities -- you could switch with just one
> > click!) or into a panel-widget that triggers the menu.
> >
> >
> > B.  Working With Kwin to Resolve Spatial Conflicts
> > ----
> > The main interaction layer with Activites, the Zooming User Interface,
> > in its current form isn't gonna cut it.  Even further development
> > isn't gonna cut it -- maybe you guys have some sort of brilliant
> > vision that pops up in ephemeral IRC logs, but I haven't seen it on
> > this list or Aaron Seigo's blog.  (No offense of course.  You might
> > not post it here, it might be at Techbase, or it might not exist).
> >
> > Suggestions.
> >
> > 1.  Team up with Kwin for Activites-transitions.  Kwin is the only
> > framework for screen-level transitions and animations that is well
> > developed enough to be used immediately in the near future, and
> > there's no need to reimplement screen transitions when Kwin has them
> > already there!
>
> Bingo.
>
> > 2.  Re-adopt the ZUI (whose name, being utterly meaningless to
> > Activities, should disappear soon except perhaps as API and developer
> > nomenclature) to use Kwin when present for switching between
> > Activities.  Be able to apply any desktop-switch-effect, perhaps, to
> > Plasma's ZUI transitions instead.  (Ex., switch between Activities
> > with the Cube and Wall).  This makes for more spatial conflicts, I
> > know.  Wait for it.
> >
> > 3.  The default method of Activity transition interaction should be
> >
> > --Switching immediately to a particular Activity (see Cashew-Menu idea
> > in A-2 above)
> >
> > And nothing else.  No "zoomed-out" overview of all possible Activity
> > desks.  Interferes with zooming-out of virtual desktops.  (Feel free
> > to debate on this).
>
> My proposal below addresses this.
>
> > 4.  Kwin needs to lay down the law and demand a single consistent
> > metaphor for Activities, and a single consistent metaphor for virtual
> > desktop switching.
> >
> > Virtual desktop switching for a long time has long called home the
> > metaphor of "different spaces on the 2D plane".  Since you remember my
> > parallel earlier (Virtual desktops = A big flat desk with tons of
> > space) I highly suggest that the Desktop Grid becomes the permanent
> > and unchangeable effect metaphor for Virtual Desktop/Space switching.
> >
> > Why?
> >
> > --Offers more flexibility.  The Cube, though beautiful, is an
> > abstraction of a 1-dimensional list of spaces that you can cycle
> > through.  The Desktop Grid allows 2 dimensions of spaces.
>
> I hate the cube, I always have. The desktop is a 2D entity and
> therefore is best represented in 2D.
>
> > --For sake of usability (debate me), there should be one and only one
> > virtual desktop metaphor.  The Compiz schizophrenia of "cube, sphere,
> > wall, plane, dodecahedron!" is not something Kwin should ever have
> > aimed to copy.
>
> Compiz is designed to be absolutely anything it wants, this has both
> advantages and disadvantages. Great for developer experimentation and
> user flexibility but it does have the
> jack-of-all-trades-master-of-none problem.
>
> > For consistency across KDE installations.  No one should try to switch
> > desktops on two different KDE computers, and find themselves assaulted
> > with a "grid" on one and a "3D pentagon" on the other.
> >
> > 5.  In my personal opinion, once the ZUI-transition-to-Kwin-effect
> > development is complete (I highly suggest you get on that, even if you
> > disagree with everything else I say) the Cube should be selected as
> > the default metaphor for Activity switching.
> >
> > Why?
> >
> > The 3D concept of "different faces on the same cube" is the nearest
> > you get to the idea that your computer's KDE desktop can be used for
> > different purposes.
> >
> > While DesktopGrid conveys the idea of a "big space you move around
> > on", the different faces of a Cube convey the idea of "separate spaces
> > entirely".
>
> Makes sense, I like it but it does conflict with what I'm going to put
> forward below.
>
> > C.  Conclusion
> > ----
> > Whether you agree with my choices for the Space metaphor vs. the
> > Desk/Activity metaphor, you must agree that they must be consistent,
> > and not conflict.
>
> Agreed.
>
> > The days of the user arbitrarily deciding his desktop metaphors must
> > come to an end -- especially since only the foolish care whether their
> > desktop is a sphere or a cube (Seriously.), and was indicative of the
> > kind of "freedom-for-freedom's sake" that unfortunately embodies every
> > disadvantage with Free Software Development.  Do Compiz one better
> > here and actually lay down a design for your metaphors.
> >
> > Users don't want components they can mix and match.  Developers do.
> > Users just want a well-designed system that they can _use_ however
> > they want.
> >
> > And since Activities is a relatively new concept that you seem
> > determined to push, you _must_ take care to separate the idea,
> > spatially, from virtual desktops.  Since it _is_ a different idea (see
> > the big desk vs. many desks summary in part A).
> >
> > Inconsistency in how the environment treats transitions between
> > desktop spaces and desktop Activities will ultimately determine how
> > well users can adjust to them.  They must occupy an entirely different
> > spatial context than mere Virtual Desktop/Spaces.  For this reason I
> > suggest the 3D Cube for them, while for the sake of 1) consistency and
> > 2) greater flexibility, I suggest Desktop Grid for Spaces alone.
> >
> > This is very important usability-wise:  my design ideas may need
> > refinement, but the idea of internal inconsistency does not.  Kwin and
> > Plasma must cooperate to set in stone these metaphors.
> >
> > Mixing and matching them, I repeat, will only hurt you in the long
> > run.  Get Plasma to work with Kwin for transitions (since Kwin has the
> > framework to do it), and then decide what effects/metaphors to use for
> > which desktop abstractions.
> >
> > And it works for audiences either way:  traditional Linux desktop
> > users can ignore your Activities and use Desktop Spaces just the way
> > they like.  Whereas perhaps a user who doesn't care for a huge virtual
> > screen area, but really likes the idea of desktops for different
> > purposes, can use the Activity/Desk concept.
>
> Makes sense.
>
> > And since they'd both use different spatial metaphors, they would
> > never conflict, and you would always tell when you were merely moving
> > through the same desktop, as opposed to switching to a different
> > task-based desktop entirely.
>
> Now on to my proposal:
> ----------------------
>
> What I'm going to propose below relies heavily on compositing support
> and I have yet to work out in detail how it can be done without it. It
> should be possible to emulate some of these ideas by creating a new
> window and overlaying it over the entire desktop and doing the
> graphics/animation in there though.
>
> Glossary:
> - Widget = Plasma widget.
> - Desktop = One virtual desktop as how it's already been implemented in
> KWin.
> - Activity = A set of Plasma widgets and application windows that have
> been grouped together and can be switched between at will.
> - Workspace = All desktops, all activities, all applications, etc.
>
> Quick bullet list right now as I can't find my notes (This also builds
> off my E-mail in "[PATCH] fade out panel in desktopgrid"):
>
> - The desktop grid becomes the main visualization for absolutely
> everything, both virtual desktops and Plasma activities.
>
> - Widgets are in their own X windows and are handled by KWin when
> compositing is enabled (New window type required?). This is a
> requirement for what's below.


It sounds strange, we kill the cross plaftforness no?.And technically how it
is possible? They are QGraphicsWidgets inside a QWidget(QGraphicsView). They
can't be separate from their scene or we render them in a separe
QGraphicsView? What about the translucency, clipping, cache provided by
QGraphicsView...Perhaps i miss something...


>
>
> - While in the desktop grid you are given a control panel that will
> allow you to control the workspace. You can create, delete and move
> desktops around (EWMH problem: How to handle out-of-order desktops?)
> while the effect is active. You can also assign activity areas here (I
> called them "zones" but I guess "activity" also works) and is the
> replacement for the zoomed out view for activities currently available
> in KDE4.
>
> - Activities are assigned to desktops. If you want to create a new
> activity you can just create a new desktop or reassign an existing one
> to be in the new activity area. One desktop can only have one activity
> assigned to it at any given moment but one activity can span multiple
> desktops. When you remove an activity from all desktops that it
> remains on the control panel and can be assigned back when the user
> requires it.
>
> - Widgets and windows can be treated the same in this implementation.
> You can assign a window to an activity just like you can assign a
> widget to an activity.
>
> - Never allow per-desktop wallpapers.


I like this feature provided by Activities.


> Instead the wallpaper can just
> be a global backdrop to fill in the otherwise unused space when there
> is no application open. This is also a good excuse for a KWin
> background effect that allows some fancy stuff such as parallax when
> moving around the workspace (Switching desktops, zooming out, etc.).
> As long as there is a widget that allows the traditional desktop
> (Instead of being a containment) everything should be fine.
>
> That pretty much sums up the main bits. I have been working on this
> idea since the start of the year and have lots of notes about the
> finer details so if you would like further information I can answer
> any questions. I can also create some mockup images of this if
> everyone thinks it is a good idea. I had done all this planning as I
> was (Is? I'm still working on it to learn more about Xlib) writing my
> own window manager and KDE workspace environment from scratch and
> wanted to make something unique, if these ideas are actually
> implemented in KDE proper then that would be great. =)
>
> One other idea that build off this but are unrelated to this
> particular discussion is dynamic desktop creation. When the user logs
> in there is only one desktop, as they attempt to switch to another it
> is created on-the-fly. The desktop grid effect also takes into account
> this dynamic nature by showing "ghosted" desktops around the edge of
> the screen, if the user clicks them or drags a window to them the
> effect zooms out a little bit more to display the new desktop. Once
> again I have notes on this, feel free to ask questions.
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090210/c2139f49/attachment-0001.htm