Adobe Source Libraries (ASL): Adam and Eve

I finally read the introduction to Adobe’s ASL GUI system, and its Adam and Eve parts. Ralph Thomas has been using it to write his Mission Photo application, so it seems to work. It’s great to see the rationale documented publically, and I guess that Adobe will profit from the feedback. Design is so much easier when you can bounce ideas off someone. I notice that the overview document is dated December 2004, so I’m late with my feedback.

Eve seems to be a UI layout description format, much like Glade (including the use of widget identifiers that are looked up later, from code with libglade, or from Adam with ASL), but without specifying actual specific widget types, so it’s “button” instead of “GtkButton”. It’s nice that it uses generic widget names, which are later realised as actual GTK+, MacOS, or Windows UI parts. It’s annoying to me that it doesn’t use XML, which could make the structure more obvious.

The documentation makes a big deal of automatic layout, without calling it that, but that’s the only sane way that anyone does layout now anyway, so that alone is not enough to make this useful. But it’s understandable that this is an issue for them, because these guys built their code base with the awkward MacOS classic APIs, and then the crappy Win32 APIs, which demand fixed per-pixel layout and implementing your own event loop. I’ve been there. GTK+ does this for you.

Adam seems to define (declaratively) how the widgets behave. Adam files seems to be made up of sheets (maybe equivalent to a dialog, or maybe a user operation, I’m not sure), and cells (though that name is not mentioned explicitly in the syntax). Adam files specify the properties of a widget in terms of the properties of another widget, so that, for instance, a widget can be deactivated if another widget is unchecked. I guess it can do more than just simple boolean logic and mathematics, but this is where it feels like I’d need some real programming to get real things done.

But it’s a nice idea if it can work without getting in the way. We have grasped at similar things in GTK+, for instance by specifying that the keyboard mnemonic for one widget (a label) can activate another widget (an entry next to the label), plus our accessibility data that expresses higher-level relationships between the UI elements. But we haven’t generalized it. Paul Pogonyshev posted on the gtkmm list and on the libsigc++ list.recently about something like this, but I don’t think the result was useful enough, possibly due to the limitations of a statically-typed language. It would be nice to solve common problems more concisely.

Adam and eve introduce several new terms (model, command, cell, sheet, field) which leaves plenty of scope for confusion, particularly because these names seem quite arbitrary and they have several existing meanings. I think I’d use more explicit names, such as data-field, if it was my project.

As far as I understand, the system expects you to think of a UI (such as a dialog) as a way to generate a command, and ASL can represent a model of this command, though “model” is a confusing name for it. This command, produced by the view (UI) is then used to transform the document model (the data). That doesn’t sound very suitable for rich interaction, but obviously it works for Photoshop and Mission Photo. Possibly you can update your application state somehow in response to individual changes to UI widgets, to allow instant-apply.

Corrections are welcome.

4 thoughts on “Adobe Source Libraries (ASL): Adam and Eve

  1. Hi Murray,

    A few notes :):

    Eve is a bit more powerful than Gtk+’s layout system as it also takes into account “guides” such as the baseline of a widget or the end of the label on (say) a popup or edit_text widget (note also that labels are included with the widget which simplifies the UI definition a lot). Unfortunately I’m not sure how to get things like baseline out of the Gtk+ widgets, so I’ll probably end up just vertically centering all widgets in a row (which seems to be what Gtk+ does) for the Gtk+ implementation in ASL.

    Also, Eve isn’t tied to any particular UI toolkit or wrapper implementation, so you can use it for laying out all kinds of things. I’m planning on using it to layout the DVD menus that will be generated by the next version of Mission Photo.

    Mission Photo doesn’t really make good use of Adam at the moment (especially as I’ve tried hard to stay away from dialogs with more than a few widgets and popup windows!). Currently Adam is really useful for doing dialog models — especially for dialogs that have complicated rules; the Photoshop image resize dialog is a good example of this (there are something like 27 different inputs into the model in that dialog).

    Finally, if you’re into c++ ASL has quite a few very useful libraries in it. Things like regular_object are really interesting (to me, at least ;)).


  2. I reread what you wrote about Eve again. There are no widget ids that get looked up in the code. The “bind:” parameters bind widgets to cells in the sheet directly — the C++ code that opens the dialog never gets to touch any of the widgets directly. If you want to change the value that’s displayed by a widget then you can change the value of the cell that the widget is bound to (assuming it’s bound to a simple cell, and not to a cell which is calculated from other cells).

    The “name:” parameter creates a label that goes next the widget.


Comments are closed.