5 ms·

Too bad Tk was replaced by wx-widgets, otherwise it could be OTPCL/Tk ;) My main usecase for Tcl/Tk was gluing some legacy and adding some GUI on top of it. Wi

Too bad Tk was replaced by wx-widgets, otherwise it could be OTPCL/Tk ;) My main usecase for Tcl/Tk was gluing some legacy and adding some GUI on top of it. With Erlang/OTP one can easily glue and orchestrate distributed code, GUI is not as easy as in Tk, since Erlang is much more verbose and wx is more complex than Tk. Any plans to support Elixir too?

yellowapple 8y ago
I haven't tested use from Elixir yet, but in theory it should Just Work™ (e.g. by calling :otpcl.eval/1). This will be even easier once I do publish it on hex.pm, since (again: in theory) it should just be a matter of including it as a dependency in your app's mix.exs. One of my first Elixir-specific goals will probably be to integrate this with Plug (and particularly Plug.Router, producing a cool hybrid between Plug and OpenBSD's pf/httpd/relayd config files). But yeah, OTPCL/Tk would be pretty sweet, even if it has to be emulated through wxWidgets (or even through something HTML/JS-friendly; I've always dreamed of being able to generate web pages via a Tk-like API and programming style).
- sbuttgereit 8y ago
  OTPCL/Scenic OK... You'd probably need an additional library (that may not exist yet) for the widget aspect... But it moves the needle a bit... https://github.com/boydm/scenic https://github.com/boydm/scenic
  - yellowapple 8y ago
    Oh hell yeah. Had no idea this existed; this is awesome.
    - nivertech 8y ago
      I was going to mentioned Scenic... The only dependency Scenic needs is OpenGL driver. I was never able to build Erlang's wx app on my Ubuntu laptop, but with Scenic it just works out of the box. IMO Tk's canvas widget can be relatively easily ported to Scenic as both based on retained mode graphics, only in Scenic each item on the canvas will be represented by a gen_server.
      - yellowapple 8y ago
        Yeah, a one(-or-more)-process-per-widget approach is exactly how I'd envision an Erlangy GUI framework (and is effectively how ordinary Tk works, except with tasks/events processed by an event loop instead of Erlang's preemptive multitasking). Scenic looks like a great starting point in that direction. I wonder how Wings3D does things? I'd imagine it uses wxWidgets, but I never actually thought to check...
deleted 8y ago
[deleted]
kazinator 8y ago
In a nutshell, the Tk GUI, to my understanding, is basically a C GUI library. A lot of its widget code is written in Tcl, so that using Tk in an application requires embedding the Tcl interpreter. Using Tk, but replacing that Tcl interpreter with one's own is likely possible, but almost certainly a big project, possibly resulting in a complicated fork of Tk. So simply bringing back Tk wouldn't do anything without a lot of additional work. One simpler possibility, though, would be to have a delegating API in the OTPCL which just forwards down to the Tcl/Tk, so that it would look like OTPCL is integrated with Tk.
- yellowapple 8y ago
  Indeed; OTPCL already diverges significantly from Tcl in very important ways that would be very hard to change while still maintaining some semblance of compatibility with Erlang and the broader ecosystem thereof; if I were to literally integrate Tk itself, that would indeed be... involved. I do like the idea of delegating to actual Tcl for a Tcl/Tk bridge, at least for something quick-and-dirty; a run-of-the-mill Erlang "port" written in Tcl ought to be an effective first pass at going about that. It should be easy to do. In the longer term, a toolkit geared specifically toward Erlang's strengths (e.g. each widget having its own process, message passing instead of callbacks, etc.) seems like it'd be a more valuable contribution to the Erlang ecosystem, even if it'd be harder than even trying to bridge OTPCL with Tk directly. Ideally OTPCL/$TOOLKIT should be as dead-simple to use as Tcl/Tk (and should be straightforward even if you swap out the "OTPCL" part of that with Erlang/Elixir/LFE/Joxa/LuErl/ErLog/etc.).

yellowapple 8y ago

I haven't tested use from Elixir yet, but in theory it should Just Work™ (e.g. by calling :otpcl.eval/1). This will be even easier once I do publish it on hex.pm, since (again: in theory) it should just be a matter of including it as a dependency in your app's mix.exs. One of my first Elixir-specific goals will probably be to integrate this with Plug (and particularly Plug.Router, producing a cool hybrid between Plug and OpenBSD's pf/httpd/relayd config files). But yeah, OTPCL/Tk would be pretty sweet, even if it has to be emulated through wxWidgets (or even through something HTML/JS-friendly; I've always dreamed of being able to generate web pages via a Tk-like API and programming style).

sbuttgereit 8y ago
OTPCL/Scenic OK... You'd probably need an additional library (that may not exist yet) for the widget aspect... But it moves the needle a bit... https://github.com/boydm/scenic https://github.com/boydm/scenic
- yellowapple 8y ago
  Oh hell yeah. Had no idea this existed; this is awesome.
  - nivertech 8y ago
    I was going to mentioned Scenic... The only dependency Scenic needs is OpenGL driver. I was never able to build Erlang's wx app on my Ubuntu laptop, but with Scenic it just works out of the box. IMO Tk's canvas widget can be relatively easily ported to Scenic as both based on retained mode graphics, only in Scenic each item on the canvas will be represented by a gen_server.
    - yellowapple 8y ago
      Yeah, a one(-or-more)-process-per-widget approach is exactly how I'd envision an Erlangy GUI framework (and is effectively how ordinary Tk works, except with tasks/events processed by an event loop instead of Erlang's preemptive multitasking). Scenic looks like a great starting point in that direction. I wonder how Wings3D does things? I'd imagine it uses wxWidgets, but I never actually thought to check...

deleted 8y ago

[deleted]

kazinator 8y ago

In a nutshell, the Tk GUI, to my understanding, is basically a C GUI library. A lot of its widget code is written in Tcl, so that using Tk in an application requires embedding the Tcl interpreter. Using Tk, but replacing that Tcl interpreter with one's own is likely possible, but almost certainly a big project, possibly resulting in a complicated fork of Tk. So simply bringing back Tk wouldn't do anything without a lot of additional work. One simpler possibility, though, would be to have a delegating API in the OTPCL which just forwards down to the Tcl/Tk, so that it would look like OTPCL is integrated with Tk.

yellowapple 8y ago
Indeed; OTPCL already diverges significantly from Tcl in very important ways that would be very hard to change while still maintaining some semblance of compatibility with Erlang and the broader ecosystem thereof; if I were to literally integrate Tk itself, that would indeed be... involved. I do like the idea of delegating to actual Tcl for a Tcl/Tk bridge, at least for something quick-and-dirty; a run-of-the-mill Erlang "port" written in Tcl ought to be an effective first pass at going about that. It should be easy to do. In the longer term, a toolkit geared specifically toward Erlang's strengths (e.g. each widget having its own process, message passing instead of callbacks, etc.) seems like it'd be a more valuable contribution to the Erlang ecosystem, even if it'd be harder than even trying to bridge OTPCL with Tk directly. Ideally OTPCL/$TOOLKIT should be as dead-simple to use as Tcl/Tk (and should be straightforward even if you swap out the "OTPCL" part of that with Erlang/Elixir/LFE/Joxa/LuErl/ErLog/etc.).