[HN Gopher] Visual Tcl
___________________________________________________________________
Visual Tcl
Author : galfarragem
Score : 124 points
Date : 2021-01-27 09:24 UTC (13 hours ago)
(HTM) web link (vtcl.sourceforge.net)
(TXT) w3m dump (vtcl.sourceforge.net)
| wiso wrote:
| I remember using https://wiki.tcl-lang.org/page/tkBuilder long
| time ago.
| lizknope wrote:
| A lot of EDA (Electronic Design Automation CAD tools for the
| semiconductor industry) tools use Tcl as the built in scripting
| language. Because of that many companies have built their CAD
| flows around Tcl so that it integrates with the tools from
| Cadence and Synopsys.
| peteretep wrote:
| > Exports Tclets which run in Netscape/MSIE. You must have the
| Tcl Plugin to see the Tclets.
|
| Not sure the Tcl Plugin would still run anywhere, which is a
| shame
| skissane wrote:
| I assume the plugin is just running Tcl/Tk inside a browser
| window.
|
| I wonder how hard it would be to recreate the same idea using
| Emscripten drawing to a HTML canvas?
|
| People have gotten Tcl to work on Emscripten [0]. I think the
| big problem is the Tk part. Tk has X11, Win32 and macOS
| backends, but emscripten supports SDL, for which there is no Tk
| backend.
|
| [0] https://github.com/aidanhs/emtcl
| swiley wrote:
| There is an SDL backend for Tk but it's not part of the
| normal distribution:
|
| http://androwish.org/home/home
| blacksqr wrote:
| The Projected Tk project aims to recreate Tk with a pluggable
| backend structure, with a web browser backend one goal.
|
| https://chiselapp.com/user/gwlester/repository/PTK/home
| Aldipower wrote:
| I think Chrome dropped support recently too..
| flohofwoe wrote:
| Would be a nice weekend hack to create a Tclet "plugin" for
| WASM. The Tcl interpreter itself is extremely easy to port to
| exotic platforms, only problem might be APIs that wrap
| underlying operating system APIs, those would need to be
| emulated on top of browser APIs.
| elviejo wrote:
| Where can I learn Tk/Tcl today?
| cartoonfoxes wrote:
| "The TCL Programming Language" is a recent (2017) book, paired
| with the language docs at https://www.tcl.tk/doc/. The language
| itself is remarkably simple.
| doublerabbit wrote:
| A couple of good resources:
|
| https://www.tutorialspoint.com/tcl-tk/index.htm
|
| https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+0
| publicola1990 wrote:
| How does using tcl and this compare with using Pascal and Lazarus
| for GUIs?
| tluyben2 wrote:
| We used this back in the day to make a touchscreen PoS
| application. It was great as you can switch from running state to
| dev state without any friction. We quickly went from nothing to
| production because of visualtcl.
| [deleted]
| badsectoracula wrote:
| I've only played briefly with it some years ago on a Linux
| installation but one thing that i found neat was that unlike
| something Visual Basic or Delphi (which were clear inspirations -
| i think this screenshot[0] with the entire UI makes it a bit more
| obvious than the windows in the linked site) is that it is a
| "live" environment (pretty much like tclsh and wish) you are
| working with (kinda like a Smalltalk, though probably not to the
| same extent).
|
| (though FWIW classic VB is a sort of in-between because you are
| editing the actual forms and state you'd see running - which is
| most likely why you can't edit a form while the program is
| running and the IDE even "hides" them - but there is an
| intentional distinction between "running" and "editing")
|
| [0] https://a.fsdn.com/con/app/proj/vtcl/screenshots/49571.jpg
| dmux wrote:
| >kinda like a Smalltalk
|
| This may be of interest if you find the idea of a live Tcl
| environment interesting:
| https://news.ycombinator.com/item?id=22852484
| mschaef wrote:
| > FWIW classic VB is a sort of in-between because you are
| editing the actual forms and state you'd see running
|
| VB could be a little weird in that respect. This screenshot of
| 1.0 has a clue about why:
|
| https://winworldpc.com/screenshot/40c3942c-c281-2230-11c3-a4...
|
| The timer control in the toolbar (left column, second from the
| bottom) is an example of a control you could drag over into the
| 'form editor', give a location, but was totally invisible at
| runtime. All it did was provide a hook for timer events.
|
| This pattern turned into something common, at least in early
| VB. The extension mechanism for the language was defined in
| terms of VBX custom controls - which were intended to be visual
| controls that showed up on screen. The model worked well as
| long as that assumption held true, but VBX was also turned into
| an ad hoc mechanism for everything else.
|
| The net of this was that you often had a form editor showing a
| bunch of totally-non-graphical VBX controls that would do
| things like send mail, interact with a PBX, whatever else.
|
| Rolling back from this mess was a bit part of the impetus for
| the way OLE/COM 2.0 was designed, specifically OCX controls and
| IDispatch.
| p_l wrote:
| Delphi continued in that manner - You could have all kinds of
| visual controls, including FTP clients, that you'd visually
| add to a form etc. - but they were also possible to
| instantiate from code.
| badsectoracula wrote:
| Though Delphi's components were always meant to be for both
| visual and non-visual uses (TControl, from which other
| visual controls descent, is just a subclass of TComponent).
| mschaef wrote:
| I didn't use it as much, but my recollection is of Delphi
| being a much more coherent product than VB ever was. This
| probably stems naturally from the way the two products came
| into being.
|
| Delphi evolved from a compiler with full access to the
| underlying Windows API, with a GUI builder and framework
| layered on top. Drag a control into a form, and it was
| fairly easy to see the code behind it down to the layer of
| the Win32 API itself.
|
| In contract, VB started out as a point and click builder
| for custom Program Manager like tools, and then had MS
| Basic attached. You could drag a control into a form, but
| then there was a very clear delineation between the code
| you could write as a VB developer and the hidden, opaque
| code provided by VB itself.
| bitwize wrote:
| This was still often done in later VB. The Internet Transfer
| Control was often used by VB and VBA programmers to give
| their applications HTTP and FTP capability.
| tabtab wrote:
| What VB should have done was have an optional "utility band"
| or the like on a screen on which to place the invisible
| widgets.
| zubairq wrote:
| Very nice. As the creator of visual JavaScript I am glad to see
| something even better in the TCL world
| qwantim1 wrote:
| I once used Tcl/Tk and am glad to see it's still out there.
|
| I've recently thought of using it again for fun.
|
| I'm constantly amazed, but shouldn't be, at how things like
| Tcl/Tk, that are used by various businesses to create
| applications, don't take off into the mainstream.
|
| I think about all of the effort today on the web using
| JavaScript. That's using a language that could hardly do anything
| 25 years ago. But it wasn't OS-specific, so it beat its
| competitor, VBScript, and later beat Applets and now Flash. I
| think the momentum that inspired V8 and development of great
| sandboxes, etc. was that JavaScript early on was fun for those
| that were creating their own webpages.
|
| Tcl/Tk wasn't fun, and neither were Java's AWT nor Swing. So,
| maybe that's why they didn't stay around.
|
| However, JS isn't that fun for me either, these days. Constantly
| learning to do it "correctly" takes a lot of effort.
| flohofwoe wrote:
| Personal opinion: Tcl was lots of fun and somewhat unique in
| being both a convenient scripting language and an easily
| embeddable language. But in the end Python and Lua became
| better replacements for those two specific areas (that's at
| least how it went in my case, I did lots of Tcl in the late
| 90's and early 2ks, but then switched to Python for "cross-
| platform-scripting").
|
| There's still no proper replacement for Tk GUIs as far as I'm
| aware though, even Python uses it for building quick'n'dirty
| cross-platform UIs.
| dlundqvist wrote:
| Tcl is still fun :) We use it at work as an embedded
| language. It powers many features, and is a quite large part
| of our product.
|
| It has absolutely lost some mindshare, but I still think it's
| a great choice.
| Pet_Ant wrote:
| > but then switched to Python for "cross-platform-
| scripting").
|
| For simple scripting I've switched to Powershell (formerly
| Windows PowerShell). It's OSS, you can use it from the
| command line and it's available on Windows/OS X/Linux.
|
| https://github.com/PowerShell/PowerShell
| FlyMoreRockets wrote:
| Not sure why you are being downvoted, you aren't wrong.
|
| How does it compare to Python?
| 7thaccount wrote:
| Powershell can be pretty expressive.
|
| It has a lot in common with Python, but the syntax is
| more C like when you're scripting, but can be used like a
| standard shell as well.
|
| The learning curve is partially steep as it takes time to
| learn the advantages and complexity of piping objects
| around instead of text streams (like Linux does).
|
| The major deal breaker for me is that file reads and
| writes which are glacially slow. Like waayyy slower than
| Python if you can believe it even if you basically call
| the .NET libraries directly instead of the cmdlets.
|
| So it makes the most sense for Windows IT admin tasks.
| Pet_Ant wrote:
| The syntax is uglier, and it doesn't have anything like
| PyCharm. However, as a shell it's syntax lends itself to
| typing out on the command line. It does have this weird
| thing where you use lots of aliases to make things
| ergonomic on the command line, but tend to use the full
| name in the script. Example "ls" is "Get-Child-Item" and
| is usable on more than just directories.
|
| What sets it apart IMHO is that it return records instead
| of just string so you can declare which fields you are
| interested in instead of trying to parse the string
| output with "cut"
| RHSeeger wrote:
| > Tcl/Tk wasn't fun
|
| That is exactly the opposite of my experience with Tcl. It is
| one of the most fun languages I've used. And it's flexibility
| is without peer excluding other Lisp-y languages. So many fun
| things you can do.
| dlundqvist wrote:
| Agree. Just the other year I discovered {*}, oh how that
| simplified some things.
| beagle3 wrote:
| Until Node (when it was more than 10 years old), JS essentially
| did not exist outside the web.
|
| And other languages essentially didn't exist inside the web.
|
| So JS's success is the web's success, other explanations are
| not helpful or needed.
|
| I wouldn't characterize JS as fun either, especially not in
| comparison to Python which predates it.
| bachmeier wrote:
| > And other languages essentially didn't exist inside the
| web.
|
| Having trouble following your argument. What were people
| doing with PHP if not "inside the web"?
| Kototama wrote:
| The argument is that since Javascript was the only
| programming language running in the browser, it was bound
| to be successful with the explosion of the web ; other
| arguments trying to justify why it succeed are not
| relevant.
| andylynch wrote:
| Funny how that came back into vogue. Netscape web server had
| a JS runtime way back then. Node is way nicer to use though.
|
| I also remember around the same time it was possible to run
| TCL in browser, like Java applets.
| vram22 wrote:
| > Netscape web server had a JS runtime way back then.
|
| And "applogics", in JS, IIRC. Touched it a bit in the
| 2000s.
| beagle3 wrote:
| You could run lots of things with the right plug-in/activex
| component. And even VBScript on IE/Win. But Netscape
| Navigator was not yet dead, so the only reliable browser
| scripting language was JS.
| Kototama wrote:
| GUI builder for desktop applications in 90s were really useful
| in increasing the productivity of programmers. It is sad to see
| how complex it is to build the UI of a web application in
| comparison. And there is no definite answer on the best way to
| do it neither.
|
| Of course now you can expose your app to the whole world. But
| instead of thinking what it means at the application level you
| spend lot of brain cycles just setting up the styles and
| uncoupling presentation and logic.
| tabtab wrote:
| Indeed! I've been trying to figure out if we MUST sacrifice
| such productivity and K.I.S.S. to get web or web-like
| features for rank and file CRUD intranet apps. Are the
| bottlenecks solvable? Related debate:
|
| https://www.reddit.com/r/dotnet/comments/kn20yi/start_with_a.
| ..
| dmux wrote:
| I wonder if we'll ever see a middle ground take over where
| apps are developed in that 90's GUI builder style but instead
| of purely desktop applications, they're more akin to tiny
| internet applications like this idea from Rebol:
| http://www.rebol.com/reblets.html
| Kototama wrote:
| Did you try that? Was it good?
| dmux wrote:
| I've never tried it, no. Just something I've read about
| in the past and it seems like something that could be
| easily done with Tcl and its "safe" interpreter
| mechanism.
| [deleted]
| GnarfGnarf wrote:
| I'm trying to compile SQLite from source, which requires Tcl.
|
| I'm getting many errors in what should be a "vanilla", hassle-
| free, off-the-shelf process. The 32-bit Tcl test suite fails with
| cryptic unresolved externals, whereas the 64-bit build only fails
| one test.
| tyingq wrote:
| As far as I know, it's not a hard dependency. I believe if you
| just build from the autoconf download after deleting the
| tclsqlite.c file it works fine.
| bsdooby wrote:
| Native Client (NaCl) comes to mind.
| pjmlp wrote:
| Back in the day Active State also had similar tooling support on
| their Tcl IDE.
|
| https://www.activestate.com/products/tcl/
| Aldipower wrote:
| The products from Active State were my choice of love before
| Sublime Text got popular. They had a very good workflow in my
| opinion. Only downside was the performance of the IDE, but
| still way better then Ecplise.
| sigzero wrote:
| There's a Tcl blast from the past.
___________________________________________________________________
(page generated 2021-01-27 23:01 UTC)