[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Discussion for Virtual Desktops and Activities future
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2018-07-16 10:44:13
Message-ID: CAGeFrHAwQwxAUYe8r4f-S-tyb8rCSax-iBrU6F_-njmZcLrTmA () mail ! gmail ! com
[Download RAW message or body]

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.

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><div \
class="gmail_quote">For the vast majority of users my proposal is identical to your \
proposal.</div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><div>  </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (switching \
activities<br> Perhaps i could live with that if a desktop can be associated to \
one<br> and only one activity, which is how i understood \
it</blockquote><div><br></div><div>Yep, that&#39;s how I envisioned it \
too.</div><div>(Also, it&#39;s effectively Michail&#39;s mockup too)<br></div><div>  \
</div><span class=""></span><br><span class=""></span></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> &gt; With KAMD only \
switching the DBus currentActivity when switching between the first two desktops to \
the last two.<br> <br>
</span>What would be the workflow/ui of adding a new virtual desktop, or<br>
adding a new activity? have some UI questions that I think should be<br>
answered before decising how viable the direction is.<br>
<br></blockquote><div><br></div><div class="gmail_quote">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&#39;s +/- icons that push/pop to the \
end don&#39;t really cut it.<br></div><div class="gmail_quote"><br></div><div \
class="gmail_quote">As for my mod, in my head it&#39;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.</div></div></div><div><br></div><div>I&#39;m not set in stone on \
that, depends a bit on getting feedback about the explicit problems with \
merging.<br></div><div><br></div><div>Of course if someone wanted to write \
Michail&#39;s mockup as an optional effect that could get far more fine grained \
control that&#39;d be fine. <br></div><div class="gmail_extra"><div \
class="gmail_quote"><div class="gmail_quote"><br></div></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic