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



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.

Regards,
Andreas Pokorny


Attachment: pgp4ZKeWkFzg4.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]