kdeuserk wrote:Could you try to address the questions I initially asked? That would help to cross out things that are not currently doable.

which question? Please keep in mind that I don't know other systems and don't want to guess from watching videos how they work. Please ask precise questions on what you have in mind and whether that would be possible.

kdeuserk wrote:would it for example be possible to show a close button only for the very right desktop?

yes of course, that's what Desktop Grid currently does. It has one section for -/+ desktops. Where the - is located is an implementation detail.

mgraesslin wrote:which question?

The second post of this whole thread where I even enumerated the questions. Some of them have vanished already but there are still valid ones you did not address.
Question 10 is unclear, so ignore it, question 1 has already been discussed.

mgraesslin wrote:As we wouldn't want to remove the possibility to have 2D layouts the primary desktop switcher (Desktop Grid) would have to have this possibility.

Hm, having a 2D layout contradicts merging present windows and desktop grid into one effect, as this would overload the default effect and could not properly replace present windows (which primarily focuses on presenting windows using space efficiently, in most cases only present windows of the current desktop). With the layout I proposed, the present windows effect could be retained but we can manage virtual desktops at the same time.
If you really want a 2D grid experience I see no reason to change anything at all design wise (apart from probably using your window decoration for thumbnails idea) and I am afraid I can't and do not want to help designing yet another 2D grid, simply because I do no like it and consider it obsolete. Apart from that the grid effect is only useful for either a low number of desktops (around 4) or pretty big screens, for the rest the thumbnails get too small too quickly.

kdeuserk wrote:Direct link: https://share.kde.org/public.php?servic ... b&download
Is the mockups_svg folder I created inside the "Visual Design Group" folder shared with others?

Thanks! Yes, the folder is shared with the whole group, I can see it.

kdeuserk wrote:The second post of this whole thread where I even enumerated the questions. Some of them have vanished already but there are still valid ones you did not address.

I didn't read those as questions addressed to me, but rather to the VDG on how it should get designed. It's mostly questions about usability, which I'm the wrong one to answer. If you have specific technical questions, please ask

kdeuserk wrote:Hm, having a 2D layout contradicts merging present windows and desktop grid into one effect, as this would overload the default effect and could not properly replace present windows (which primarily focuses on presenting windows using space efficiently, in most cases only present windows of the current desktop).

I think the focus of a new design should clearly be on present windows. Virtual Desktops is an advanced feature we have disabled by default. If it's possible to also add Virtual Desktop management that is fine, but it shouldn't be a UX which doesn't make sense for one virtual desktop.

I'm also not 100 % sure whether the two effects need to be merged. It would also be fine to have two different modes which share a lot of design and code.

kdeuserk wrote:A few questions:
1.) Do we aim to support dynamic virtual desktops? (like gnome does). But then the "grid" would not be a grid anymore. Imho the grid is only useful if the number of virtual desktops is low (around 4 is the optimum on most laptop screens). For everything else the way OS X and Gnome do it is more efficient.

I beg your pardon? A grid (2 dimensional) can display n^2 the amount of items of same scale factor.
If you suggest the VDs should be scrolling, you might want to have a look at the tabbox layout discussion, resp. the review request that triggered it[1]
Not to mention that a grid could scroll as well and still make better use of space.

kdeuserk wrote:2.) Do we plan to merge both, present windows and the desktop grid into one effect having all the features listed in your blog post?

This is possible only to a limited degree (resp. killing present functionality or enforcing collapsing virtual desktops)
Present windows can display windows from all desktops - you either scratch that feature or ensure there're no virtual desktops w/o windows or in doubt waste a giant amount of space.

kdeuserk wrote:3.) A bit unrelated question, but out of interest: Will we support different number of desktops on different activities?
4.) An idea I have been having for quite some time: Wouldn't it be great if the activity switcher kind of made use of of the effect we are about to design?

At first, we'd need to define what activities actually are in regards to the WM:
https://bugs.kde.org/show_bug.cgi?id=318153
Also this would cross with plasmas "one activity per VD" feature (to eg. support different wallpapers per desktop)

kdeuserk wrote:5.) Kind of a feature request that does not really need mockups: when one drags a window over another, could they be tabbed?

Kind of unrelated, but in general "yes", that's technically possible and I don't see functional problems with this

kdeuserk wrote:6.) Why not having additional buttons on hover if configured? like all buttons the user has configured for the window decoration? there shouldn't be a space problem.

Also see viewtopic.php?f=285&t=123480 on the topic.

kdeuserk wrote:7.) something that is quite broken in the current design: what about closing windows that ask for confirmation? What can be done technically to handle that situation? can we detect such windows, or only guess through pinging the window? If there is no proper technical method, simply ignore that point and leave the situation as it is.

