2

I know it was a lot of work to develop KDE Activities as they are now, but to me it seems that the concept is partially wrong and hard to understand for new users.

I would therefore like to propose a simpler, logical and more flexible approach to organizing and working with a multitasking desktop environment. First step back from what you know about the current implementation and imagine the following... A computer can use one or multiple screens (monitors that can be added or removed on the fly). On each screen you can place one of several (virtual) desktops and switch between them independently as you wish. Desktops represent your working environments and contain windows of your applications. Each desktop can be of a specific type that defines the placement of taskbars, widgets and plasmoids. The user can than arrange their desktops in the order they wish in a virtual 2D grid whose purpose is easier understanding and visual representation (also add, remove or move desktops them around on the fly).

It is now up to the user which desktop types he prepares (probably one or more for each type of activity) and how he arranges them and organizes his working environment. The proposed way of organizing would then be to use each virtual grid row for a separate activity.

Benefits of this would be to not be constrained by which activities you can do at once, because you could switch desktops independently (even switch to desktops that were originally on another screen). This means that when working on only one activity at a time the user would switch all their screens to desktops from this activity/row in the grid (there should probably be shortcuts to switch all screens at once). But in case a user is doing more things at once or following something in another activity he could just switch one of the screens to the desired desktop and use other screens for the main work he is doing. For additional flexibility and usability it would probably be good to also have an option to specify screen types or to have the ability to make taskbars stick to a screen (e.g. the main toolbar with systray should probably be always present on only one screen, others could even be without a taskbar, but each should have plasmoids corresponding to their purpose/activity).

An example would be a user that has 2 monitors. He could first be watching TV on the main monitor and have an IM application open on the smaller one. He then gets a great idea an application he is developing and switches the main screen to his development desktop, but he doesn't want to miss the movie and therefore switches the smaller screen to the TV desktop. While he has written his idea down in the TODO list he would like to share it with some coworkers and therefore switches the main screen to the IM desktop, opens a group chat and copies what he has written... All the time he was doing things he able to watch the movie.

I would also recommend for the developers to check out what the Enlightenment E17 window manager can do, because it is pretty flexible and also allows independent switching of desktops (unfortunately limited to one screen), making windows remember on which desktop they should appear and similar goodies that are window managers job to do.

One technical issue with this proposal - if you allow two different screens with different resolutions to view a single virtual desktop at different times, how do you resolve the difference in resolution? Do you scale everything? Do you shift things around to fit? Do you save per-resolution layouts or hope that the general solution comes up with the original layout (or close enough to) when viewing that virtual desktop with the original resolution? I would imagine it is virtually impossible to find a general solution that handles every case gracefully.
This is especially problematic if the two different screens have (vastly) different aspect ratios (at work, we each have two wide-screen monitors that support rotating 90 degrees, and some developers use one in landscape and the other in portrait).

I do like the idea of having each screen be independent, though - one thing that I miss from E17.

airdrik wrote:how do you resolve the difference in resolution? Do you scale everything? Do you shift things around to fit? Do you save per-resolution layouts or hope that the general solution comes up with the original layout (or close enough to) when viewing that virtual desktop with the original resolution?

I think that, because of text readability scaling the whole virtual desktop could only be used as part of switching animations or optional zooming/desktop resizing effects. It would also be great to have the ability that after switching a desktop with a custom positioned window to a smaller screen and back again, the window would be at the same place and size.

This could be accomplished in two basic ways:

- only the top left coordinate for each window would be relatively mapped to the new resolution (size and window state (maximized, tiled left/right..) would stay the same)
- the top left and bottom right coordinate would be relatively mapped to the new resolution (window borders (not content) would relatively resize with the whole desktop, window state would stay the same)

