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: Will Duquette on 15 Dec 2009 11:11 On Dec 15, 7:29 am, Arndt Roger Schneider <arndt.ro...(a)web.de> wrote: > Will Duquette schrieb: > > > > >On Dec 15, 2:56 am, Arndt Roger Schneider <arndt.ro...(a)web.de> wrote: > > >>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 > > >The ttk::panedwindow is far from redundant; in my experience it works > >*much* better (in both behavior and appearance) than the non-ttk > >panedwindow. > > Fine, use the ttk:panedwindow code for the stand-alone geometry manager. > > >On top of this, moving the ttk widgets into a separate package would > >be a major step backward for Tk. > > Why? You have two applications, one linked against tile, > and another one only with tk, where is the step backward? > It provides the same environment as is current in 8.5, plus the > option to use a smaller set on such platforms which don't > have themes or were the extra memory requirements are to > big a burden. > > -roger The Ttk widgets are not a replacement for the classic Tk widgets; the two sets are complementary.
From: Georgios Petasis on 15 Dec 2009 11:17 O/H Óscar Fuentes έγραψε: > "slebetman(a)yahoo.com" <slebetman(a)gmail.com> writes: > >> On Dec 15, 3:19 am, Óscar Fuentes <o...(a)wanadoo.es> wrote: >>> "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> writes: >>> >>> [snip] >>> >>>> That's one of the *great* things about Tcl, that you can easily extend >>>> it with extra functionality through packages, your own code, or >>>> through calling external programs. >>> And how is this different from every other existent programming >>> language? >>> >> The word "easily" > > "easily" here is subjective. It is "easy" to introduce new commands for > interfacing with C code, in the sense of requiring less boilerplate than > other languages. But Tcl requires more work than others (notably, some > languages or implementations requires one line of code per C/C++ > reflected function/method, some languages requires none.) > > It is not so easy to reflect complex external data on the Tcl data > model, though. > > The above is for interfacing with external libraries. Certainly, a > programmer who can't get the grips on Tcl's weirdness will say that is > not easy to add functionaility to Tcl writting Tcl code. > > And EIAS is not all that great for some tasks. Being interpreted forces > you to write C from time to time. > > So, Donal's is reflecting its own personal likes and dislikes. What he > says makes no sense otherwise. > And there is always SWIG. This makes interfacing easy for all languages. However, Tcl has the advantage of stubs. Not all languages have a stub library, where you link with it and forget the binary: it runs with any version greater than the one linked (officially, unofficially it runs also with earlier versions as long as you don't use functions not available in earlier versions). George
From: Tcl Bliss on 15 Dec 2009 13:33 Death of TCL has been predicted many times and for many years but it is still alive and better than ever, a lot of it due to ActiveState http://www.activestate.com actively :) supporting it. Thanks ActiveState. Of course, there are other contributors, thank you all. One very visible major shortcoming, IMHO, is a flaky support of command line history browsing. Most modern scripting languages support readline but in TCL it doesn't work by default and requires a good effort to make it work. I have not been patient enough lately to make it work. Of course, I can use Tkcon but not when I ssh to a remote system, which I do a lot.
From: Óscar Fuentes on 15 Dec 2009 13:58 Rodericus <scire(a)web.de> writes: >> What was it that you are actually trying to build or do? [snip] > I dont write any comercial program, from time to time a program that > run only once to solve a task, or an application with the > functionality I need for my work. [snip] > As Tcl/Tk is dying, I will have perhaps to use more C, I will find the > way. Troll alert! (Well, actually I don't think he intends to troll. Too often a troll is indistinguishable from a clueless, self-righteous dude.) -- Óscar
From: Rodericus on 15 Dec 2009 14:49
On 15 Dez., 15:42, "David N. Welton" <davidnwel...(a)gmail.com> wrote: > > As Emacs became extreemely fat, I began to use vi, [...] > You might have a look at 'ed', as "ed is the standard text editor". Ed was the first editor I used on a Unix computer. Before I used "sos" editor on a DEC 10 computer connected to an LT100 paper terminal (tops 10 operating system). Rodrigo |