[Xquartz-dev] geometry regression in 2.3.2-beta3

[robert delius royar]

OK regarding fspanel, just wanted to know whether it was supposed to be that 
way

Note, the comment about iconified startups being correct was not correct.  I 
tried a new startup and found they do not open where they were told.

Regarding xterm, I replaced the supplied xterm with the recompiled one (to get 
the toolbar), so that is different (MD5 894d4cd506579611f42ca75ec22be2ea)

But I see the error with XEmacs also.

The MD5 for /usr/bin/quartz-wm is c612da09f845b4cde972f57e2ecd243e

To start an xterm in my startup sequence, I have
/usr/X11/bin/xterm -title "XTerm (darwinports)" +nul +dc +cm -rightbar -tn 
xterm-256color -geometry 132x55+40+35 -ls -hc yellow1 -sb -sl 5000 -bc -cr blue 
-ms red -j +ah -bw 0 -pc -b 4 -fa "Bitstream Vera Sans Mono" -fb "Bitstream 
Vera Sans Mono Bold" -fs 9 -u8&

The size value is honored, but the orientation is always 0+0.

Finally, I am replying from my office computer which is also a G5 (but 
one year older).  On that machine with everything the same as home--even 
an rsync of /usr/X11 and /A/U/X11.app from home), the problem does not 
show up (so far, at least).  And then I ran MD5 on quartz-wm.  The one 
on my office machine has dd56c0db0274e8debd013dab1178e2a6 which is not 
the same as home.  I wish I had checked the date on the home version.
The office quartz-wm is
-rwxr-xr-x 1 root wheel 181492 2008-09-04 18:05 /usr/bin/quartz-wm
so I assume that a new quartz-wm was in the install package I ran at 
home.


Wed, 12 Nov 2008 (08:28 -0800 UTC) Jeremy Huddleston wrote:

>
>  On Nov 12, 2008, at 06:56, robert delius royar wrote:
> 
> >  Tue, 11 Nov 2008 (21:26 -0800 UTC) Jeremy Huddleston wrote:
> > 
> > >  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
> > 
> >  I am seeing the same thing with xterm 237 (self compiled with the 
> >  configuration
> >  ./configure --enable-wide-chars --enable-256-color \
> >   --with-terminal-type=xterm-256color --enable-dabbrev \
> >   --prefix=/usr/X11 --enable-mini-luit --enable-toolbar \
> >   --with-X --with-Xaw3d CC=/usr/bin/gcc-4.2 ).
> > 
> >  The program flashes open at its requested geometry location then 
> >  disappears and returns to 0,0.  I see this in any xterm I open.
>
>  Even with the one that comes with 2.3.2_beta3?
> 
> ~   $ which xterm
>  /usr/X11/bin/xterm
> 
> ~   $ gmd5sum /usr/X11/bin/xterm
>  5afb0c7d50f868a4451dcd7799e8adb4  /usr/X11/bin/xterm
> 
> ~   $ gmd5sum /usr/bin/quartz-wm
>  c612da09f845b4cde972f57e2ecd243e  /usr/bin/quartz-wm
> 
> ~   $ xterm -geometry 80x24-0+0
>
>  Works for me... =/
> 
> >  I have some processes that start automatically at X11 initial startup 
> >  which are set to begin iconified.  When I de-iconify those xterms or 
> >  XEmacs processes for the first time later in a session, they open where 
> >  their initial geometry settings requested.  The initial geometry was 
> >  provided as a command-line parameter.
>
>  Hmm...
> 
> >  Perhaps I need some additional Xresource values to fix this?
>
>  I doubt it... it's probably a quartz-wm bug.
> 
> >  I also see this with a 21.5.beta28 (latest hg sources) XEmacs.
>
>  Why the heck is this working for me then... hmm... can you check the md5sum
>  of your xterm and quartz-wm...
> 
> >  Finally, I use fspanel.  It now obscures the OS X dock, but other X11 
> >  windows do not.
> > 
> >  fspanel is set to remain in the X foreground.  I suspect that looking at 
> >  the code might help discover where the problem came in.  I have a modified 
> >  version of fspanel which does not support separate desktops. But I did not 
> >  modify the sections that keep it foregrounded.
>
>  It was a bug that it didn't obscure the dock.  That bug is now fixed, so it
>  does obscure the dock.  X layers are now properly translated to OSX layers
>  like they were in Tiger.
> 
>

-- 
Dr. Robert Delius Royar <r.royar at morehead-st.edu>
Associate Professor of English, Morehead State University