Tcl/TK is indeed dying
in [TCL]
|
Prev: www.prevayler.org anyone do an in ram data base with transactionlog in tcl?
Next: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
From: Rob on 15 Dec 2009 05:20 Donal K. Fellows wrote: > On 15 Dec, 05:20, Rob <dislexic_wob...(a)NOSPAMyahoo.com> wrote: >> The code you refer to is presumably in a demo rather than the actual >> core code. > > It's supposed to say "Hebrew Language" or equivalent. But I don't read > any Hebrew script at all (or Arabic) so it's quite possibly wrong. > Fixes welcome. (Well, it's actually changed now so fixes are not > needed now.) > >> Requesting that the Arabic version say 'Palestine' would be fine, > > In a demonstration that is supposed to be totally non-controversial? > Not at all. There has never been any intent for Tcl/Tk to display > *any* political point of view on topics like this, even an even-handed > basis. Donal So the demo should say "hello world" in whatever language it displays. If I understand your comment you are saying that the discrepancy has already been fixed, which is a good thing. My response re 'the fix' was somewhat flippant and not at all appropriate. My apologies to all on that point. I actually posted my message simply because I was annoyed with Rodrigo making a totally inappropriate political statement (as stated in his final sentence) in a place that should be totally non-political (as you have said yourself). Rob.
From: Arndt Roger Schneider on 15 Dec 2009 05:56 Donal K. Fellows schrieb: > [snip] >For Tk, the >really big thing is the new themed widgets, both conceptually (the new >state model) and in implementation terms (Tk no longer has to look >utterly outmoded). > >Donal. > > Tk and Tile are memory wise the largest parts in Tcl/Tk. Tile is dependent on Tk, but Tk should not be dependent on Tile. In order to reducing the memory footprint of Tcl/Tk: Separate Tile into a shared library, create an alternative wish loading tile, importing the ttk windows into the global namespace as default. The other wish(Tk) is then still able to load tile as a package. Requires under X11 to implement all Tcl-dialogs independent from either Tk or tile aka separate the file dialog into its own namespace, put styles and visual configuration inside the option database. Second Tk: Remove all embedded bitmaps and replace them with font-glyphs, very much as you did with the warning symbols inside the message box, but with anti-aliased glyphs, instead! Do progressingly the same with all controls: corners, shadows, highlightthickness, indicators... start with radiobutton and checkbutton indicators. Make the glyph-font user customizable: Gives a full vectorized themed engine, anti-aliasd, fast as hell, low memory footprint. Third Panedwindow: Reduce platform dependencies: The panedwidow is a simple geometry manager and should not be implemented as a window, make it the fourth general purpose geometry in Tk and leave the stash configuration to the developer using it. Remove the redundant version in tile. -roger
From: Larry W. Virden on 15 Dec 2009 07:22 On Dec 15, 1:09 am, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > Or even a language which has > "gaps" in functionality. Depends on one's definition of "gaps in functionality". If one says that, meaning "the language is incapable of implementing the functionality", then I agree that phrase is inaccurate. However, in most cases that I've seen using that type of statement, what is meant is that "out of the box, Tcl does not provide working code that provides the functionality". Certainly one has to admit that there are quite a large number of areas not addressed by Tcl code out of the box. If one created a checklist comparing Perl, Python, Java, Tcl, and compared the functionality that is implemented a) after compiling the source tar/zip file, or even b) including the online automated repository (aka CPAN, teapot, etc.) I have no doubt that Tcl would have the smaller list of functionality. That's because, despite the original poster's claim, Tcl continues to be a relatively small language, out of the box. There are languages which start out smaller - C is pretty darn small when you look at JUST what is built as the compiler. Even after you add in libc, it is pretty small. Java, when you look at a distribution like the runtime distribution, is a pretty small functional set. But there are numerous additional packages outside of the source distribution, or even package repository, which allows one to add functionality. For instance, there are various scripts for reading RSS feeds - http://panoptic.com/tcllian/scripts/view.adp?script=rss.tcl for example (and there are more that show up when web searching). Do they do everything that the python library in question do? Probably not. Tcl packages tend to be "just enough" to get the job done that the writer needs. If they are so inclined to make their code available, they have the expectation that others who need more will code it. But that, of course, doesn't "get the job done" as quickly as a library that has been worked on over a period of time. And there's the struggle in an open source community - how to get higher quality libraries from people who are quite busy accomplishing their day jobs (and sometimes their night jobs and weekend jobs, etc.). It takes help by the entire community, to test, fix, enhance, and contribute back code so that, in the end, the community has better packages. Of course, using "the best tool" is a great approach. However, for those who spend significant amount of bytes discussing what someone else needs to do to make Tcl better, there is a useful contribution area for them to pay forward. Take a look at the Tcl you use. Learn the package better. Write tutorials, submit improvements to the docs, write examples that can go on the web either at http://wiki.tcl.tk/ or the package's home site. Answer questions patiently. Contribute useful code that allows others to get jobs done well using Tcl. > > Most of these tasks are made easy because Tcl imposes no particular > "world view" on really anything. The only thing that is really > enforced is the basic syntax of the language. Well said. Thank you.
From: Larry W. Virden on 15 Dec 2009 07:28 On Dec 15, 1:34 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > If we look at Tcl the language, the big changes have been the adoption > of UNICODE, the addition of the expansion syntax, and the introduction > of a new datatype (the dict, though it really just captures ideas in > Tcl that already existed), and 8.6 adds an object system and a much > more powerful execution model (coroutines). In terms of the > implementation, 8.0's upgrading of Tcl's value model and the > introduction of compilation are the massive features. For Tk, the > really big thing is the new themed widgets, both conceptually (the new > state model) and in implementation terms (Tk no longer has to look > utterly outmoded). And of all those changes, every one can be ignored to some extent. UNICODE is probably the closest thing that really impacts the way someone codes, and that only if the input is going to be UNICODE. The rest of these changes are features that one can make use of, but need not worry about if they so choose. There have been more 'minor' changes that result in a need to tweak programs than there have been 'major' changes to the scripting language itself. Certainly from a C API, there have been a variety of changes (ANSIfication, stubs library, etc.) that has resulted in the need to change code. But in general, the language has stayed relatively stable.
From: David N. Welton on 15 Dec 2009 07:48
On Dec 14, 1:17 pm, Rodericus <sc...(a)web.de> wrote: > First of all, I thank everybody answering. About the recommendation of > Etcl, lua, jim: I will see them , but I do not think they are the > alternative, for example due to licence, due to object orientation > that I do not like. http://www.lua.org/license.html http://jim.berlios.de/license.html Both of these are very liberal licenses that let you include the code in your own proprietary works and basically do whatever you want with it. It took me all of 5 minutes to find that information. Lua has some sort of OO, but it's fairly minimalistic, and it's evident that you did not even look at it before writing your post. Jim, as far as I know, doesn't really have an OO system, and is very small and minimalistic. What was it that you are actually trying to build or do? |