Notes from "New OSD in Plasma 2"

[Martin Klapetek]

On Sat, Jan 18, 2014 at 12:25 PM, Martin Graesslin <mgraesslin at kde.org>wrote:

> On Monday 13 January 2014 18:46:28 Martin Klapetek wrote:
> > Hey all,
> >
> > following are the notes from the "New OSD in Plasma 2" discussion we had
> > here at the Plasma sprint.
> >
> > The basic idea is that the shell should provide a way for certain apps to
> > display a short passive transient notification. That includes things like
> > when user changes brightness, volume, changes the keyboard layout,
> virtual
> > desktop or activity and possibly few others.
> >
> > This would be handled over DBus with custom QML files doing the
> rendering.
> > The flow is as follows: user changes volume - kmix sends a dbus signal -
> > plasma has a slot handling that signal - plasma loads the QML file for
> > rendering and puts it on screen with special window class - kwin gives it
> > extra love cause of the win class.
>
> I had some thought on the "KWin gives it extra love" and how we can
> identify
> the window. The preferred way on my side would be a window type and there
> is
> one existing type which we might reuse: _NET_WM_WINDOW_TYPE_NOTIFICATION
> [1].
> We have complete support for it in KWin and KWindowsystem as
> NET::Notification
> in NET::WindowTypes enum. KWin recognizes the notification and does nothing
> with it [2]. To be more precise KWin does not support the window type for
> managed windows, only for override redirect windows. That's easy to change,
> though.
>

Who should do the positioning? Plasma or KWin?


> Adding support for it in the PlasmaCore.Dialog should be simple. It already
> has a WindowType enum which just needs another value for Notification.
>

We do have control over the QWindow inside which Dialog is displayed.


>
> In KDE software it is used in Krita and Amarok for a notification (in case
> of
> Amarok it's the OSD). Other uses I couldn't find on my system. I failed
> with
> lxr, maybe someone else is more apt at using that tool ;-)
>
> The special love KWin could give the OSD is to put it into an own layer.
> The
> recommendation for stacking orders does not contain notifications [3]. The
> question is where to put it. In my opinion it should be above keep above
> and
> dock windows, but I'm unsure whether it should be above active fullscreen
> windows or below. Personally I'm always annoyed by the screen brightness
> notification on top of a video. Given that I suggest that we introduce a
> new
> layer between keep above and active fullscreen windows.


> Comments?
>

Truth is you don't need to know the /exact/ brightness or volume level in
fullscreen video, you simply fiddle with it until it suits you. In this
case it's maybe not as much about showing the exact percentage, but about
providing visual feedback that you hit the correct keys and that they are
working - I can imagine cases where users will press it couple times more
to actually check if the brightness controls do work.

Changing the layer order would be easy afterwards right? I guess we could
try your proposal and see how it works in practice.

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140118/9d157fcc/attachment.html>