This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin, tcl/tk, and "native" [Was: Re: Interest in "native" Tcl/Tk/Expect/Itcl/...packages?]


Jean-Sebastien Trottier wrote:

I would say that what we already have is:
    Tcl/Tk: half-Windows/half-Cygwin, GDI

Err...ok. If by this you mean


tcl: cygwin (no GUI), but it doesn't do cygwin paths correctly in all cases
tk: cygwin, X11


As you can see above, the current Tcl version uses windows APIs to
access the filesystem. So, I would consider it as a mixed
half-Windows/half-Cygwin version...

Thus, I would say the Tk GUI is not the only problem in the current
version...

Granted, given your examples.


Contrary to Jean-Sebastien Trottier's assertion, replacing the current "cygwin, GDI" implementation with the "native, GDI" ActiveState version will NOT satisfy the current requirements of insight/gdb and other existing cygwin packages.


I never (did|meant to) "assert" that people should switch to using
ActiveState's Tcl.

Err...what was this, then: "Apart from getting Tk to work without X, I don't see any... If you want Tk for Windows, might as well get it from ActiveState."


To me, that says: there is no need for non-X tk on cygwin. If you want non-X, what you really want is windows (GDI). So go get ActiveStates'. My point is that THAT is not true, given the distinction between windowsGDI and windowsRUNTIME. If I misunderstood your point, I apologize.

Although (I think) it would be possible to have 2 Tk DLL's ("Cygwin, X"
vs "Cygwin, GDI"), I like Charles Wilson's idea to try and use W11:

Not my idea -- it was Igor's. ('tis a good one, tho, if you can make it work.) However, SteveO packages libW11 together with rxvt; it is not a separate package. (and his build technique to get it to work is...unique) So, if you need to add stuff to libW11 and need specific header files, there may be issues. You'll need to work with SteveO and perhaps split libW11 to a separate project and package.


    On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote:
    > Rxvt already does this.  Do tk/itk make GDI calls that aren't
    > covered by rxvt's W11 library?  If so, wouldn't a more worthwhile
    > investment of effort be to extend the W11 library with the
    > implementation of the appropriate X11 calls (by plundering the
    > tk/itk GDI implementation as needed), and then use the W11 library
    > in the same way as rxvt does.

So, let's extend the terminology:

a "Cygwin, W11" version
    uses xlib calls to draw stuff on a display using the W11 library
    this works with or without a xserver running

With this "Cygwin, W11" Tk version, this would cover the insight/gdb
requirements without the need for 2 distinct Tk DLL's or majorly hacking
the code.

I will try and have a proof of concept working ASAP...

Cool!


BTW, I interpret cgf's statement

"If someone wants to take over gdb + tcl/tk maintainership that's fine, though. That is gold-star worthy."

to mean that cgf is willing to relinquish maintaining gdb/insight AND tcl/tk -- but not just tcl/tk alone. It's a package deal; you'd need to accept gdb maintainership too. Is that a correct interpretation, cgf, or is there a third choice: you'd give up maintaining tcl/tk but continue maintaining gdb SO LONG AS the tcl/tk maintainer's changes don't force you to do more than minimal work to keep gdb up-to-snuff?

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]