On Tue, Feb 10, 2009 at 6:02 PM, Lucas Murray <lmur...@undefinedfire.com>wrote:
> On Wed, Feb 11, 2009 at 12:27 AM, Jud Craft <craft...@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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