If the user presses the close button for a window and afterward a modal dialog for that window is added, that's pretty much likely a reaction to the close request. This could be intercepted. Problems arise afterwards:
a) what to do if this dialog causes the need for more interaction (save dialog or something)
b) let's say we take that window out of present windows, bring it on top and pass it the focus:
should we merge it into the window gallery when it "looses" the focus (or rather the user clicks into the gallery area below)?
c) if the user presses "cancel", we won't know that the process was canceled - the window would remain in the "every new modal for this is probably a reaction to the close request" mode - so spontanous dialogs (messages) mapped by this window would behave exactly as the (assumed) "wanna close" diaog.

Other than that, a window could signal "_KDE_NET_WM_ON_CLOSE_MODAL" or similar prop. properties. Needs to get supported by WM and client, though.

kdeuserk wrote:8.) Will we support naming Desktops right in the effect? This is certainly something that has minor priority and can be added later.

Imo, an edit dialog could show up when extending the count, yes.

kdeuserk wrote:9.) How is the state of different wallpapers/widgets for different desktops right now? I remember reading that was kind of difficult and currently a hack kind of using activities.

This is a plasma-desktop (general desktop shell) issue/limitation.
Traditionally, different wallpapers were done by changing them when the current desktop changed. This does of course not work when more than one VD is visible at the same time. At this point, every desktop (with a different wallpaper) needs to be an actually different window. This is done by plasma-desktop for activities (implying also to have different plasmoids on the desktop etc.)

kdeuserk wrote:10.) Could we allow showing panels? I see no reason not to show them.

Notice that panels can be of random size and position and are layered above most windows.
Showing them at real size/position in desktopgrid (it's available in present windows) could thus be problematic. I however do not see a problem with a minime in desktopgrid (notably when the windows remain layouted like in present windows in such mode)

kdeuserk wrote:11.) Should every window be equally covered or should we group windows by application and relation (parent window etc.) like OS X does it? This would be really useful, because if you have Kmail open and have an own window for composing mails, it would be good if the composer window and the kmail one were visually grouped.

Such layout is technically possible, but would of course interfer with space usage optimizations.
Overmore, a stacking layout like in mission control doesn't seem reasonable to me (unless you make other modifications, i'll do a second post on the topic


On dynamic VDs like in gnome:
a) I object autocollapsing. Period. Whenever you close windows, the VD amount would change and if you've not changed the VD for a longer time, approaching a special VD turns into hide and seek.
Let alone users who navigate their VDs using shortcuts ("developing kwin was on VD4. No? VD3? No? Ah, VD2...") Also you cannot go to a specific VD to launch an application there as only window.
b) Inserting VDs at specific positions is possible. I do not object entire desktop swapping (ie. desktop names beyond present swapping of all windows)
c) *removing* a specific desktop (unlike *reducing* the amount of VD) brings us back to https://bugs.kde.org/show_bug.cgi?id=318153
It mostly raises the question about what to do with the windows on that desktop. Previous desktop? Next desktop? Randomly distribute them? Close them?

This should absolutely *not* be ambigious or "unexpected" (hello Thomas P.
In general, it however maybe a reasonable feature of VD management. The key here are the VD names.
If I want to get rid of the VD named "Work" (because I retired.... faaaaaaaar from now I currently have to reduce the amount of VDs and either replace "Work" (say VD3) with the label assigned to the previously last VD (say 9, "Patience" or relabel each and every label [3,8] - that seems pretty cumbersome.

[1] https://git.reviewboard.kde.org/r/109832/

First of all thanks for addressing all the points in a very competent way, kudos!

luebking wrote:A grid (2 dimensional) can display n^2 the amount of items of same scale factor.

Yeah but those desktops get pretty small fast depending on the number of desktops, making the window thumbnails barely useful for a bigger number of desktops.
If I understand you right, you call the concept I am referring to and talking about as "collapsing virtual desktops". This could solve unifying the different effects without loosing features, though I am still not certain how filtering (covering searching and filtering by applications name etc.) should be done exactly, I am working on it though. If that problem was solved I see no point in not collapsing virtual desktops.
I think we should handle two cases in that discussion: 1.) basic view 2.) filtering view, both being two states of the same effect. I am currently thinking of having a two dimensional organization for the filter view (desktops and their attached windows are shown without collapse in a symmetic way, I will start the mockup when I find the time.)

luebking wrote:If the user presses the close button for a window and afterward a modal dialog for that window is added, that's pretty much likely a reaction to the close request. This could be intercepted.

I think the modal window should be exposed to the user then, when this is detected, and when the user made the decision we should return to the effect. Maybe we could expose that window on top of the effect? If the user presses Cancel, he decided not to close the window, which is okay. I do not see a problem with that.

luebking wrote:Imo, an edit dialog could show up when extending the count, yes.

I was thinking of being able to edit the name inline when you (double) click on it.

luebking wrote:a) I object autocollapsing. Period. Whenever you close windows, the VD amount would change and if you've not changed the VD for a longer time, approaching a special VD turns into hide and seek.
Let alone users who navigate their VDs using shortcuts ("developing kwin was on VD4. No? VD3? No? Ah, VD2...") Also you cannot go to a specific VD to launch an application there as only window.

