On Tue, Aug 03, 2004 at 02:48:47PM +0100, Matthew Walton <matthew alledora co uk> wrote:
> 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
Yes, thats what I want, but I would hate an interface in which I had to
derive from some base model class just to wrap the model of a text field.
Then again you would have to write a lot of interface code to "get your
data into the gui".
I propose a system that works without strong coupling of Gui classes
and user classes, and more important than that, a system which saves a
lot of lines of code.
> 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.
Even that little data should be stored in the users object. But I think,
that with the current design of gtkmm, this decision is done by the gtk+
developers, isn't it?
Regards
Andreas Pokorny
Attachment:
pgpiNvUIU2ynp.pgp
Description: PGP signature