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
