[boost] Re: GUI Library Proposal for a Proposal

From: George van den Driessche (grebe_at_[hidden])
Date: 2004-11-16 09:26:34

> Message: 10
> Date: Tue, 16 Nov 2004 13:53:14 +1100
> From: "Mathew Robertson" <mathew.robertson_at_[hidden]>
> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal
> To: <boost_at_[hidden]>
> Message-ID: <018801c4cb87$7bf2cdf0$a901000a_at_mat>
> Content-Type: text/plain; charset="iso-8859-1"
>
> > >>>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. 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.

> > > 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).

> 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.

> ------------------------------
>
> Message: 11
> Date: Tue, 16 Nov 2004 13:57:22 +1100
> From: "Mathew Robertson" <mathew.robertson_at_[hidden]>
> Subject: Re: [boost] Re: GUI Library Proposal for a Proposal
> To: <boost_at_[hidden]>
> Message-ID: <019e01c4cb88$0aea6220$a901000a_at_mat>
> Content-Type: text/plain; charset="iso-8859-1"
[snip]
> > Even reflected property types should be of trivial types:
> > 1. build in types
> > 2. std::string
> > 3. types that can simply be read from /written to strings.

I don't agree with this either, but:

> > 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.

> 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?

George