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)
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk