Re: [Bug-apl] Tk/Tcl interface

[Elias Mårtenson]

I'd love to add trace (step) functionality to the Emacs mode, if the underlying functionality is available. Jürgen?

A native library for sockets is an obvious feature to add. It should be rather trivial to do so.

GUI interface is, in fact, less important in my opinion. These days most people do GUI's using web technologies anyway.

Regards,

Elias

On 22 April 2014 22:12, Blake McBride <address@hidden> wrote:

I know the history of J, and I agree with what they did.  I also fully agree with your observations regarding Tk.  GTK+ is a far better choice than Tk.  There is one important difference though.  Integrating GTK+ is a huge job!  Integrating Tk is much easier.  Bang for the buck, Tk is a good first pass at enabling a GUI interface of some sort.

The work done on APL's file systems and code cleanups are far more important to me.  I just think that adding sockets and a GUI interface at some point would present GNU APL as a total solution.  Having said all that, however, I certainly think the present course of tightening up the code, adding more standard APL facilities (trace, stop, etc.), and a file system are top priority.  I am just bring up some of theses ideas.

Thanks!

Blake

On Mon, Apr 21, 2014 at 9:52 PM, Elias Mårtenson <address@hidden> wrote:

The J community seems to be pretty excited about their QT interface. Tk is easy to use, but results in horrible-looking applications that doesn't integrate well with the rest of the interface.

If I were to implement support for a GUI framework, it'd be either GTK+ or Android, depending on whether I wanted to target desktops or mobile devices.

That said, I have no intention to do either so my opinions on this matters approximately this much: ⍬

Do you have plans to implement this Tk support? If so, I will applaud your efforts and my preferences for other frameworks will not stop me from helping if I can.

Regards,

Elias

On 22 April 2014 09:30, Blake McBride <address@hidden> wrote:

Just an idea.