Plasma/Kwin cooperation to achieve efficacy of Activites spatial metaphors

[Lucas Murray]

On Wed, Feb 11, 2009 at 8:46 AM, Jud Craft <craftjml at gmail.com> wrote:
> Well, keep in mind, Plasma was not originally intended to be
> cross-platform.  It was a happy accident of being not-tied-as-tightly
> to Kwin and X as the developers hoped.

But it would still be a regression so we can't really do that.

> It may be possible to fall back on the old 2D ZUI when in Windows, for
> example.  But the original purpose of Plasma was to be the best
> workspace on KDE and X possible, so that should be a higher priority
> than cross-platform compatibility.

For the proposal to work in every situation there will need to be two
desktop grid/workspace managers: One built into KWin so it can do all
the fancy stuff and one built into Plasma so it can be used
cross-platform and when using another window manager such as Compiz in
KDE. The Plasma one will just be a fullscreen window and do all the
work in software like it already does, you just won't be able to
control application windows in the manager like you would with the
KWin version.

> On 2/10/09, Alexis Ménard <menard at kde.org> wrote:
>> 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
>>>
>>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>