Thread: [tcltk-perl] RE: Tcl-Tk-0.77
Brought to you by:
hobbs
From: Jeff H. <je...@Ac...> - 2004-04-17 21:52:59
|
Robert Hicks wrote: > Saw the module on CPAN. My question is why not? Why doesn't > the Perl community use that module to interface with Tk since > it allows you to stay up-to-date with Tk itself? Robert, Perl/Tk and Perl's Tcl::Tk module have both been around for a while, but Perl/Tk was more complete at first, offering a simpler fully itegrated solution. At this point for Tcl::Tk you are still required to have a local Tcl/Tk installation to build (this may be addressed with companion modules later). At a technical level, Tcl::Tk wasn't all that spectacular because it stayed 100% with the string-based interfaces that Tcl has had for over a decade. Only in the last couple of weeks has Tcl::Tk been transformed with a pure SV <> Tcl_Obj bridge. In an app we test on locally (a few thousand lines of code just for the app), we have seen 15% lower (better) memory usage and snappier performance than the original Perl/Tk version. In addition to that, by alleviating the need to maintain the specialized port of Tk for Perl (where Tcl is partially ripped out), we are able to fully leverage platform portability better. Vadim uses this on Win/CE, and you could also use this on OS X with Tcl/Tk's native Aqua port. Feature level portability also must be noted. The app we had used Tk->fileevent on unix - but that's never been ported to Windows for Perl/Tk, although Tcl has had fileevents on Windows for *7* years. Using Tcl::Tk we were able to abstract this easily using the Tcl fileevent in a way that a Perl programmer can still find friendly. All this new development is very recent though. The point isn't to bury Perl/Tk, as Nick has done an excellent job maintaining that over the years. The point is to provide an architectural replacement to make it easier to maintain in the years to come. Perl/Tk compatability in Tcl::Tk has a lot until it's near complete. If you want to build UIs from scratch though, it's all there ready to use. Regards, Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos |
From: Vadim K. <va...@ar...> - 2004-04-18 06:43:16
|
> > Saw the module on CPAN. My question is why not? Why doesn't > > the Perl community use that module to interface with Tk since > > it allows you to stay up-to-date with Tk itself? It becames obvious that web page describing and illustrating features is required. There must be screenshots of Perl application that use Tcl/Tk with standard widgets, and with some pure-Tcl and some unusual for perlTk world widgets, (like BLT?) Downloadable demos that could be executed also will be good. BTW it would be good to develope a feature when Tcl/Tk binaries, that Tcl::Tk use, could live in any directories, so to ease creating of distributions that could be moved and executed without requiring TCL to be installed (it is really easy and I use this at work). "demo" and "tk-demo" directories of Tcl::Tk must be updated and improved. Vadim. |
From: Vadim K. <va...@ar...> - 2004-04-18 16:50:48
|
I was pleased to notice that once BLT is installed (project BLT on sourceforge.net site) it is extremely easy to manipulate from perl with perlTk syntax. That is, although gaining perlTk compatibility is easy and not completed, but Tcl::Tk module is complete enough to create new applications with this approach, like Jeff already mentioned. Screenshot is at http://home.peterstar.net/vkonovalov/BLT-tests/btl-test.jpg http://home.peterstar.net/vkonovalov/BLT-tests/btl-test.pl.html (There exists a small problem - BLT widgets typically invoked as blt::graph, and either "import blt::*" should be used, or there could be a conflict in widget names, but it is really easy to work aroud). I'll try creating some explanations for publishing demos to web, but I am extremely slow on this. And homepage on SF is not ready for web publishing yet? Best regards, Vadim. |
From: Jeff H. <je...@Ac...> - 2004-04-19 18:15:49
|
> BTW it would be good to develope a feature when Tcl/Tk=20 > binaries, that Tcl::Tk use, could live in any directories, so=20 > to ease creating of distributions that could be moved and=20 > executed without requiring TCL to be installed (it is really=20 > easy and I use this at work). Can you elaborate on what you mean here? I think I understand it to mean relocatable shared libs on any platform, but I'm not quite sure. I've thought about having an optional configuration option for Tcl::Tk that uses the stubs libraries. It is a bit tricky, but then it would operate like the Tcl browser plugin. There would be no implicit dependencies on a particular set of Tcl/Tk dlls. Instead you would start up and then try to load the Tcl and Tk dlls based on a set of heuristics. This frees you from a) implicit dll tiedown b) version dependency (can use Tcl 8.5 even if compiled for 8.4) c) location dependency (see the npWin.c to see how I allow for several locations) NpCreateMainInterp: http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/gene= ric/ npInterp.c?content-type=3Dtext%2Fplain&rev=3D1.6 NpLoadLibrary: http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/win/= npWi n.c?content-type=3Dtext%2Fplain&rev=3D1.7 This would go in Tcl.xs:BOOT Jeff |
From: Vadim K. <va...@ar...> - 2004-04-19 18:44:46
|
> > BTW it would be good to develope a feature when Tcl/Tk > > binaries, that Tcl::Tk use, could live in any directories, so > > to ease creating of distributions that could be moved and > > executed without requiring TCL to be installed (it is really > > easy and I use this at work). > > Can you elaborate on what you mean here? I think I understand > it to mean relocatable shared libs on any platform, but I'm > not quite sure. I was thinking only for Windows, but yes, having such a feature on all platforms must be done, not only for one of them. I meant that from time to time it is needed to package all required files into one executable so to have a possibility to run it regardless whether computer have Tcl (or Perl) installed. This is why "starkit"/tclkit is needed, and Perl's PAR. > > I've thought about having an optional configuration option for > Tcl::Tk that uses the stubs libraries. It is a bit tricky, but > then it would operate like the Tcl browser plugin. There > would be no implicit dependencies on a particular set of Tcl/Tk > dlls. Instead you would start up and then try to load the Tcl > and Tk dlls based on a set of heuristics. This frees you from > > a) implicit dll tiedown > b) version dependency (can use Tcl 8.5 even if compiled for 8.4) > c) location dependency (see the npWin.c to see how I allow for > several locations) It would be fine if mentioned "heuristic" could be configured somehow. Most obviously - to have a way to specify exact location of binaries. Up to now I used some hack for this. > > NpCreateMainInterp: > http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/generic / > npInterp.c?content-type=text%2Fplain&rev=1.6 > > NpLoadLibrary: > http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/win/npW i > n.c?content-type=text%2Fplain&rev=1.7 > > This would go in Tcl.xs:BOOT Great. Best regards, Vadim. |
From: Jeff H. <je...@Ac...> - 2004-04-19 19:09:43
|
> > Can you elaborate on what you mean here? I think I understand it to > > mean relocatable shared libs on any platform, but I'm not quite sure. > > I was thinking only for Windows, but yes, having such a > feature on all platforms must be done, not only for one of them. > > I meant that from time to time it is needed to package all > required files into one executable so to have a possibility > to run it regardless whether computer have Tcl (or Perl) > installed. This is why "starkit"/tclkit is needed, and Perl's PAR. We have starkits on the Tcl side, but not dll-based ones. I would have to look into that further. In any case, Windows is the one platform I'm least worried about, because cwd and the path to the executable are guaranteed to be in the load path, which makes relocation unnecessary (as it also has defined lookup paths in Tcl). It's the other platforms that are more ornery. > > operate like the Tcl browser plugin. There would be no implicit > > dependencies on a particular set of Tcl/Tk dlls. Instead you would > > start up and then try to load the Tcl and Tk dlls based on a set of > > heuristics. This frees you from > It would be fine if mentioned "heuristic" could be configured > somehow. Most obviously - to have a way to specify exact > location of binaries. Up to now I used some hack for this. You define the heuristic in code, but currently on Windows the Tcl browser plugin looks in: 1) Hard-coded (binary patchable) directory 2) Path based registry location of installed ActiveTcl and on Unix: 1) TCL_PLUGIN_DLL env var 2) Hard-coded (binary patchable) directory 3) any compatible version on LD_LIBRARY_PATH Jeff |