[GUI] Another stateful issue, and a proposal for the solution of all those
Vincenzo Ciancia
ciancia@cli.di.unipi.it
Tue, 1 Apr 2003 22:35:34 +0200
Well, I promise this is the last feature request for state handling. I
want... linked variables! For example a function
link :: (a -> b) -> (b -> a) -> Var a -> Var b -> IO ()
when one writes to one variabile, the other gets written and vice-versa.
This is not as easy as it seems (see the Ports library for issues), but
can be done in various ways. It's useful when, for example, you want a
scrollbar that control a numeric, user-writable textbox. You really want
the two values to be synchronized!
Also, this is useful for easy persistence of attributes.
I am not sure the issue is generally solvable with filters only, like
locking, but I guess so. Maybe it needs the ability to get any value
that is *actually* written in the state, after all the filters have been
processed.
However, since it's clear that this state handling problem is longer to
solve than I expected, but it's also clear that some of the problems
that could arise needs to be handled now, or they will cause trouble
forever (think about how would you implement filters if you had not
them) I see three possible ways to keep on working:
1. Decide what of all the features that have been mentioned are really
necessary, and identify primitive and derived features among those, then
implement the thing.
2. Decide a minimal set of features (for example: create, get, set) that
a "variable" needs to have, and just be prepared to extend that
interface. This allows people that are not interested in subtle state
handling techniques (wich are more high-level than mid-level) to start
working on the widgets.
3. Decide the same minimal set of features, wich are the only one used
in the construction of the base widgets, and allow the functions to be
changed like other attributes. For example, we say that the features
that are necessary to implement widgets are create, get and set. Then we
allow the programmer to pass its own functions to a button, and the
button will use these three functions to create, get and set its
attributes. This allows to add e.g. filtering capabilities to the
existing library in a second moment, and be sure that any other library
that uses the get/set interface also gets "filtered".
Note that combo of 1 and 2, and of 1 and 3 are possible, and if we
choose 1, we are really getting "extended 2".
If I haven't been clear, just ask; I would like to hear what you all
think about this.
Vincenzo