Review Request 122679: Show Desktop feature: refurbished
Vishesh Handa
me at vhanda.in
Sat Apr 4 13:47:24 UTC 2015
> On March 22, 2015, 8:28 p.m., Kai Uwe Broulik wrote:
> > Sorry for being late to the party:
> >
> > UX issues I have with that implementation:
> > - No transition, the windows just disappear (would be cool to have them slide out of the screen or have them stay at the edges of the screen like OSX does it, but that's visuals)
> > - Cannot access plasmoid or containment config windows (or GHNS in widget explorer) - they don't appear in that mode, nor do they exit it
> > - KRunner exits this mode, imho KRunner should be usable from there (usability?)
> > - Panels inaccessible (though usability even proposed hiding them in Dashboard mode, so..)
> >
> > Other than that this would 100% replace my Dashboard usecase, so +1 for the overall idea.
> >
> > Usability team, ping?
>
> Thomas Lübking wrote:
> - No transition
> Definitively, but another patch (we'll have to wire up a showingDesktop signal and then script something nicely ;-)
>
> - Cannot access plasmoid or containment config windows
> We'll have to require them to either be transient for the desktop or set the keepAbove flag (and interpret that in layers.cpp) to still keep "normal" docks (panels) hidden
>
> - KRunner exits this mode
> Afaics that's a general (re-occurring ;-) "problem" w/ krunner, unrelated to this patch.
> Non-dock type windows that are not in the desktop group break the mode. This applies because krunner is another process than plasmashell (afair the KDE3 runner was part of kdesktop)
> => KRunner must either become a dock-type (and keepabove or transient) or move itself into the desktops window group (be transient for it or have the same WM_CLIENT_LEADER)
>
> However, I put "problem" in quotation marks, because that rather seems the minimize-all (aka. "you wanted to switch the VD" ;-) case of cleaning up the workspace (for the very next action will break the mode anyway when you run a new application)??
>
> - Panels inaccessible
> See above - we can either make dock-type windows (mostly panels) unconditionally visible or require them to setup a special condition (transient for desktop or keep above)
>
> The question on what to do here is also the question mostly asked by this RR =)
> The global behavior (as long as we don't require transiency/keepabove hints from "some" panels) is very easy to adjust, though.
>
> @Usability team, please also see my very first comment for more information on layer control.
>
> kdeuser 56 wrote:
> My use case for the dashboard was mainly, when I had a lot of windows and I wanted to customize plasma: Simply trigger dashboard and cutsomize the Desktop, othwerwise, you would have to use "Show Desktop" or change to an empty workspace. I really liked what we had in plasma5 till now, because the panels were accessible, why wouldn't they be? What speaks against the panels? They are accesible all the time, why wouldn't that be in dashboard mode too? When the panels are inacessible, I have to treat cutsomization (my main use case), seperately for widgets and panels, something I find an unnecessary barrier. If my opinion is worth anything here, I would vote for accessible panels, dimmed or not.
> On another note: even when you do not customize stuff, you use the dashboard/show desktop for accessing information on the workspace. Now I trigger dashboard, but want to have a look at a notificaiton too, while I am for example reading my plasma notes. Now I would have to exit the dashboard and reenter it, because the panels are not accessible. I don't think the panels ever distract that much, they should be made inaccessible.
>
> Thomas Pfeiffer wrote:
> Sorry for keeping you waiting for so long. I was very busy recently, and apparently I'm the only one who is currently active on the usability list. So here goes:
>
> * Transition: We all agree that we need a transition, but since Thomas said it will be another patch, we won't discuss it here further (just keep it in mind)
> * Config windows: I'm still for a separate "workspace configuration mode" (Andrew and I have talked about our plans for that to some Plasma devs, but we yet have to properly introduce our ideas) which would make it unnecessary to show config dialogs on the dashboard (and if we do have a separate mode, I'd indeed vote for _not_ showing them in the dashboard). However, as long as there is no separate config mode, I agree with kdeuser56 that the dashboard is probably the best place available to configure the workspace and therefore config dialogs should be visible there. Just please don't put too much effort into this as it might become obsolete later.
> * Panels: I'm a bit torn here. The thing is that we have not defined what the dashboard is supposed to be used for. If it is only for glancing at or quickly interacting with desktop widgets, then panels would only be distracting. If it is for interacting with the workspace in general, then of course panels should be accessible. One argument against showing panels would be that clicking on a window in the task switcher would break the mode (the window should not go below the dashboard, as that would be inconsistent with switching via alt-tab). Still, I see valid arguments for both alternatives, so I'll leave that to you. Just make sure that either panels are fully visible and can be interacted with, or are hidden/dimmed/faded and cannot be interacted with, as any mix of the two would be confusing.
> * Layer: In contrast to what I said here ( https://bugs.kde.org/show_bug.cgi?id=338534 ), I now think that "always on top" windows should be kept above the dashboard, if we want to encourage the user's mental model of "the desktop as basically just another window, which we would with the tab-switching. In general, we should try to keep that mental model in mind when making decisions in this area.
> * KRunner: Since KRunner is a Plasma user's "life-line", it has to be always accessible. Having it break the dashboard mode would probably feel weird, as it's something one often invokes on the fly, without wanting to leave the current context. Of course if one uses it to start a new GUI application, then that breaks the dashboard mode, which is okay. This is by far not KRunner's only use, though.
>
> I hope I was able to address all questions. If not, feel free to point any questions that are still open out to me.
>
> Thomas Lübking wrote:
> There're meanwhile even *two* transitions in this patch series ;-)
>
> * Layer: keepAbove *always* on top of the "deskboard" or conditionally (ie. for the latter you'd still be able to alt+tab them above or below)
>
> * We *will* require a hint on krunner, ideally set it transient for the desktop window.
> -> Vishesh, does krunner already link kwindowsystem (since that'll likely be required to find the desktop WId, QDesktopWidget is the root wid)
>
> * Other panels: I'd suggest to leave that to the client? If a panel is set keepabove, it would remain shown, otherwise not?!?
> Vishesh, does krunner already link kwindowsystem (since that'll likely be required to find the desktop WId, QDesktopWidget is the root wid)
Yes. It links against it.
- Vishesh
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122679/#review77926
-----------------------------------------------------------
On March 31, 2015, 9 p.m., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122679/
> -----------------------------------------------------------
>
> (Updated March 31, 2015, 9 p.m.)
>
>
> Review request for kwin, Plasma, KDE Usability, Martin Gräßlin, Marco Martin, and Vishesh Handa.
>
>
> Bugs: 344083
> https://bugs.kde.org/show_bug.cgi?id=344083
>
>
> Repository: kwin
>
>
> Description
> -------
>
> commit b4e3a736c3643179b5b4ea73f7706918a03483fe
> Author: Thomas Lübking
> Date: Mon Mar 30 11:38:54 2015 +0200
>
> add eyeOnScreen effect
>
> commit 4aaeeda8fbebded0e915b39a54092c586de179ce
> Author: Thomas Lübking
> Date: Mon Mar 30 11:38:38 2015 +0200
>
> support gaussian curve and animationEnded signal in ScriptedEffect
>
>
> commit a1e7f1a2ccefffd42e360bbaae48ecdfaa5b1ff4
> Author: Thomas Lübking
> Date: Sun Mar 29 00:15:57 2015 +0100
>
> Add effect to move windows to corners on showing the desktop
> commit d92c46e96fe9fb13403b859c5e334b618d45d268
> Author: Thomas Lübking
> Date: Sun Mar 29 00:15:22 2015 +0100
>
> Remove AnimationData wrapper around metadata. Allow to set metadata directly in animation objects
> commit ed38cf37b26aa15d77c5b73734581055be234233
> Author: Thomas Lübking
> Date: Sun Mar 29 00:13:41 2015 +0100
>
> make window elevation scriptable
> commit c297fd5c55ba862151265e4b8b65b5ffe6048a8d
> Author: Thomas Lübking
> Date: Sun Mar 29 00:12:21 2015 +0100
>
> forward showingDesktop signal to effects
> commit 570a92331f3691c1fb2affa4f853c75d6062f7e3
> Author: Thomas Lübking
> Date: Sun Mar 29 00:08:32 2015 +0100
>
> emit signal when showingDesktop changes
>
>
> commit a1b80b4e310b2c75b4d9811af1d23f699bc658b5
> Author: Thomas Lübking
> Date: Sun Feb 22 16:41:45 2015 +0100
>
> add "MinimizeAll" script
>
> to compensate withdrawn core feature (which
> though has been hidden so far)
>
> commit 983efb916e282d2263b4abcc92f714c06b3bfcc1
> Author: Thomas Lübking
> Date: Wed Feb 18 02:09:00 2015 +0100
>
> break showingDesktop w/ tabbox/PW/DG
>
> This is now crucial, because while before (the minimized) windows were conditionally shown, but are now always behind the desktop.
> Also, it makes the tabbox more consistent.
>
> commit ff531c8e2adc407da00bef88f18d03e3829b25fa
> Author: Thomas Lübking
> Date: Wed Feb 18 01:37:45 2015 +0100
>
> implement showingDesktop by raising the desktop window
>
> commit 190a0cc022d9935d658a6218d0b3caa79b038563
> Author: Thomas Lübking
> Date: Wed Feb 18 00:09:46 2015 +0100
>
> remove secret showDesktopIsMinimizeAll feature
>
>
> Diffs
> -----
>
> client.h 6b947fe
> client.cpp b6af2fa
> effects.h ae71d61
> effects.cpp 20a8773
> effects/CMakeLists.txt 98a9349
> effects/badbadwindows/CMakeLists.txt PRE-CREATION
> effects/badbadwindows/package/CMakeLists.txt PRE-CREATION
> effects/badbadwindows/package/contents/code/main.js PRE-CREATION
> effects/badbadwindows/package/metadata.desktop PRE-CREATION
> effects/desktopgrid/desktopgrid.cpp 97cb2a3
> effects/eyeonscreen/CMakeLists.txt PRE-CREATION
> effects/eyeonscreen/package/CMakeLists.txt PRE-CREATION
> effects/eyeonscreen/package/contents/code/main.js PRE-CREATION
> effects/eyeonscreen/package/metadata.desktop PRE-CREATION
> effects/presentwindows/presentwindows.cpp 7a62ec0
> kwin.kcfg 80ca365
> layers.cpp ae08207
> libkwineffects/kwineffects.h b77e461
> manage.cpp 8b1a2ee
> options.h 67e5868
> options.cpp cdaa851
> scripting/scriptedeffect.h 39af241
> scripting/scriptedeffect.cpp ba646f6
> scripts/CMakeLists.txt 34dedb7
> scripts/minimizeall/contents/code/main.js PRE-CREATION
> scripts/minimizeall/metadata.desktop PRE-CREATION
> tabbox/tabbox.cpp 4a00e4b
> workspace.h 16fa351
> workspace.cpp f9c1ab1
>
> Diff: https://git.reviewboard.kde.org/r/122679/diff/
>
>
> Testing
> -------
>
> * The script (though mostly in KWin4, trouble w/ ksycoca5...)
> * Obviously the supersecret key is now dead ;-)
> * Been playing around with alternate desktop showing.
>
>
> Thanks,
>
> Thomas Lübking
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150404/022f6871/attachment-0001.html>
More information about the Plasma-devel
mailing list