Updated Tcl Tk and Tix

Updated Tcl Tk and Tix

[Mike Clarkson]

Now that a recent version of Tcl Tk and Tix are available for
CYGWIN, could the current distribution get updated to 8.3.4,
and could Python be recompiled against it?

See:

    ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/

[unknown@ITSWINME /usr/lib]$ python2.2
Python 2.2 (#1, Dec 31 2001, 15:21:18)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> root = Tkinter.Tk()
>>> root.tk.eval('set tk_version')
'8.0'
>>>

Many thanks,

Mike.

(PS: please reply by email as I am not subscribed to the lists.)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Mumit Khan]

On Fri, 7 Jun 2002, Mike Clarkson wrote:

> Now that a recent version of Tcl Tk and Tix are available for
> CYGWIN, could the current distribution get updated to 8.3.4,
> and could Python be recompiled against it?
>
> See:
>
>     ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/
>

Someone will have to build and maintain the packages, and so far the
few people who I had asked have declined. Anyone?

In case someone is willing to contribute the packages with updated
Tcl/Tk/BLT/Tix/etc, I should point out that there are quite a few
differences from Cygwin Tcl/Tk tree:

1. The DLLs/executables don't have cyg prefix.

2. I haven't made some of the path related modifications that Cygwin
(basically the former Cygnus tree) makes such as installing the Tcl/Tk
files into datadir instead of stock Tcl's libdir.

3. None of the dejagnu tests are in my tree.

4. Various other infrastructure items that are normally in Cygnus
tree.

5. Various changes to defaults such as fonts etc (lots of it in Tix)
that are specific to Cygnus tree.

My goal is minimum deviation from release trees.

Regards,
Mumit



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Nicholas Wourms]

> 
> Someone will have to build and maintain the packages, and so far the
> few people who I had asked have declined. Anyone?
> 
> In case someone is willing to contribute the packages with updated
> Tcl/Tk/BLT/Tix/etc, I should point out that there are quite a few
> differences from Cygwin Tcl/Tk tree:
> 
> 1. The DLLs/executables don't have cyg prefix.
> 
> 2. I haven't made some of the path related modifications that Cygwin
> (basically the former Cygnus tree) makes such as installing the Tcl/Tk
> files into datadir instead of stock Tcl's libdir.
> 
> 3. None of the dejagnu tests are in my tree.
> 
> 4. Various other infrastructure items that are normally in Cygnus
> tree.
> 
> 5. Various changes to defaults such as fonts etc (lots of it in Tix)
> that are specific to Cygnus tree.
> 
> My goal is minimum deviation from release trees.
> 
Mumit,

Chuck and I were just discussing this and we came up with some
observations:

1)This package is way to big for one person to do alone.  I'm sure someone
might me more receptive to the idea if you were still involved (which
isn't clear from your message as to whether you would be).

2)It probably would be best to wait until the new gcc-3.1 and binutils
release comes out (any day now?).

3)The big question: right now (and in the future) the cygwin tk/tcl build
will be mingw-ish (native windowing, not X windowing). Red Hat won't want
to force its GNUpro customers to use a Xserver just to run gdb.  So, what
*we* -- the net users -- really want is TWO tk/tcl's:  one that uses
mingw/w32api, and another one that uses posix api/paths and whose tk uses
X11R6.

4)This will take a lot of time, discussion, planning, and implementation.

I'd be willing to help, but unfortunately I have a few other projects on
my plate, so there is no way I want to tackle that by myself, though I
suspect that #3 could be fixed by removing os-centric defines and
replacing with feature-centric defines (eg. -DUSE_POSIX_PATHS).  Chuck
suggested not to stir up discussion on this, so until #2 is satisfied,
I'll leave it at that.

Cheers,
Nicholas


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Mumit Khan]

On Fri, 7 Jun 2002, Nicholas Wourms wrote:

> Chuck and I were just discussing this and we came up with some
> observations:
>
> 1)This package is way to big for one person to do alone.  I'm sure someone
> might me more receptive to the idea if you were still involved (which
> isn't clear from your message as to whether you would be).

As I mention it the README file provided with the patched Tcl/Tk, I simply
can't support it. The only reason I put it up for ftp is to make it
available for those who may need it. I can provide explanations for the
changes, but that's about it.

It's actually not that large -- the changes are usually quite
self-explanatory, and most of these changes have been in Cygwin's tcl/tk
releases from a long time (days of Ian Taylor and others hacking on Source
Navigator, and probably from even before that).

You'll notice that only Tcl has some non-trivial changes -- the rest of
the packages just needed configuration tweaks to build under Cygwin.

> 2)It probably would be best to wait until the new gcc-3.1 and binutils
> release comes out (any day now?).

