On Wed, Aug 04, 2004 at 02:07:13AM +0200, Christer Palm <palm nogui se> wrote: > Andreas Pokorny wrote: > > > >After initializing the property, the widget and connecting both,the > >system keeps in synch on its own. And you still can react on signals or > >do your own processing. > > > >So I guess, I will try to get a simple Gui library working that > >implements that idea. > > > > You should find it rather easy to derive a set of widgets that have this > kind of functionality. I've used that technique very successfully, > although in my case, my widgets "plugs" into an existing property model > rather than beeing generic. > > I think the hard part of what you are proposing is to make something > that is generic enough to meet everyones needs. There are numerous > reasons as to why you'd typically need some logic in between the view > and the application model. Yes, that is the reason why I allowed to have the property as foreign objects, that might be defined only in the translation unit, in which the developers works with the Gui-objects. The current properties handle a lot of kinds of value accesses: - by memory offset: the compound object pointer is casted to char, the offset is added and the address is then converted to the value type. This type of property should be used for public values, or for properties which get initialized within classes - reference access: the user supplies method pointers of type: ValueType const& (CompoundType::*)() const void (CompoundType::*)( ValueType const& ) for set and get procedures. - pointer access .. and different kinds of pointer access - value access .. - reference set-access, by returning a non-const reference ValueType & (CompoundType::*)() - C-Functions, or C++Functors which get and set values. You can also combine reference access and value access method pointers.. Since get and set operations use different parts of the property object, thus they can initialized independently. I guess i have handled all common access types for values. The container property on the other hand only handles containers that can be accesed like stl containers, at the moment. The property assumes that the user has a stl container within the compound type, and a method to access the container directly, like the tools() method of the Gtk::Toolbar class in Gtkmm-2.2. But it is easy to fulfill the interface of the container_property: One has to write a template structure with two methods, which return proxy objects that provide read-write and read-only access on the container. The proxy objects carry iterator information. They provide a method to test if the iterator reached the end of the container, a method to access the current object, a method to proceed to the next element, and one to reset the iterator to the beginning. Finally the write access proxy object allows appending objects to the container. The interface of the proxy objects will certainly grow in the next months, since methods to erase certain elements from the container are still lacking. Also inserting object at the current position is missing. And I made some ugly hacks to wrap pointer stl-containers. From my point of view the value property is complete, but might be extended with improved initialization methods, while the container property is still under development. Regards Andreas Pokorny
Attachment:
pgpaz50aEA0GK.pgp
Description: PGP signature