[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-13 15:27:26
Message-ID: CAGeFrHDwios7zS8VBs5S47TwvFyVz7VP1B4K+XcPy8w9zbHsmA () mail ! gmail ! com
[Download RAW message or body]
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.
[Attachment #3 (text/html)]
<div dir="auto"><div><br><br><div class="gmail_quote"><div \
dir="ltr"><br></div></div></div><div dir="auto"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> VDs to inform KWin, if they are not part of the current \
activity and<br> therefore should not be switched to when switching through VDs. \
Also<br> the pager must know which VDs not to display in the current activity.<br>
But as said this can be a porperty on the VDs and not on the Activity.<br>
><br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div \
dir="auto">I think kwin shouldn't filter them. Pager lists all, effects and \
shortcuts cover all. </div><div dir="auto"><br></div><div dir="auto">This is the \
crucial part that makes it merging.</div><div dir="auto"><br></div><div \
dir="auto">Yes, its a behavioral change, but its also the key part of fixing the \
currently complex and semi-duplicated ui.</div><div dir="auto"><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > * The provider of the list \
of virtual desktops is ultimately kactivitymanagerd<br> Why is KAMD the provider? I \
think KWin should be the provider of all<br> VDs and KAMD then tells KWin which \
subset of VDs should be currently<br> switchable (using the property above) depending \
on the activity KAMD<br> has set.<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto">I meant its the source kwin would use to manage \
the list of desktops.</div><div dir="auto"><br></div><div dir="auto">Like kscreen \
manages outputs, but the WL_output iface still comes from kwin.</div><div \
dir="auto"><br></div><div dir="auto">Kamd is the "kscreen" in this \
case.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">To try \
and re-summarise:</div><div dir="auto"><br></div><div dir="auto"><span \
style="font-family:sans-serif">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.</span></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic