ex11 - brain dump 3

[Vlad Dumitrescu]

Hi,

I have som more thoughts about the widget framework:

** widget framework should be independent of rendering system (X11 in this
case), this way same widgets could be used for example with an OpenGL renderer
(in Wings)
    - what are the dependencies? Input events are easy to abstract out, because
they're just messages; so the problem is with drawing.
        One way would be to put all drawing code in a separate module, and use
it's name as a parameter. This can also be used to implement different
look-and-feel UIs for one renderer.
        The downside is that one widget's code is distributed.

        A variant would be to have the Widget:Draw() function receive an
argument that names the renderer/look-and-feel.
        The downside is that in order to add new renderers one has to edit all
widget files (and maybe one doesn't have the sources).

        Another way would be to combine the above: check for a local function
first, and if it doesn't exist, look for another module that implements a draw()
for the current widget.


** there is also another side of extensibility, i.e. when it comes to behaviour.
A button shares some functionality with a text field; a tri-state button even
more so with a regular button; and so on... The question is: how to make this
common functionality available without having to resort to cut-and paste?

        Since the red thread in this situation is event handling, then the first
solution that come to mind is to have a chain of processes, where the topmost is
the most specialized and where "unknown" messages are passed on downwards.
            The drawback is that there can be many more processes than strictly
needed, but each one is simple and can be a standard gen_server. Also the
asynchronous nature of this interaction may cause problems.

        One can also use only one process that holds a list of callback modules,
and goes down in it when no handler is found.


** It may be argued that reading programs will be more difficult, because all
functionality is no longer locally defined, but I think it's just the same thing
as with gen_server for example: once the framework is in place and stable, one
"knows" what it does behind the scenes and starts from that when building on. It
is a price to pay for being able to reuse basic functionality, for flexibility.

best regards,
Vlad