Skip to content

Simplify and modernize API #9

@emmt

Description

@emmt

Implementation of interface to Tcl is quite complete but it has some complexity that could be avoided to the cost of breaking changes. This issue is to start a discussion about these proposed changes.

Only one shared interpreter

TclTk let you create several interpreters private ones and shared ones. A shared interpreter is the one used by default if no interpreter is specified. Due to the constraint that an interpreter can only be used in the thread where it was created, there is currently a shared interpreter per Julia thread. In practice and since Julia taks can migrate to another thread, this is not practical. The proposition is to have a single shared interpreter which is used by default and which runs on the main Julia thread and to use the same approach as Tk.jl: if a Tcl command is to be executed from another thread, it creates a channel to push its request to the timer task managing the communication with Tcl (and running in the main thread) and blocks until this yields a result (or an exception).

Separate Tcl and Tk sub-modules

The main use of TclTk is to create a GUI. This task must be as simple as possible and the code be as redable and understandable as possible. It is proposed that TclTk has a number of sub-modules:

  • TclTk.Tcl to implement the management of Tcl objects (allocation, conversion, etc.), of Tcl interpreters (one shared and, possibly, several private as explained above), to run the event loop, to deal with variables, to evaluate scripts (via TclTk.Tcl.eval), to execute commands (via TclTk.Tcl.exec), and run callbacks.

  • TclTk.Tk to implement Tk methods, widgets, and images. For simplicity, it is proposed that this module only uses the single shared interpreter so there is no question about where live the widgets and images.

  • TclTk.Ttk for Themed Tk widgets like in TclTk.Tk.

Themed widgets are the default ones

It is proposed to have Button, Label, Frame etc. default to the themed version. When no Ttk counterpart exists (e.g. Menu, Text, Canvas, or Toplevel), the Tk widget is the default. In any case TclTk.Tk.WidgetClass or TclTk.Ttk.WidgetClass can be used to choose a specific version of WidgetClass.

Sub-commands

It is proposed that widgets have sub-commands, for example for a canvas w, w.find_withtag(args...) is a better syntax compared to TclTk.Tcl.exec(Int, w, "find, :withtag, args...). Common widget sub-commands are cget and configure.

Fetch Julia objects/values from Tcl object

In some cases, it is needed to efficiently retrieve Julia object/value of a known type T from a Tcl object, possibly, from an item of a list of Tcl objects. However, (i) Base.convert(T, obj) can only work to convert the whole object obj, (ii) some objects (currently Tk images or widgets) require an interpreter (not just obj), and (iii) the syntax obj[i => T] is implemented to convert the i-th item of obj considered (and is more efficient than convert(T,obj[i])) but introduces a weird syntax style in Julia code. It is proposed to extend a method like fetch to cover most of the needs:

x = fetch(Float64, obj) # like convert(Float64, obj)
x_i = fetch(Float64, obj, i) # like convert(Float64, obj[i]) or obj[i => T]
w, x, y = fetch(Tuple{Widget,Int,Int}, obj, 2:4)

The last case is typicall of a callback invoked for a mouse event bound with arguments "%W %x %y" with obj the list of Tcl objects representing the arguments of the callback (the 1st one being the name of the called command). With this, the code is efficient (no temporaries), redeable, and compact (several arument can be fetched).

Simplify callback mechanisms

There are typically two cases where callbacks are needed: as the argument of a -command option (e.g. in a button widget) or bound to an event. There should be some simple syntax to do this. In the 2nd case, a possible syntax could be something like:

bind(widget, "<ButtonPress-1>",  (on_click, :W, :x, :y))

to call Julia function on_click with the wiget path and the mouse coordinate (the symbolic notation of arguments is reminiscent of the percent notation for Tk events).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions