[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Plasma/Kwin cooperation to achieve efficacy of Activites spatial
From: Alexis_Ménard <menard () kde ! org>
Date: 2009-02-10 22:24:38
Message-ID: 81941aea0902101424o312d38e6t325ac4bad0438982 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Feb 10, 2009 at 6:02 PM, Lucas Murray <lmurray@undefinedfire.com>wrote:
> On Wed, Feb 11, 2009 at 12:27 AM, Jud Craft <craftjml@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
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic