Re: Emacs as a desktop environment

[Stephen J. Turnbull]

Ulrich Mueller writes:

 > There hasn't been much activity on the GTK+ bug in the last 5 years.
 > I really wonder why they aren't interested in fixing this.

Why wonder?  You obviously "do" free software, you *could* fix it
(possibly at very high cost to yourself[1]).  If you don't care enough
to fix it yourself, is it really that surprising that they don't?
Clearly, they itch there even less than you do, so they're scratching
something else.

<topical state="on">
Kudos to the Emacs community for caring so much about That Other Guy's
Bugs, and fixing them!
</topical>

Footnotes: 
[1]  Although sometimes it's surprisingly easy.  AFAIK X.org's
"nonblocking mode" _XtWaitForSomething() still can block.  But it took
me less than 15 minutes to interrupt the infloop, locate that function
in the gdb backtrace, download the source, trace the code and realize
there were a minimum of two ways to block in that loop, and verify it.
Another ten minutes to find out where to submit a patch that fixed
both for my purposes, and do it.  I guess the patch was suboptimal;
AFAIK it never was applied. :-/  MacPorts fixed the problem in their
build of Xlib by using select() instead of poll(), so I don't much
care any more.

Hell, I wouldn't even be surprised if the GTK+ bug is related to this
one, since in both cases you're multiplexing on fds.  I wouldn't bet
you can find that relationship in 15 minutes, though. :-)