Redundancy in initarg names

[j3pic]

I saw this, and it left me somewhat disappointed:

(define-example drop-files (screen)
  (let* ((window (windowing:make-window screen :class 'custom-window))
         (focus (make-instance 'alloy:focus-list :focus-parent window))
         (layout (make-instance 'alloy:border-layout :layout-parent window))
         (label (alloy:represent "Drop some files here!" 'alloy:button :focus-parent focus :layout-parent layout)))
    (setf (slot-value window 'label) label)))

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 the parent 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 to parent 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 a child mixin class that provides the parent field.

[Shinmera]

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.

[Shinmera]

I agree that there should be ways to create the UI more easily, but there simply isn't any redundancy here.