Subject: Re: [boost] [rfc] cppgui
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-07-06 03:06:08
>
>>> We need to concentrate on properly describing the data first. A
>>> language (c++ or other) that says 'this data is a number (with min max
>>> etc)' or not only is this a string, but it is an email address (so
>>> that interfaces like the iPhone can adapt with @ symbols etc).
>>
>> How do you intent this to work, without having to define all possible
>> cases up-front, allowing extensibility?
>>
>
> A few thoughts:
> - Start at the bottom - with known data types (int, float, string).
> - use a capabilities hierarchy. ie a generic string-editing-widget
> can be used as a number-editing-widget, just not the best one.
> Similarly it can be a date-editing-widget, etc.
> - As a widget-author, all you need to do is to "publish" your widget's
> abilities. ie a single string that describes your widget.
> "NumberEditor". Eventually we build up a standard set of
> descriptions, similar to standard 'concepts' in STL, type-traits, etc.
> ie, we can have 3 different widgets that all advertise as
> "NumberEditor", and that would mean they all implement the concept
> (and interface) of NumberEditor. I suppose a widget might need to
> advertise multiple interfaces that it implements, we would need to
> support that as well.
>
> That's it for the widgets. The hard part is the 'widget selector'
> that matches the required widget to the data model. Currently, the
> 'widget selector' is usually the coder (via hand-written code, or RC
> files, or Eve, etc), or maybe the UI designer if you can teach them
> Eve (which I recommend you do!).
> But with descriptions, the 'widget selector' can be automated code.
> Consider an example:
>
> struct Date // a poor date struct
> {
> int year;
> int month;
> string day;
> };
>
> This struct needs to be described to the widget system:
> - the struct needs a descriptor string: "Date" // I'll comment about
> the naming later
> - the struct needs to be flagged as a 'struct' or 'aggregate' or
> 'record' - ie that it has members fields
> - each item within needs a descriptor "Year", "Month", "Day"
> - each item needs to be described by type - int, int, string
> - each item optionally gets min/max/default and/or an
> array/enumeration of possible values (ie [ "Monday", "Tuesday",...] )
>
> Now, the point is that the 'widget-selector' system can look at this
> struct and do:
> 1. do I have a "Date" widget? if yes, use that and be done (or if I
> have more than one to choose from, check other constraints to decide
> the best one)
> 2. if I don't have a "Date" widget, I need to make a group of widgets,
> one for each member of "Date". ie:
> 2.1 Do I have a "Year" widget?
> 2.2 If not, do I have an "int" widget? (should, it is a base type)
> etc
>
> Note that the widget-selector can decide on the proper selector not
> only by the descriptor tag "Day" or just type "string", but also be
> the optional criteria - if the string has an enumeration ("Monday",
> "Tuesday",...) then the choice might be a pop-up list box (or even a
> group of radio buttons if the list is short), or it could just default
> to an edit box (and force the validation to happen later).
>
> ** As for naming - obviously, if I named my struct up there "Date" and
> your widget advertises that it can edit a "Date", then we had better
> be talking about the same structure. So maybe it would need
> "namespacing" like "MyApp.Date", and then an appropriate widget is
> unlikely to be found. - But think about "Boost.DateTime". You can
> write a widget that understands "Boost.DateTime" (and maybe a few
> people will write competing widgets) and my code will use the boost
> DateTime library, and we'll understand each other.
>
> The important part is that, for the widgets, it isn't really more work
> - it is just communicating (in some agreed upon way) what it is that
> the widget is already doing.
>
I forgot to add - much of the structure description work might be the
same as what is done for Boost.Python and Boost.LangBinding.
Tony