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
