Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/#review29676 --- This review has been submitted with commit 67939b125c4c68e7c40bd4c1c6e270178e215416 by Martin Gräßlin to branch master. - Commit Hook On March 5, 2013, 6:26 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 5, 2013, 6:26 p.m.) Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 22, 2013, 8:52 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/#review29054 --- any comments? Otherwise I'm just going ahead and push it into master. - Martin Gräßlin On March 5, 2013, 7:26 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 5, 2013, 7:26 p.m.) Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 5, 2013, 7:26 p.m.) Review request for kdelibs and David Faure. Changes --- further testing showed that with this patch everything behaves like it should: KWin is no longer managing the Java Applet windows - neither in Alt+Tab nor in the list of Clients they are shown. When embedding ends they are managed again by KWin. Description (updated) --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/#review28554 --- Reg. switcher skipping: SkipSwitcher isn't NETWM and wasn't added to KWindowSystem / NET because of the libs freeze. Also see bug #191310 One could pass the window a type like NET::Override (while that's honest but not NETWM compliant) or eg. NET::Desktop or NET::Dock (though bumping it to the above layer until it's re-embedded) However, *actually* when a (managed) window gets embedded, kwin should unmanage it (thus drop it from the focuschain, thus switcher) since we don't care about non-toplevel windows. Thus i actually don't see why the window would need to be set NET::Hidden | NET::SkipTaskbar | NET::SkipPager at all. It's about to be embedded the very next moment and the flicker has occurred at this point as well. Reg. flicker: what *could* (- means: i don't like that too much) be done is to schedule every maprequest for some 50ms (by this also managing) what would also protect us reg. bug #192470 - Thomas Lübking On March 4, 2013, 7:29 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 4, 2013, 7:29 p.m.) Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar, though they are still shown in Alt+Tab. Seems like we never exported the SkipSwitcher flag. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
On March 4, 2013, 9:29 p.m., Thomas Lübking wrote: Reg. switcher skipping: SkipSwitcher isn't NETWM and wasn't added to KWindowSystem / NET because of the libs freeze. Also see bug #191310 One could pass the window a type like NET::Override (while that's honest but not NETWM compliant) or eg. NET::Desktop or NET::Dock (though bumping it to the above layer until it's re-embedded) However, *actually* when a (managed) window gets embedded, kwin should unmanage it (thus drop it from the focuschain, thus switcher) since we don't care about non-toplevel windows. Thus i actually don't see why the window would need to be set NET::Hidden | NET::SkipTaskbar | NET::SkipPager at all. It's about to be embedded the very next moment and the flicker has occurred at this point as well. Reg. flicker: what *could* (- means: i don't like that too much) be done is to schedule every maprequest for some 50ms (by this also managing) what would also protect us reg. bug #192470 However, *actually* when a (managed) window gets embedded, kwin should unmanage it (thus drop it from the focuschain, thus switcher) since we don't care about non-toplevel windows. that's something that surprised me as it just doesn't happen. Quite likely a bug in KWin Reg. flicker: what *could* (- means: i don't like that too much) be done is to schedule every maprequest for some 50ms the fade effect does kind of take care of it. To really see the flicker I had to add a 5 sec sleep before embedding - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/#review28554 --- On March 4, 2013, 8:29 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 4, 2013, 8:29 p.m.) Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar, though they are still shown in Alt+Tab. Seems like we never exported the SkipSwitcher flag. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
Re: Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet
On March 4, 2013, 8:29 p.m., Thomas Lübking wrote: Reg. switcher skipping: SkipSwitcher isn't NETWM and wasn't added to KWindowSystem / NET because of the libs freeze. Also see bug #191310 One could pass the window a type like NET::Override (while that's honest but not NETWM compliant) or eg. NET::Desktop or NET::Dock (though bumping it to the above layer until it's re-embedded) However, *actually* when a (managed) window gets embedded, kwin should unmanage it (thus drop it from the focuschain, thus switcher) since we don't care about non-toplevel windows. Thus i actually don't see why the window would need to be set NET::Hidden | NET::SkipTaskbar | NET::SkipPager at all. It's about to be embedded the very next moment and the flicker has occurred at this point as well. Reg. flicker: what *could* (- means: i don't like that too much) be done is to schedule every maprequest for some 50ms (by this also managing) what would also protect us reg. bug #192470 Martin Gräßlin wrote: However, *actually* when a (managed) window gets embedded, kwin should unmanage it (thus drop it from the focuschain, thus switcher) since we don't care about non-toplevel windows. that's something that surprised me as it just doesn't happen. Quite likely a bug in KWin Reg. flicker: what *could* (- means: i don't like that too much) be done is to schedule every maprequest for some 50ms the fade effect does kind of take care of it. To really see the flicker I had to add a 5 sec sleep before embedding Quite likely a bug in KWin Misbehavior - ReparentNotify is just swallowed but not handled at all. (We'd have to somehow check whether there's a client for the window and/or whether mapping is to the deco or - if reparented too root - we need to manage it - 4.11 - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/#review28554 --- On March 4, 2013, 7:29 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109282/ --- (Updated March 4, 2013, 7:29 p.m.) Review request for kdelibs and David Faure. Description --- KWindowSystem::doNotMange is a method which performs a D-Bus call to KWin to inform KWin about a window with a specific title to not manage it. Manage here actually meens to set the window to state hidden, but it's nevertheless properly managed and e.g. appears in the Alt+Tab window switcher and is also shown in the taskbar. It's rather obvious that KHTML should not expect the window manager KWin and should not interact with it through D-Bus - after all it's an X11 window manager and we normally talk X. This hack had been added for the Java applet years ago. The reason for this is that the Java windowing system abstraction AWT is too limited. It doesn't allow direct interaction with the window system causing the Applet window to be first mapped to the screen and then getting embedded. This causes a short flicker which is worked around by the doNotManage hack. To suppress this flicker KHTML now sets the appropriate flag and also the flicker is hardly visible anyway because nowadays our computers are much faster ;-) and we have compositing. The doNotManage call clearly falls too short and therefore this change improves the situation by setting the hidden flag and in addition the skip pager and skip taskbar. This at least makes sure that the applets are not shown in the taskbar, though they are still shown in Alt+Tab. Seems like we never exported the SkipSwitcher flag. Diffs - khtml/java/kjavaappletwidget.cpp e9adc4c Diff: http://git.reviewboard.kde.org/r/109282/diff/ Testing --- installed Java, got it somehow magically configured to even have a plugin, found a website, applet is shown. Thanks, Martin Gräßlin
