Mail Archives: cygwin/2010/08/28/11:50:48
On 8/28/2010 10:31 AM, Reini Urban wrote:
> 2010/8/27 Charles Wilson:
>> Obviously git and
>> python-idle both work with X (on linux) so it's doable to convert --
>> just a nuisance.
>
> A big nuisance in my eyes.
> Why do I have to start a xserver, when I can use native fast small GDI?
Why do you have to start cygserver (for posix IPC), when you can use
native fast small named pipes, or native fast small shared memory?
Either tcl/tk is actually ported to cygwin, or it isn't. When compiled
as it currently is, internally tcl/tk is a hybrid monster: this is
actually a bug in tcl/tk. It conflates the concept of "display
technology" with "runtime support". So, when you compile for "GDI" you
also get "I like C:/foo paths" and other native-win32-ness -- BUT it
isn't actually a native win32 app/lib, because it ALSO uses the cygwin
runtime.
It just uses it wrong.
But, it was always just a stop-gap, quick-n-dirty "port". It "worked"
-- enough that GDB/insight DTRT, at least. When it is used by other
clients, technically -- AFAIK -- it isn't actually supported. But there
are sharp edges in this unhappy marriage of GDI, native win32 calls, and
the cygwin runtme.
So, the right answer is a "real" port of tcl/tk. There are two ways to
do this:
1) just compile it like you would on unix. Then, you get X11, not GDI
-- but you also avoid all the other win32isms. This will "just work";
recompile with the "correct" options and you're golden.
2) disentagle all the assumptions in the tcl/tk code between
"windowing system" and "win32ness as it relates to non-windowing code".
This is a BIG job, and NOBODY wants to do it.
okay, so: 3) or...status quo with a mostly working, two year old
pseudo port, with some sharp edges...
During a previous discussion, the list consensus was that X11 /would/
have been fine, BUT at the time we didn't actually have a maintained
Xserver since the previous maintainer left, and our current maintainers
had not yet stepped forward. Now, though, our X server is well
maintained and works very well...so that reason no longer applies.
The only /technical/ barrier now is that in some security-locked-down
environments, non-Admin's cannot grant permission to applications to
open a networking port. Since on cygwin, even unix domain sockets are
emulated using networking ports, AND because the Xserver /will not work/
without that unix socket being opened...you can't run an Xserver in
those environments, which means you wouldn't be able to run insight,
gitk, etc etc.
Then there's the pain involved in coordinating the switch with other
maintainers of tcltk clients, and the existing higher-priority demands
on cgf's time, ... and it just hasn't bubbled to the top.
> The PIPE problem appears elsewhere also, and will be fixed with 1.7.7.
Well, I wasn't pre-cognitively suggesting, last year, that we switch
from GDI to X11 to fix this PIPE problem...
--
Chuck
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -