Includes - tclkit does not include tcl. Files within a Tclkit or starkit are accessed only via VFS. There are limitations and differences in file and directory behavior through VFS that are not present when using native file handling. See tclvfs page for some of the differences.
The boundary between the real external filesystem and the internal filesystem is not always seamless e. This difference has been fixed in Tcl 8. And no, I don't know why we have two pages While there are many factors involved, one of the most important is certainly the fit of the tool to the project at hand. Tcl and Tk aren't the perfect tool for everything, but they do work well for a surprisingly large number of projects. Here are some things to consider when trying to decide if Tcl and Tk might be a good fit as one of the languages for your next project.
Tcl is a dynamic programming language, along with other languages like Perl, Python, Ruby, etc. Dynamic languages are complementary to system programming languages, and designed to solve different problems. You'll find features in system programming languages that help in creating complex data structures and algorithms, worry about compile-time type safety, and so on. Dynamic languages make it easy to quickly manipulate data, often pulled from networks, user interfaces and devices.
Typing, where present, is usually less rigidly defined, and determined at runtime. LV : going back to the top of this page, how about a look at the strikes against Tk that originally started this page:. Does Tile really address this?
While I recognize that Tcl and Tk provide some degree of i18n and localization , are we at full level, compared to other toolkits? What progress has been made for the specialized languages where, I presume, output and input are not traditional left to right, top to bottom, style? This is not a technical issue.
I use cygwin and MontaVista on Windows, Solaris environments and part of my toolkit for multi-platform support is Perl. Net Gui based apps in Tk. Why did I do that? Oh yeah It works, I keep forgetting.
But then, which serious scripting environment is not cross-platform? In those days most things looked awful and Tk looked good. Nice, I could now develop wherever I liked. But, did I really need to?
Back then Tk was seen as a one tool for all. And again, true, it can be. But, does it need to be? If the argument for using Tcl is Tk, which for many it was, then why have other scripting environment taken the lead over Tcl? Tk'ers boast of the inclusion of Tkinter with other packakges, but then TkInters sits there along with many other graphic toolkits. Its not that Tk is obsolete, Tk is old fashioned, like loons, Oxford bags or ha'penny round collars.
Ask any a new comer to coding which scripting environment he should know, the chances are its Python. Personally, I'm not interested in Python, I like Tcl way of doing things. Its simple. Do I have a solution? Tcl should be promoted more, promoted separately from Tk. I don't want to cause offence, but Tk should be accepted for what it is, a loadable module. One of many useful loadable modules. In closing, it would be interesting to take a poll of Tcl users to see whether or not they genuinely need cross-platform graphics.
Is it a desirable feature, rather than a necessary feature? In terms of the future, if full cross platform applications are needed, to run on any machine, anywhere, then Tcl scripted on-line applications should be worth considering.
Maybe some way of using Tcl to script new Goggle Aps. But then, is it really needed? Bryan Oakley if you think you don't need a cross-platform GUI toolkit, think of it as three platform-specific toolkits that happen to share the same API. If you take the time to learn a toolkit on one platform, isn't it nice to know your hard-earned knowledge will transfer if you ever find yourself working on a different platform? I use a Mac at home where I do most of my tinkering.
Then I got a gig working on a linux box. For the better part of a decade I was able to leverage my GUI expertise without having to learn a new toolkit. My experience speaking with users of other scripting languages, even though Tkinter is there, they choose something else.
Ok, this is my personal experience, it may be limited. But, when people choose a scripter, they choose a 'fashionable' language, and then use whatever Graphics front end they have that is vogue for the platform they're using.
My point is this, Tk is an add-on to Tcl. We should be out there saying, Tcl is good, it will work with the most popular graphics environment for your system.
Ok, I use Linux I want Gtk compliant apps. Tcl gives Tk its method of working, and that is good. It is the good features that should be promoted, not Graphics. Unlike the times when John created Tk, there are many different graphic toolkits out there, some of them, like Gtk, owe a lot to Tk. But, if Tk, is so hot, why is there now reducing interest in Tcl! NEM : Because people often make bad engineering choices, such as choosing a GUI toolkit based on fashion and popularity?
WJG : It is a cosmetic issue. It is a matter of choice. When Tk came along, there was little choice. Now we have lots. A lesser system prevailed over its better rival, why? Popularity, market selection. The whole history of IT is rife with good product cast aside due to market demand. Tk may be OS transferable, this is not the problem, it needs to transfer into the decision list of professional coders. The scripting language MEL was derived from Tcl.
But then, 'other factors' lead to a Tcl type scripter becoming dropped in favour of Sophia, now changes are afoot and Python scripting is available [ L6 ]. Why hasn't Tcl been reconsidered? I'm not certain but, I guess for the strongest reason of all -fashion and popularity. There is a certain irony though, Python is named after the TV show Monty-Python, now there's something outdated, outmoded and relegated to history. Lars H : But does any of what you've written above suggest a concrete action?
With respect to "Drop Tk, promote Tcl", the trend for years has been to make Tk more of an ordinary extension one milestone being where we started to explicitly [package require Tk] for the benefit of tclkit users , and although movement may be slow because not so much effort is invested in it, due to lack of interest , the direction is clear: dependencies in Tk upon internal Tcl interfaces are removed, generally useful features in Tk are moved to Tcl.
What more is there, in your opinion, that the Tcl community could do? WJG : I'm not advocating Tk developers in favour of anything, that's good carry on with it.
I'd like to see more people our there who develop using scripting languages to become more aware of Tcl and look at some of its advantages.
Secondly, Tcl is a language, not a product. Its survival does not depend on being widely adopted. Popularity brings lots of disadvantages too. Personally, I've grown to quite enjoy Tcl being somewhat under the radar.
Why does it matter if Maya chooses Python instead of Tcl? They're both fine languages. As you say, the Tcl will survive, but it needs to thrive. I'd actually love to see the latter bits spun off into their own package say, TkWidgets leaving the widget management and display system as the Tk core.
Spinning Tk widgets off to a TkWidgets package would also trim a few hundred K from our starpack basekits too ZB it would be interesting to take a poll of Tcl users to see whether or not they genuinely need cross-platform graphics But of course at least I need. Casteele - I also use Microsoft's. NET, and still use the older non-. NET compilers. My point is, Tk is not dead, and it probably will not die in my lifetime.
Not because it's the biggest, best, "one tool to rule them all" or anything, like some people seem to want it to be, but because it does one specific job, and it does it exactly how it's supposed to do it.
It does not try to be some all-encompassing, all-knowing, answer-to-everything. And that is what I think the problem is with those who seem to think it's dead, or useless; It does not do everything they want it to do.
0コメント