Tcl Programming/Tk Examples
en.wikibooks.orgI’ve said it before, but I’d love to see a best-practices CRUD app done in tcl, tk, and SQLite along the lines of the north winds thing from Microsoft. The SQLite interface in tcl is a thing of beauty to rival tk.
Look at AOLServer, yes that AOL. https://aolserver.github.io/
Sure, desktop CRUD apps have been obsolete for 25 years, but I meant a desktop application in tk. Also, an example application like Northwinds, not a framework.
Not exactly what I’m thinking either, but look at how concise pgaccess (for postgresql) was.
Besides AOLServer, there were Safelayer and Vignette.
However you will only get to see AOLServer's source code, as the latter two were proprietary.
Not too surprising since D. Richard Hipp is both contributing to SQLite and Tcl.
I used SQLite with Tcl for many years, and yes, it truly is.
Tcl/Tk is cool.
Tcl/Tk makes UI's that jar in an ugly, immediately recognisable as "old-fashioned" way. This matters to users whether we like it or not. It would be a very niche commercial software project that used it for its UI no matter how beautifully elegant the functionality of its UI. Best ever UI will still elicit an "Ew, yuk." From the majority of its users.
Graphical UIs have been de rigeur for what, 30+ years? We still suck at the tools to program them which are all a pain in the backside to use even when making something very simple and expected. We still suck at programming these UIs when we use them. All of them. I have no answers to this.
AC3D[0] is a 3D mesh editor that uses Tcl/Tk for the UI with the core functionality being in C. The "ttk" subset of controls is themable and AC3D has its own theme[1] which, at least to me, it doesn't look that different from the themes of other 3D software. Though it also allows you to edit and create your own themes and personally i made this[2] which i like better (though i think the people who belong in that "majority of users" group you imagine are more likely to elicit that "Ew, yuk." from my theme :-P).
I remember 20 years ago that half of Linux GUI apps were Tcl/Tk. Yes, people made fun of them for not being "native", but I'd much prefer a Tcl/Tk app over a modern Electron one.
I hear you. Don't you think it's a shame that in 20 years we haven't got anything that is actually better? Easier to program? Easier to design for usability? Better looking? I would have guessed we would have. Delphi/kylix, VB, gtk+, qt, win-whatever, mac-whatever, wx, electron. All of them. Not really the thing huh?
It's quite possible to make attractive GUIs in Tcl/Tk if you're willing to put in the effort and have some design sense.
It's also really easy to create truly ugly (but functional) GUIs in Tcl/Tk.
> Tcl/Tk makes UI's that jar in an ugly, immediately recognisable as "old-fashioned" way.
Yes, and they are thousand time more usable that the "modern" crap.
GUI design is going backwards since 10 years.
survivor bias. Nothing magical about tcl/tk (cool as it is) that makes guis more usable, sadly. Nothing in modern gui libraries that prevents good usability design either.
Guis have always been more discoverable and just better for certain tasks, usually where you want to see something with immediate updatable feedback but the gui libraries have always been terrible. They were terrible 30 years ago, and 20 and 10 and still today.
I don't have answers.
WRT what hulitu refers to (as i understand it), it isn't Tcl/Tk that makes the GUIs more usable, it is more that the modern trends that largely came out of small touch screens and often use flat(ish) themes with a lot of padding and unused screen real estate that make desktop applications less usable.
Tcl/Tk just makes it harder (though not impossible) to make such GUIs because its defaults were made before those trends, but it isn't unique to it - the same applies, e.g., to applications made with Qt Widgets. Note that here i do not refer to how easy it is to make the GUI, just on how usable applications are from a desktop user's perspective when using the default look and feel.
This particular problem is largely a matter of trends - some libraries/technologies make it easy to follow those trends, others harder, however the root issue isn't so much the libraries/technologies in question but the trends themselves.
What Tcl needs
1. a package manager
2. language server
3. a vs code plugin or an emacs mode for the language server
I know there was a (somewhat?) successful package repository and manager called Teapot and Teacup [0] respectively that was run by ActiveState but I don't believe it's actively having packages added to it. I really wish there was some new development along these lines to allow for github repos to be imported (I think I've seen this in Golang). As far as the language server goes, I'm guessing that would be really difficult to implement for Tcl since each command can essentially implement its own DSL.
Teapot/Teacup was lovely while ActiveState was supporting it. I believe someone in the community still maintains a Teapot, but I don't know how current it is.
And as for language server—yeah, not gonna happen.
decent uses this for their software for their espresso machines. Unfortunately, they don't really have any software expertise internally, so the product is largely a buggy mess.
Have people made replacement software for those? They always seemed like the kind of thing where that'd happen if it's in any way friendly to it.
Yes, but it's a lot of work, and you're making replacement software for a commercial product for free.
Tcl is markdown for programming logic.
... if programming logic was riding a dragon, with rockets, on top of a minivan.