Re: Dynamic Arrows

[Cyrille Chepelov <cyrille chepelov org>]

Le Sat, Feb 02, 2002, à 01:10:24AM -0600, Richard Rowell a écrit:

> > What information was this <type> tag supposed to carry ?
> The arrow type I thought might be usefull to categorize the various arrows as 
> there are already enough that the arrow menu spans my entire screen.  I 
> hadn't planned on hacking the interface stuff in right away, but perhaps this 
> might be a good idea for the future?  (especially since users may/will be 
> hacking in their own "arrows", no telling how many there may be a year from 
> now).

Oh, I see. And you've just driven me into a perhaps interesting idea: like
shapes have no "organisational" data (ie, they don't specify on which sheet
they appear), don't put "organisational" data in the new-style arrows.
Rather, we should (one day !) expand sheets to also specify which arrow (and
probably XMLised line types...) belong to which sheet (then, the same arrow
"shape" would be able to appear in several sheets). This would go along with
a revamp of the toolbox, perhaps by designing a control to encapsulate what
we have right now in the toolbox proper and the arrow/line style buttons;
then, the option could be offered to the user to have more than one
"toolbox" controls opened (probably in the _same_ toolbox window; gimp-like
UI is nice but too much strain on the WM ain't always a win IMO), allowing
to pick elements from more than one sheet (most useful case: we'd be able to
dump the current hardcoded "standard" half of the toolbox; we'd just have
two toolbox controls, one opened on the "standard sheet" by default and
another opened to whatever the user wants. Or, if the user wants ER and UML
simultaneously, good. Etc.

Of course, this is only a random thought for a very future improvement...
that your proposed code would certainly help enable.


> > So, basically, the exact shape of the arrow depends on the size of the line
> > which holds the arrow ? Uuuuh. Why not take the existing "width" and
> > "length" and use these as a scaling factor (and define the arrow as in a
> > 1x1 or 10x10 or 100x100 box, you choose the scale) ?
>
> No, the arrow's size depends only upon "length" and "width".  The way it is 
> coded now, there is a 200x200 unit box the arrow can be drawn in.  0,0 is 1/2 
> the "length" away from "to" and is "on the line".  100,0 is "to" .  100,100 
> would be a point tangent to the "to,from" line 1/2 "width" away from "to", 
> and so is 100,-100.  

Oh ! OK, I mis-understood you. Fine. 
One thing that'd be *very* nice would be if you could include the
specification of where the line should stop relative to the originally
specified endpoint (where should it be trimmed):
this'd help resolve one of the most long standing graphic bugs....
In case it never struck you in all its ugliness, let's imagine this:
                                                          \
                                                          |\
--------------------------+        -----------------------+-\+
                          |                                  |
this is the endpoint ---> *                                X *>
                          |                                  |
--------------------------+        -----------------------+-/+
                                                          |/  
                                                          /  ^ notice that "+"

it would be nice if your new arrow types could have the ability to transform
the coordinates of the * endpoint, for instance into the "X" point above.
(yes, native arrow types should do that too; or rather, at some point native
arrow primitives should probably all be converted to use your code. It's not
like what we have with shapes and objects, current arrows have no behaviour).


> To make a long story short the code already scales on width/length, and the 
> units are arbitrary. I could just as easily make the origin "to" and make the 
> "unit" length/width 1 instead of 100.

Whatever's the lightest load on the arrow designer is probably the better.

        -- Cyrille

-- 
Grumpf.