> Are these masses of tests (in box_[sg]et_props()) really necessary ?
> What about having struct type (ObjectType *) and field offset fields in
> PropDescription, and then let a pair of object_auto[sg]et_props()
> functions handle that automatically ? [there will probably be a need for
> macros around G_STRUCT_MEMBER to handle the access to the object's
> fields].
Sometimes a simple offset is not enough -- for instance, with flowchart
box, one property corresponds to box->text->height, which can't be
described as an offset in the box structure (although, in this case maybe
making the Text structure a single property would be useful).
Having some convenience routines to help write the get/set_props functions
would be good.
>
> I've got a 4) to append to your list of things to do :
> 4) provide functions which use the PropDescription to automate the
> grunt work of _save() and _load() functions (basically, _load() becomes
> _create() + modification of the field values according to whatever was
> saved, then only update_values() the object). Bumm ! 100 less lines of
> code per object (30-40 with lazyprops.h).
Another good idea. I think we may have touched on this in the last lot of
properties discussions on the list. The save function could be a standard
function, but the load one would probably need a small amount of object
dependent code. Each object will need to implement the properties they
inherit from Object, Element, etc. This should not be too difficult to
do.
>
> Are _[sg]et_state() still useful/mandatory with your code ? If yes, then :
> 5) provide functions to automatically build state objects
> according to the PropDescription. If an object is complicated enough to
> require a manual implementation, then the programmer still has the choice
> to manually implement _[sg]et_state(). Otherwise, it becomes :
> void foo_set_state(Foo *foo, FooState *state) {
> prop_auto_get_state(state,foo_props,foo);
> }
> and basta ! 30 less lines of code per object.
That should not be too difficult. I am not sure how many objects will
require a get_state/set_state function now though.
>
> Finally (while I'm at this),
> 6) There might be a use for a NotebookPageDesc object :
> struct NotebookPageDesc {
> { _N("page 1"), 0 },
> { _N("page 2"), 0 },
> { _N("page 3"), 0 },
> { NULL } };
> Then a field in PropDescription to tell the dialog building code in which
> page to put each field (NULL page meaning _N("General"), and if only NULL
> pages, then no notebook).
>
Being able to specify some extra formatting for the properties would be
good. I don't think it is worth making it complicated enough to build the
UML class dialog though :)
> Just my .02 EUR, of course.
>
> -- Cyrille
>
James.
