Re: Unit selection input

[Cyrille Chepelov <cyrille chepelov org>]

Le Tue, Jan 22, 2002, à 11:19:47PM -0600, Lars Clausen a écrit:

> Further delving into properties turn up a problem:  The standard properties
> code doesn't have a pointer to the diagram at all.  Either one will have to
> be passed down through object_get_props_from_offsets(), or the objects will
> have to hold a pointer to their diagram, or something else entirely.
> Cyrille, do you have any ideas?

Huh... let me see if I understand the problem.

You've got a collection of objects, some having length properties (font
height, whatever). All these properties must display length values in a
per-diagram configurable unit. Therefore, to know which length, the
properties must either be provided a pointer to the diagram, or to the
object which the must hold a pointer to the diagram. Correct ?

We can edit properties belonging to several objects (let me rephrase:
"we can edit properties values which stem from the properties of several
objects, and apply the modified values back to the objects' properties"),
but all these objects belong to the same diagram (it doesn't make sense to
select objects in two diagrams at once, and to edit them as a single group,
does it ?).

Hmmm. Tough choice. 
        1) we add a pointer to the diagram in each and every object. 
        2) we add a parameter to a whole bunch of functions
(object_apply_props, object_get_props_from_object, etc), which then all
suffer from the "data clump" syndrome. 
        3) we could do 2) and Introduce Parameter Object, turning the
GPtrArray of props into a first-class struct (which would hold both the
GPtrArray of props and the pointer to the diagram, plus whatever else would
be useful). 

In all three cases, don't forget to ++DIA_PLUGIN_API_VERSION, because we break
binary compatibility (not like we really care, but anyway.)

Applying 1) means we reserve the possibility to apply a set of property
values to objects of different diagrams. 

Applying 2) means longer parameter lists, I don't really like that.

Applying 3) means we have to construct the struct in the first place (how to
name it ? Hmmm. struct PropValData ?). And, I have some trouble seeing the
natural coupling between a set of property values and the diagram (except
the need for some property values to know in which unit to display).

When beginning to type, I was more in favour for 3). Now, the "bunch of
unrelated struct fields" problem (emphasized by the trouble naming the 
struct !)problem is strongly pushing me back towards 1) 

(actually, towards building a two-way navigability in the 

        [diagram] ------> * [layer] -------> * [object] 

link. Seen like that, a pointer from each object back to the layer, and from
each layer back to the diagram looks like a much less horrible solution.
Besides, this even begins to sound actually good: we have the position, 
bounding_box and now layer fields in the object, together they completely 
define the object's (X-Y-W-H-Z) coordinates. This sounds very logical to 
me. Besides, I see other cool uses, like interesting selection modes: select
layer by clicking a (non-current layer) object, etc.)

        -- Cyrille

-- 
Grumpf.