Re: [boost] Re: GUI Library Proposal for a Proposal

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-11-16 17:24:54

> > > >>>The FOX GUI has exactly this capability, you can connect a variable
> > directly to the widget, without requiring any glue code at all.  In fact,
> > you can connect the same variable to multiple widgets at the same time (eg
> > a 'spinner' widget and an 'editeline'), without requiring the programmer
> > to write any type of callback mechanism.
> > > >>>
> > > >>>This works because all GUI events are bi-directional.  For more
> > information, read: http://www.fox-toolkit.org/datatarget.html
> > > >>>
> > > >>
> > > >>That seems a lot of code, compared to:
> > > >>http://www.torjo.com/win32gui/save_dlg.html
> > > >>Not to say about validation...
> > > >
> > > >
> > > > The problem with this implementation is that the 'user_name' field
> > cannot (usually)
> > > > connect to more than one widget at a time.
> > >
> > > That is a current limitation, but I don't think you need it so much.
> > > Anyway, you can work around it, by listening to kill_focus events:
> > > - you will have temporary variables, and each is bound to a control.
> > > - You listen for kill_focus from these variables
> > > - on kill_focus, you synchronize the temporary variables
> >
> > Thats a hack, plain and simple... and it requires the application
> > programmer to synchronise the state of these variables -> it should be a
> > capability within the GUI library.  What I am suggesting is that the
> > technique described, is added as a native capability to the library so
> > that this error-prone code is eliminated.
> [snip]
> 
> It wouldn't be very difficult. You can track which widgets are bound to a
> given datum and signal them all when its value changes. You would need that
> capability anyway if you ever wanted to display data that change for reasons
> other than user input. But you still have to detect the changes, and that's
> the tricky part to generalise.

No its not difficult - there is a library framework that already supports this capability, and it is trivial to use.  You dont want to force the programmer to remember to synchronise the widget state to the state of the variable, every time the variable changes value -> this should be automatic, and transparent.

> In the end you're going to have a hard time
> completely avoiding writing special-case code for data that need to update
> their attached views.

Only for complicated widgets like tables, maybe a treelist.

> > > > Also, most widget libraries dont allow you to connect a variable to
> > a widget,
> > > >and still allow user validation.  This is because the widget library
> > >  > doesn't callback into the validation code,
> > > > since it assumes that if it is connected to a widget, then no
> > validation code is necessary.
> > > >
> > >
> > > That's the win32gui' advantage :)
> > >
> > >
> > > "if it is connected to a widget, then no validation code is
> > necessary."
> > > - that really sounds silly.
> >
> > Not really, there are two reasons why validation code is not necessary.
> >
> > 1. User validation always needs to be done by your business/process
> > rules.
> >    -> When the 'go' event is generated, your app should validate the
> > application variables (some of which will be connected to widgets).  The
> > validation will need to reset any variables which are in an out-of-bound
> > condition (this implies that the GUI will need to re-synchronize to the
> > new state of the variables).  I wont comment on whether it is good to
> > intertwine business logic within GUI update code....
> 
> You might want to provide feedback as to the validity of fields before the
> dialog is finished. Java does this all over the place and it's enormously
> helpful (it's one of the things that makes Eclipse lovely).

I didn't say that this wasn't possible, I just said that you shouldn't need to synchronise the validated value to every other widget.  Validity and widget-synchronisation are orthogonal problems.

> > 2. Some widgets dont need validation eg: spinner, combobox, slider...
> > These almost never need validation, since they are only ever populated
> > with valid values.
> 
> Unless there's some dependency between fields such that, for example,  the
> values listed in a combo-boxexclude certain other choices from another
> combo-box.

then why put those values in the combobox?  Offering a user some form of static list, then disallowing them to choose one of them, is bad UI design...

In any case, widget-synchronisation doesn't preclude validation.

> > > For case 3., you might also have a validation function which will be
> > > used in design-mode to validate user input.
> > >
> > > At least that's what I want.
> >
> > I'm not sure that is valid.
> >
> > Take a TreeList as an example.  The items in a treelist are almost
> > always sub-classes, based on some type of generic 'TreeItem' class.  I'm
> > not sure that a TreeItem can always be represented as a string.
> 
> I'm not sure that a TreeItem can be represented as anything other than a
> string, on some platforms.

I'm not sure why a treeitem would be platform dependant, but I can think of a few examples where a treeitem may not be a string, eg: a CAD program may use a treelist to represent things that can be drawn -> the item itself may contain many megabytes of 'property' data -> I dont thing a string would accurately represent the tree item.

> > Also, the position of a treeitem (within the treelist), may not
> > necessarily be able to be stringified.
> 
> Would it be important? Couldn't it just come out as a vector of ints if you
> really needed it?

no - parent / child relationship may be important, and the items in the list may not be enumerable.

A table widget is another example where the cells may or may not be able to be represented as a string, and not be (efficiently :-) vector'izable.

regards,
Mathew