Hi all,
I'm in the process of greatly simplifying (factoring in lib/) the
"implementation borrowing" technique I sent last week-end. However, to do
this, I'd like to break binary compatibility by adding a few fields in
front of ObjectOps, ObjectTypeOps and ObjectType :
struct _ObjectOps {
struct _ObjectOps *overriden; /* will always be declared NULL */
/* insert here the traditional fields */
};
struct _ObjectTypeOps {
struct _ObjectTypeOps *overriden; /* will always be declared NULL */
/* insert here the traditional fields */
};
struct _ObjectType {
const char *name;
int version;
char **toolbar_pixmap; /* maybe get rid of this, and say that
sheet "toolbar" is the toolbar ? */
const char *inheritsfrom;
ObjectTypeOps *ops;
ObjectOps *objops; /* this is 'new' */
};
Basically, a binary object type (eg RoundedZigZag) can declare at compile
time to inhnerit from most of another binary object type (eg ZigZag), and
provide incomplete (or nonexistent) *Ops structures.
Once all libraries are loaded and the object registration step is done, a
fixup step is to be done, which will search for all objects type claiming
to inherit from another one ; for each such type, the "overriden" member
of the *Ops structure will be filled with a pointer to the parent type's
*Ops struct, and the NULL members of the *Ops structure filled with the
parent's members.
If an object type chooses to not provide one of the *Ops structure, a copy
of the parent's struct shall be allocated during this step.
Once all dependencies are resolved (in a clever way, so that there could
be several levels of inheritence), objects which declare an unknown parent
type should be ruthlessy unregistered, with loud stderr complaints.
Once the object register and fixup steps are done, the load process goes
on to the sheet registration phase, and from now on, things look unchanged
to the rest of dia's engine.
This improves on my previous "snarf.diff" patch by removing about 100
lines in each child object type : now the only remaining stuff is the
Object* structures and the new, overriding routines.
My question is : can I break binary compatibility (we're not yet at 1.0),
or should I try to re-order the structure members to keep current binary
libs loadable ?
-- Cyrille
My roadmap (comments and help welcome):
[1] build an object inheritance mechanism to limit code
duplication.
2 Eliminate register_sheets(), handle the filling of sheets
through improved index.sheet (built so that a user-defined sheet takes
precedence over dia-supplied ones).
3 Bring a property list in struct Object, so that each property
has value/min/max/visible/editeable fields.
4 Provide default Load/Save/Edit routines using property lists
5 tweak the midclick menu system for step 6 (perhaps not as
radically as I had stated last sunday).
6 de-couple object implementation from object type definition ;
put object type definition in XML files (define a suitable format, similar
to the way shapes are defined). Property list contents and midclick
menu appearance are defined in the object type definition file
7 Convert objects so that they actually use the properties, and
stop using custom Load/Save/Edit routines (wherever applicable). Define
the properties in a way clever enough to allow file-level compatibility
with older binaries (at least ascending).
8 While doing 7, possibly try to merge object implementations
wherever practical.
step 3 and 7 should ease a bit the task for scripting folks.
------------------------------------------------------------------------------
Grumpf.
