Wed Jan 14 09:44:16 CET 2004
I thought I'd share some random and unsorted thoughts I had about a widget
framework. Nothing revolutionary, but why let them go to waste? :-)
* widget users should see only generic events, not X ones. By that I mean there
should be a generic protocol (as is sketched in ex11_widget_button) for example
onClick, onDoubleClick, onEnter, onKeyPressed, onMouseMove, onMouseButtonDown,
etc. Maybe even onCreate, onDestroy?
* the event handlers should get the widget pid as an argument, so that they can
react according to the current state. For example draw_button() paints slightly
different if the button is pressed.
* the !! operator is cool, but it should be used with care. Maybe the
implementation of sysd:rpc should be refined to include timeouts and the
possibility to get the reply later (à la gen_server). The reason is that if
there are several widgets interacting (i.e. their states are interdependent)
it's very easy to get a deadlock.
For example radio buttons work as a unit.
* there is some GUI functionality that isn't local to a widget (even if it may
seem to be). For example tab order is known at parent window level, so the
parent window should get the opportunity to see keypresses before the child,
filtering tabs out (unless the child specifically wants to get them).
* there will be quite a bit of functionality common for many widgets. I think
there should be a way to reuse it without resorting to cut-and-paste techniques
;-) I won't mention inheritance (oops, I just did!) because there are other
ways - like for example providing plenty of hook points and functionality for
adding/removing custom hooks (à la Emacs).
For example implementing a tri-state button would require very little
changes to a regular button.
* It would be good if we could find an existing framework from which to map the
functionality. There's no need to make all mistakes from scratch. Most
frameworks are OO and make heavy use of inheritance, which is not a good
starting point, but see above.
That's it for now. Cheers!
More information about the erlang-questions