--000000000000db0dd905711b8331 Content-Type: text/plain; charset="UTF-8" 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. --000000000000db0dd905711b8331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the vast majority of users my proposal is = identical to your proposal.
The only real d= ifference is in mine we explicitly say that we never assume VD ID =3D=3D ac= tivity ID which can allow for most future complexity should someone want to= both implement and opt into it.
= =C2=A0
(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)
=C2=A0

=
> With KAMD only switching the DBus currentActivity when switching betwe= en 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/rem= oving is something that needs some thinking. The core questions needs answe= ring 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 act= ivity 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 bes= t 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 gr= ained control that'd be fine.

--000000000000db0dd905711b8331--