I don't see why gcc-3.1 and a newer binutils release is relevant here.

> 3)The big question: right now (and in the future) the cygwin tk/tcl build
> will be mingw-ish (native windowing, not X windowing). Red Hat won't want
> to force its GNUpro customers to use a Xserver just to run gdb.  So, what
> *we* -- the net users -- really want is TWO tk/tcl's:  one that uses
> mingw/w32api, and another one that uses posix api/paths and whose tk uses
> X11R6.

There's probably just a handful of people using the XFree version of Tk
under Cygwin, and that's one of the reasons I never bothered to add it
to the configuration. I did do that a long time ago when I needed it for
the just the reason you mention. If you want to try this, here's a
starting point: Use --with-x when configuring; cd into the Unix directory
when you see --with-x specified, and build everything without -mwin32.
There needs to be a few other tweaks, but that's really the big part of
it. In a sense, we use the two Cygwin "personalities" -- a POSIX layer
with X11, and a POSIX layer with Windows GDI.

> 4)This will take a lot of time, discussion, planning, and implementation.

Given the very small number of users using X11 enabled Tk, I don't see why
this should hold up a package release for updated Tcl/Tk/etc. Assuming
someone steps forward as the package maintainer, the rest of it can be
added over time.

> I'd be willing to help, but unfortunately I have a few other projects on
> my plate, so there is no way I want to tackle that by myself, though I
> suspect that #3 could be fixed by removing os-centric defines and
> replacing with feature-centric defines (eg. -DUSE_POSIX_PATHS).  Chuck
> suggested not to stir up discussion on this, so until #2 is satisfied,
> I'll leave it at that.

I would first wait for a package maintainer(s) to take over, and then deal
with the rest of the issues as they come up.

Regards,
Mumit



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Christopher Faylor]

On Sun, Jun 09, 2002 at 07:08:05PM -0500, Mumit Khan wrote:
>I would first wait for a package maintainer(s) to take over, and then deal
>with the rest of the issues as they come up.

That would be me.  I'll release 8.3 versions of tcl/tk when the issues with
the 8.3 sources on sources.redhat.com have been resolved.

I've previously mentioned that there are apparently some strange issues with
tk and insight that are being (very slowly) tracked down.

In the meantime, if anyone is burning to have a cygwin 8.3 version of
tcl/tk, they can build it from the sources on sources.redhat.com.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[S. L.]

[...]
> > 3)The big question: right now (and in the future) the cygwin tk/tcl
> build
> > will be mingw-ish (native windowing, not X windowing). Red Hat won't
> want
> > to force its GNUpro customers to use a Xserver just to run gdb.  So,
> what
> > *we* -- the net users -- really want is TWO tk/tcl's:  one that uses
> > mingw/w32api, and another one that uses posix api/paths and whose tk
> uses
> > X11R6.
> 
> There's probably just a handful of people using the XFree version of Tk
> under Cygwin, and that's one of the reasons I never bothered to add it
> to the configuration. I did do that a long time ago when I needed it for
> the just the reason you mention. If you want to try this, here's a
> starting point: Use --with-x when configuring; cd into the Unix directory
> when you see --with-x specified, and build everything without -mwin32.
> There needs to be a few other tweaks, but that's really the big part of
> it. In a sense, we use the two Cygwin "personalities" -- a POSIX layer
> with X11, and a POSIX layer with Windows GDI.
[...]

I cannot keep from replying.
While Mumit, "silently" just states the POSIX as a de facto relation with
"his" (SIC! :) tcl/tk, ignoring any diversion, in Nicholas' message there is
still confusion. This confusion is motivated by the actual state of tcl/tk
distributed with cygwin. Which is a mingw application.
So, for the cygwin sake I would just point here that the first case Nicholas
presents, i.e. :

"TWO tk/tcl's:  one that uses mingw/w32api,"

it's OT. Given the fact that the nowadays "official" tcl/tk distributed with
cygwin needs quite a lot of hack to be usable from cygwin applications, I
would say that the net users need a tcl/tk that uses cygwin/w32api, a POSIX
layer, _and_ which is "autotools enabled".

SLao

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Nicholas Wourms]

> > There's probably just a handful of people using the XFree version of
> Tk
> > under Cygwin, and that's one of the reasons I never bothered to add it
> > to the configuration. I did do that a long time ago when I needed it
> for
> > the just the reason you mention. If you want to try this, here's a
> > starting point: Use --with-x when configuring; cd into the Unix
> directory
> > when you see --with-x specified, and build everything without -mwin32.
> > There needs to be a few other tweaks, but that's really the big part
> of
> > it. In a sense, we use the two Cygwin "personalities" -- a POSIX layer
> > with X11, and a POSIX layer with Windows GDI.
> [...]

