KJavaAppletWidget's usage of KWindowSystem

Martin Gräßlin mgraesslin at kde.org
Thu Feb 28 14:35:50 GMT 2013


On Monday 04 February 2013 17:47:45 Aaron J. Seigo wrote:
> On Saturday, February 2, 2013 13:05:15 David Faure wrote:
> > I tried removing the doNotManage() call, and...
> 
> if you replace them with:
> 
> 	setWindowFlags(Qt::X11BypassWindowManagerHint | windowFlags())
I spent some time today on the problem and the window flag cannot work.

The window which gets embedded is not created by Qt but by Java using AWT. AWT 
seems to be extremely limited and doesn't expose any information of the 
underlying windowing system. This means we cannot make the window override 
redirect or get the window ID prior to mapping the window. Which explains the 
hack with the window title: it's the only X11 bit which can be modified.

Java comes with a proper abstraction for X11, but it doesn't look safe to use 
it: "... is internal proprietary API and may be removed in a future release". 
Also the API is typically Java by having a class XCreateWindowParams which has 
a method add(Object key, Object value) without documentation what key is.

I don't have any hopes that we can change the Java parts to make the window 
behave correctly.

Back to the problem we actually want to solve: getting rid of the API.
While testing I had not noticed the flicker at all - I assume the mapping is 
faster than the fade in animation of KWin (and of course KWin doesn't show the 
window before it's painted). I had to add a several second sleep to really see 
the issue.

What I found most interesting is that the hack inside KWin doesn't solve any 
problems. I still see the KJAS windows in Alt+Tab and have even seen them in 
the taskbar - which nicely shows how going D-Bus with KWin is clearly not a 
solution. I had a closer look at what KWin does with the window and although 
it's called "doNotManage" the window gets managed, all it does is hide the 
window in the manage state again (for the interested [1]). That could also be 
done by KHTML to avoid the flicker (which is obviously still there even if 
done by KWin, just shorter).

Overall I think we should really kill the code - it's wrong in multiple ways 
and too much hacks to prevent a flicker.

--
Martin Gräßlin

[1] http://code.woboq.org/kde/kde-workspace/kwin/manage.cpp.html#444
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130228/5fd15ecd/attachment.sig>


More information about the kfm-devel mailing list