X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Message-ID: <4C793018.7030005@cwilson.fastmail.fm>
Date: Sat, 28 Aug 2010 11:49:44 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
References: <20100827182230 DOT 8007 DOT qmail AT web4111 DOT mail DOT ogk DOT yahoo DOT co DOT jp>	<AANLkTinVuCaQvBs-ENXDpF5Qk6Xu4dfdrrg3rhcOspwG AT mail DOT gmail DOT com>	<4C781218 DOT 20004 AT cwilson DOT fastmail DOT fm> <AANLkTinRHi3hKBViNo5bszm5=brVhLX_cpbv6eG=yT32 AT mail DOT gmail DOT com>
In-Reply-To: <AANLkTinRHi3hKBViNo5bszm5=brVhLX_cpbv6eG=yT32@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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