Review Request 109282: Drop usage of KWindowSystem::doNotMange from KJavaApplet

[Martin Gräßlin]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130304/b527a131/attachment.htm>