Okay we both agree that we do not want that part.

luebking wrote:It mostly raises the question about what to do with the windows on that desktop.

What about disallowing removing Desktops that hold windows? Could that be implemented more easily?

mgraesslin wrote:I think the focus of a new design should clearly be on present windows. Virtual Desktops is an advanced feature we have disabled by default. If it's possible to also add Virtual Desktop management that is fine, but it shouldn't be a UX which doesn't make sense for one virtual desktop.

Okay than what luebking calls collapsing virtual desktops could as well support going in that direction. Right now there are 3 prominent present windows mode:
1. Windows of current Desktop
2. Windows of all Desktops
3. Windows of current Application

1. is easily statisfied with the collapsed design, 2. makes only sense in the context of virtual desktops anyway and 3. has yet to be addressed.

There's a fourth mode: a random selection of windows. That's used by the task manager if it groups windows. It's quite similar to the third mode, though.

Sorry to jump into the discussion, but I think redesigning Desktop Grid can only be done with thinking about the respective role that Activities and Virtual Desktops should have in Plasma 5. Once this is clear, then design choices can be made consistently.

In my humble opinion, virtual desktop should only be a way to layout windows, sort them, group them. Activities are a kind of sub-sessions, where in theory your whole environment adapts to the thing you are currently doing.

Different wallpapers and plasmoids in different VD makes no sense for me, and can confuse a lot the users on the difference between activities and VDs. If you want different plasmoids and wallpapers, use different activities. This also means that perhaps a desktop effect for switching between activities should be designed. In my opinion, if designing an integrated effect like OSX's Mission Control for Plasma, it should merge Present Windows with Activities, not VDs.

For instance, I don't understand why you would want to name a VD. Could people using this feature describe how they use it and why. Isn't it more related to an activity? I think most people prefer using VDs than activities because it is easier (partly because there is the Desktop Grid effect, and none for Activities) or because they don't understand what Activities are for. If the experience of using Activities is improved, I think more people would use them.

Additionally, I think that a dynamic number of VDs like in Gnome-shell would make sense. It would help understand that VDs are only about windows. If there is no more windows anymore in a VD, then there is no point in it existing. In the same logic, you should have a different number of VDs by activities (once again because VDs are only about windows).

Anyway, I think it is very important to sort this issue in Plasma 5, and make it clear for users what is the difference between Activities and VDs. Only once this is solved, a new effect can be designed. This is the way I see it, but maybe others have another opinion on the matter.

AGuiFr wrote:Sorry to jump into the discussion, but I think redesigning Desktop Grid can only be done with thinking about the respective role that Activities and Virtual Desktops should have in Plasma 5. Once this is clear, then design choices can be made consistently.

Imho Virtual Desktops are orthogonal to activities, in fact they are a sub-concept and have always been. Every activity can hold virtual Desktops. Activities is a much broader concept, like two sessions under two different users, just without the isolation between users.
I agree about the widgets part ... the different virtual desktops of an activity should maybe not have different widgets. The wallpaper is a critical part imho. I think it can help to recognize the virtual desktop, but apparently the wallpaper is also a widget. So you are right that currently there is a bit of a conflict.

This is roughly how I imagine filtering windows:



https://share.kde.org/public.php?servic ... 17b34b03c6

Note: This not collapsed, only the basic state is collapsed (when nothing is typed in the search box). This would covering presenting windows of all virtual desktops as well as filtering windows from all desktops.

Hy wife say "perfect now it is much more confused" sorry she is very direct.

Sorry for my last answer I don't want to flame you. It is realy good that you start with mockups. thanks.

Hello!
This is a quick take on how I imagine a new kwin effect that combines the current, present windows and desktop grid, effects.



Brief discription:
The screen is divided in two areas.
1. A filter bar is located at the top and the currently selected desktop is presented along with its windows.
2. At the left of the screen a horizontal desktop grid exists with buttons to add or remove desktops.

How it functions:
1. User selects a desktop from the left by clicking on the desktop thumbnail. The selected desktop changes with a nice animation, its windows are also nicely presented.
The user can now switch to that desktop by either clicking anywhere at the right or by selecting a window.
Or he can arrange the windows by dnd a single window from the current desktop to another on the left. Clicking and draging in the right will select all the windows from the current desktop and will allow him to drop them to another desktop on the left.

Limitations over current effects:
1. The user now needs to click twice in order to change the current desktop and switch to it. (Not a big problem since keyboard shortcuts exist.)
2. Virtual desktops can only be horizontal aligned. (Although a similar effect with a different layout can be made available to the user.)
3. The user can't pick a specific window from the desktop grid by dnd, but all the windows on that desktop. (In contrary to Desktop Grid) why not?

https://share.kde.org/public.php?servic ... 1e41c65c74
(And yes I have used Gnome Shell before )