Attending the Tcl 2002 conference, I saw a number of presentations that mentioned in passing a problem that I am dealing with in my application:

Automatic (or semiautomatic) generation of Tk GUIs based on metadata descriptions.

The applications of this take several forms.

• GUI builders need to interpret user gestures into code to build an interface
• Some XML applications interpret XML to produce user interfaces for editing values

I can see where a front-end/back-end system of reading and interpreting file contents or user gestures then calling constructors to build the interface might make some sense.

Here are the questions:

• Is there such a library now?
• If there were such a library, how would you expect it to be used?
• If there were such a library, how would you expect it to be organized?

Conceivably, the generated interface might be on one system connected to a remote system.

Thoughts? Pointers to wiki pages?

escargo

---

Traditionally, this sort of thing has been done via the option database I believe; I think Brent Welch's book describes how to do it. XML seems like a nicer solution to me, though. But I don't think I'd tie "user gestures" in too strongly. On the other hand, it's easy to see how a GUI Builder could store the program's structure as a DOM tree, which could then be loaded and saved as an XML document. Then, if they were ordered appropriately, the app could avoid the cost of including the DOM by parsing the XML document as a sequence of streaming events (a la TclXML) and building the app as it goes. -- WHD

---

I've done this sort of thing for years, though the specifications themselves have tended to be static (in some sense). Take a look at the GUI code used to configure the tiprender system [1] which reads a stylized GUI specification from a file and builds (and runs) the whole GUI based on that. -- DKF

---

It's true that the GUI builder could and should store the interfaces' current definition somewhere (so you can save and edit it later), but if your GUI builder has a button for creating a widget, some version of the widget needs to be created as soon as the button is pushed. That's the kind of "user gesture" I had in mind.

I see a process of perhaps three parts:

1. Reading the file or interpreting the gesture to determine the intent
2. Calling some helper to generate the tcl code that matches the intent
3. Either storing that code or executing that code to make the actual interface appear.

One problem I am wrestling with right now is figuring out the right way to bind the generated data entry widgets to an appropriate data value.

Let me try to make that more clear. It would not be far off to describe my application as a data base interface, where there are business logic rules in addition to data base referential integrity checks that ensure that values in the various record fields are valid.

Some of the validity checks must be done when values change. Some of those validity checks must be done considering other values in the same record (think of validating an IP address and a subnet mask). Other times the values in the record are foreign keys that must be present in other tables.

What I need to be able to do for each entry widget (whether automatically generated or not) is associate with it the field name and structure name that controls its validation. (It would also control what time of entry widget was constructed dynamically, since I have typing information available also.)

I can think of these ways to do the association.

1. I can try to embed the field name and record type into the widget name path.
2. I can construct a table that maps the widget name path to a value that contains the field name and record type.
3. I can set the validatecommand to call a validation proc with the additional parameters that I need (added 25 Sep 2002).

The latter method is probably the most flexible. If there are better ways of doing this, I look forward to being educated about what they are.

escargo

---

See also (links added as they are found)

• Menus made easy
• MetaGUI I believe is one approach to data driven tk programming. AEC

---

Is there any documentation on the format of the .ui files associated with SpecTcl? They are one example of the serialization (storage format) for GUI specifications.

escargo

---

AM I just created a small package called "Poor man's GUI" - just the thing that might be useful here. See the Wiki page A poor mans GUI.

---

A couple of conferences ago, stevel presented a paper on kitview.

---