Mumit,

The reason there is only a handful of people using this is because this
functionality hasn't really been advertised as being available.  I'm sure
that this can be fixed by minor modifications to the Makefile.am /
configure.in based on you recommendations.  Since you did do this awhile
back, can you post (on your website) your modifications?  The biggest
issue I had is not with TK but with TCL using Windows paths as opposed to
POSIX paths.  This breaks the test scripts on an number of packages, for
example the berkeley db.  How would you propose dealing with this issue,
short of having to modify every tcl script that uses POSIX paths?  As for
why wait until GCC 3.1 point, that was a comment made by Chuck, so I'll
let him explain that if he cares to.

 
> I cannot keep from replying.
> While Mumit, "silently" just states the POSIX as a de facto relation
> with
> "his" (SIC! :) tcl/tk, ignoring any diversion, in Nicholas' message
> there is
> still confusion. This confusion is motivated by the actual state of
> tcl/tk
> distributed with cygwin. Which is a mingw application.
> So, for the cygwin sake I would just point here that the first case
> Nicholas
> presents, i.e. :
> 
> "TWO tk/tcl's:  one that uses mingw/w32api,"
> 
> it's OT. Given the fact that the nowadays "official" tcl/tk distributed
> with
> cygwin needs quite a lot of hack to be usable from cygwin applications,
> I
> would say that the net users need a tcl/tk that uses cygwin/w32api, a
> POSIX
> layer, _and_ which is "autotools enabled".

S.L.,

Now you've confused me, I'm not sure what you are getting at here... Why
is what I'm saying off topic?  The tcl/tk suite that uses mingw/w32api is
already distributed in the mainline distribution.  The point I was making
is the same one you summerized in the end, we need an autotools enabled
tcltk suite which generates both a Win32api and POSIX versions.  To
further elaborate, maybe the Win32 libraries ought to reside in the
win32api directory with it's own version of {Tk Tcl}Config.sh residing
there, too.  Perhaps wrapper scripts could be used, in the same manner as
autotools, to determine which binaries/configs should be used.  In any
event, this is just my take on some of the things which I've discussed
with other people.

Cheers,
Nicholas


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Mumit Khan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2426 bytes --]

On Mon, 10 Jun 2002, Nicholas Wourms wrote:

> The reason there is only a handful of people using this is because this
> functionality hasn't really been advertised as being available.  I'm sure
> that this can be fixed by minor modifications to the Makefile.am /
> configure.in based on you recommendations.  Since you did do this awhile
> back, can you post (on your website) your modifications?  The biggest
> issue I had is not with TK but with TCL using Windows paths as opposed to
> POSIX paths.  This breaks the test scripts on an number of packages, for
> example the berkeley db.  How would you propose dealing with this issue,
> short of having to modify every tcl script that uses POSIX paths?  As for
> why wait until GCC 3.1 point, that was a comment made by Chuck, so I'll
> let him explain that if he cares to.

Hi Nicholas,

I dug up my old patches, but those are not quite relevant anymore as most
of those changes are unnecessary due to fixes to configuration since. I'm
attaching a quick patch against stock Tcl 8.3.4 (no changes for Tk needed)
to build under Cygwin as a "Unix" host using X11. Less than 10 lines of
changes, but it doesn't do dynamic loading, shared libraries, etc. Left as
an excercise for the interested ;-)

