Re: Unit selection input

[John Volpe <jtvolpe e-design-services com>]

Hi all,

I have been using dia for some time now and I am very impressed.  Good 
job.........

Over the years I have used many other drawing packages (Mechanical CAD, PCB 
Layout/Schematic Capture and Diagramming).  In all the cases I am familiar 
with the, the units and scale factors can be set on a per layer basis. Idea 1 
below would allow us to have separate units for each layer.  

I would like to make the following suggestions.  Please feel free to nuke 
them as needed.

1. All dimensions in all items/objects be kept in some universal units.  Then 
converted to output and from input.  This would allow the changing of the 
units without changing the physical size of the objects.

2. Scaling be specified per layer.  This would allow a background (Title 
Block, Border etc.) to be scaled for the drawing.  If the drawing items need 
to be scaled to fit in the paper, the background would not.

3. Allow the user to create a layer which is a scaled view of a (portion of) 
another layer (set of layers).  -OR - Create a view object which would show a 
scaled "view" of some portion of the drawing.  This, of course, would allow a 
detail or overview view to be created.

Thanks, Keep up the good work,
John Volpe

On Wednesday 23 January 2002 01:45, you wrote:
> 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