> On März 22, 2015, 8:28 nachm., 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 Handa wrote:
> > 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.
Splendid.
You'll want to do something (not typo-safe ;-) along these lines
(QDesktopWidget::winId() is NOT the desktop, but the root window)
```cpp
WId desktopId = 0;
foreach (WId id, KWindowSystem::stackingOrder()) {
KWindowInfo info(id, NET::WMWindowType|NET::XAWMState);
if (info.windowType(NET::DesktopMask) == NET::Desktop && info.mappingState()
== NET::Visible) {
desktopId = id;
break;
}
}
if (desktopId)
KWindowSystem::setMainWindow(winId(), desktopId);
```
I fear, you'll have to do this everytime showing the runner, since changing
activities, restarting or replacing plasmashell might/will change the WId of
the (visible) desktop.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122679/#review77926
-----------------------------------------------------------
On April 4, 2015, 3:28 nachm., Thomas Lübking wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122679/
> -----------------------------------------------------------
>
> (Updated April 4, 2015, 3:28 nachm.)
>
>
> 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
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
