Re: [Xquartz-dev] geometry regression in 2.3.2-beta3
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. 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. Perhaps I need some additional Xresource values to fix this? I also see this with a 21.5.beta28 (latest hg sources) XEmacs. 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. -- Dr. Robert Delius Royar <r.royar@morehead-st.edu> Associate Professor of English, Morehead State University
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.
participants (2)
-
Jeremy Huddleston
-
robert delius royar