On Sun, Jan 14, 2007 at 12:27:35AM +0000, Thomas Adam wrote: > On Sun, Jan 14, 2007 at 12:50:57AM +0100, Dominik Vogt wrote: > > On Sat, Jan 13, 2007 at 09:12:00PM +0000, Thomas Adam wrote: > > > On Sat, Jan 13, 2007 at 04:34:17PM +0100, Dominik Vogt wrote: > > > > > There appears to be a discrepency between how FvwmIdent calculates the > > > > > geometry of the specified window, in relation to, say, how xwininfo > > > > > calculates it. In both cases, xwininfo's report of the geometry of a > > > > > window is correct. You just have to use a test case of: > > > > > > > > > > xterm -g some_geometry_string > > > > > > > > > > for the numbers from xwininfo and FvwmIdent to see what's happening. > > > > > I > > > > > don't have time to look into why at the moment, I wish I did. > > > > > > > > Fixed. > > > > > > Are you sure? There is a difference in the numbers between the > > > FvwmIdent module shipped with 2.5.19 and the updated on in CVS, but > > > they're still reporting erroneous numbers in the geometry string that I > > > can tell. > > > > Um, yes I'm quite sure (apart from the new bug I introduced with > > the "fix". > > > > > Here's an example: > > > > > > xterm -g 80x24+0+0 > > > > > > Places xterm in the top-left corner of the current page. If you run > > > FvwmIdent (from 2.5.19, say) on that window, you'll get a reported > > > geometry of: > > > > > > 484x316+0+0 > > > > That's the geometry in pixels. > > I'm obviously missing something fundamental here. :) > > That's what I thought -- but this wouldn't really help a client such as > XTerm would it? (which largely depends on resize increments to determine > geometry unless one has ResizeHintOverride set, for instance). To my > eyes, when I use FvwmIdent to ascertain information about a window, such > as its geometry, I'd like to think that when I do: > > my_app -geometry 100x34+0+0 > > That it opens up in that location. But it doesn't -- not, if you say, > compare it to the output from xwininfo, which, when using its geometry > string, does open up the application in the position I would have > expected it to. Ideally, shouldn't both xwininfo and FvwmIdent's > geometry reporting match?
I don't understand what your problem is. When I start xterm like this: $ xterm -g "80x24+0+0" I get an 80x24 xterm at +0+0. FvwmIdent says: X: 0 (frame x position) Y: 0 (frame y position) Width: 587 (frame width) Height: 342 (frame height) Geometry: 80x24+0+0 So FvwmIdent gives me the frame's size and position and the width/height/position of the client as if the wm had not decorated it (80x24+0+0). Without any options, xwininfo reports the client window's absolute position (+4+22) and the size in pixels (579x316). It can also report the frame's geometry if called with the "-frame" option (587x342, +0+0). So, what *is* the problem with that? > > > Of course, it _should_ be 80x24+0+0. If you were to then issue a > > > command of: > > > > > > xterm -g 484x316+0+0 > > > > > > That is going to obviously give you one huge XTerm. :) > > > > You're looking at the wrong lines of the output. The numbers you > > are looking for are in the "Geometry:"-line near the bottom of the > > window. > > Aye -- and using those numbers still produce an erroneous size. Huh? For me it says 80x24+0+0, and that's exactly the string I passed to xterm in the first place. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
