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

List:       kde-panel-devel
Subject:    Re: Suggestion: Merge "Showing Desktop" and "Dashboard" mode
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2014-01-19 15:42:52
Message-ID: df64d2b1-e8f9-497c-9974-ea46c7890fe6 () gmail ! com
[Download RAW message or body]

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


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