Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 05/04/2012 16:54, Eliot Moss wrote:
Something seems to have changed between the last 1.11 release and
the 1.12.0 (up through the 1.12.0-2 release made yesterday).
Thanks for testing!
The window for StartXWin, which is minimized, did not previously
result in an X icon in the taskbar, but now does, and it is
distinct from the stack of X icons for my several launched
xterms. I feel it is clutter and want to suppress it, but I
don't know how at this point.
I guess the window you are seeing is the terminal window in which bash is
being run? It's the job of the run command to hide that window, and why it
should suddenly stop doing so when the XWin at the bottom of the process tree
changes, I have no idea.
This might perhaps be related to a bug in cygwin 1.7.12 where cygwin
executables were wrongly handled as native, non-cygwin executables?
Separately, going from 1.12.0-1 to 1.12.0-2 changed my xemacs
icon, to one that is nearly transparent (there's something
there, but very hard to discern). In the past xemacs gave
its own icon (which I could never find or override).
Thanks for pointing this out. I'd introduced a couple of bugs into the
fallback icon conversion code for a bitmap pointed to by WM_HINTS (which is
only used when a NET_WM_ICON property isn't present)
I've applied a couple of fixes, so hopefully this works better now. I've
uploaded a snapshot at [2]. Perhaps you could try that out and see if that
improves things for you?
I suspect that the 'XE' icon from
/usr/share/xemacs-21.4.22/etc/xemacs-icon.xpm is baked into the Xemacs
executable. If Xemacs itself doesn't provide a way to change it, you could
override it for multiwindow mode by using the ICONS directive in XWinrc.
xemacs -T xemacs-n xemacs-name xemacs1
STYLES {
console MINIMIZE
Eliot MINIMIZE
xemacs1 MINIMIZE
}
These various commands / files all seem to be seen and used. And by the way,
the xemacs1 MINIMIZE does not seem to work -- it always starts maximized and I
have to minimize it manually. Hints on that?
Using -name to set the xemacs resource name does not set the window class
name, apparently by design [1], so this style directive will not match the
window title or window class name of your xemacs window.
Fortunately, you could probably achieve the same effect by adding the
'-iconic' command line option to the xemacs invocation.
On 05/04/2012 17:11, Eliot Moss wrote:
On xorg-server 1.12.0-2, doing
a reload of .XWinrc via the .XWinrc menu cases an
exception that kills the X server. I does put up
an error window saying what happened (a
segmentation fault).
This was also related to the icon conversion changes and should be fixed in
the latest snapshot.
[1] http://www.nada.kth.se/cgi-bin/info?%28xemacs-faq.info%29Q3.1.7
[2] ftp://cygwin.com/pub/cygwinx/XWin.20120406-git-b309f093d6e90201.exe.bz2
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Problems with emacs built with gsettings support [was: Problems with emacs built against gtk3]
On 4/4/2012 6:12 PM, Yaakov (Cygwin/X) wrote:
On 2012-04-04 09:15, Ken Brown wrote:
Another option is to use gtk3 but to put the GSETTINGS_BACKEND
workaround into the emacs startup code:
setenv (GSETTINGS_BACKEND, memory, 1);
I've been testing this, and it seems to work (but I won't be completely
confident until I've had emacs running for a day or so). Do you see any
downside?
This is intended solely for testing and debugging. Settings will not be
saved from one invocation to the next, so that's a pretty big downside.
OK, that was a bad idea. I'm going to try to debug this problem.
I was wrong when I said that the problem doesn't occur with gtk2. I
based that statement on earlier tests; but I did those tests several
months ago, when I started this thread, and I probably didn't have
dconf-service installed at the time. Now I can reproduce the problem
with both gtk2 and gtk3. But the problem doesn't occur if I build emacs
with the configure option --without-gsettings. I've changed the subject
line accordingly.
By the way, emacs (starting with emacs-24) will use both GSettings and
GConf if they're available. But there doesn't appear to be any problem
using GConf alone.
Here's my most recent debugging session. This is from a build using
gtk2 and GSettings (but not GConf):
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
[...]
Reading symbols from /home/kbrown/src/emacs/test/src/emacs...done.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/test/src/emacs -Q
[New Thread 12220.0x950]
[...]
[New Thread 12220.0x330c]
Program received signal SIGSEGV, Segmentation fault.
0x00289d7a in ?? ()
(gdb) bt full
#0 0x00289d7a in ?? ()
No symbol table info available.
#1 0x007bd264 in __morecore ()
No symbol table info available.
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
#2 0x0001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
wsock_started = true
wsadata = {wVersion = 514, wHighVersion = 514,
szDescription = WinSock 2.0, '\000' repeats 245 times,
szSystemStatus = Running, '\000' repeats 121 times,
iMaxSockets = 0, iMaxUdpDg = 0, lpVendorInfo = 0x0}
#3 0x00606175 in calloc (nmemb=4294867296, size=8) at gmalloc.c:1547
result = 0x0
#4 0x in ?? ()
No symbol table info available.
This looks very strange to me, especially the part about WinSock. Where
could that have come from?
Here are the steps for reproducing the problem:
1. Install the following packages and their dependencies:
gnutls-devel
libdbus1-devel
libdbus1_3
libgif-devel
libgtk2.0-devel
libgtk3-devel
libMagick-devel
libMagickCore5
librsvg2-devel
libSM-devel
libXpm-devel
[These might not all be necessary for reproducing the problem, but
they're used in my build or as runtime dependencies of my build.]
2. Build emacs with GSettings support but not GConf support:
wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.95.tar.gz
tar -xf emacs-24.0.95.tar.gz
cd emacs-24.0.95
./configure --without-gconf make
[Note: By default, the build will use gtk2. The option
--with-x-toolkit=gtk3 will make it use gtk3.]
3. Start the X server using the Start Menu shortcut, with no ~/.startxwinrc.
4. In the resulting xterm window:
eval `dbus-launch --sh-syntax`
cd emacs-24.0.95/src
./emacs -Q
5. Ignore emacs; it will eventually crash. This could take one or more
hours, but it happens every time on my system. It happens much faster
if I don't disable GConf support.
It would be extremely helpful if someone could try to reproduce this.
At the very least, I'd like to rule out the possibility that it's caused
by BLODA on my system.
Ken
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Problems with emacs built with gsettings support [was: Problems with emacs built against gtk3]
Hi Ken, Ken Brown wrote: Now I can reproduce the problem with both gtk2 and gtk3 If you remember I flagged this on 24.11.2011 with a private mail. After the upgrading to GNOME 3.2, not only the gtk3 build was unstable but also the old gtk2 builds were unstable... Since then I am using this target C:\cygwin-2\bin\run.exe bash -l -c 'GSETTINGS_BACKEND=memory emacs -display 127.0.0.1:0.0 2/dev/null ' to start Emacs from a link on desktop, and it works both with gtk2 and with gtk3 builds. Notice, I do not use Cygwin service (dbus,... etc.) Any way I will try to follow your recipe to reproduce the problem, but I am sure it is still there.. Here are the steps for reproducing the problem: Ciao, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 4/6/2012 1:01 PM, Jon TURNEY wrote: On 05/04/2012 16:54, Eliot Moss wrote: Something seems to have changed between the last 1.11 release and the 1.12.0 (up through the 1.12.0-2 release made yesterday). The window for StartXWin, which is minimized, did not previously result in an X icon in the taskbar, but now does, and it is distinct from the stack of X icons for my several launched xterms. I feel it is clutter and want to suppress it, but I don't know how at this point. I guess the window you are seeing is the terminal window in which bash is being run? It's the job of the run command to hide that window, and why it should suddenly stop doing so when the XWin at the bottom of the process tree changes, I have no idea. Yes, which is why I, too, was surprised. This might perhaps be related to a bug in cygwin 1.7.12 where cygwin executables were wrongly handled as native, non-cygwin executables? I just installed 1.7.13, and the behavior is still there. It goes away when something completes, which happens when all the windows started by .startxwinrc are gone. If I kill it, then all those initial windows die. Perhaps this is all normal, *except* that the run window is displayed. Separately, going from 1.12.0-1 to 1.12.0-2 changed my xemacs icon, to one that is nearly transparent (there's something there, but very hard to discern). In the past xemacs gave its own icon (which I could never find or override). Thanks for pointing this out. I'd introduced a couple of bugs into the fallback icon conversion code for a bitmap pointed to by WM_HINTS (which is only used when a NET_WM_ICON property isn't present) I've applied a couple of fixes, so hopefully this works better now. I've uploaded a snapshot at [2]. Perhaps you could try that out and see if that improves things for you? Yes! Now the xemacs icon is back to the way it used to be. I suspect that the 'XE' icon from /usr/share/xemacs-21.4.22/etc/xemacs-icon.xpm is baked into the Xemacs executable. If Xemacs itself doesn't provide a way to change it, you could override it for multiwindow mode by using the ICONS directive in XWinrc. Maybe; if I find one I like :-) ... These various commands / files all seem to be seen and used. And by the way, the xemacs1 MINIMIZE does not seem to work -- it always starts maximized and I have to minimize it manually. Hints on that? Using -name to set the xemacs resource name does not set the window class name, apparently by design [1], so this style directive will not match the window title or window class name of your xemacs window. Fortunately, you could probably achieve the same effect by adding the '-iconic' command line option to the xemacs invocation. Actually, -iconic does not work; neither does it work to set the iconic resource to true. Seems to be an xemacs thing. In fact, here is a quote from the FAQ: Ugh, this stuff is such an incredible mess that I've about given up getting it to work. The principal problem is numerous window-manager bugs... However, I find that the .XWinrc MINIMIZE style *does* work ... but of course only for windows I create later. And the class name is emacs, not xemacs, hence a STYLE entry of: emacs MINIMIZE ... Does this suggest to you any other way that might work to get an iconified xemacs from the .startxwinrc file? On 05/04/2012 17:11, Eliot Moss wrote: On xorg-server 1.12.0-2, doing a reload of .XWinrc via the .XWinrc menu cases an exception that kills the X server. I does put up an error window saying what happened (a segmentation fault). This was also related to the icon conversion changes and should be fixed in the latest snapshot. That is indeed now fixed. Thanks for all the fixes! E [1] http://www.nada.kth.se/cgi-bin/info?%28xemacs-faq.info%29Q3.1.7 [2] ftp://cygwin.com/pub/cygwinx/XWin.20120406-git-b309f093d6e90201.exe.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
