Re: Discussion for Virtual Desktops and Activities future
On mercoledì 25 luglio 2018 12:12:58 CEST David Edmundson wrote: > Adding 1 would mean having the relevant UIs have a separate add activity / > add a new VD to this activity which needs some quite a few more changes. yeah, i was talking about what would happen in the ui, of course the backend should have the possibility to add any number -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
> > I don't have a strong opinion about > > * I don't have a strong opinion about what we do in the front end
Re: Discussion for Virtual Desktops and Activities future
On Wed, Jul 25, 2018 at 10:43 AM, Marco Martin wrote: > On martedì 17 luglio 2018 11:16:29 CEST David Edmundson wrote: > > > Yes, if you were to configure it to have 4 desktops per activity and > you > > > > add an activity you get 4 more desktops. > > > > David > shouldn't be more, add an activity you get one new virtual desktop, then > you > can add more for that activity if you want? > At a backend level, I think it's important that we're flexible enough that we can do anything. I don't have a strong opinion about Adding N closely matches the current behaviour. Particularly if it's controlled with a spinbox somewhere. Adding 1 would mean having the relevant UIs have a separate add activity / add a new VD to this activity which needs some quite a few more changes.
Re: Discussion for Virtual Desktops and Activities future
> shouldn't be more, add an activity you get one new virtual desktop, > then you can add more for that activity if you want? +1 I guess that original David's comment was about when we thought all activities would have the same number of VDs. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A
Re: Discussion for Virtual Desktops and Activities future
On martedì 17 luglio 2018 11:16:29 CEST David Edmundson wrote: > > Yes, if you were to configure it to have 4 desktops per activity and you > > add an activity you get 4 more desktops. > > David shouldn't be more, add an activity you get one new virtual desktop, then you can add more for that activity if you want? -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
> Couldn't we teach each Swoosh how to have its own set of favorites, > recents etc, but also how to inherit the "standard" or "default" set? > Then a Swoosh could be either an Activity or a Virtual Desktop. So, configuration? That would work if it can be made pretty. Cheers, Ivan
Re: Discussion for Virtual Desktops and Activities future
Couldn't we teach each Swoosh how to have its own set of favorites, recents etc, but also how to inherit the "standard" or "default" set? Then a Swoosh could be either an Activity or a Virtual Desktop. Nate On 07/17/2018 07:03 AM, Ivan Čukić wrote: UI-wise: We currently (let's pretend) have two options for the users (I've replaced the terms activity and VD with 'swoosh' inspired by the former Mozilla problem): - have multiple swooshes where favourites, recents etc. are shared - have multiple swooshes where favorties, recents are per-swoosh Marco's proposal, for the sake of simplicity, wants to - have multiple swooshes where favourits, recents etc. are per-swoosh, just prettier What's the benefit then? How would the concept be made clearer by this change? Even pretending we have just two cases (since everyone thinks that the group C does not exist), the proposed solution just erases one of them. I don't think that a bad implementation of something in kwin that was created by a former Plasma developer and that none of us want to touch is a good enough reason for removing a group of users. I really don't see this as a concept simplification. Especially since we tried to make no VDs, only activities to be the default. If the aim is to force the users to use activities because they are cool, I think we need a different aim. If the problem is only that switching activities is not pleasant - no desktop effects, etc. this is IMO the wrong way to tackle it. Implementation-wise In Plasma 5, KAMD is the only entity that manages activities for a reason. We have had so many problems in Plasma 4 when Plasma wanted to do the same thing that KAMD does. Just remember the 'let's create a new activity for every user login' bug that we had. Having KWin control the activities, while KAMD is managing activities is a *bad* idea. Cheers, Ivan
Re: Discussion for Virtual Desktops and Activities future
UI-wise: We currently (let's pretend) have two options for the users (I've replaced the terms activity and VD with 'swoosh' inspired by the former Mozilla problem): - have multiple swooshes where favourites, recents etc. are shared - have multiple swooshes where favorties, recents are per-swoosh Marco's proposal, for the sake of simplicity, wants to - have multiple swooshes where favourits, recents etc. are per-swoosh, just prettier What's the benefit then? How would the concept be made clearer by this change? Even pretending we have just two cases (since everyone thinks that the group C does not exist), the proposed solution just erases one of them. I don't think that a bad implementation of something in kwin that was created by a former Plasma developer and that none of us want to touch is a good enough reason for removing a group of users. I really don't see this as a concept simplification. Especially since we tried to make no VDs, only activities to be the default. If the aim is to force the users to use activities because they are cool, I think we need a different aim. If the problem is only that switching activities is not pleasant - no desktop effects, etc. this is IMO the wrong way to tackle it. Implementation-wise In Plasma 5, KAMD is the only entity that manages activities for a reason. We have had so many problems in Plasma 4 when Plasma wanted to do the same thing that KAMD does. Just remember the 'let's create a new activity for every user login' bug that we had. Having KWin control the activities, while KAMD is managing activities is a *bad* idea. Cheers, Ivan
Re: Discussion for Virtual Desktops and Activities future
On Tue, Jul 17, 2018 at 8:55 AM, Marco Martin wrote: > On lunedì 16 luglio 2018 12:44:13 CEST David Edmundson wrote: > > As for my mod, in my head it's basically what you just said above. > Clicking > > + creates an activity which means KAMD then creates a N desktops. > Clicking > > - tells KAMD to delete the activity which in turn deletes N desktops. > Might > > I think the reason is that i still don't understand the proposal > completely. > N desktop you mean if i have 4 virtual desktop it creates 4 desktops per > activity, or it creates one and then is up to the user adding more? > > Yes, if you were to configure it to have 4 desktops per activity and you add an activity you get 4 more desktops. David
Re: Discussion for Virtual Desktops and Activities future
On lunedì 16 luglio 2018 12:44:13 CEST David Edmundson wrote: > As for my mod, in my head it's basically what you just said above. Clicking > + creates an activity which means KAMD then creates a N desktops. Clicking > - tells KAMD to delete the activity which in turn deletes N desktops. Might I think the reason is that i still don't understand the proposal completely. N desktop you mean if i have 4 virtual desktop it creates 4 desktops per activity, or it creates one and then is up to the user adding more? -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Mon, Jul 16, 2018 at 12:44 PM David Edmundson wrote: > I'm not set in stone on that, depends a bit on getting feedback about the > explicit problems with merging. I think the problem is that not many people fully understand what your proposed solution would look like in the end. I at least don't from what I have read until now. You need to write a clear full draft on what your proposal would look like from user POV and how the implementation could probably be done. Best would be imo to do this in a separate email chain, so we can discuss the proposal alone, since this chain became already quite long. I will also do this for two solutions I thought of (which would keep the status quo though or extend upon it).
Re: Discussion for Virtual Desktops and Activities future
For the vast majority of users my proposal is identical to your proposal. The only real difference is in mine we explicitly say that we never assume VD ID == activity ID which can allow for most future complexity should someone want to both implement and opt into it. > (switching activities > Perhaps i could live with that if a desktop can be associated to one > and only one activity, which is how i understood it Yep, that's how I envisioned it too. (Also, it's effectively Michail's mockup too) > With KAMD only switching the DBus currentActivity when switching between > the first two desktops to the last two. > > What would be the workflow/ui of adding a new virtual desktop, or > adding a new activity? have some UI questions that I think should be > answered before decising how viable the direction is. > > Yeah, adding/removing is something that needs some thinking. The core questions needs answering for the basic merging case too. Now we have fixed IDs, kwin's +/- icons that push/pop to the end don't really cut it. As for my mod, in my head it's basically what you just said above. Clicking + creates an activity which means KAMD then creates a N desktops. Clicking - tells KAMD to delete the activity which in turn deletes N desktops. Might not be the best for the group of dual-activity-VD users, but it would be quite simple and consistent. I'm not set in stone on that, depends a bit on getting feedback about the explicit problems with merging. Of course if someone wanted to write Michail's mockup as an optional effect that could get far more fine grained control that'd be fine.
Re: Discussion for Virtual Desktops and Activities future
On Fri, Jul 13, 2018 at 1:54 PM David Edmundson wrote: > work - 1 > work - 2 > browsing - 1 > browsing - 2 I really don't like having a different set of desktops for each activity, to me would be really confusing, and i don't think it would cover my main use case? (switching activities Perhaps i could live with that if a desktop can be associated to one and only one activity, which is how i understood it (so then you can switch to the activity when you switch desktop), but if there are multiple desktops per activity, still showing them all in the pager is.. weird > With KAMD only switching the DBus currentActivity when switching between the > first two desktops to the last two. What would be the workflow/ui of adding a new virtual desktop, or adding a new activity? have some UI questions that I think should be answered before decising how viable the direction is. there would need to be: * an operation that creates an activity with its associated desktop * an operation which creates another desktop for the current activity both in the pager? one in the pager and the other one in the activity manager? * What happens when you delete an activity? all its desktops get deleted? * What happens when you delete the last desktop for an activity? the activity gets deleted? is it possible to create an ux workflow which makes this not confusing? -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Sun, Jul 15, 2018 at 3:57 PM Martin Flöser wrote: > Activities are weird and we (Thomas and I) never knew what they are and > how we should integrate them in KWin. The existing code is just a bad > copy of virtual desktops (bad because it copied the code 1:1 without > understanding what it does including the things which just don't make > sense). It's one of the few areas in KWin which are truly unmaintained. totally agree on that point, it's a bad copy which needs to go. > So from KWin perspective I would prefer: > * virtual desktops gain support for windows on multiple desktops it does ;) > * activity support gets removed from KWin > * any mapping from activity to virtual desktop happens outside of KWin > (e.g. in kamd) yeah, i would like too to have the direct support of activities in kwin gone (even in x11, but won't be possible for a long time i fear) the way i originally tought about it was: * kwin manages/saved/reads virtual desktops as now * kamd uses as a "source" of valid activities the list of kwin desktops * kamd reacts to desktop change with activity change * removing a desktop would mean removing an activity * adding a desktop is adding an activity * if is kamd to ask to create an activity, it asks to kwin beforehand, and creates it only if/when kwin anwered with a new desktop id * if kamd wants to switch activity, asks kwin beforehand annoying thing, the desktops kwayland protocol would have to have a pretty much 1:1 identical implementation in dbus (which may be needed anyways for the desktops kcm...)
Re: Discussion for Virtual Desktops and Activities future
On Fri, Jul 13, 2018 at 6:20 PM David Edmundson wrote: > - effects show more options > - pager will show more options > - set on activity desktop menu will show more options > (not really a huge issue. Just don't change activities if you don't want to > change activities) To me that's exactly the problem, the direction went from "how can we make it simpler" to "how we cover every possible workflow making it even more complex in the process" I don't think it could ever be made really "good" if we try to preserve all possible workflows, sometimes to get something from mediocre to really good, its scope has to be narrowed a lot -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
Hi all, just chiming in to give some KWin perspective. Activities are weird and we (Thomas and I) never knew what they are and how we should integrate them in KWin. The existing code is just a bad copy of virtual desktops (bad because it copied the code 1:1 without understanding what it does including the things which just don't make sense). It's one of the few areas in KWin which are truly unmaintained. From KWin perspective the only useful element is that it allows to have a window on multiple "virtual whatever". On the other hand everything around activities makes KWin code way more complex. We have from user perspective two menus offering more or less the same. We have duplicated code all over the place. E.g. every effect needs to be desktop and activity aware. This results in strange bugs like desktop grid switching activities when you click empty space. The ideas we had when activity support was integrated into KWin just never emerged. Things like sub-sessions, windows being truly activity aware, applications using the information all just never happened. On the other hand the interaction with kamd has caused problems several times. That is due to the nature of having a side channel related to window management. We just are in a tricky situation if KWin asks kamd about information it should get from KWin. So from KWin perspective I would prefer: * virtual desktops gain support for windows on multiple desktops * activity support gets removed from KWin * any mapping from activity to virtual desktop happens outside of KWin (e.g. in kamd) Following the discussing I think that goes into the direction David suggested. What I think would be a disservice to KWin (and thus also Plasma) would be to build up any changes on top of the existing activity support in KWin. It needs to be kicked out, it's in a bad state. Cheers Martin
Re: Discussion for Virtual Desktops and Activities future
I find it very constructive in the discussion that everyone speaks its mind in order to understand better what we are trying to accomplish here. Based on that I think that there are some goals that almost all agree. G1: Simplify the Activities/VDs infrastructure for kwin and plasma desktop in order to improve its maintenability G2: Support workflows for groups A and B G3: Improve the UI that Activities/VDs (MERGE) are presented to users Based on G1-3 I think that we can see wayland as opportunity and not as burden and improve the Activities/VDs area Goals that are still communicated without reaching a "We all agree" state: *G4: Support group C and not make them feel as a second citizen in Plasma in comparison with groups A and B 2018-07-13 22:59 GMT+03:00 Marco Martin : > so there would be some desktops fused with an activity some not. > the association could be 1:1 or m:n.. tough i see m:n would risk to > gather again a very confusing ui > > Marco and Nate, concerning the UI approach I have in my mind the following Group A: - a. Pager should work as now - b. VDs switching/handling (small view), needs probably something like the Activity Switcher - c. VDs switching/handling (big view), Present Desktops kwin effect is really nice Group B: - a. Pager should work as now - b. Activities switching/handling(small view), I think the current Activity Switcher is just fine - c. Activities switching/handling (big view), Present Activities kwin effect would be really rice Group C: - a. Pager, probably the user just needs to choose between A and B - b. Activities/VDs switching handling (small view): maybe just a column like the Activity Switcher is doing - c. Activities/VDs switching handling (big view): There is already work on this :) from WorkFlow project in Plasma 4 era Mockup: http://i.imgur.com/uO1KYl.jpg Implementation: http://i.imgur.com/1Z01D.jpg Article that justifies the mockup: https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html There is a chance that b(s) for all groups can be the same UI that changes accordingly and c(s) the same kwin effect, there also some work on this area from : https://github.com/ajoshpratt/kwinOverview
Re: Discussion for Virtual Desktops and Activities future
On Fri, Jul 13, 2018 at 1:54 PM David Edmundson wrote: > * Windows are not directly associated with activities > > * Windows are on N virtual desktops > > * Kwin and plasmashell taskamanager/pagers only speak virtual desktops. > References to both VDs and activities in the UI are reduced to 1 list. > > * The provider of the list of virtual desktops is ultimately kactivitymanagerd This is an interesting proposal (which i need to think about it a bit more), tough in the meantime made me me think another approach: * Virtual desktops as usual * a virtual desktop can be pinned to an activity, so switching to it would also switch the activity (and the other way around.. i guess) so there would be some desktops fused with an activity some not. the association could be 1:1 or m:n.. tough i see m:n would risk to gather again a very confusing ui -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Thu, Jul 12, 2018 at 4:43 PM Ivan Čukić wrote: > Activities are not meant to be switched overly often. In the way that > I see activities, you switch to an activity and work for at least half > an hour. If a project deserves less time to focus on than half an > hour, it is either a one of a kind project, or it does not deserve to > have a dedicated activity. That's an important point, in does indeed ring a bell :) thinking about the idea (still keeping desktop a bit task oriented in my mind) I can see virtual desktops being kinda temporary activities, then the concept of a "promotion" to activity -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Fri, Jul 13, 2018 at 5:51 PM, Ivan Čukić wrote: > > I think kwin shouldn't filter them. Pager lists all, effects and > shortcuts > > cover all. > > Ugh... I think that will kill the group 'C'*. While it /would/ be > possible to to use multi-VD-multi-activity setup, it would be far from > convenient. > I fully expected "ugh", but it's an effort to compromise from killing group C completely. The things that would change are: - relative switch to desktop shortcut will work but won't wrap the same - explicit switch to desktop shortcut will be "wrong" - effects show more options - pager will show more options - set on activity desktop menu will show more options (not really a huge issue. Just don't change activities if you don't want to change activities) - changing VD of a window that's on activitiy A won't change the VD of that window on activity B (arguably a feature) The explicit switch to activity shortcuts and the activity switcher could still work exactly as it does now. Have I missed anything else? > Or it would require an alternative set of applets that behave in a > more sane way then the default ones :) > > For the pager, that's definitely do-able. Not sure about the rest. Cheers, > Ivan >
Re: Discussion for Virtual Desktops and Activities future
> Work "stack" Home "stack" > || || > |VD 1| |VD 3| > | Web browser| | Web browser| > | IDE| |Music player| > || || > > || || > |VD 2| |VD 4| > |Email | |Konversation| > |chat| | Telegram | > || || This has the same problem David's proposal has - if you have 5 activities and 3 VD for each, you get a pager with 15 different VDs. > With a user interface that explicitly supports and encourages this sort of > thing (e.g. the ability to apply current activity-specific features such to > multiple Virtual Desktops; "next" and "previous" keyboard shortcuts > automatically bound to the top row of each column), it might be sufficient. This is really hackish. Currently, we have people who tie activity switching to 'restore last used VD for an activity' and people who just want to remain on the same VD. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A
Re: Discussion for Virtual Desktops and Activities future
> I think kwin shouldn't filter them. Pager lists all, effects and shortcuts > cover all. Ugh... I think that will kill the group 'C'*. While it /would/ be possible to to use multi-VD-multi-activity setup, it would be far from convenient. Or it would require an alternative set of applets that behave in a more sane way then the default ones :) Cheers, Ivan
Re: Discussion for Virtual Desktops and Activities future
On Fri, 13 Jul 2018 08:22:31 -0700 Ivan Čukić wrote > This would provide the more obvious distinction - "groups" are for > window management and "activities" are about providing different > workspaces. "groups" would be volatile in the sense that their number > can vary a lot - quick creation, automatic destruction etc. (like > activities in gnome shell) Hmm, just on first glance I'm not a huge fan of this. It seems like it would just replace confusion over two similar-but-slightly-different concepts that have their own user interfaces with confusion over two other similar-but-slightly-different concepts that have their own user interfaces. Instead, perhaps we can help out the Group C users by leveraging an existing feature of our Virtual Desktop implementation: the ability to have not just a flat list of Virtual Desktops, but rather a two-dimensional array of them. Users who currently use both multiple Activities and multiple Virtual Desktops could use the columns to approximate Activities, and the rows within each column as actual Virtual Desktops. Here's an example: Status quo == Activity 1: work - Virtual Desktop 1: Web browser and IDE - Virtual Desktop 2: Email and chat apps Activity 2: home - Virtual Desktop 1: Web browser and music player - Virtual Desktop 2: IRC and Telegram Proposed new workflow = Work "stack" Home "stack" || || |VD 1| |VD 3| | Web browser| | Web browser| | IDE| |Music player| || || || || |VD 2| |VD 4| |Email | |Konversation| |chat| | Telegram | || || With a user interface that explicitly supports and encourages this sort of thing (e.g. the ability to apply current activity-specific features such to multiple Virtual Desktops; "next" and "previous" keyboard shortcuts automatically bound to the top row of each column), it might be sufficient. Nate
Re: Discussion for Virtual Desktops and Activities future
VDs to inform KWin, if they are not part of the current activity and > therefore should not be switched to when switching through VDs. Also > the pager must know which VDs not to display in the current activity. > But as said this can be a porperty on the VDs and not on the Activity. > > > I think kwin shouldn't filter them. Pager lists all, effects and shortcuts cover all. This is the crucial part that makes it merging. Yes, its a behavioral change, but its also the key part of fixing the currently complex and semi-duplicated ui. > * The provider of the list of virtual desktops is ultimately > kactivitymanagerd > Why is KAMD the provider? I think KWin should be the provider of all > VDs and KAMD then tells KWin which subset of VDs should be currently > switchable (using the property above) depending on the activity KAMD > has set. > I meant its the source kwin would use to manage the list of desktops. Like kscreen manages outputs, but the WL_output iface still comes from kwin. Kamd is the "kscreen" in this case. To try and re-summarise: The only difference between my twist and Marco's proposal is that the Kactivities::currentActivity doesn't have to change on every vd switch so you can have n virtual desktops with the same activity information.
Re: Discussion for Virtual Desktops and Activities future
@David Regarding the backend (wherever the actual logic ends up in - kwin or kamd), your idea does sound nice. It would also provide the ability that some of the 'C' category users wanted - to have variable number of VDs per activity. But the problem is not primarily how to handle the 'unification' implementation-wise, but UI-wise. UI is what we primarily need to be concerned with. One potential UI approach that came to me, which might be able to cover all categories of users and which would fit David's proposal, is the following,: - Activities and VDs get mostly merged. The current activity switcher + VD animations end up there (with some improvements). - Window organization part of VDs gets changed into "window groups" or "window sets" where the windows can be grouped together. Switching the groups could use the same effect as minimize/restore, but with a group of windows. Or something along those lines. This would provide the more obvious distinction - "groups" are for window management and "activities" are about providing different workspaces. "groups" would be volatile in the sense that their number can vary a lot - quick creation, automatic destruction etc. (like activities in gnome shell) Now, this would require *a lot* of work, and while supporting all the use-cases for activities/VDs I know of, it would change workflows of many users. OTOH, these components would need significant **coordinated** changes: - Task manager - Pager - Activity-related applets - KWin - KWin rules (we still need to be able that certain applications need to be always in same 'group') - Plasma And I'm not sure we could have a slow roll-out of the features across several releases. This would need to be done all at once. Cheers, Ivan
Re: Discussion for Virtual Desktops and Activities future
On Fri, Jul 13, 2018 at 1:54 PM David Edmundson wrote: > > Whilst personally I am in favour of just completely unifying, I think there's > an option that might be a happy medium. > > --- > > If we were to unify, we would do the following: So the following is not the "happy medium", but what you would be in favor of? But it looks not like complete unifying. > * Windows are not directly associated with activities > > * Windows are on N virtual desktops > > * Kwin and plasmashell taskamanager/pagers only speak virtual desktops. > References to both VDs and activities in the UI are reduced to 1 list. That makes sense. I would argue there still should be a property on VDs to inform KWin, if they are not part of the current activity and therefore should not be switched to when switching through VDs. Also the pager must know which VDs not to display in the current activity. But as said this can be a porperty on the VDs and not on the Activity. > > * The provider of the list of virtual desktops is ultimately kactivitymanagerd Why is KAMD the provider? I think KWin should be the provider of all VDs and KAMD then tells KWin which subset of VDs should be currently switchable (using the property above) depending on the activity KAMD has set. > > > There's nothing there that forces 1 activity == 1 desktop. > Instead we can associate desktops with activities. > > i.e Kactivitymanagerd with 2 activities, that wanted 2 desktops on each > activity it could choose to create 4 desktops named: > > work - 1 > work - 2 > browsing - 1 > browsing - 2 > > With KAMD only switching the DBus currentActivity when switching between the > first two desktops to the last two. > > We remove all the overlap in the UI. Plasma+KWin code still get /massively/ > simplified. A user can still have multiple desktops associated with the same > activity for correct stats/tagging. Shortcuts to change activity will go to > KAMD instead of kwin, which can then tell kwin to go to an explicit desktop. > > There will be some behavioural changes to the current state, but I don't > think there would be any actual regressions. > > David Sounds like a fine plan on the backend side. VDs and Activites would then still be available and could be combined arbitrarily. If we go with that then another topic we should discuss in the future is how to make the Activity Ui more intuitive to use.
Re: Discussion for Virtual Desktops and Activities future
Whilst personally I am in favour of just completely unifying, I think there's an option that might be a happy medium. --- If we were to unify, we would do the following: * Windows are not directly associated with activities * Windows are on N virtual desktops * Kwin and plasmashell taskamanager/pagers only speak virtual desktops. References to both VDs and activities in the UI are reduced to 1 list. * The provider of the list of virtual desktops is ultimately kactivitymanagerd There's nothing there that forces 1 activity == 1 desktop. Instead we can associate desktops with activities. i.e Kactivitymanagerd with 2 activities, that wanted 2 desktops on each activity it could choose to create 4 desktops named: work - 1 work - 2 browsing - 1 browsing - 2 With KAMD only switching the DBus currentActivity when switching between the first two desktops to the last two. We remove all the overlap in the UI. Plasma+KWin code still get /massively/ simplified. A user can still have multiple desktops associated with the same activity for correct stats/tagging. Shortcuts to change activity will go to KAMD instead of kwin, which can then tell kwin to go to an explicit desktop. There will be some behavioural changes to the current state, but I don't think there would be any actual regressions. David
Re: Discussion for Virtual Desktops and Activities future
On Thursday, July 12, 2018 4:36:02 PM CDT Michail Vourlakos wrote: > 2018-07-12 17:43 GMT+03:00 Marco Martin : > As a plasma user I am a [Multiple Activities and 1 VD] user so I am get used > in that workflow and I wouldnt like to miss it :) > > > I have in my mind without any > study but only based on the personal communication, the users are separated > like > this: > > [A] - 75% (1 Activity + Multiple VDs) > [B] - 20% (Multiple Activities + 1 VD) > [C] - 5% (Multiple Activities + Multiple Desktops) > I just lurk here, but as a long time user of KDE and Plasma, I've fallen into all three categories at one time or another in the last 15 years, so I feel like I might have a perspective that's worth while. Of course, in KDE 3, before activities were introduced, I fell into A, since that was the only option. I spent a fair bit of time in category C during Plasma 4, but with Plasma 5, but I've now converted to category B. I'd love to go back to C, but it's so inconvenient. I have a single monitor (on a laptop) so windows get cluttered really quickly. In KDE 3, virtual desktops were great for that. I had one desktop dedicated to email, one to IM, one to a web browser, one to programming homework, and one to other homework (papers and the like). Each desktop had different launchers on the panel, and different superkaramba widgets (I think - this was more than 10 years ago, so if that was never a feature, forgive me). For Plasma 4, it lost the ability to have different panels per VD, but it did (eventually) allow different plasmoids per VD, so a lot of my panel customizations moved to launcher plasmoids. But I also expanded my desktop model from KDE 3 to use activities. So for example, I had a “general” activity with a desktop for my email, and a desktop for general web browsing, etc. And then a “development” activity which had a desktop for my IDE, and a desktop for file transfers, and desktop for dev related web browsing (stack overflow, documentation, etc.) But that had short-comings. The number of virtual desktops was fixed, so in order to have enough for one activity, I had too many for others. Then Plasma 5 came along, and desktops all had to share the same plasmoids. And everything continued to share the same panels. So in order to keep separate launchers and plasmoids per desktop, I switched to many activities with a single desktop each, and keep them open in groups. So my web browser, email, and console activities are pretty much always running, while my office work activity, game activity, and development activities start and stop. And then to save my sanity, I wrote an activity system tray plasmoid to allow fast switching between activities. So the features I'd like to see ideally would be “activity as a logical grouping of virtual desktops.” In my perfect world, I could have say, 13 virtual desktops, divided unevenly across 4 activities. Each desktop could have different plasmoids and panels. And plasmoids and panels could be pinned like windows, so they could be attached to a single desktop, or shared across them (including across desktops on different activities). I'm sure that's not easy, but it's my 2 cents. ---Tim
Re: Discussion for Virtual Desktops and Activities future
On 07/12/2018 03:36 PM, Michail Vourlakos wrote: As a plasma user I am a [Multiple Activities and 1 VD] user so I am get used in that workflow and I wouldnt like to miss it :) It seems to me that if we merge the features of both, it should be possible to not lose anything for people who use Activities but not Virtual Desktops, or Virtual Desktops but not Activities. The tricky case to get right is for people who use both. Nate
Re: Discussion for Virtual Desktops and Activities future
2018-07-12 17:43 GMT+03:00 Marco Martin : > On Wed, Jul 4, 2018 at 9:28 PM Michail Vourlakos > wrote: > > > > unfortunately not David, family matters prevent me from attending > > That's too bad, I'm still looking forward to some day, somehow making > an in person meeting with you and other lattedock people happen.. > > unfortunately for the last nine months I am the only one "Latte" person. I have lost contact with Johan the second developer we were working with. We disagreed at some point were Latte was heading and afterwards I couldnt establish any further communication. > > In the meantime, can you provide a clear summary on what are the > features/behaviors you expect for lattedock users' need? > > I suppose you are referring to Activities/VDs topic. Based on that the most advanced feature for lattedock users is going to be introduced with Latte v0.8 next week. That is multiple layouts(panel/docks) loaded simultaneously based on the Activities running. That is of course X11 centric until Activities-support for windows is introduced somehow in wayland. A demonstration can be found here: https://www.youtube.com/watch?v=utBQTIsJKTU What Latte is doing, is that can set for its panels/docks to belong in different Activities. The Latte docks/panels are always OnAllDesktops so if in the future there will not be a combination of Activities and VDs at the same time it isnt important for Latte. As a plasma user I am a [Multiple Activities and 1 VD] user so I am get used in that workflow and I wouldnt like to miss it :) Concerning Latte users demographics what I have in my mind without any study but only based on the personal communication, the users are separated like this: [A] - 75% (1 Activity + Multiple VDs) [B] - 20% (Multiple Activities + 1 VD) [C] - 5% (Multiple Activities + Multiple Desktops) The above image keeps me focused on the features that must be definitely supported and what bugs are very important... Some of [C] group members I think that can become [B] group users with better organization of their workflows to different Activities. The thing is that [C] group members are very difficult to find in order to understand their needs...
Re: Discussion for Virtual Desktops and Activities future
> And there would be quite a nice opportunity for a nice pr campaign. IF (and that is a big "if") we can create a new feature (just don't call it "Virtual Activated Desktops" :D) that will merge activities and VDs in a sane way, which would not be overly limiting, I would be more than happy. It is the proposal 'make VDs and activities the same thing' that I have a problem with. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A
Re: Discussion for Virtual Desktops and Activities future
> Personally i always used virtual desktops exactly for that, as "activities", > even before activities were a thing, "i need a new physical space to stuff > new windows" is not an use case that ever occurred to me in any way > noted that there are people which see virtual desktops like that.. will have > to be taken into account somehow, still consider it a pretty crazy use > case tough. I'm going to be evil now. Wikipedia definition (not because W is flawless, but mostly because the 'crazy use case' comment ;) https://en.wikipedia.org/wiki/Virtual_desktop In computing, a virtual desktop is a term used with respect to user interfaces, usually within the WIMP paradigm, to describe ways in which the virtual space of a computer's desktop environment is expanded beyond the physical limits of the screen's display area through the use of software. This compensates for a limited desktop area and can also be helpful in reducing clutter. > Ironically, to me activities never were really able to replace virtual > desktops as "activities", because its window management part never > got the love it deserved nad always lookedlike a kinda broken virtual > desktop implementation, so always falled back to the "multiple > workspaces" implementation kwin was really built around.. which is > virtual desktops. Now, while I agree with this statement, there is an "upside" to the problematic WM-presentation of activity switching. Activities are not meant to be switched overly often. In the way that I see activities, you switch to an activity and work for at least half an hour. If a project deserves less time to focus on than half an hour, it is either a one of a kind project, or it does not deserve to have a dedicated activity. With this in mind, having a non-pretty switching (though, I did try to make it prettier to an extent that kwin allows with the following script https://store.kde.org/p/1110510/) is not a huge problem. But I agree - it should be prettier. >> Previously, we had problems when we tried to equate activities with any >> specific thing. As in, 'an activity is a group of Plasma widgets'. The >> same will happen if the activity becomes 'a group of windows'. >> >> This has been discussed quite a few times before. > > mostly because i think the whole concept of activities always was a > blurry thing, because each one working on them had a different idea > about them to begin with This is also the truth - on two levels: - Everyone in the Plasma team who dipped their toes into activities had (at least slightly) different visions of what they are, I think this is the case because of the second level: - Activities *are* a blurry thing. I've seen so many different workflows that people created with them. While I have a clear vision of what activities are, I don't think we can make them exactly that. The same goes for the vision that anyone in Plasma team has. We need to try to make one or two more focused usage patterns more streamlined, but we can not make them *be* only that. As an analogy, imagine what would happen if we said 'Dolphin is too powerful, it allows users to have a really weird filesystem layouts, lets force them to have 5 directories Pictures, Videos, ...'. Even if this would fit a significant percentage of our user base, this is not something that we can do. We could make the main UI of Dolphin present the files like that while still allowing normal file management (like most Android file managers do), but we can not remove the 'powerful when needed' features altogether. Cheers, Ivan -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A
Re: Discussion for Virtual Desktops and Activities future
On Wed, Jul 4, 2018 at 9:28 PM Michail Vourlakos wrote: > > unfortunately not David, family matters prevent me from attending That's too bad, I'm still looking forward to some day, somehow making an in person meeting with you and other lattedock people happen.. In the meantime, can you provide a clear summary on what are the features/behaviors you expect for lattedock users' need? -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Wed, Jul 4, 2018 at 9:12 PM Nate Graham wrote: > very different things: Virtual Desktops are for window organization > within the current set of tasks, and Activities are for higher-level > task and context switching. which is.. a pretty blurry concept, it asks the question "which of the two i should use now" which is a mental step too much... that said, i guess it's pretty obvious that the "traditional virtual desktop mode" is still needed optional, (it's all we can deliver for 4.14 anyways) in that case activities would stay independent.. but lose all their window management related features. > > Both concepts have merit and are useful, but it's true that the current > user interfaces for them are rather confusing for a variety of reasons: > both have similar animated transitions; one has an accessible user > interface and a keyboard shortcut but the other one doesn't; one can > have different wallpapers but the other one can't; etc. > > I'm willing to experiment with combining them to improve the user > interface, but I think it's important to keep in mind the different > reasons *why* people use one or the other (or both), and fluidly support > all of those use cases without losing any current functionality. So for > example: > > - You should be able to mark a Virtual Desktop as "private" > - Virtual Desktops should be able to have different wallpapers, panel > settings, recent documents lists, etc. all 3 things depend exclusively on activites > - I'd like to see a visible-by-default method to switch between Virtual > Desktops, plus appropriate keyboard shortcuts the pager is visible if there were 2 desktop by default, an always visible way to add a desktop may be nice, often want to have that, but don't know what wouldn't be "too invasive" (like an always visible icon in the panel would be) keyboard shortcuts are there (ctrl f1-f4, tough would be meta tab for everybody if get merged) > In addition to alleviating potential user confusion, combining them > while keeping current functionality may yield a PR advantage since it > would represent an opportunity to shift the narrative from "KDE has two > confusing versions of Virtual Desktops that nobody understands" to "KDE > Has the best, most feature-filled Virtual Desktops implementation!" yeah, to me that's why activities never were really used much, all their beautiful advanced features were hidden behind the idea of "they are kinda broken virtual desktops" which is not true, but i'm pretty that is the perception And there would be quite a nice opportunity for a nice pr campaign. -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Tue, Jul 3, 2018 at 8:03 PM Ivan Čukić wrote: > Just read the phab discussion. If I misunderstood the situation, please > correct me. > > Wondering where the original discussion happened where 'we' decided to > merge two orthogonal concepts into one. Can you point me to the relevant > thread on plasma-devel? > > If this is about providing a unified implementation in kwin for both VDs > and activities, I'm fine with that. If not, then continue reading. > > VDs are for managing windows - a solution for the 'I don't have a screen > large enough for all these windows'. > > Activities are for managing work - a solution to the 'I don't want > documents/files/etc. from separate projects to get jumbled up together'. > Personally i always used virtual desktops exactly for that, as "activities", even before activities were a thing, "i need a new physical space to stuff new windows" is not an use case that ever occurred to me in any way noted that there are people which see virtual desktops like that.. will have to be taken into account somehow, still consider it a pretty crazy use case tough. Ironically, to me activities never were really able to replace virtual desktops as "activities", because its window management part never got the love it deserved nad always lookedlike a kinda broken virtual desktop implementation, so always falled back to the "multiple workspaces" implementation kwin was really built around.. which is virtual desktops. > Previously, we had problems when we tried to equate activities with any > specific thing. As in, 'an activity is a group of Plasma widgets'. The same > will happen if the activity becomes 'a group of windows'. > > This has been discussed quite a few times before. > mostly because i think the whole concept of activities always was a blurry thing, because each one working on them had a different idea about them to begin with -- Marco Martin
Re: Discussion for Virtual Desktops and Activities future
On Tue, Jul 3, 2018 at 5:36 PM Michail Vourlakos wrote: > Example: I am working on my current actitivity and I am writing a note in a > plasma widget. I am creating a new Activity, should that Activity look the > same as the previous one and if I change the note in the first should it look > the same and in the second? (at this example a current VDs user would answer > should be in sync and always the same, a current > Activity user would answer it doesnt matter, it is unrelated) the desktop contents would be completely new, so you would lose such note (also a new desktop with contents copied would be wrong, as when you switch back after having modified the note contents you would wonder why it got the old contents..). for sure i would like to still provide the possibility of having just desktops, either by having the linking optional, or making optional for plasma to switch its desktop when the activity changes.
Re: Discussion for Virtual Desktops and Activities future
David> Are you (Michail and Ivan) at Akademy? Not this year, I'm taking a rest from socializing ;) Nate> very different things: Virtual Desktops are for window organization Nate> within the current set of tasks, and Activities are for higher-level This is exactly my view of VD vs activities. Nate> both have similar animated transitions; one has an accessible user Nate> interface and a keyboard shortcut but the other one doesn't; one can Can you elaborate? With transitions, you mean plasma-widgets-and-wallpaper-slide in activities vs windows-slide transition with VDs? That is the only similarity between the UIs as far as I see. > I'm willing to experiment with combining them to improve the user Experimenting is good. I'd love to see a unified UI that would make activities and VDs 'obvious' while still being good for only-activities or only-vd setups. We had an experiment (and a full implementation) back in the 5.1 days [1] that was meant to provide a nicer UI for activity handling (which might have confused people regarding VD relation to activities even more :) ). But the ideas we had to add VD support to it were quite problematic. The UI was quite busy as it was. Since then, I got a bit disillusioned wrt the unified UI idea, and I'm currently leaning more to an activity UI that is document-focused (favorites, recents, ...) instead of the window-focused one. But I haven't come up yet with anything that looks manageable. Michail> Backend-wise, B1 sounds like a great idea. I see not technical reason why it would need to be either-or. If a window can have a list of VDs assigned, that list might contain activities as well. The matching would be as simple as 'current VD is in the list' && 'current activity is in the list'. Or, everything could share the same code, while there would be two separate lists (this would be cleaner IMO). Cheers, Ivan [1] https://youtu.be/uxaDaXW67Oo?t=41s -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3 45DF C9C5 77AF 0A37 240A
Re: Discussion for Virtual Desktops and Activities future
2018-07-04 22:01 GMT+03:00 David Edmundson : > > Are you (Michail and Ivan) at Akademy? > > unfortunately not David, family matters prevent me from attending
Re: Discussion for Virtual Desktops and Activities future
I used to be of the opinion that having both Activities and Virtual Desktops was "too confusing" to users. I've changed my opinion recently, because I finally came to understand how they're designed to be used for very different things: Virtual Desktops are for window organization within the current set of tasks, and Activities are for higher-level task and context switching. Both concepts have merit and are useful, but it's true that the current user interfaces for them are rather confusing for a variety of reasons: both have similar animated transitions; one has an accessible user interface and a keyboard shortcut but the other one doesn't; one can have different wallpapers but the other one can't; etc. I'm willing to experiment with combining them to improve the user interface, but I think it's important to keep in mind the different reasons *why* people use one or the other (or both), and fluidly support all of those use cases without losing any current functionality. So for example: - You should be able to mark a Virtual Desktop as "private" - Virtual Desktops should be able to have different wallpapers, panel settings, recent documents lists, etc. - I'd like to see a visible-by-default method to switch between Virtual Desktops, plus appropriate keyboard shortcuts In addition to alleviating potential user confusion, combining them while keeping current functionality may yield a PR advantage since it would represent an opportunity to shift the narrative from "KDE has two confusing versions of Virtual Desktops that nobody understands" to "KDE Has the best, most feature-filled Virtual Desktops implementation!" I have no opinions regarding how the two concepts are or ought to be implemented on the backend. Nate On 07/04/2018 09:57 AM, Michail Vourlakos wrote: 2018-07-03 22:19 GMT+03:00 Eike Hein mailto:h...@kde.org>>: This is the relevant thread :-) There are some technical decisions and commit reviews referencing MERGE and this is why I proposed this thread. Proposed technical decisions: 1. Virtual Desktops Ids from integers will be QVariants possibly strings I guess 2. An empty Virtual Desktops list will mean to All Desktops even when then user has enabled manually all dekstops records What are the reasons for [1] to be proposed? [A] Desktops and Activities will share the same way and code to identify themselves and thus it will be easier to maintain (I cant object to that of course) [B1] Activities and VDs will be able to be combined. That is the current situation so I suppose [1] is just for [A] (I have no problem with that) OR [B2] Activities and VDs will NOT be able to be combined. So the users in the future will be able to use Virtual Desktops OR Activities and never in combination. (I think that this is what kwayland protocol is trying to support currently. Even though that would break some user workflows for those users that combine VDs and Activities together, personally I also dont object BUT this must be communicated and prepared to all parts Plasma and VDG that is). Things to consider for [B2] [B2.1] How the user will be able to switch between VDs and Actitivities easily? [B2.2] How this dual way of doing things can be presented to the user in a way that has meaning in order to choose what prefers? P.S. [A] and [B] are just my guesses feel free to correct me
Re: Discussion for Virtual Desktops and Activities future
Are you (Michail and Ivan) at Akademy? David
Re: Discussion for Virtual Desktops and Activities future
2018-07-03 22:19 GMT+03:00 Eike Hein : > > This is the relevant thread :-) > > There are some technical decisions and commit reviews referencing MERGE and this is why I proposed this thread. Proposed technical decisions: 1. Virtual Desktops Ids from integers will be QVariants possibly strings I guess 2. An empty Virtual Desktops list will mean to All Desktops even when then user has enabled manually all dekstops records What are the reasons for [1] to be proposed? [A] Desktops and Activities will share the same way and code to identify themselves and thus it will be easier to maintain (I cant object to that of course) [B1] Activities and VDs will be able to be combined. That is the current situation so I suppose [1] is just for [A] (I have no problem with that) OR [B2] Activities and VDs will NOT be able to be combined. So the users in the future will be able to use Virtual Desktops OR Activities and never in combination. (I think that this is what kwayland protocol is trying to support currently. Even though that would break some user workflows for those users that combine VDs and Activities together, personally I also dont object BUT this must be communicated and prepared to all parts Plasma and VDG that is). Things to consider for [B2] [B2.1] How the user will be able to switch between VDs and Actitivities easily? [B2.2] How this dual way of doing things can be presented to the user in a way that has meaning in order to choose what prefers? P.S. [A] and [B] are just my guesses feel free to correct me
Re: Discussion for Virtual Desktops and Activities future
> I think this is a fair recap so far: The recap sounds great. > When Martin and I started talking about the > Wayland protocol, we > were keen to do work that would reusable > for either use case. This I especially like this part. As I said, merging the implementation (at least to some extent) is a great idea. > I think it's a reality that we have users who > use both together, [...] Yes, we have users that do that, we have users that only use one or the other, and we have users that don't use either. It is the same with any more advanced feature we have. We give users the choice, and the users are smart enough to pick what they need. We have several launchers, some use multiple ones, some a single one, and some don't use a launcher. > It's also reality that we have critics who > complain the two are > redundant and it's all a big mess. This part I don't care about. I care about users, not critics. Trolls will always find something to complain about. > It's not a surprise to me that the idea of > merging them has come up, I'm not surprised either, the same idea has been popping up every few years. The problem with it is that the proposals are usually about modelling a particular person's view of activities. > It does mean > being willing to take some people's existing > workflows away, though. I'm not willing. It goes against Plasma design principle of 'simple by default, powerful when needed'. I'm all for designing a new UI for all of this (though I'd like to see it based on the current one which I find quite pretty :) ) which would communicate clearly what activities are for and what VDs are for. > I also think merging has technical risks, e.g. Not only the speed. It would also make problems for the Plasma - the current activities design is quite baked in the underlying organisation of the shell. What would this change require, and how would it handle different behaviours on X11 and Wayland which was mentioned in Phab. > e.g. the VDG's > mulled Activity overview/dashboard thingie. This thing https://cukic.co/2014/07/01/just-a-teaser/ ? Cheers, Eike
Re: Discussion for Virtual Desktops and Activities future
On 07/04/2018 03:00 AM, Ivan Čukić wrote: > Wondering where the original discussion happened where 'we' decided to > merge two orthogonal concepts into one. Can you point me to the relevant > thread on plasma-devel? This is the relevant thread :-) I think this is a fair recap so far: * When Martin and I started talking about the Wayland protocol, we were keen to do work that would reusable for either use case. This resulted in a draft protocol by Martin which as far as window management goes is a superset of what X11 virtual desktops and Activities can do. * We now have working code based on the above that's gearing up to make virtual desktops work on Wayland, with no work yet done on Activities in any way. * At the Plasma 5.14 kickoff it was decided not to work on Activities for the 5.14 timeframe, so there's ample room for discussions and decision-making. * Marco really wants to merge them. * I'm indifferent because I don't use either. I think it's a reality that we have users who use both together, using seperate activities for silo'ing files and favorites, and virtual desktops to partition window-space within them. I think it's also a reality that we have users who avoid using both because of the perception of multiplied complexity, and miss out on Activities features because they stick to virtual desktops for simplicty. It's also reality that we have critics who complain the two are redundant and it's all a big mess. I don't think we have any clue what the percentages are, or what the opportunity cost to having both really is. It's not a surprise to me that the idea of merging them has come up, and I can see the appeal of a more simplified system. It does mean being willing to take some people's existing workflows away, though. I also think merging has technical risks, e.g. if it increases the latency of a "virtual desktop switch" it could make the perhaps most-used aspect of the feature unergonomic. I also think which of our options is more appealing is also up to what UI we use to expose them in the end, e.g. the VDG's mulled Activity overview/dashboard thingie. Cheers, Eike
Re: Discussion for Virtual Desktops and Activities future
Just read the phab discussion. If I misunderstood the situation, please correct me. Wondering where the original discussion happened where 'we' decided to merge two orthogonal concepts into one. Can you point me to the relevant thread on plasma-devel?If this is about providing a unified implementation in kwin for both VDs and activities, I'm fine with that. If not, then continue reading. VDs are for managing windows - a solution for the 'I don't have a screen large enough for all these windows'.Activities are for managing work - a solution to the 'I don't want documents/files/etc. from separate projects to get jumbled up together'.Previously, we had problems when we tried to equate activities with any specific thing. As in, 'an activity is a group of Plasma widgets'. The same will happen if the activity becomes 'a group of windows'.This has been discussed quite a few times before. Has anyone collected the use-cases of activities before coming up with this idea?Cheers, Ivan Sent via the BlackBerry Hub for Android From: mvourla...@gmail.comSent: 3 July 2018 5:36 pmTo: plasma-devel@kde.orgReply to: plasma-devel@kde.orgSubject: Discussion for Virtual Desktops and Activities future A discussion started by me at: https://phabricator.kde.org/D13745 about concerns related to future Activities / Virtual Desktops merge (I will call it MERGE in the future). As proposed the discussion can be moved here.In my opinion having a concrete draft how things are going to work from a user point view it might bring design issues that can be solved earlier than later. My opinion in the matter can be found at: https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html1. I think that the previous draft can be used in order to identify any users workflow breakage from MERGE.2. A new draft describing MERGE from a user point of view should be created in order for everyone (plama team and VDG) to understand what they are trying to create.By reading comments I identified a internal decision in order for MERGE to be based more in Activites infrastructure for Plasma product and to VDs infrastructure for KWin product. I would propose to forget the technical approach and focus more on the user point of view. This could help avoid the VDs/Activities debate that started in Plasma 4/5 era and it is still present at a smaller degree.I will start with one concern based on the comments I read even though it would be better for everyone to describe first what is expecting from the MERGE.Concern [A]If MERGE creates a new Activity each time the user needs more space for its windows, doesnt that break totally the VDs users workflow? Example: I am working on my current actitivity and I am writing a note in a plasma widget. I am creating a new Activity, should that Activity look the same as the previous one and if I change the note in the first should it look the same and in the second? (at this example a current VDs user would answer should be in sync and always the same, a current Activity user would answer it doesnt matter, it is unrelated)
Discussion for Virtual Desktops and Activities future
A discussion started by me at: https://phabricator.kde.org/D13745 about concerns related to future Activities / Virtual Desktops merge (I will call it MERGE in the future). As proposed the discussion can be moved here. In my opinion having a concrete draft how things are going to work from a user point view it might bring design issues that can be solved earlier than later. My opinion in the matter can be found at: https://psifidotos.blogspot.com/2012/03/activities-and-workareas-draft.html 1. I think that the previous draft can be used in order to identify any users workflow breakage from MERGE. 2. A new draft describing MERGE from a user point of view should be created in order for everyone (plama team and VDG) to understand what they are trying to create. By reading comments I identified a internal decision in order for MERGE to be based more in Activites infrastructure for Plasma product and to VDs infrastructure for KWin product. I would propose to forget the technical approach and focus more on the user point of view. This could help avoid the VDs/Activities debate that started in Plasma 4/5 era and it is still present at a smaller degree. I will start with one concern based on the comments I read even though it would be better for everyone to describe first what is expecting from the MERGE. Concern [A] If MERGE creates a new Activity each time the user needs more space for its windows, doesnt that break totally the VDs users workflow? Example: I am working on my current actitivity and I am writing a note in a plasma widget. I am creating a new Activity, should that Activity look the same as the previous one and if I change the note in the first should it look the same and in the second? (at this example a current VDs user would answer should be in sync and always the same, a current Activity user would answer it doesnt matter, it is unrelated)