The lack of POSIX paths is simply due to a bug in Cygwin's Tcl/Tk. I'll
post a fix relative to Cygwin Tcl/Tk sources hopefully soon (these are
in my sources, so someone in need could potentially pick it up from
there). If that's the major reason, I recommend staying with a version
of Tcl/Tk that uses Windows API to be closer to the Cygwin supplied ones,
after fixing the problem(s). The only item I didn't fix is mentioned in
my README (can't remember off-hand what that is). One of the reason that
this wasn't in a long time ago is because of ancient bug in relative
pathname handling in cygwin, and cgf fixed that a *long* time ago.

I'm not sure how to respond to the post by S.L, who for some reason thinks
that Cygwin's Tcl/Tk are in reality Mingw applications.

Don't know if this helps your problem at all, but it reaffirm how easy
it is to port a Unix application to Cygwin. The hack I added for timezone
mess should be moved elsewhere and done better. The change in
tclUnixChan.c is to work around the old lseek bug, which may or may not be
fixed by now.

After applying the fixes, you build it just like you would on a Unix host
with X11 installed.

Regards,
Mumit


[-- Attachment #2: Cygwin/xfree changes for Tcl/Tk 8.3.4 --]
[-- Type: TEXT/PLAIN, Size: 3164 bytes --]

Quick hack to get Cygwin/xfree version of Tcl/Tk 8.3.4. This patch is
against the *official* release tree.

2002-06-10  Mumit Khan  <khan@nanotech.wisc.edu>
	* generic/tcl.h: Don't define _WIN32 for Cygwin, let -mwin32 do
	it instead.
	* generic/tclClock.c (timezone): Cygwin specific hack.
	* unix/tclUnixChan.c (TclpGetDefaultStdChannel): Work around Cygwin
	lseek bug.

Index: generic/tcl.h
===================================================================
RCS file: /home/cvsroot/tcltk8.3/tcl/generic/tcl.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 tcl.h
--- generic/tcl.h	2002/04/02 03:49:23	1.1.1.1
+++ generic/tcl.h	2002/06/11 03:52:24
@@ -70,7 +70,7 @@ extern "C" {
  */
 
 #ifndef __WIN32__
-#   if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__) || defined(__MINGW32__) || defined(__BORLANDC__)
+#   if defined(_WIN32) || defined(WIN32) || defined(__MINGW32__) || defined(__BORLANDC__)
 #	define __WIN32__
 #	ifndef WIN32
 #	    define WIN32
Index: generic/tclClock.c
===================================================================
RCS file: /home/cvsroot/tcltk8.3/tcl/generic/tclClock.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 tclClock.c
--- generic/tclClock.c	2002/04/02 03:49:23	1.1.1.1
+++ generic/tclClock.c	2002/06/11 03:52:25
@@ -18,6 +18,10 @@
 #include "tclInt.h"
 #include "tclPort.h"
 
+#ifdef __CYGWIN__
+# define timezone _timezone
+#endif
+
 /*
  * The date parsing stuff uses lexx and has tons o statics.
  */
Index: unix/tclUnixChan.c
===================================================================
RCS file: /home/cvsroot/tcltk8.3/tcl/unix/tclUnixChan.c,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 tclUnixChan.c
--- unix/tclUnixChan.c	2002/04/02 03:49:22	1.1.1.1
+++ unix/tclUnixChan.c	2002/06/11 03:52:36
@@ -2452,10 +2452,17 @@ TclpGetDefaultStdChannel(type)
     int fd = 0;			/* Initializations needed to prevent */
     int mode = 0;		/* compiler warning (used before set). */
     char *bufMode = NULL;
+#ifdef __CYGWIN__
+    struct stat statBuf;
+#endif
 
     switch (type) {
         case TCL_STDIN:
+#ifdef __CYGWIN__
+            if ((fstat(0, &statBuf) == -1) &&
+#else
             if ((lseek(0, (off_t) 0, SEEK_CUR) == -1) &&
+#endif
                     (errno == EBADF)) {
                 return (Tcl_Channel) NULL;
             }
@@ -2464,7 +2471,11 @@ TclpGetDefaultStdChannel(type)
             bufMode = "line";
             break;
         case TCL_STDOUT:
+#ifdef __CYGWIN__
+            if ((fstat(1, &statBuf) == -1) &&
+#else
             if ((lseek(1, (off_t) 0, SEEK_CUR) == -1) &&
+#endif
                     (errno == EBADF)) {
                 return (Tcl_Channel) NULL;
             }
@@ -2473,7 +2484,11 @@ TclpGetDefaultStdChannel(type)
             bufMode = "line";
             break;
         case TCL_STDERR:
+#ifdef __CYGWIN__
+            if ((fstat(2, &statBuf) == -1) &&
+#else
             if ((lseek(2, (off_t) 0, SEEK_CUR) == -1) &&
+#endif
                     (errno == EBADF)) {
                 return (Tcl_Channel) NULL;
             }

[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[S. L.]

[...]
> I'm not sure how to respond to the post by S.L, who for some reason thinks
> that Cygwin's Tcl/Tk are in reality Mingw applications.
[...]

Mumit,

Okok, I must admit now, that doing a cygcheck on .exes and .dlls of tcl/tk
package, they all depend on cygwin1.dll, but only because of cygtcl80.dll
dependency, i.e.: 

$ cygcheck c:/cygwin/bin/cygwish80.exe
c:/cygwin/bin/cygwish80.exe
  c:/cygwin/bin\cygtcl80.dll
    c:/cygwin/bin\cygwin1.dll
      C:\WIN\SYSTEM\KERNEL32.dll
    C:\WIN\SYSTEM\USER32.dll
      C:\WIN\SYSTEM\GDI32.dll
        C:\WIN\SYSTEM\ADVAPI32.dll
  c:/cygwin/bin\cygtk80.dll
    C:\WIN\SYSTEM\COMDLG32.DLL
      C:\WIN\SYSTEM\SHLWAPI.dll
      C:\WIN\SYSTEM\COMCTL32.dll
      C:\WIN\SYSTEM\SHELL32.dll

$ cygcheck c:/cygwin/bin/cygtk80.dll  
c:/cygwin/bin/cygtk80.dll
  c:/cygwin/bin\cygtcl80.dll
    c:/cygwin/bin\cygwin1.dll
      C:\WIN\SYSTEM\KERNEL32.dll
    C:\WIN\SYSTEM\USER32.dll
      C:\WIN\SYSTEM\GDI32.dll
        C:\WIN\SYSTEM\ADVAPI32.dll
  C:\WIN\SYSTEM\COMDLG32.DLL
    C:\WIN\SYSTEM\SHLWAPI.dll
    C:\WIN\SYSTEM\COMCTL32.dll
    C:\WIN\SYSTEM\SHELL32.dll

This leads to a incapacity of GUI applications (wish, itkwish, tix) to work
with POSIX paths in their widgets (I must launch vtcl with a command like
"HOME=c:/cygwin/home/user cygwish80 c:/place/where/is/vtcl" to have my .vtclrc
preferences loaded). Which is not the case with your tcl/tk.
And also remains fact that the great majority of apps that come with tk
GUIs, are unable to build using the "./configure" steps, for the 8.0 tcltk
package (the "official" cygwin one).

Thanks anyway for your versions,

SLao

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[S. L.]

[...]
> Now you've confused me, I'm not sure what you are getting at here... Why
> is what I'm saying off topic?  The tcl/tk suite that uses mingw/w32api is
> already distributed in the mainline distribution.  The point I was making
[...]

You're right about tcl/tk "mingw/w32api", but I'd consider that package
(20001125) as an example of "how must not be provided" cygwin packages.

[...]
> is the same one you summerized in the end, we need an autotools enabled
> tcltk suite which generates both a Win32api and POSIX versions.  To
> further elaborate, maybe the Win32 libraries ought to reside in the
> win32api directory with it's own version of {Tk Tcl}Config.sh residing
> there, too.  Perhaps wrapper scripts could be used, in the same manner as
[...]

Here the confusion I was talking, rises again. All GUI shells from tcl/tk
suite, would use win32api, wether they are cygwin (POSIX enabled), or mingw.

SLao

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Nicholas Wourms]

--- "S. L." <s_i_lao@gmx.net> wrote:
> [...]
> > Now you've confused me, I'm not sure what you are getting at here...
> Why
> > is what I'm saying off topic?  The tcl/tk suite that uses mingw/w32api
> is
> > already distributed in the mainline distribution.  The point I was
> making
> [...]
> 
> You're right about tcl/tk "mingw/w32api", but I'd consider that package
> (20001125) as an example of "how must not be provided" cygwin packages.

I agree...

> [...]
> > is the same one you summerized in the end, we need an autotools
> enabled
> > tcltk suite which generates both a Win32api and POSIX versions.  To
> > further elaborate, maybe the Win32 libraries ought to reside in the
> > win32api directory with it's own version of {Tk Tcl}Config.sh residing
> > there, too.  Perhaps wrapper scripts could be used, in the same manner
> as
> [...]
> 
> Here the confusion I was talking, rises again. All GUI shells from
> tcl/tk
> suite, would use win32api, wether they are cygwin (POSIX enabled), or
> mingw.
> 

But that leaves us who use XFree out in the dust.  Since XFree is part of
the mainline distribution, we should have XFree support (as well).

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[S. L.]

Nicholas,

[...]
> > Here the confusion I was talking, rises again. All GUI shells from
> > tcl/tk
> > suite, would use win32api, wether they are cygwin (POSIX enabled), or
> > mingw.
> > 
> 
> But that leaves us who use XFree out in the dust.  Since XFree is part of
> the mainline distribution, we should have XFree support (as well).
[...]

As you probably noticed, I avoided to make any reference to X versions of
the tcl/tk suite. This is a X related problem and should be passed to another
list, either xfree or (eventually new?) a xapps one.

SLao

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Nicholas Wourms]

--- "S. L." <s_i_lao@gmx.net> wrote:
> Nicholas,
> 
> [...]
> > > Here the confusion I was talking, rises again. All GUI shells from
> > > tcl/tk
> > > suite, would use win32api, wether they are cygwin (POSIX enabled),
> or
> > > mingw.
> > > 
> > 
> > But that leaves us who use XFree out in the dust.  Since XFree is part
> of
> > the mainline distribution, we should have XFree support (as well).
> [...]
> 
> As you probably noticed, I avoided to make any reference to X versions
> of
> the tcl/tk suite. This is a X related problem and should be passed to
> another
> list, either xfree or (eventually new?) a xapps one.

Again,

You missed the point, but I'm not going to argue it anymore.  FYI, it is
*OK* to discuss X related things on this list, provided it is in the
context of an application which is both Console and X based.  Discussion
of X-related items which uncover a bug in the cygwin dll is also valid on
this list.  A quick scan of the archives would have answered that one for
you...  Making a new list for XFree-apps is just plain dumb... I'm
subscribed to enough lists as it is without having to subscribe to another
one.  I'm sure there are many others who feel the same.

Cheers,
Nicholas
 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Christopher Faylor]

On Tue, Jun 11, 2002 at 11:59:32AM +0200, S. L. wrote:
>[...]
>> Now you've confused me, I'm not sure what you are getting at here... Why
>> is what I'm saying off topic?  The tcl/tk suite that uses mingw/w32api is
>> already distributed in the mainline distribution.  The point I was making
>[...]
>
>You're right about tcl/tk "mingw/w32api", but I'd consider that package
>(20001125) as an example of "how must not be provided" cygwin packages.

The tcltk package in cygwin has some cygwin knowledge but it is not
complete.

Maybe we can stop talking about this now?

If you want to help, check out (via CVS) the tcl/tk 8.3 sources from
sources.redhat.com and offer your help in the insight mailing list for
tracking down problems.

As I said previously, future packages will be based on this.  If you
want to improve things, stop complaining and start contributing.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Charles Wilson]

Christopher Faylor wrote:

> The tcltk package in cygwin has some cygwin knowledge but it is not
> complete.
> 
> Maybe we can stop talking about this now?
> 
> If you want to help, check out (via CVS) the tcl/tk 8.3 sources from
> sources.redhat.com and offer your help in the insight mailing list for
> tracking down problems.
> 
> As I said previously, future packages will be based on this.  If you
> want to improve things, stop complaining and start contributing.


I believe Nicholas DOES want to help -- but was confused as to where to 
start.  He mentioned the idea to me, but I couldn't offer any advice 
except "go to the list" -- because I'm confused too.

There's the cygwin official release, based on tcl/tk 8.0 with partial 
cygwin support but MSWin GUI.  Because of Red Hat commercial concerns 
vis a vis GNUpro, I imagine any official release of the 'tcl' and 'tk' 
packages will ALWAYS use MSWin GUI's --- you don't want your GNUpro 
customers to have to run the Xserver just to debug their code...

NEW INFO from cgf (of which neither I nor Nicholas were aware): However, 
the cygwin support in that version of tcl/tk could be improved -- and 
development in that direction, for tcl/tk-8.3 is happening on the 
insight mailing list.  Gotcha.

There's also the issue that some folks -- me, for instance -- would like 
a tcl/tk that DOES work with X11 (e.g for integration with Gnome/KDE, 
etc).  How should *that* be attempted?  perhaps 'tcl-x' and 'tk-x' 
packages installed under /usr/X11R6/ ?  Should those be based on the 
official tcl/tk 8.3 sources, or on the "fork" (if it is a fork) that is 
being worked on by the insight-on-cygwin guys...and where should this X 
  version be discussed: also on the insight list, or on the cygwin-xfree 
list, or here?  If not on the insight list, then how should the 
tcl-x/tk-x and tcl/tk package development be coordinated?

And of course, there's the all-important question: suppose all the 
technical details were worked out wrt tck/tk-8.3 on cygwin and 
tcl-x/tk-x-8.3 on cygwin.  Would the tcl-x/tk-x packages be accepted for 
distribution?  (e.g. would all this just be a waste of Nicholas' time?)

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Christopher Faylor]

Still talking about this, huh?

On Tue, Jun 11, 2002 at 12:34:05PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>
>>The tcltk package in cygwin has some cygwin knowledge but it is not
>>complete.
>>
>>Maybe we can stop talking about this now?
>>
>>If you want to help, check out (via CVS) the tcl/tk 8.3 sources from
>>sources.redhat.com and offer your help in the insight mailing list for
>>tracking down problems.
>>
>>As I said previously, future packages will be based on this.  If you
>>want to improve things, stop complaining and start contributing.
>
>I believe Nicholas DOES want to help -- but was confused as to where to 
>start.

Then he should no longer be confused.  In fact, I would have guessed
that no one should have been confused after my initial response where I
identified myself as the current tcltk maintainer.  But my guess would
have been wrong.

>There's the cygwin official release, based on tcl/tk 8.0 with partial 
>cygwin support but MSWin GUI.  Because of Red Hat commercial concerns 
>vis a vis GNUpro, I imagine any official release of the 'tcl' and 'tk' 
>packages will ALWAYS use MSWin GUI's --- you don't want your GNUpro 
>customers to have to run the Xserver just to debug their code...

Why drag GNUpro into this?  We already have a tcltk package.  tk
obviously already uses the windows GUI.  I can't imagine a scenario
where I would consider dropping support for that.  There are *obviously*
people using it already.  Do we want the cygwin community to be able to
run insight on Windows without an X server?  Of course we do.  Cheesh.

>NEW INFO from cgf (of which neither I nor Nicholas were aware): However, 
>the cygwin support in that version of tcl/tk could be improved -- and 
>development in that direction, for tcl/tk-8.3 is happening on the 
>insight mailing list.  Gotcha.

It depends on what you mean by "new info".  I've mentioned problems
previously wrt gdb.  Maybe it was in cygwin-apps.  I don't remember.

Then, I mentioned, in this very thread, that 8.3 was already available
in the sources.redhat.com repository:

http://sources.redhat.com/ml/cygwin/2002-06/msg00484.html

Maybe you'd have a point about this "new info" if you were responding
to my original message about the subject but, for some reason, you seem
to have ignored that one.  Apparently it takes multiple attempts to get
the point across.

(Hint for your next response:  "You never SAID that it was being handled
in the insight mailing list!  You only mentioned that there were strange
issues with tk and insight which were being tracked down."  I believe
that is how these interchanges normally go.)

>There's also the issue that some folks -- me, for instance -- would like 
>a tcl/tk that DOES work with X11 (e.g for integration with Gnome/KDE, 
>etc).  How should *that* be attempted?  perhaps 'tcl-x' and 'tk-x' 
>packages installed under /usr/X11R6/ ?  Should those be based on the 
>official tcl/tk 8.3 sources, or on the "fork" (if it is a fork) that is 
>being worked on by the insight-on-cygwin guys...and where should this X 
> version be discussed: also on the insight list, or on the cygwin-xfree 
>list, or here?  If not on the insight list, then how should the 
>tcl-x/tk-x and tcl/tk package development be coordinated?

FWIW, I have no plans on releasing an X version of tcltk.  It's premature
to consider it.

I suppose that the insight mailing list might be interested in seeing
patches, however.

>And of course, there's the all-important question: suppose all the 
>technical details were worked out wrt tck/tk-8.3 on cygwin and 
>tcl-x/tk-x-8.3 on cygwin.  Would the tcl-x/tk-x packages be accepted for 
>distribution?  (e.g. would all this just be a waste of Nicholas' time?)

I know that you are familiar with the mechanism for getting new packages
into the distribution.  I can't imagine why I'd object to someone releasing
X versions of tcl/tk libraries as long as they didn't interfere with the
packages that are already part of cygwin.

Whatever is offered should come from the same code base, however.

That's it for me.  If anyone wants to help with this, I'll see you over in
the insight mailing list.  I'm sure that the people there will be very
grateful to have people tracking down problems and will be willing to
discuss problems with people who are serious about solving them.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Updated Tcl Tk and Tix

[Charles Wilson]

Christopher Faylor wrote:

> Then he should no longer be confused.  In fact, I would have guessed
> that no one should have been confused after my initial response where I
> identified myself as the current tcltk maintainer.  But my guess would
> have been wrong.


I believe the confusion is now cleared up.  Any questions below are 
(obviously?) rhetorical.

the confusion was not about who maintains the current tcl/tk -- at least 
not after your initial response.  It was about the possibility of X 
support, how it could be integrated into the same package, or NOT 
integrated and released as a separate binary in a separate package 
(tk-x, etc).  And should discussions of cygwin packaging issues REALLY 
be discussed on insight's list?  Probably not.

Not everything is clearly "here" or "there", "black" or "white".  Some 
things are grey.  [Reiterate: but the cygwin-specific issues w.r.t 
packaging, maintaining, and X, have now been authoritatively answered in 
this thread.  The only thing left is bugfixes and testing of tcl/tk -- 
and that belongs over on the insight list]


> Why drag GNUpro into this?  We already have a tcltk package.  tk
> obviously already uses the windows GUI.  


Yep.

> I can't imagine a scenario
> where I would consider dropping support for that.  There are *obviously*
> people using it already.


Yes.  And the most important of those people, from the p.o.v. of Red 
Hat, who supports this entire cygwin project and provides the web space, 
mailing list, and honest-to-god paid developers, are the GNUpro 
customers.  I've got no beef with that.  It's a wonderful thing.  Where 
would we be without Cygnus's and now Red Hat's support?

>  Do we want the cygwin community to be able to
> run insight on Windows without an X server?  Of course we do.  Cheesh.


Absolutely true -- but personally I wouldn't mind having to crank up an 
Xserver to debug a program (unless, of course, I was trying to debug 
X... <g>).  Others probably have stronger feelings.  I'm not saying the 
we should replace the current tcl/tk packages with ones that only 
support X.  I'm agreeing that the status quo is and will remain the 
status quo -- and that's okay.  Besides, it's not really my decision 
anyway -- you're the maintainer.


>>NEW INFO from cgf (of which neither I nor Nicholas were aware): However, 
>>the cygwin support in that version of tcl/tk could be improved -- and 
>>development in that direction, for tcl/tk-8.3 is happening on the 
>>insight mailing list.  Gotcha.

> It depends on what you mean by "new info".  I've mentioned problems
> previously wrt gdb.  Maybe it was in cygwin-apps.  I don't remember.


I dunno.  I musta missed the *earlier* threads.  Sorry -- I've not been 
following the list super closely for the last few weeks...


> Then, I mentioned, in this very thread, that 8.3 was already available
> in the sources.redhat.com repository:
> 
> http://sources.redhat.com/ml/cygwin/2002-06/msg00484.html


I did see that...but what wasn't clear to me was how those sources 
related to the "official 8.3" sources, or to the previous cygwin 8.0 
sources.  Was it merely a direct import of the official 8.3, or did you 
do a merge and 'up-port' the cygwin changes from 8.0 (a *massive* job, 
IIRC).  And what about Mumit's changes?  Why'd he post a version on his 
site -- with patches, presumably different than the "cygwin official" 
ones...confusing.

Yes, the "questions" raised in the previous paragraph HAVE been answered 
in this thread -- which wasn't the case when the thread first 
started...so there's no need for anyone to chime in with "answers" to 
the questions above.  Yippee for mailing list archives.

> Maybe you'd have a point about this "new info" if you were responding
> to my original message about the subject but, for some reason, you seem
> to have ignored that one.  Apparently it takes multiple attempts to get
> the point across.


New info in the sense that *I* didn't know about it before you posted it 
in *this* thread -- in your first response (not the second; the 
confusion I mentioned was not "current" confusion, it was "earlier" 
confusion.  Sorry that wasn't clear.  My bad.)


> (Hint for your next response:  "You never SAID that it was being handled
> in the insight mailing list!  You only mentioned that there were strange
> issues with tk and insight which were being tracked down."  I believe
> that is how these interchanges normally go.)


Nope, that part was clear -- from your first reply + the second one. 
You should know better than to expect the obvious from me -- I'll always 
come up with new and better ways to annoy you, Chris. <g>

 
> FWIW, I have no plans on releasing an X version of tcltk.  It's premature
> to consider it.


Ah, thanks for making that clear.  Since it's your opinion as the 
official maintainer, and the one person here with the best understanding 
of the codebase, that it is premature to consider an X version, then 
that's cool.


> 
> I suppose that the insight mailing list might be interested in seeing
> patches, however.


Everybody loves patches...

 
> I know that you are familiar with the mechanism for getting new packages
> into the distribution.  I can't imagine why I'd object to someone releasing
> X versions of tcl/tk libraries as long as they didn't interfere with the
> packages that are already part of cygwin.


righto.  It's that whole "do no harm" thing -- don't clobber other 
peoples packages.  So, *later* when it is no longer premature to 
consider an X version, then I suppose you wouldn't be annoyed if someone 
ELSE released and maintained a separate build of tcl/tk for X, even 
though the codebase for your package and his were the same.  It would 
just require a little coordination, probably...but you wouldn't feel 
like Nicholas or Mumit or whoever was stepping on your "turf".


> Whatever is offered should come from the same code base, however.


Right -- coordination is the name of the game.  But not until later, at 
least until well after the MSWinGUI version of tcl/tk for cygwin is "out".


> That's it for me.  If anyone wants to help with this, I'll see you over in
> the insight mailing list.  I'm sure that the people there will be very
> grateful to have people tracking down problems and will be willing to
> discuss problems with people who are serious about solving them.


Good deal.  See you there -- as much as I'm able.  End of thread.  I hope.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/