Enclosed is the verbose patch i mentioned on the Java thread. gunzip verbose.patch.gz cd blackbox patch -p0 < /path/to/verbose.patch make
when you run the new binary the path from initial request to final display has a print whenever the window size would have changed. There are also additional prints in the methods called when a window requests a change. Typical output looks like this: 0xc00046: initial (30, 25) w: 100, h: 43 the initial number is the window id in hex, it matches the output of xwininfo. I could not include the window's title because it is not available that early in the code. If blackbox really is causing problems I expect to see a reasonable value for initial and then weirdness later. There is a print in there which says: sizes reflect the frame from now on after this, expect the x,y width, height to be slightly different. The numbers now reflect the managed blackbox frame not the initial data from the client window. In general the window will move down around 15 - 20 pixels, have its height increased by around 20 - 30 pixels, and its width adjusted from 2 - 10 pixels. Going from w: 100, h: 43 to w: 1000, h: 300 should not happen unless something requested the change. When you test JBuilder I would ask that you move any ~/.jbuilder (or whatever it is called) aside and run the app as if you just installed it. In fact, if you create a dummy user on your machine and run the program from that account it would ensure none of your personal settings were involved. Some of these apps store the last known width, height and coordinates to open at that spot later on. So if bad values were stored last time you will see them this time. Please let me know if the list manager eats the attachment.
verbose.patch.gz
Description: verbose.patch.gz
