[rgui-dev] Tom's yaml interface definition

[Thorsten Roggendorf]

Hi,

it needed some time to sink in ... what you wrote there really looks
amazing.
Various confused thoughts:

Should toplevel not be on the next indention level?
model: eclipse
toplevel:


I wanted to test how extensible your concept is and started modularizing
our eclipse app to get reusable parts:

model: file_dialog
  toplevel:
    name:
      entry:
        name: file_dialog_title
        value: 'Please enter filename:'
    container:
      name: file_selection
      [... tree view, file selection and entry]
    container:
      name: action
      action:
        name: ok
        label: Ok
        callback: file_dialog.ok
      action:
        name: cancel
        lable: Cancel
        callback: file_dialog.exit

model: file_menu
  name: file_menu
  uses: file_dialog
  attribute:
    name: file_name
    type: string
  type: menu
    action:
      name: open
      lable Open
      callback:
        function: file_menu.open
        attribute: file_menu.file_name
    action:
      name: save
      lable: save
      callback:
        function: file_menu.save
        attribute: file_menu.file_name          
    action:
      name: save_as
      lable: Save as ...
      callback:
        function: file_menu.save_as
        attribute: file_menu.file_name
    action:
      name: exit
      lable: Exit
      callback: file_menu.exit



[...]
    container:
      name: filemenu
      type: menu
      label: File
      module:
        include: file_menu
        extension:
          between: save_as, exit
          action:
            name: close
            lable: Close
            callback:
              function: eclipse.filemenu.close
              attribute: eclipse.filemenu.file_name
[...]

So far I did not encounter something that could not be expressed that
way. However there might be room for simplification.

What I called function in calllback might be generated automatically.
Having to write it out might add flexibility though. This is a tradeoff
we will often have to face. The attribute or return parameter or
whatever could turn out to be essential though.

The seperate attribute in the file_menu is needed to allow the client
app to determine the filename by other means and have filemenu generate
the file_menu.save event without instantiating file_dialog first.
The uses clause in filemenu might be simplified away too. The file_menu
will decide for itself if it needs to invoke file_dialog on a save
event. If the attribute file_name has a value it will skip the
file_dialog.

I also used callback without defining function and attribute. That way
the argument becomes the argument of function. The thing starts becoming
messy already. We have introduced a dozen keywords and now I start
messing everything up. Damn.

General remarks. The event clause is indeed very interesting. I don't
know if this a problem, but if you have more than one action bound to an
event, the execution order is undefined. This problem does not occur in
the gui-toolkits I know.

I can't imagine that what we are talking about has not been tried
before. Once you think into it the whole thing becomes so obviously
useful - indeed an essential technology - that I can't imagine other
people have not already tried it. This smells of university project.
A prominent technology that lies in our target direction is IDL, the
Interface Definition Language. That one only targets APIs and component
models (CORBA) though, without addressing GUIs or other interface types.
I googled a (tiny) bit, but if other people tried the same as we, their
signal is lost in the IDL noise.

Language choice:
What I really like about your choosing yaml is its supreme readability.
For this stage of communicating ideas, it seems well suited (maybe I
should learn it before evaluating it though ...). However, if this ever
gets beyond the stage of enthusiastic brainstorming, we should think
about other options too.

Cheers

   Thorsten