> On Nov. 30, 2014, 10:45 nachm., Thomas Lübking wrote: > > Please notice that override redirects are above EVERY managed window, ie. > > if you fullscreen window happens to be an SDL(? some toolkit does this at > > least) game, the new layer will fail its job. > > > > Random 3¢: > > So either this is superfluous (the window should just be override redirect) > > or (reg. wayland and unmanaged clients) in NETWM (to get away from > > unmanaged clients in general) > > > > Because that re-appeared over and over again lately: > > I'd pesonally oppose this as "but we always forget to make new QML stuff > > override redirect" specific solution. > > > > Otoh, if this actually was a canonical type w/ well defined behavior, we > > could make fine-grained adjustments, eg. have it not above keep-above > > fullscreens or similar. > > Martin Gräßlin wrote: > it was a suggestion by me to introduce a new type. The problem is that we > mixed up notification and osd. That is I implemented support for notification > and thought that would be for notification, but it got used for OSD. > > Now the initial idea on why I wanted to have it with a dedicated type > still holds: having more information in KWin about the window type. That's a > good thing in general. So even if it were just an override redirect it should > have a type to indicate it's type. We will need that on Wayland anyway that > windows must provide more information than currently (no override redirect > there). > > Concerning the games which use override-redirect: I don't think we should > design our API around the brokeness of games.
I'm certainly ok w/ extending and fine-graining the window types, but would prefer to have it in NETWM[1] (instead of having a proprietary feature and later on possible collision/confusion), notably because: ``` _NET_WM_WINDOW_TYPE_NOTIFICATION indicates a notification. An example of a notification would be a bubble appearing with informative text such as "Your laptop is running out of power" etc. This property is typically used on override-redirect windows. ``` "bubble" ... "with informative text" ... "typically used on override-redirect windows" sounds *a lot* like an OSD. So it needs proper distinction, resp., if this is for very specific "notifications" (volume slider), maybe just a specification that managed keep-above notifications are supposed to be in the active layer (thus on top of fullscreen windows, unless those are flagged keepabove as well - i don't want a volume hint when an imp runs on me ;-) --- I just mentioned the games (a "full screen" override redirect is not broken per se) to point out that this might not have the desired outcome. --- [1] Do you btw. already have an opinion about reviving it? - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121299/#review71139 ----------------------------------------------------------- On Dez. 1, 2014, 6:49 nachm., Kai Uwe Broulik wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121299/ > ----------------------------------------------------------- > > (Updated Dez. 1, 2014, 6:49 nachm.) > > > Review request for KDE Frameworks, kwin and Martin Gräßlin. > > > Repository: kwindowsystem > > > Description > ------- > > This adds a NET::OSD window type for the OSD (eg. volume feedback) so it can > be placed even ontop of active fullscreen windows in contrast to the > Notifications. > > Not sure whether a kde netwm thing is required or we could just use some > other method in KWin to decide placement. > > Also dunno what impact on ABI this has, I tried to only add enum values at > the end. > > > Diffs > ----- > > autotests/netwininfotestclient.cpp 16ba4b3 > src/netwm.cpp 1ccba32 > src/netwm_def.h 0352f33 > > Diff: https://git.reviewboard.kde.org/r/121299/diff/ > > > Testing > ------- > > In conjunction with Review 121300 these are now ontop of fullscreen windows. > > > Thanks, > > Kai Uwe Broulik > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
