Re: [Xquartz-dev] geometry regression in 2.3.2-beta3
It works for me: ~ $ emacs -geometry 80x61-0+0 ~ $ emacs --version GNU Emacs 22.3.1 Copyright (C) 2008 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. my xwininfo: xwininfo: Window id: 0x800014 "emacs@<snip>" Root window id: 0x3bd (the root window) (has no name) Parent window id: 0x60000b (has no name) 4 children: 0x80002f (has no name): () 516x793+0+65 +2844+365 2 children: 0x8000c3 (has no name): () 18x13+0+780 +2844+1145 0x8000c2 (has no name): () 18x767+0+0 +2844+365 0x80005f (has no name): () 516x38+0+27 +2844+327 1 child: 0x800060 (has no name): () 516x38+0+0 +2844+327 15 children: 0x8000e2 (has no name): () 34x34+449+2 +3293+329 1 child: 0x8000e3 (has no name): () 34x34+0+0 +3293+329 0x8000e0 (has no name): () 34x34+415+2 +3259+329 1 child: 0x8000e1 (has no name): () 34x34+0+0 +3259+329 0x8000de (has no name): () 34x34+381+2 +3225+329 1 child: 0x8000df (has no name): () 34x34+0+0 +3225+329 0x8000dc (has no name): () 34x34+347+2 +3191+329 1 child: 0x8000dd (has no name): () 34x34+0+0 +3191+329 0x8000da (has no name): () 34x34+313+2 +3157+329 1 child: 0x8000db (has no name): () 34x34+0+0 +3157+329 0x8000d8 (has no name): () 34x34+279+2 +3123+329 1 child: 0x8000d9 (has no name): () 34x34+0+0 +3123+329 0x8000d6 (has no name): () 34x34+245+2 +3089+329 1 child: 0x8000d7 (has no name): () 34x34+0+0 +3089+329 0x8000d4 (has no name): () 34x34+211+2 +3055+329 1 child: 0x8000d5 (has no name): () 34x34+0+0 +3055+329 0x8000d2 (has no name): () 34x34+177+2 +3021+329 1 child: 0x8000d3 (has no name): () 34x34+0+0 +3021+329 0x8000d0 (has no name): () 34x34+143+2 +2987+329 1 child: 0x8000d1 (has no name): () 34x34+0+0 +2987+329 0x8000ce (has no name): () 34x34+109+2 +2953+329 1 child: 0x8000cf (has no name): () 34x34+0+0 +2953+329 0x8000cc (has no name): () 29x34+80+2 +2924+329 1 child: 0x8000cd (has no name): () 29x34+0+0 +2924+329 0x8000ca (has no name): () 34x34+46+2 +2890+329 1 child: 0x8000cb (has no name): () 34x34+0+0 +2890+329 0x8000c8 (has no name): () 34x34+12+2 +2856+329 1 child: 0x8000c9 (has no name): () 34x34+0+0 +2856+329 0x800063 (has no name): () 506x38+10+0 +2854+327 0x800049 (has no name): () 516x27+0+0 +2844+300 6 children: 0x80005e (has no name): () 42x23+250+2 +3094+302 0x80005d (has no name): () 48x23+202+2 +3046+302 0x80005c (has no name): () 60x23+142+2 +2986+302 0x80005b (has no name): () 64x23+78+2 +2922+302 0x80005a (has no name): () 39x23+39+2 +2883+302 0x800059 (has no name): () 36x23+3+2 +2847+302 0x800015 (has no name): () 1x1+-1+-1 +2843+299 Absolute upper-left X: 2844 Absolute upper-left Y: 300 Relative upper-left X: 0 Relative upper-left Y: 22 Width: 516 Height: 858 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x21 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +2844+300 -0+300 -0-20 +2844-20 -geometry 80x61-0-20 Bit gravity: NorthWestGravity Window gravity: NorthWestGravity Backing-store hint: NotUseful Backing-planes to be preserved: 0xffffffff Backing pixel: 0 Save-unders: No Someone wants these events: KeyPress KeyRelease EnterWindow LeaveWindow Exposure StructureNotify FocusChange PropertyChange ColormapChange Do not propagate these events: Override redirection?: No Window manager hints: Client accepts input or input focus: Yes Initial state is Normal State Normal window size hints: User supplied location: 0, 0 User supplied size: 0 by 0 Program supplied minimum size: 48 by 91 Program supplied base size: 36 by 65 Program supplied x resize increment: 6 Program supplied y resize increment: 13 User supplied size in resize increments: 0 by 0 Program supplied minimum size in resize increments: 8 by 7 Program supplied base size in resize increments: 6 by 5 Program supplied window gravity: NorthWestGravity No zoom window size hints defined No window shape defined No border shape defined On Nov 11, 2008, at 20:18, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
What does 'xwininfo -all' say about this window?
Attached. I've since found that no set of position coordinates will be honored :-( ... the size coordinates are fine, but the window ends up at top left no matter what the last two numbers are.
(It's interesting that what's shown as the -geometry is +0+0 ... that's most certainly not what's in the environment...)
Oh ... not sure if this is relevant, but I should probably mention that this is a remote client coming in via SSH proxying. Again, all of this setup worked fine before beta3.
Also, the force-to-upper-left behavior is affecting some but not all of the windows displayed by a Tcl application I use heavily. Dunno what to make of that.
regards, tom lane
xwininfo: Window id: 0xc00013 "emacs@sss2.sss.pgh.pa.us"
Root window id: 0x1fd (the root window) (has no name) Parent window id: 0x600047 (has no name) 1 child: 0xc00014 (has no name): () 496x797+0+0 +0+22 1 child: 0xc00015 (has no name): () 496x797+0+0 +0+22 6 children: 0xc00040 (has no name): () 12x13+482+782 +482+804 0xc00041 (has no name): () 12x13+482+782 +482+804 0xc0003e (has no name): () 12x377+482+392 +482+414 0xc0003f (has no name): () 12x377+482+392 +482+414 0xc0003c (has no name): () 12x377+482+2 +482+24 0xc0003d (has no name): () 12x377+482+2 +482+24
Absolute upper-left X: 0 Absolute upper-left Y: 22 Relative upper-left X: 0 Relative upper-left Y: 22 Width: 496 Height: 797 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x21 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+22 -944+22 -944-59 +0-59 -geometry 80x61+0+0
Bit gravity: NorthWestGravity Window gravity: NorthWestGravity Backing-store hint: NotUseful Backing-planes to be preserved: 0xffffffff Backing pixel: 0 Save-unders: No
Someone wants these events: KeyPress ButtonPress ButtonRelease EnterWindow LeaveWindow PointerMotion Exposure VisibilityChange StructureNotify FocusChange PropertyChange ColormapChange Do not propagate these events: Override redirection?: No
Window manager hints: Client accepts input or input focus: Yes Initial state is Normal State
Normal window size hints: User supplied location: 940, 0 Program supplied size: 496 by 797 Program supplied minimum size: 16 by 4 Program supplied base size: 16 by 4 Program supplied x resize increment: 6 Program supplied y resize increment: 13 Program supplied size in resize increments: 82 by 61 Program supplied minimum size in resize increments: 2 by 0 Program supplied base size in resize increments: 2 by 0 Program supplied window gravity: NorthEastGravity No zoom window size hints defined
No window shape defined No border shape defined
Jeremy Huddleston <jeremyhu@apple.com> writes:
It works for me: ~ $ emacs -geometry 80x61-0+0 ~ $ emacs --version GNU Emacs 22.3.1
Well, I'd be the first to admit that I'm using an ancient Emacs (19.34.1 actually) ... but I wouldn't expect it to break between beta2 and beta3. In any case there are some points here that make me think you've got a pretty small value of "work":
-geometry 80x61-0-20
This doesn't match the requested value.
Bit gravity: NorthWestGravity Window gravity: NorthWestGravity Program supplied window gravity: NorthWestGravity
Shouldn't the window gravity be northeast given the -0+0 position request? On mine, I see the program supplied gravity that way. regards, tom lane
I wrote:
Well, I'd be the first to admit that I'm using an ancient Emacs (19.34.1 actually) ... but I wouldn't expect it to break between beta2 and beta3.
Also, I'm getting the same behavior with emacs 22.2.1 ssh'd in from a reasonably up-to-date machine (Fedora 9). regards, tom lane
Well my emacs is using gtk2 for windowing... Is yours using motif maybe? What is the output of 'ldd /usr/bin/emacs' on your Fedora box? On Nov 11, 2008, at 21:18, Tom Lane wrote:
I wrote:
Well, I'd be the first to admit that I'm using an ancient Emacs (19.34.1 actually) ... but I wouldn't expect it to break between beta2 and beta3.
Also, I'm getting the same behavior with emacs 22.2.1 ssh'd in from a reasonably up-to-date machine (Fedora 9).
regards, tom lane _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
Well my emacs is using gtk2 for windowing... Is yours using motif maybe? What is the output of 'ldd /usr/bin/emacs' on your Fedora box?
Looks gtk'ish from here: $ ldd /usr/bin/emacs linux-vdso.so.1 => (0x00007fffef7ff000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x0000003220c00000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x0000003220800000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x0000003221400000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x0000003220400000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x0000003220000000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x000000321e400000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x000000321e800000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x000000321b800000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x000000321c800000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003f72600000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000321b400000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f72a00000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003222c00000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003f7fa00000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x000000397c800000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003f7f200000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x000000321d400000) libz.so.1 => /lib64/libz.so.1 (0x0000003f73200000) libm.so.6 => /lib64/libm.so.6 (0x0000003f72200000) libungif.so.4 => /usr/lib64/libungif.so.4 (0x0000003221800000) libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x0000003229000000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000321c400000) libXft.so.2 => /usr/lib64/libXft.so.2 (0x0000003226000000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x000000321dc00000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003f76e00000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003f76600000) libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003268600000) libc.so.6 => /lib64/libc.so.6 (0x0000003f71e00000) libgif.so.4 => /usr/lib64/libgif.so.4 (0x000000321cc00000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003268200000) libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x000000321f000000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x000000321e000000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x000000321d000000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x000000321f800000) libXi.so.6 => /usr/lib64/libXi.so.6 (0x000000321d800000) libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x000000321fc00000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x000000321ec00000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x000000321f400000) libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x0000003f77600000) /lib64/ld-linux-x86-64.so.2 (0x0000003f71a00000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003221c00000) libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x000000321bc00000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000321c000000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003f75e00000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003f74200000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003f74e00000) In case it helps: $ rpm -qf /usr/lib64/libgtk-x11-2.0.so.0 gtk2-2.12.12-1.fc9.x86_64 regards, tom lane
On Nov 11, 2008, at 21:13, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
It works for me: ~ $ emacs -geometry 80x61-0+0 ~ $ emacs --version GNU Emacs 22.3.1
Well, I'd be the first to admit that I'm using an ancient Emacs (19.34.1 actually) ... but I wouldn't expect it to break between beta2 and beta3.
So what's happening here is we've added support for window gravity for placement... so there *might* be a bug there... I need to look into exactly what that ancient emacs is doing... Can you run quartz-wm with DEBUG=1 in your environment. I do this with this ~/.xinitrc: export DEBUG=1 . /usr/X11/lib/X11/xinit/xinitrc >& ${HOME}/xinitrc-debug.txt --- Then just start up X11, run emacs and send me your ~/xinitrc-debug.txt (it might not have all the info I need, so I may need to send you another quartz-wm to drop in and get me more debugging info)... Could you also bzip2 that emacs binary and send it to me. I'll try to get it to run on one of my linux boxes to reproduce the problem myself.
In any case there are some points here that make me think you've got a pretty small value of "work":
-geometry 80x61-0-20
This doesn't match the requested value.
Bit gravity: NorthWestGravity Window gravity: NorthWestGravity Program supplied window gravity: NorthWestGravity
Shouldn't the window gravity be northeast given the -0+0 position request? On mine, I see the program supplied gravity that way.
Yeah... so I think emacs might be doing something "smart" rather than using gravity in my version... which led me to think that there might be a gravity bug still...
participants (2)
-
Jeremy Huddleston
-
Tom Lane