[WillAdams]

One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program.

For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs.

I'd really like for there to be an agreed-upon standard option for graphical program development which was interactive and cross-platform.

[ofalkaed]

I don't think it is needed. I am a hobby programmer and not even remotely competent but I can whip up GUIs in Tk with little effort and I find it quicker and easier than the graphical UI designers.

[WillAdams]

I am a visual person (at least that's what I told myself when I chose to get a graphic design degree rather than do computer science (but was one 300-level course short of a CS minor)), and I find the disconnect between the visual appearance and the obtuse code a quite difficult stumbling block --- the one tool I was successful doing using Python and TK never had a visual appearance I was satisfied with.

[ofalkaed]

If I am not sure how things should be laid out I just sketch it on graph paper or on my tablet, I consider each square of the graph to be 10 pixels or what ever suits and have at it. 10 or 15 minutes will generally be enough to go through many revisions and leave me with map to follow, 5 or 10 minutes of typing and it is done. After that tweaks are just changing a few numbers and the results are essentially instant since no compile time and you can see the results with a command from your editor.

Wish also has an interactive mode, not point and click but results are instant, great for learning Tk. No idea if it can work with tkinter though.

[musicale]

> why there isn't a standard graphical tool for laying out a GUI program

It is a bit surprising since it seems like you could use Tcl/Tk to write it.

The Tk canvas makes writing simple drawing programs fairly easy, and a GUI editor seems like it wouldn't be terribly difficult.

[rmu09]

Once upon a time (Tcl??/Tk3.6) there was XF by Sven Delmas. It had some issues and really would have needed something like namespaces. AFAIR it took forever to get a stable version for Tk4.0.

[musicale]

> a cross-platform HyperCard clone

I wish there were more of these, preferably open source (and, since I'm dreaming, native and web versions.) ;-)

[RodgerTheGreat]

Decker is FOSS, and available in both a web version and native builds for MacOS, BSD, Linux, and Windows: http://beyondloom.com/decker/

If you've seen Decker previously you might find it useful to know that it has recently acquired several "escape hatches" for interoperating with software and APIs outside its usual sandbox: http://beyondloom.com/decker/decker.html#thedangerzone

[musicale]

Thanks for reminding me of Decker, which I think has been featured on HN a few times.

I live in a HiDPI, color world but the 1-bit vintage Mac-style GUI and fonts look nice to me.

https://hypercard.org also has some interesting links.

I think the sandbox/doesn't play well with others issue has affected the use cases of environments from HyperCard to Lisp to Smalltalk. Tcl/Tk seems designed for connecting to other software.

[RodgerTheGreat]

There are basically two parts to Decker's stance on sandboxing:

To maintain fidelity between the capabilities of web-decker and native-decker, the constraints of web browsers need to be treated as a common denominator. Some of the ways that conventional webapps circumvent these constraints are not an option for web-decker, because it's designed to function without a server-side component; this avoids dependencies on centralized infrastructure. (There are also some features intentionally left out because they would be inaccessible on e.g. touch-based devices which lack a physical keyboard or the ability to register "hover" events from a pointing device.)

To center user-empowerment, Decker should be "safe by default" and require affirmative consent for things like sending information to remote servers or accessing the local filesystem. If a user understands the risks, they can deliberately shift Decker into a more permissive mode of operation which lets it interoperate directly with local resources, raw browser APIs, etc. By default, Decker can safely run applications written by untrusted third parties, and in "dangerous" mode it is more comparable to a conventional automation tool or scripting environment. This approach may not please everyone, but it is a carefully-considered compromise.

Decker does have paletted color support; many decks produced by users apply this to great artistic effect: https://itch.io/games/tag-decker

[WillAdams]

Livecode going opensource and targeting HTML5 was a big part of why I chose it (and funded it on Kickstarter).

Still annoyed about their changing course and removing the Community Edition.