Re: OSD and Notification Window Type
On Tuesday 25 November 2014, Martin Gräßlin wrote: plasma tooltips are override redirect yes did that change recently? If yes, Kai Uwe could you please try again? Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp constructor (note that the first time it shows up there is the usual qt xcb problem in which the window is shown an instant before the flags can really be set) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: OSD and Notification Window Type
On Tuesday 25 November 2014 10:09:42 Marco Martin wrote: On Tuesday 25 November 2014, Martin Gräßlin wrote: plasma tooltips are override redirect yes did that change recently? If yes, Kai Uwe could you please try again? Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp constructor (note that the first time it shows up there is the usual qt xcb problem in which the window is shown an instant before the flags can really be set) aha, so the first time it's not an override redirect, because changing this flag is not possible after the window got created. 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: OSD and Notification Window Type
On Monday 24 November 2014 19:55:21 Kai Uwe Broulik wrote: Hi everyone, owing to Eike's request I have investigated how to improve fullscreen handling in notifications, queuing them while in fullscreen. While doing so I found a few usability quirks: First of all, the OSD uses the Notification WindowType, which - I think there has been a bit of a miscommunication - is meant for notifications. The OSD stays on top of everything, which is fine, but not the active fullscreen window. I thus propose to have a window type/layer for the OSD that stays on top of everything since I want to have volume feedback even when watching a movie. +1 to that Furthermore, I've been using the notification applet with the Notification window type and it was no pleasant experience. The popups were always in the way, systray and other popups, even tooltips(!) were covered by the notification popup. At the moment you can bring popups above notifications by focussing the popup which is nice but there's an issue where clicking a notification causes the popup to close, which eats focus [1]. tooltips should not be managed windows, but override redirect. From EWMH spec: This property is typically used on override-redirect windows. - If Plasma is not using override redirect windows for tooltips this is a bug that should be fixed. An override redirect window is always on top of any window managed by KWin (e.g. the notifications). Concerning other popups and the systray popups this need to be thought about what we want to achieve. Concerning the systray popup I think we rather found a weak spot in our setup: systray popup and notification using the same area on the screen might not be the best solution. Anyway also this is fixable by looking at the window types and then redefining where the notifications should go. IMHO the layer is currently correct. A notification should be on top of other windows, we don't want to have it shown e.g. behind the panel. As far as I can see, it has been agreed upon that notifications should never go ontop of an active fullscreen window (you don't want a Hey, darling notification pop up during a presentation) but otherwise on top. yes, exactly. 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
OSD and Notification Window Type
Hi everyone, owing to Eike's request I have investigated how to improve fullscreen handling in notifications, queuing them while in fullscreen. While doing so I found a few usability quirks: First of all, the OSD uses the Notification WindowType, which - I think there has been a bit of a miscommunication - is meant for notifications. The OSD stays on top of everything, which is fine, but not the active fullscreen window. I thus propose to have a window type/layer for the OSD that stays on top of everything since I want to have volume feedback even when watching a movie. Furthermore, I've been using the notification applet with the Notification window type and it was no pleasant experience. The popups were always in the way, systray and other popups, even tooltips(!) were covered by the notification popup. At the moment you can bring popups above notifications by focussing the popup which is nice but there's an issue where clicking a notification causes the popup to close, which eats focus [1]. As far as I can see, it has been agreed upon that notifications should never go ontop of an active fullscreen window (you don't want a Hey, darling notification pop up during a presentation) but otherwise on top. I am fairly out of ideas now. Cheers, Kai Uwe [1] https://bugs.kde.org/show_bug.cgi?id=338946 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD and Notification Window Type
On Monday 24 November 2014, Martin Gräßlin wrote: First of all, the OSD uses the Notification WindowType, which - I think there has been a bit of a miscommunication - is meant for notifications. The OSD stays on top of everything, which is fine, but not the active fullscreen window. I thus propose to have a window type/layer for the OSD that stays on top of everything since I want to have volume feedback even when watching a movie. +1 to that shouldn't that window type be perhaps renamed in OSD to avoid future confusion? Furthermore, I've been using the notification applet with the Notification window type and it was no pleasant experience. The popups were always in the way, systray and other popups, even tooltips(!) were covered by the notification popup. At the moment you can bring popups above notifications by focussing the popup which is nice but there's an issue where clicking a notification causes the popup to close, which eats focus [1]. tooltips should not be managed windows, but override redirect. From EWMH spec: This property is typically used on override-redirect windows. - If Plasma is not using override redirect windows for tooltips this is a bug that should be fixed. An override redirect window is always on top of any window managed by KWin (e.g. the notifications). plasma tooltips are override redirect yes Concerning other popups and the systray popups this need to be thought about what we want to achieve. Concerning the systray popup I think we rather found a weak spot in our setup: systray popup and notification using the same area on the screen might not be the best solution. Anyway if the popup is open i think the notification should reposition itself to accomodate that (both appearing on top or under the systray popup is quite wrong, should simply be elsewhere). I had a patch for it but was quite horrible, maybe i can give it another go in a prettier way -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: OSD and Notification Window Type
On Monday 24 November 2014 20:25:09 Marco Martin wrote: On Monday 24 November 2014, Martin Gräßlin wrote: First of all, the OSD uses the Notification WindowType, which - I think there has been a bit of a miscommunication - is meant for notifications. The OSD stays on top of everything, which is fine, but not the active fullscreen window. I thus propose to have a window type/layer for the OSD that stays on top of everything since I want to have volume feedback even when watching a movie. +1 to that shouldn't that window type be perhaps renamed in OSD to avoid future confusion? no, we need to introduce a new window type OSD. Notification is a NETWM specified window type, we cannot rename it. plasma tooltips are override redirect yes did that change recently? If yes, Kai Uwe could you please try again? 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
