Closed j3pic closed 1 year ago
The point is that in alloy the focus tree and the layout tree are explicitly separate. This does create more work as you need to manage both, but is necessary in order to provide meaningful navigation in contexts without a pointer device.
I agree that there should be ways to create the UI more easily, but there simply isn't any redundancy here.
I saw this, and it left me somewhat disappointed:
It would be convenient to have a macro that allows one to define the parent/child relationships between GUI elements declarative, HTML-like manner. There's an example of such a thing for Racket's GUI library.
The Racket library relies on the fact that every GUI element has a
parent
, so it can just derive theparent
from the element's place in the macro body.But you couldn't write something like this for Alloy because there'd be no way to programmatically determine that the parent of one type of object is the
:focus-parent
, and the parent of another type is the:layout-parent
, and so on. You can't even derive the prefix toparent
from the name of the class.This is probably being done to avoid name conflicts in the case of multiple inheritance. Perhaps instead of each class having its own
parent
field, there could be achild
mixin class that provides theparent
field.