Re: No need for 770 device to debug the AWT problems
On Thu, 2006-03-23 at 07:50 +0100, Clemens Eisserer wrote: I should have added that it works fine with the JDK. Matchbox is kick-ass! Well I never thought it could be matchbox's fault. Matchbox is just the WindowManager - a very little puzzle-part in the whole picture. What is the exact bug report? What it doesn't work when run with Matchbox as window manager? If you have a small source code example that works normally with other window managers, but doesn't with Matchbox that would help. I tried some of our demo programs under matchbox and they seem to work fine. Matchbox just make the windows very big (only one window on top allowed it seems). But that didn't really seem to break anything that I could see. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: No need for 770 device to debug the AWT problems
What is the exact bug report? I think this guy talks about the repainting problem I've seen when I tried to run AWT/swing applications on my N770. Even on the native side the expose-events were never received although it worked with a small gtk-testcase I created. This is the only problem which could be at least a bit matchbox related - maybe classpath's AWT peers set some hints that don't work. Could also be a broken version of GTK deployed with the N770. lg Clemens This is just my private opinion, I respect the work of everybody who has ever contributed to classpath. I always found the GTK peers disgusting, tons of effort, code, binary size and bugs just for supporting native lf. And thanks to GTK broken from time to time with each new GTK release. My favourite would be a java-only implementation of x-protocoll based peers so that not even a single line native code would be needed (ok, maybe for the shm stuff) - widgets could be painted using swing like SUN now does with their XAWT. However just an opinion and (for now) too little time to do it myself. Thanks for doing all the work, its great to see how far classpath has come. What it doesn't work when run with Matchbox as window manager? If you have a small source code example that works normally with other window managers, but doesn't with Matchbox that would help. I tried some of our demo programs under matchbox and they seem to work fine. Matchbox just make the windows very big (only one window on top allowed it seems). But that didn't really seem to break anything that I could see. Cheers, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEImCAxVhZCJWr9QwRAocFAJwJUdojjVGANhDRrbYUKWBkr7FmEACeKCOs QvGXwTA1I+kp9s9A6lo8gx8= =sVGz -END PGP SIGNATURE-
Re: No need for 770 device to debug the AWT problems
I should have added that it works fine with the JDK. Matchbox is kick-ass! Philippe Laporte wrote: Hi, Having a 770 device is not needed. What one needs is a nested X server that runs the same WM as on the 770 (Matchbox). Step-by-step instructions: 1. Build classpath 2. Build a JVM 3. Goto http://projects.o-hand.com/matchbox/sources/ and download the latest version of matchbox-window-manager and libmatchbox First build libmatchbox then the matchbox-window-manager: libmatchbox: $ ./configure make make install (use --prefix if you want it somewhere special) matchbox-window-manager: $ ./configure --enable-standalone --disable-ping-protocol --disable-xrm This is how I built it, I guess you can do it in another way as well.. (you can use --prefix here as well) then: $ make make install Hit CTRL-ALT-Fwhatever log on then: $ X :1 xterm -display :1 This will start a new X server with a xterm.. start the wm: $ matchbox-window-manager (if it is located in your $PATH) So this way one can debug on an x86 desktop Seems like an Xserver tuning is also needed: From [EMAIL PROTECTED]: The fixed pixmap problem, how do I best get the fix? There is no problem in Matchbox. Fix is to disable composite in X server build (which is done). Previous thread: [EMAIL PROTECTED] wrote: Expose-events work in 770 normally, bug is in the application/library side, not in Matchbox. Problem with pixmap depth was solved by disabling composite extension in Xomap build (if it does not work, the problem is trivial for application side to fix just by using some other function to query colordepth instead). Thomas Fitzsimmons wrote: Hi, On Tue, 2006-03-07 at 13:46 +0100, Clemens Eisserer wrote: Classpath's AWT of course runs on top of GTK+. Not on the 770, it has several problems but I am not experienced enough to solve them: - Expose events seem not to be sent by X or at least are not received by java. I did some debgugging and as far as I can tell no expose events are sent by X. Interesting. Does the 770 window manager allow overlapping windows or dialogs? Maybe there is no need for expose events except one on initial startup. Maybe we need to post paint events in response to something other than an expose event, when running on the 770. I'd appreciate more information on this. - When creating offscreen images they are created using 24 bit depth since GTK_RGB thinks this is best (why do we ask GTK_RGB for the default pixmap depth and do not simply use the depth the screen is running?). But 770's X server has no colormap assigned to 24-bit mode so it asserts. Yes, I think we currently assume a 24-bit colormap in the GTK peers, which is wrong. I'd like to see this fixed. Best Regards,
