Re: [gtkmm] Feature Wish: ad-hoc or external properties for simplified data binding

[Matthew Walton <matthew alledora co uk>]

Andreas Pokorny wrote:

> Hi Dear Gtkmm Developers, 
> So far i wrote just one larger gtkmm application. During that time i
> noticed that most of the ugly code was dedicated to data
> synchronisation. That application I worked on used one or rather two
> libraries for constructive solid geometry, and scene rendering. 
> These libraries were not developed with gui usage in mind.
> So there was no observer system to inform other parts of the software
> about a value change.
>
> Ok, back to gtkmm. Most of the code written in the application was 
> about sending data from the library objects to gtkmm widgets and vice
> versa. I had to handle two data storages for variables, and two possible
> sources of changes. Either through user input or due to a action within 
> the libraries. Since gtkmm widgets emit signals whenever the value
> changes, I also had to check that a internal value change did not emit
> a signal into the handling routine for changes due to user input. 
>
> So I started to search for a better solution. It would be fine if I
> could tell the libraries to read the data from the widget directly, or
> if I could tell gtkmm to read from and set values directly to the library 
> structures. 
> In both cases one of these two application parts had to know the other. 
>
> I realized that I need a common external connection system, which handles
> the data transfer between these parts for the application. C++ does not
> provide a general property system like maybe C#, and well the properties
> which are provided by gtkmm did somehow not fit into the picture. 
> I have to admit that I did not try to use the glibmm propery types as a
> ad-hoc connection, maybe it does work well, then this mail is
> superfluous.
>
> I wanted to provide properties that wraps around every common type of 
> data ( both single values, and sequence containers ) access, and that
> could be assigned to gtkmm widgets. So far I am pretty much done with
> the first part, the properties and their connection to user defined
> types. 
> In the next weeks, I will try to create augmented gtkmm widgets that 
> make use of these external properties and forward all read and write 
> accesses to a user provided the property.
>
> The final initialization would look like that:
>   
> // A user defined type:
> struct MyData
> {
>   private:
>     std::string name;
>     std::string data;
>   public:
> 	std::string const& get_name() const;
> 	std::string const& get_data() const;
>
> 	void set_name( std::string const& name );
> 	void set_data( std::string const& data );
> };
>
> // external Property storage for MyData
> struct Data{}; // Keytype for our map, to associate the property of the data attribute
> struct Name{}; // Keytype for our map, to associate the property of the name attribute
> typedef property_map< vector< elem<Name, std::string>, elem<Data,
>     std::string>, MyData> MyDataPropertyType;
>
> MyDataPropertyType MyDataProperties;
>
>
>   // We have to define the access on the real data 
>   // for each property of MyData, there are a lot possible
>   // variations in the access methods, e.g. 'get' and 'set' by
>   // pointer values, or member memory offsets is also possible.
>   MyDataProperties.get<Name>().init( &MyData::get_name,
>       &MyData::set_name );
>
>   
>   MyDataProperties.get<Data>().init( &MyData::get_data,
>       &MyData::set_data );
>
>   augmented::Entry TextfieldA, TextfieldB;
>   MyData object;
>   
>   TextfieldA.set_data( object, MyDataProperties.get<Data>());
>   TextfieldB.set_data( object, MyDataProperties.get<Name>());
>
>   // Now the Textfields should display and work on the values 
>   // stored on object, no further work has to be done to handle
>   // value changes. 
>
> The proerty_map template is a just used for storage and access 
> purpose, it is just some syntactic sugar added to this example. 
> But the property_map could be used in algorithms that need some 
> further type information. 
> Currently I use it in a xml serializer. 
>
> If you want to see, the current code have a look at this subversion 
> repository: 
> Property System: 
> http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/util/
> Serializer:
> http://svn.zynot.org/svn/zynot/projects/xeta/trunk/source/src/serialize/
>
> Both directories include some example and test applications. 
>
> I am sending this mail for several reasons. First of all i would like to
> get input, maybe i missed an important point, and I am producing some
> senseless code. I also wonder if it is possible to bypass the data
> storage of the gtk libraries. Finally I would like to get some support,
> from people interested in that concept. 
>
> After finishing the single value widgets I will try to get this concept
> into the tree and list store interface.

What you appear to be wanting here is a seperation of data and 
presentation (or Model-View-Controller), which is a fairly classic 
concept from all sorts of places. You should find that the TreeView 
widget (and the ComboBox in gtkmm 2.4) already have this abstraction - 
to use any external data store, you just have to wrap it in an interface 
derived from Gtk::TreeModel. TextView also has an external data store, 
so you could write a wrapper for more or less any source of text you 
cared to use for that. Other widgets don't already have it (the new 
sheet widget for GTK 2.8 will be using MVC as I understand it), but they 
could probably be coerced into it with a bit of effort.

That said, though, other widgets don't have substantial internal data 
storage - buttons have very little state information inside them, as 
also for checkboxes and so forth, which is why the widgets which do use 
MVC use it and the ones which don't, well, don't.