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