Community
Participate
Working Groups
I'm having a problem with the way dialog are displayed. The dialog box is rendered far too small. I need to resize the dialog box to see all of its contents. This is annoying but not a very big problem however some dialog boxes cannot be resized, ie XDocklet Configuration "Add Standard" dialog displays only ok and cancel buttons I cannot resize and I'm unable to see the list box. I'm using eclipse 3.0.1 GTK on Debian/Linux "Testing". My GTK library is version 2.4.13, jdk sun 1.5.0. I'm currently running enlightenment 16.6 but have also had the problem in Gnome and KDE. I've upgraded eclipse to 3.1M2 and still have this problem
Created attachment 15468 [details] This is a image (png) of the dialog box as it is rendered Added image of the dialog box before I resize it.
Created attachment 15469 [details] This is the dialog box when I resize the window Image of the resized dialog box
Created attachment 15472 [details] Picture of my desktop + dialog box that cannot be resized This is a picture of my entire desktop. Eclipse is shownig a dialog box for deploying a servlet. Notice I cannot see the list of deployment targets. I can press OK to deploy but it is hit and miss as to what item I'm deploying to.
Can you please grab this: http://vektor.ca/bugs/gtkinfo.c ... and compile it like so: gcc -Wall -g `pkg-config --cflags --libs gtk+-2.0` gtkinfo.c -o gtkinfo .. and post the results here? I think it may reveal what's going on.
Billy, I've compiled and run the script on my home box, same setup as at work and I'm having the same problems. The code crashes Segmentation fault, see below. I've commented out the line it crashes on recompiled and rerun, output attached also. derm@elric:~$ ./gtkinfo Version information: Compiled on GTK+ version 2.4.13. Running on GTK+ version 2.4.13. Environment variables: GTK_PATH is not set. GTK_EXE_PREFIX is not set. GTK+ will search: $libdir/lib/gtk-2.0/... GTK_DATA_PREFIX is not set. GTK+ will search: $prefix/share/themes GTK2_RC_FILES is not set. GTK+ will read: $sysconfdir/gtk-2.0/gtkrc and ~/.gtkrc-2.0 General settings: Language is en-gb. Theme is Default. Default font is Sans 10. Icon theme is hicolor. Xft antialiasing is turned on. Display name is :0.0 and has 1 screens. Screen 0: 1024x768 on 1 monitors. Window manager is Enlightenment. Monitor 0: 0,0 1024x768 Style information from a button: Focus width 1, focus pad 1. Segmentation fault ****** Commented out line recompiled and rerun ***** derm@elric:~$ ./gtkinfo Version information: Compiled on GTK+ version 2.4.13. Running on GTK+ version 2.4.13. Environment variables: GTK_PATH is not set. GTK_EXE_PREFIX is not set. GTK+ will search: $libdir/lib/gtk-2.0/... GTK_DATA_PREFIX is not set. GTK+ will search: $prefix/share/themes GTK2_RC_FILES is not set. GTK+ will read: $sysconfdir/gtk-2.0/gtkrc and ~/.gtkrc-2.0 General settings: Language is en-gb. Theme is Default. Default font is Sans 10. Icon theme is hicolor. Xft antialiasing is turned on. Display name is :0.0 and has 1 screens. Screen 0: 1024x768 on 1 monitors. Window manager is Enlightenment. Monitor 0: 0,0 1024x768 Style information from a button: Focus width 1, focus pad 1. Normal foreground (0,0,0), background (56540,56026,54741). Font information from a default label: Font: Sans Size: 10240 (10 pixels) Approximate char width: 4962 (5 pixels) Approximate digit width: 6144 (6 pixels) Global font information: There are 30 font families. There are a total of 86 faces in all families.
Thanks for the output. Sorry about the segfault, I've fixed it now. It does not matter for this case, the info you gave is useful. I thought that the problem might be bad font metrics, since these are used for dialog resizing, but your font information seems sane for this test tool. I can't see anything strange about your GTK+ setup. I did notice though that both of your screenshots include some additional plugins. Can you show some examples of badly resized dialogs with just the Eclipse SDK installed? How about the "Window > Open Perspective > Other" or "Window > Preferences" dialogs? How about the dialog that appears when you hit Ctrl-L? Is it all dialogs, or just these ones relating to the servlet plugins you have installed?
Billy, Sorry for the delay in responding, I've had a few days off ill, back to the grind today. Now that I'm back at work I've rerun the gtkinfo program, output is slightly different see below. Version information: Compiled on GTK+ version 2.4.13. Running on GTK+ version 2.4.13. Environment variables: GTK_PATH is not set. GTK_EXE_PREFIX is not set. GTK+ will search: $libdir/lib/gtk-2.0/... GTK_DATA_PREFIX is not set. GTK+ will search: $prefix/share/themes GTK2_RC_FILES is not set. GTK+ will read: $sysconfdir/gtk-2.0/gtkrc and ~/.gtkrc-2.0 General settings: Language is en-gb. Theme is Default. Default font is Sans 10. Icon theme is hicolor. Xft antialiasing is turned on. Display name is :0.0 and has 1 screens. Screen 0: 1024x768 on 1 monitors. Window manager is Enlightenment. Monitor 0: 0,0 1024x768 Style information from a button: Focus width 1, focus pad 1. Normal foreground (0,0,0), background (56540,56026,54741). Font information from a default label: Font: Sans Size: 10240 (10 pixels) Approximate char width: 5671 (6 pixels) Approximate digit width: 7168 (7 pixels) Global font information: There are 35 font families. There are a total of 110 faces in all families. I've deleted the eclipse directory and unzipped eclipse-SDK-3.1M2-linux-gtk.zip to give me a fresh install, no additional plugins added. I've also selected a new workspace. I have encountered some dialog problems, I've attached some screen shots. I'm still a little worried that this is related to the windowmanager. I've deleted the eclipse directory and re-installed and tried the same tasks under fluxbox rather than enlightenment. It works OK. So I tried enlightenment again with a fresh install and different 'widow placement settings' (Place window under mouse). Works OK, although when I reset the 'window placement settings' and re-install it still works OK. Not ideal I had hoped it would have shown problems again. All I can say is it seems to be random at the moment. I'll set the window placement settings to 'Place under mouse' and see how this afternoon goes this afternoon. Thanks, Derm.
Created attachment 15595 [details] Dialog problem fresh install no additional plugins
Created attachment 15596 [details] resized dialog fresh install no additional plugins
After a week of using the Fluxbox windowmanager and a fresh install of Eclipse I have encountered no problems. I'm sure the dialog problems I've had are related to the use of Enlightenment as a windowmanager. My only concern is that the window settings seem to be retained, ie if I encounter problems under enlightenment and then switch window mamager dialog boxes are still rendered incorrectly. Finally a big thanks to all.
I have the same problems using Enlightenment, but using a different theme (BrushedMetal-Tigert). Search/Replace dialog is my major nightmare. I checked the source code of that dialog and couldn't find a call to shell.pack() . It is very important to pack the shell or give it a well calculated default size (learned by experience running my own apps on Enlightenment).
Cute. OK, I will have to try and get an Enlightenment setup going and see if it's worth fixing.
I can provide additional screenshots and setup info if you need it. Fixing this problem is really worth the effort.
I guess I was hinting more at Enlightenment's difficulty and brokenness. I've had my share of Enlightenment-specific bugs in my own applications beyond Eclipse. :) Let me see if I can reproduce it anyway and figure out in more detail what's going on...
Oops, I wanted this one.
So far, I cannot reproduce this problem using enlightenment 0.16.6 from Debian, BushedMetal-Tigert theme. I've opened a lot of dialogs (including find/replace) and have never had them at an incorrect size. I have been testing with 3.1M4 and 3.0.1. I talked to raster on IRC, and he did indicate that 0.16.6 has some potential race conditions when moving or resizing windows and mapping them. This likely explains the packing case mentioned by Rodolfo. He mentioned that these problems are solved in e17, and that 16.6/16.7 both have fixes for this sort of thing. Since these are race conditions, it may explain why this problem can be somewhat elusive. Given that there are known problems with this version of enlightenment fixed in later versions, and since I cannot reproduce the problem, I am going to close this bug as WORKSFORME. Please re-open if you have a specific and reproducable way of triggering the race. Rodolfo, if you have a specific change or suggestion for the Search/Replace dialog that improves its behaviour for you, please file a new bug about this issue.
Problems are still present in e17 (tested with eclipse 3.1M4 and e17 from CVS (1/2/04). I added myself to this bug aftter a negative experience with e16.7 and eclipse 3.1M3. Enlightenment 0.16.6 is too old I can provide images showing problems with some dialogues on e17. I can also install e16.8 and test eclipse in that version.
Does it happen all the time, or only sometimes? Can you tell me more about your system?
Once this problem appears, it seldom goes away. I have upgraded from the stable e16.7 to e.17 and it still happens. Right now I'm running e17 on Fedora Core 3 (with all updates applied) on a Pentium IV with 512MB of RAM. This problem was also observed on SuSE 9.x by someone else and reported to Enlightenment User's mailing list. As you suggested in Comment #16, I opened bug 82230 where you can see two images captured today.
*** Bug 82230 has been marked as a duplicate of this bug. ***
Billy, I'm not sure whether this helps: I reviewed the FindReplaceDialog code (see bug 82230) and found that we missed to set the layout data for the dialog's main composite. This is now fixed in HEAD.
If this change is available on next stable build, I'll test it.
It will be interesting to see if this change improves the find dialog. In the mean time, raster was able to reproduce the problem on e17 and we have been debugging what's going on from the WM side on IRC. I'll keep you posted.
Yes it's in the N-builds and the next I-build. I can send you a preview if you don't want to wait.
Created attachment 16984 [details] raster: annotated X protocol log from a working dialog
Created attachment 16985 [details] raster: annotated X protocol log from a non-working dialog
raster is the enlightenment author. He has provided some interesting debugging logs from running eclipse. <raster> i basically started the eclipse logs from the moment it creates the dialog window and on until it maps (shows) it and beyond <raster> in the working example it resizes the window to a sane size before mapping it <raster> in the non workign one it simply doesnt <raster> you can see e17's own internal debug output from each situation Log from e17 of a non-working dialog: ##- CONF REQ 0x1800a18 , 1X1+0+0 generic config request 14006f0 0 0 1x1 ... ##- CONF REQ 0x1800a18 , 332X1+162+96 generic config request 14006f0 162 96 332x1 ... ##- CONF REQ 0x1800a18 , 1X1+162+96 generic config request 14006f0 162 96 1x1 ... ##- CONF REQ 0x1800a18 , 1X1+0+0 generic config request 14006f0 0 0 1x1 ... ##- NEW CLIENT 0x1800a18 ##- ON MAP CLIENT 0x1800a18 SIZE 332x1 ##- SIZE HINTS for 0x1800a18: min 1x1, max 32767x32767, base 0x0 ##- MWM HINTS SET 0x846583c! ##- NEW CLIENT SETUP 0x1800a18 ##- REQUEST POS 0x1800a18 [162,96] ##- BORDER NEEDS POS/SIZE CHANGE 0x1800a18 ##- CONF REQ 0x1800a18 , 332X1+0+0 ##- CONFIGURE REQ 0x1800a18 mask: S Log from a working dialog: ##- CONF REQ 0x1400538 , 1X1+0+0 generic config request 1400538 0 0 1x1 ... ##- CONF REQ 0x1400538 , 494X471+421+243 generic config request 1400538 421 243 494x471 ... ##- CONF REQ 0x1400538 , 1X1+421+243 generic config request 1400538 421 243 1x1 ... ##- CONF REQ 0x1400538 , 1X1+0+0 generic config request 1400538 0 0 1x1 ... ##- NEW CLIENT 0x1400538 ##- ON MAP CLIENT 0x1400538 SIZE 494x471 ##- SIZE HINTS for 0x1400538: min 1x1, max 32767x32767, base 0x0 ##- MWM HINTS SET 0x846583c! ##- NEW CLIENT SETUP 0x1400538 ##- REQUEST POS 0x1400538 [421,243] ##- BORDER NEEDS POS/SIZE CHANGE 0x1400538 ##- CONF REQ 0x1400538 , 494X471+0+0 ##- CONFIGURE REQ 0x1400538 mask: S
I finally tracked down the problem. The cause of the problem is the function gdk_window_get_frame_extents (). The documentation for this function says that it returns the size of a window including any trim added by the window manager. Enlightenment (and especially e17) uses virtual roots, which breaks the algorithm used by GDK to infer the frame size. This confuses SWT into thinking that the windows have huge frames, making setBounds() behave strangely. Raster claims that the following patch to GTK+ (or a variation on the theme) will fix the problem. It uses a new NETWM hint to query the frame size from supporting window managers: http://bugzilla.gnome.org/show_bug.cgi?id=163910 In the mean time, setting the trim sizes to 0 in SWT makes Eclipse's dialogs size correctly for me under e17. We may be able to add a workaround for this in case we detect enlightenment, or see if we can avoid using gdk_window_get_frame_extents().
Using Rasterman's patch, Eclipse now seems to behaving as it should for me. Excellent!
OK from polish team, Kim please put this in, then add other developers required to make this happen.
Versions of enlightenment before 0.17 are now fixed by the change for bug 99527, and raster's patch was accepted into GTK+ for 2.6. I am just going to mark this as a duplicate of the newer bug. *** This bug has been marked as a duplicate of 99527 ***
