Re: Re: Re: Notes from New OSD in Plasma 2
Martin GräßlinOn Tuesday 21 January 2014 08:32:16 wrote: On Tuesday 21 January 2014 01:06:36 Martin Klapetek wrote: On Mon, Jan 20, 2014 at 6:59 PM, Thomas Lübking thomas.luebk...@gmail.comwrote: On Montag, 20. Januar 2014 17:29:18 CEST, Martin Klapetek wrote: How would the positioning work inside kwin and where? kwin/placement.cpp I'm stucked. I'm pretty sure I'm setting the NET::Notification windowType on the PlasmaCore.Dialog, however when it shows up, KWin tells me it's NET::Normal (Client::windowType()) plus Client::isNotification() returns false. Probably a bug in PlasmaCore.Dialog. It shouldn't be NET::Normal at all, but NET::Dialog by default. I'll have a look. I had a look and the Plasma side seems fine. You can verify using xprop. My demo dialog got the notification type. But KWin does not yet support notifications window type for managed windows. You need a patch to KWin, for example http://pastebin.kde.org/pkyshgvpx Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Notes from New OSD in Plasma 2
On Tue, Jan 21, 2014 at 8:57 AM, Martin Gräßlin mgraess...@kde.org wrote: I had a look and the Plasma side seems fine. You can verify using xprop. My demo dialog got the notification type. Hmm...I might have been wrong then, using xprop on the OSD I get _NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL Which I don't understand as the Dialog code looks fine and it goes through NETWinInfo::setWindowType(..) setting the notification type properly. Also if the type is Normal, shouldn't it have normal win decorations? I'm getting a borderless window (unless that's actually done by some inner kwin stuff). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Re: Notes from New OSD in Plasma 2
On Tuesday 21 January 2014 14:26:59 Martin Klapetek wrote: On Tue, Jan 21, 2014 at 8:57 AM, Martin Gräßlin mgraess...@kde.org wrote: I had a look and the Plasma side seems fine. You can verify using xprop. My demo dialog got the notification type. Hmm...I might have been wrong then, using xprop on the OSD I get _NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL That's not what I had. My example code which I wrote this morning for testing: http://pastebin.kde.org/phhnfbtda I executed the code using qmlscene. Maybe that makes a difference. Which I don't understand as the Dialog code looks fine and it goes through NETWinInfo::setWindowType(..) setting the notification type properly. Also if the type is Normal, shouldn't it have normal win decorations? I'm getting a borderless window (unless that's actually done by some inner kwin stuff). No, the type is _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, normal is just the fallback for all other window managers. Override is our window type hint for don't decorate me. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Re: Notes from New OSD in Plasma 2
On Tue, Jan 21, 2014 at 3:10 PM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 21 January 2014 14:26:59 Martin Klapetek wrote: On Tue, Jan 21, 2014 at 8:57 AM, Martin Gräßlin mgraess...@kde.org wrote: I had a look and the Plasma side seems fine. You can verify using xprop. My demo dialog got the notification type. Hmm...I might have been wrong then, using xprop on the OSD I get _NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL That's not what I had. My example code which I wrote this morning for testing: http://pastebin.kde.org/phhnfbtda I executed the code using qmlscene. Maybe that makes a difference. Ok, two things I noticed: 1) If visible: true is not present, the type is never NET::Notification, even in your code. Once added, it has proper type. 2) This works when executed in qmlscene only, it does not work when using KDeclarative::QmlObject for the dialog. I'll investigate why. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Re: Notes from New OSD in Plasma 2
On Tue, Jan 21, 2014 at 3:28 PM, Martin Klapetek martin.klape...@gmail.comwrote: On Tue, Jan 21, 2014 at 3:10 PM, Martin Gräßlin mgraess...@kde.orgwrote: On Tuesday 21 January 2014 14:26:59 Martin Klapetek wrote: On Tue, Jan 21, 2014 at 8:57 AM, Martin Gräßlin mgraess...@kde.org wrote: I had a look and the Plasma side seems fine. You can verify using xprop. My demo dialog got the notification type. Hmm...I might have been wrong then, using xprop on the OSD I get _NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL That's not what I had. My example code which I wrote this morning for testing: http://pastebin.kde.org/phhnfbtda I executed the code using qmlscene. Maybe that makes a difference. Ok, two things I noticed: 1) If visible: true is not present, the type is never NET::Notification, even in your code. Once added, it has proper type. 2) This works when executed in qmlscene only, it does not work when using KDeclarative::QmlObject for the dialog. I'll investigate why. Update: windowType for the Dialog is overiden by Qt (in QXcbWindow::setNetWmWindowFlags). That method (in combination with window flags) however does not support NET::Notification. Should we extend that system? Or should we make that method not /replace/ the type but just add it (would that even work?)? Should we work around that in our code? Please advise. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 3:55 PM, Thomas Lübking
thomas.luebk...@gmail.comwrote:
KWin cannot take care of moving it if plasma determines the position, but
i think that the client requesting the OSD should determine the
preferred/requried screen (see brightness example for why) and KWin the
position.
Currently Plasma does not determine the position afaics, just the size, the
placing looks like it's done by kwin. How would the positioning work inside
kwin and where? I now set the NET::Notification window type on the OSD,
would there be some special if (windowType == NET::Notification) {
position stuff; } ? I'd like to play around with that for a bit.
KWin can then avoid window collisions (as is now, in smart, maybe with a
center preference) and esp. fullscreen windows in the multiscreen case (if
the OSD doesn't care), resp. we can allow a particular placing for OSDs
(what could more or less be a simplified config for a window rule on
screen/placing/position)
Smart placement is typically not a client job.
+1
Most important (from client side) about this window type should be fully
input shaped (output only) and denying input focus (latter faking
override_redirect)
We cannot enforce either from KWin's side if we're re-using an existing
type.
Done now.
OT about flash: minitube.
Btw does it also handle when you click a youtube link you got from someone
(IM, email etc)?
Cheers
--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Montag, 20. Januar 2014 17:29:18 CEST, Martin Klapetek wrote: How would the positioning work inside kwin and where? kwin/placement.cpp You may want to take a look at https://git.reviewboard.kde.org/r/110918/ in addition. Btw does it also handle when you click a youtube link you got from someone (IM, email etc)? passing a yt url as minitube parameter works as expected (get's you that video and related ones) but handling http://www.youtube.com/watch?v=foobar;; differently from eg. http://www.kde.org or even http://www.youtube.com would require a smarter kde-open (or xdg-open wrapper) - so far one can only handle protocols or mimetypes. Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Mon, Jan 20, 2014 at 6:59 PM, Thomas Lübking thomas.luebk...@gmail.comwrote: On Montag, 20. Januar 2014 17:29:18 CEST, Martin Klapetek wrote: How would the positioning work inside kwin and where? kwin/placement.cpp I'm stucked. I'm pretty sure I'm setting the NET::Notification windowType on the PlasmaCore.Dialog, however when it shows up, KWin tells me it's NET::Normal (Client::windowType()) plus Client::isNotification() returns false. Doesn't look as easy as I thought it would be :) Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Notes from New OSD in Plasma 2
On Tuesday 21 January 2014 01:06:36 Martin Klapetek wrote: On Mon, Jan 20, 2014 at 6:59 PM, Thomas Lübking thomas.luebk...@gmail.comwrote: On Montag, 20. Januar 2014 17:29:18 CEST, Martin Klapetek wrote: How would the positioning work inside kwin and where? kwin/placement.cpp I'm stucked. I'm pretty sure I'm setting the NET::Notification windowType on the PlasmaCore.Dialog, however when it shows up, KWin tells me it's NET::Normal (Client::windowType()) plus Client::isNotification() returns false. Probably a bug in PlasmaCore.Dialog. It shouldn't be NET::Normal at all, but NET::Dialog by default. I'll have a look. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
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. Adding support for it in the PlasmaCore.Dialog should be simple. It already has a WindowType enum which just needs another value for Notification. 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? Cheers Martin [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2560306 [2] Exception: the glide effect excludes notifications from animation [3] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#STACKINGORDER signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 12:25 PM, Martin Graesslin mgraess...@kde.orgwrote: 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Saturday 18 January 2014 12:53:10 Martin Klapetek wrote: On Sat, Jan 18, 2014 at 12:25 PM, Martin Graesslin mgraess...@kde.orgwrote: 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? I don't care, but I would say Plasma. I think that simplifies it given that you have to set x/y anyway. 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. The main problem I used to have is when powerdevil changes the brightness, especially when e.g. a TV is connected to the system. Kind of useless then. Changing the layer order would be easy afterwards right? I guess we could try your proposal and see how it works in practice. Yes, that would be very easy. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 1:03 PM, Martin Graesslin mgraess...@kde.orgwrote: Who should do the positioning? Plasma or KWin? I don't care, but I would say Plasma. I think that simplifies it given that you have to set x/y anyway. That actually brings another quesion - on which screen it should show up? I'd put it wherever mouse cursor currently is. Opinions? 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. The main problem I used to have is when powerdevil changes the brightness, especially when e.g. a TV is connected to the system. Kind of useless then. I thought about exactly this case. But if you disable the OSD in passive actions, you might also miss that the computer is about to power off your display (the brightness goes down every once in a while and when it's at 0, DPMS will kick soon...by default). So I guess you do want some kind of notification on external TV in case you left your power management enabled. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Saturday 18 January 2014, Martin Klapetek wrote: On Sat, Jan 18, 2014 at 1:03 PM, Martin Graesslin mgraess...@kde.orgwrote: Who should do the positioning? Plasma or KWin? I don't care, but I would say Plasma. I think that simplifies it given that you have to set x/y anyway. That actually brings another quesion - on which screen it should show up? I'd put it wherever mouse cursor currently is. Opinions? +1 Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Saturday 18 January 2014 13:15:18 Martin Klapetek wrote: On Sat, Jan 18, 2014 at 1:03 PM, Martin Graesslin mgraess...@kde.orgwrote: Who should do the positioning? Plasma or KWin? I don't care, but I would say Plasma. I think that simplifies it given that you have to set x/y anyway. That actually brings another quesion - on which screen it should show up? I'd put it wherever mouse cursor currently is. Opinions? Show it on all screens. That is create one OSD per screen. If that's not wanted I'd say we use what KWin considers the active screen. And we could take care of moving it there. (Active screen is depending on config option the screen with the active window or the screen which has the mouse). 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. The main problem I used to have is when powerdevil changes the brightness, especially when e.g. a TV is connected to the system. Kind of useless then. I thought about exactly this case. But if you disable the OSD in passive actions, you might also miss that the computer is about to power off your display (the brightness goes down every once in a while and when it's at 0, DPMS will kick soon...by default). So I guess you do want some kind of notification on external TV in case you left your power management enabled. Proper fix: DPMS should not kick in when a video is being played and there are powermanagement hooks for it. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 1:34 PM, Martin Graesslin mgraess...@kde.orgwrote: I thought about exactly this case. But if you disable the OSD in passive actions, you might also miss that the computer is about to power off your display (the brightness goes down every once in a while and when it's at 0, DPMS will kick soon...by default). So I guess you do want some kind of notification on external TV in case you left your power management enabled. Proper fix: DPMS should not kick in when a video is being played and there are powermanagement hooks for it. YouTube. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Saturday 18 January 2014 13:34:39 Martin Klapetek wrote: On Sat, Jan 18, 2014 at 1:34 PM, Martin Graesslin mgraess...@kde.orgwrote: I thought about exactly this case. But if you disable the OSD in passive actions, you might also miss that the computer is about to power off your display (the brightness goes down every once in a while and when it's at 0, DPMS will kick soon...by default). So I guess you do want some kind of notification on external TV in case you left your power management enabled. Proper fix: DPMS should not kick in when a video is being played and there are powermanagement hooks for it. YouTube. I heard rumors about Flash going to die in April :-) Apart from that: let's follow what we said in other threads. Work on the best default experience with working applications and ignore the broken ones. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 1:48 PM, Martin Graesslin mgraess...@kde.orgwrote: Proper fix: DPMS should not kick in when a video is being played and there are powermanagement hooks for it. YouTube. I heard rumors about Flash going to die in April :-) If only ;) Apart from that: let's follow what we said in other threads. Work on the best default experience with working applications and ignore the broken ones. Afaik all normal video apps (vlc (s)mplayer at least) use DPMS inhibition (I heard mplayer generates X mouse move events for that). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
Hi, (I hope I have used KMail's Reply-To-All feature correctly) That actually brings another quesion - on which screen it should show up? I'd put it wherever mouse cursor currently is. Opinions? I think it depends on what kind of OSD. For Keyboard layout and Volume it's fine to show where the cursor is but for the brightness I think it should be shown on the display that actually is affected (the internal one) - I'd say people would know/expect pressing the screen brightness keys on a notebook changes the notebook's screen and not the attached beamer, so the OSD should be shown on the notebook screen. Btw what about Keyboard brightness? I've just seen a mail from Martin Klapetek(?) to Jens about keyboard *layout* and *screen* brightness - we need a fancy monochrome icon for keyboard brightness, too, as the current generic keyboard icon doesn't work very for this. Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 1:57 PM, Kai Uwe Broulik k...@privat.broulik.dewrote: Hi, (I hope I have used KMail's Reply-To-All feature correctly) That actually brings another quesion - on which screen it should show up? I'd put it wherever mouse cursor currently is. Opinions? I think it depends on what kind of OSD. For Keyboard layout and Volume it's fine to show where the cursor is but for the brightness I think it should be shown on the display that actually is affected (the internal one) - I'd say people would know/expect pressing the screen brightness keys on a notebook changes the notebook's screen and not the attached beamer, so the OSD should be shown on the notebook screen. Good point, thanks. I wonder if we can get that info from some component. Btw what about Keyboard brightness? I've just seen a mail from Martin Klapetek(?) to Jens about keyboard *layout* and *screen* brightness - we need a fancy monochrome icon for keyboard brightness, too, as the current generic keyboard icon doesn't work very for this. Ah yes, I should have updated the list about that - I talked to Jens shortly after and we came up with more icons than I requested originally, including the keyboard brightness plus one for Wi-Fi being turned on/off :) Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
Am Samstag, 18. Januar 2014, 14:01:29 schrieb Martin Klapetek: Ah yes, I should have updated the list about that - I talked to Jens shortly after and we came up with more icons than I requested originally, including the keyboard brightness plus one for Wi-Fi being turned on/off Aaaand Bluetooh, and Touchpad? ;) Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Sat, Jan 18, 2014 at 2:05 PM, Kai Uwe Broulik k...@privat.broulik.dewrote: Am Samstag, 18. Januar 2014, 14:01:29 schrieb Martin Klapetek: Ah yes, I should have updated the list about that - I talked to Jens shortly after and we came up with more icons than I requested originally, including the keyboard brightness plus one for Wi-Fi being turned on/off Aaaand Bluetooh, and Touchpad? ;) Bluetooth should already be there somewhere and touchpad too, yes. Ok I just checked the log here's the complete list we talked about (sorted by priority): * Screen brightness * Keyboard layout * Keyboard brightness * Wi-Fi on/off * Touchpad on/off * Bluetooth on/off (already there) They should all be usable from OSD and also in their smaller versions from inside plasmoids (like the battery one). I had left that up to Jens to either make two sets of them (big for OSD with different details; small for systray/plasmoid icons) or just one scalable. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Samstag, 18. Januar 2014 13:34:49 CEST, Martin Graesslin wrote: Show it on all screens. That is create one OSD per screen. If that's not wanted I'd say we use what KWin considers the active screen. And we could take care of moving it there. (Active screen is depending on config option the screen with the active window or the screen which has the mouse). Plasma-desktop could need the active screen to be exported anyway (taskbar needs to know whether a window can raise - see bug #246838) KWin cannot take care of moving it if plasma determines the position, but i think that the client requesting the OSD should determine the preferred/requried screen (see brightness example for why) and KWin the position. KWin can then avoid window collisions (as is now, in smart, maybe with a center preference) and esp. fullscreen windows in the multiscreen case (if the OSD doesn't care), resp. we can allow a particular placing for OSDs (what could more or less be a simplified config for a window rule on screen/placing/position) Smart placement is typically not a client job. Most important (from client side) about this window type should be fully input shaped (output only) and denying input focus (latter faking override_redirect) We cannot enforce either from KWin's side if we're re-using an existing type. Reg. the layer fullscreen windows, we're more or less in the same dilemma as with should this FS window unredirect?, ie. when does what message is just annoying, ie. if one changes the screen brightness or the volume, one would likely not want to be informed about that while playing a video or game, while in the chromebook case (FS browser as sub-OS) the fullscreen state is completely irrelevant in this regard. IOW: we need better information of the nature of a fullscreen window. OT about flash: minitube. Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
Just so my presence is known: the icons are on their way! Its my birthday today so I thought no one will notice if I slag off for one weekend, will they? ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Saturday 18 January 2014 15:55:31 Thomas Lübking wrote: On Samstag, 18. Januar 2014 13:34:49 CEST, Martin Graesslin wrote: Show it on all screens. That is create one OSD per screen. If that's not wanted I'd say we use what KWin considers the active screen. And we could take care of moving it there. (Active screen is depending on config option the screen with the active window or the screen which has the mouse). Plasma-desktop could need the active screen to be exported anyway (taskbar needs to know whether a window can raise - see bug #246838) I like the idea of exposing the active screen. Will try to draft something tomorrow. Most important (from client side) about this window type should be fully input shaped (output only) and denying input focus (latter faking override_redirect) We cannot enforce either from KWin's side if we're re-using an existing type. Good point, we will need to extend the PlasmaCore.Dialog for that. I can also try to work on that. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
Hello, On Mon, Jan 13, 2014 at 11:16 PM, Martin Klapetek martin.klape...@gmail.com wrote: This would be handled over DBus with custom QML files doing the rendering. Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Thu, Jan 16, 2014 at 2:02 PM, Bhushan Shah bhus...@gmail.com wrote: Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Currently shell, but since it will be installing those QML files, I guess apps/themes will be able to override it. I need to talk to someone more knowledgeable about that first, but they should definitely be themeable. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
If you load a qml file from lookfeel that should be fine. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Thursday, January 16, 2014 14:40:43 Martin Klapetek wrote: On Thu, Jan 16, 2014 at 2:02 PM, Bhushan Shah bhus...@gmail.com wrote: Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Currently shell, but since it will be installing those QML files, I guess apps/themes will be able to override it. I need to talk to someone more knowledgeable about that first, but they should definitely be themeable. Themable, yes, by means of Look and Feel package. Overridden by apps: no, for the sake of consistency. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
