On Sonntag, 19. Januar 2014 14:17:15 CEST, Martin Graesslin wrote:
The idea is to reuse the desktop windows, hide the wallpaper (on compositing) and restack it on top of all other windows.
That would imply to dump the "dashboard" as some additional plasmoid container, 
correct?

Thus if the showing desktop mode is entered we do no longer hide the windows but move the desktop windows and it transients on to an own dashboard layer.
Perfectly legal approach, it would (presumingly?) implement option a2 from
http://forum.kde.org/viewtopic.php?f=83&t=118281

Notice however, that this would technically prevent the scenario where eg. 
krunner is shown w/o breaking the _NET_SHOWING_DESKTOP state.

Given that we never really supported the showing desktop mode
kdeplasma-addons-applets-showdesktop?

and I hardly see a difference between the showing desktop mode and dashboard
Not unless they've different content

Opinions?
Referring back to the brainstorm, the first comment concern about (a2) was that 
users could wonder why the expected window is not showing up.
This of course be less ("not") a problem for a translucent desktop client.

The ongoing complaints about present (d) (break state with new window) somehow tell me 
that we should not follow that approach as only alternative in the special layer 
implementation - and force the users into the (b) (pref. "b2") invocation.

So i'm fine with that combo, leaving the only concern about the different 
contents of the desktop and dashboard containment.
The client (plasma-*) could handle that internally (exchanging plasmoids 
depending on mode) but i've little idea on how either desktop or dashboard is 
commonly used in this regard (ie. whether there's actually need exclusive 
access to different item sets, eg. folderview on the desktop and weather 
widgets on the dashboard etc.)
A solution to this could be the desktop implementing "virtual containments" ie. 
like on a smartphone (and unlike virtual desktops or activities not affecting other 
client visibility)

Cheers,
Thomas
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to