On Sun, 31 Oct 1999, James Henstridge wrote:
> This could be implemented by getting each object to implement the
> following methods:
> list_props -- list the names and types of all the properties of this
> type of object. This would fit in the ObjectTypeOps structure, as it
> is not tied to a particular instance of the object.
> get_props -- get the current values of a number of named properties.
> set_props -- set the current values of a number of named properties.
This is a step in the right direction ; however, this doesn't allow to
have different object types (in the user point of view) sharing a common,
otherwise identical binary implementation [more programmer and
power user flexibility, less code, less forking, less cut-n-pasted bugs,
identical user-interface].
What I suggested is to tag struct Object itself, with a PropertyList
member, and have a set of routines :
void property_set_XXXX(PropertyList *prop,const char name,XXXX value);
bool property_get_XXXX(PropertyList *prop,const char name,XXXX
*value, XXXX *default, /* where applicable */ XXXX *min, XXXX *max, XXXX *step);
The implementation for these routines would be in lib/object.c or in a new
file lib/property.c ; there would be practically no property handling
stuff in a regular object's implementation ; the GetPropertiesFunc and
ApplyPropertiesFunc of its ops struct would be NULL ; likewise for its
LoadFunc and SaveFunc.
The big drawback is that the cost of accessing a property (for instance,
at draw time) is much bigger than accessing a struct member. To eliminate
this problem, struct Object should have a bool "dirty" member, guaranteed
to be set to true everytime a function external to the object itself
(property editing dialog, create/load routines...). This way, the routines
which require frequent access (foo_draw()) can do caching if needed.
Of course, a really crazy object could always be allowed to override the
default dialogs, or the default load/save implementation, though it
shouldn't need to override the latter.
Oh, I just noticed that there are in fact two sets of defaults : the
user-specified defaults (not yet enabled in dia, AFAIK), and the type
defaults (a "Realises" and a "Generalisation" objects are two different
types, but are [should be] a single binary implementation ; each type has
different defaults for the arrow type, line width and line style, and none
of them are visible and editable by the user).
Implementing the edition of the first sets of defaults is trivial : for
each (user-level) object type, a property list is attached, and is edited
by the regular property list dialog editor. When a new object is created,
it's property list is simply a copy of it's type's property list.
> This also has the benefit of being able to select a number of shapes and
> getting a dialog of the intersection of their properties. This could also
> be used with grouped objects.
True ; this feature is possible with both systems ("properties are
implemented and specified by each object type, at the binary type level",
your proposition, and "properties are implemented at the object level, and
specified outside the binary type level" -- my proposition).
-- Cyrille
------------------------------------------------------------------
Oh, my god ! I'm trapped into a V90 modem ! GPG ID: A879BEF8