Because none of this solutions is perfect in all circumstances it could either be user selectable (while switching between drastically different resolutions he could be asked what to do and his answer remembered) or there could be a *smart desktop switching/resizing algorithm*. By default it would use the second method, but only allow windows to either shrink or grow by eg. 15@kb_pc (would not allow to resize more). In case of almost identical resolutions or in case of windows with specific states (eg. maximized) the experience would be seamless, in case of drastically different resolutions the windows would just resize a little, but otherwise stay at the same relative position. Because this method would in some cases break the idea of having all windows at same positions after switching around, the original coordinates in the original resolution before switching could be remembered in case you are just switching around (as long as you don't open a new window or move or resize one).

I too would like independent virtual desktop switching per screen for KWin. It is an useful feature I have grown to like from the Awesome window manager.

I think virtual desktops should not be interchangeable between screens because different screen resolutions can be problematic for window sizes or the desktop widgets positions.

An example would be a user that has 2 monitors. He could first be watching TV on the main monitor and have an IM application open on the smaller one. He then gets a great idea an application he is developing and switches the main screen to his development desktop, but he doesn't want to miss the movie and therefore switches the smaller screen to the TV desktop. While he has written his idea down in the TODO list he would like to share it with some coworkers and therefore switches the main screen to the IM desktop, opens a group chat and copies what he has written... All the time he was doing things he able to watch the movie.

A simpler solution would be that the user moves the video window to the smaller screen and switches the main screen desktop. That is one desktop switch less to do and less complex to code.

dpalacio wrote:I think virtual desktops should not be interchangeable between screens because different screen resolutions can be problematic for window sizes or the desktop widgets positions.

Yes, it is more complex to code, but imho this effort is the difference if you want to have the best window manager (with features no one else has), not just a good average one.

One reason why interchangable desktops between screens would be great is also the usefulness when using them on a portable device. Imagine a laptop that someone in the office has connected to his full HD monitor over HDMI and doing last minute corrections for his presentation, he could then just unplug the monitor (and disable the disconnected screen) and still have all desktops accessible, later at the meeting he could then just plug the LCD projector with a VGA cable in it (would auto detect and create a new screen) and switch to the desktop where his presentation is. In my opinion people will in the future travel around, be portable and plug devices in various displays even more and this would be one of the bigger reasons for choosing an operating system and desktop environment.

gw0 wrote:Yes, it is more complex to code, but imho this effort is the difference if you want to have the best window manager (with features no one else has), not just a good average one.

I think kwin has plenty enough unique features to be considered the best window manager. The amount of additional complexity introduced (in both the code and the UI itself) by allowing a given virtual desktop to be viewable by screens with different sizes (esp. different aspect ratios) is significant enough to not be worth the effort required.

gw0 wrote:One reason why interchangable desktops between screens would be great is also the usefulness when using them on a portable device. Imagine a laptop that someone in the office has connected to his full HD monitor over HDMI and doing last minute corrections for his presentation, he could then just unplug the monitor (and disable the disconnected screen) and still have all desktops accessible, later at the meeting he could then just plug the LCD projector with a VGA cable in it (would auto detect and create a new screen) and switch to the desktop where his presentation is. In my opinion people will in the future travel around, be portable and plug devices in various displays even more and this would be one of the bigger reasons for choosing an operating system and desktop environment.

I agree that having seamless integration for plugging/unplugging devices is becoming more and more important. I don't think allowing you to exchange desktops between screens is necessary to have a seamless integration.

When you plug in a new screen, it creates a new virtual desktop (or configurable number of VDs) specific to that screen to which you can drag windows, add widgets, etc. When you detach a screen, the configuration is saved for future use and any open applications are suspended (or frozen - state saved to disk). If you reattach a screen that has a suspended configuration, it will automatically resume those applications. A screen management UI will then allow you to close disconnected screens (and any suspended applications), move applications to another active screen, or discard unneeded screen configurations.
In your scenario, the HD monitor has its configuration and open applications which is retained for when you return to that monitor. The projector gets a fresh configuration (or reuses its previous configuration, if there is one), and when starting the presentation you get prompted for which screen you want it to show on.

Yes, in the beginning I also also thought about a solution for moving windows from different/disabled desktops around through a nice UI. It would be pretty great to have that, but it would somehow break the idea (at least the way I understand it) behind having different working environments for different activities, because once a screen for an activity is disconnected only windows could be moved and used elsewhere, but all other things in the environment for that activity not (i.e. specially configured taskbars, useful plasmoids..). Or do you consider this a minor inconvenience?

airdrik wrote:When you plug in a new screen, it creates a new virtual desktop (or configurable number of VDs) specific to that screen to which you can drag windows, add widgets, etc. When you detach a screen, the configuration is saved for future use and any open applications are suspended (or frozen - state saved to disk). If you reattach a screen that has a suspended configuration, it will automatically resume those applications. A screen management UI will then allow you to close disconnected screens (and any suspended applications), move applications to another active screen, or discard unneeded screen configurations.

Huh, suspend whole applications? Some thoughts about that: What about the ones that have active network connections that are e.g. downloading or streaming something? Is it reliable to determine which applications have windows on the disconnected screen? What about applications with multiple windows on multiple screens? What about minimized or "minimized to tray" applications that were open on that screen but later minimized probably to another screen?

gw0 wrote:Yes, in the beginning I also also thought about a solution for moving windows from different/disabled desktops around through a nice UI. It would be pretty great to have that, but it would somehow break the idea (at least the way I understand it) behind having different working environments for different activities, because once a screen for an activity is disconnected only windows could be moved and used elsewhere, but all other things in the environment for that activity not (i.e. specially configured taskbars, useful plasmoids..). Or do you consider this a minor inconvenience?

well, currently there isn't the notion of moving plasmoids between activities, but that could be added.

airdrik wrote:When you plug in a new screen, it creates a new virtual desktop (or configurable number of VDs) specific to that screen to which you can drag windows, add widgets, etc. When you detach a screen, the configuration is saved for future use and any open applications are suspended (or frozen - state saved to disk). If you reattach a screen that has a suspended configuration, it will automatically resume those applications. A screen management UI will then allow you to close disconnected screens (and any suspended applications), move applications to another active screen, or discard unneeded screen configurations.

Huh, suspend whole applications? Some thoughts about that: What about the ones that have active network connections that are e.g. downloading or streaming something? Is it reliable to determine which applications have windows on the disconnected screen? What about applications with multiple windows on multiple screens? What about minimized or "minimized to tray" applications that were open on that screen but later minimized probably to another screen?

Well, you could either suspend on disconnect or suspend when the screen is stopped (similar to when you stop an activity - I don't think the functionality to stop/freeze the applications on an activity has been implemented, yet, but this could work similarly). Certainly these are all different scenarios that would need to be addressed.

airdrik wrote:well, currently there isn't the notion of moving plasmoids between activities, but that could be added.

Just to expose it - when having the ability to move all things around, also with an option of moving them around together, would in the end have the same effect as switching to a desktop from another screen. Having dynamic number of virtual desktops and simply creating new blank ones (similar to what is in the newest version of Gnome) would probably also be nice for this.

I would like to approve this idea, as from my understanding it is about making each monitor a separate entity instead of just an extension of your screen estate - but it's worded a bit confusingly. Could you please rewrite your idea (especially the subject) to be more direct and concise about what you would like to see implemented?

Technical issues about the implementation can be discussed later.

Hm, in edit mode the subject is a read only field that does not want to be changed. I wanted to change it in: Make each desktop a separate entity that can be put on any screen

This means a new idea needs to be opened?

I have changed it for you to what I believe to be more accurate, can you please confirm this?