Le Wed, Apr 03, 2002, à 05:52:15PM -0600, Lars Clausen a écrit:
> Firstly, I notice explicit differences between hollow_ellipse and
> filled_ellipse in whether to account for the line width. Same for the dots
> and boxes. Shouldn't all of the account for the line width, so as to line
> up nicely with the connection point?
This was mostly kept from the previous behaviour (I believe that Alex wrote
it that way). The current code is mostly mine, in a constant visual aspect
refactoring.
> Second, I notice you're using beziers rather than ellipses to draw the
> round shapes. Any particular reason for that? Beziers are notoriously
> difficult to translate into other formats, as they aren't really standard.
non-horizontally aligned ellipses cause at least as many problems to
uncapable renderers than Beziers. For Beziers, the approximation problem was
already solved, so I re-used that code. And speed didn't seem to be an issue
here for anyone, so in hindsight, this wasn't a too bad decision.
> Thirdly, I notice that the various objects have arrow information as Arrow
> start_arrow, rather than Arrow *start_arrow. Not only does that waste some
> space, it also means that we can't add onto the Arrow structure without
> causing binary incompatibilities. Any reason to not change that?
None ! (though I care about binary incompatibility as much as of my first
cent).
> Lastly, a general question. With the upcoming arrow adjustment system, it
> will be possible to have transparent arrowheads where the line doesn't show
> through. Is that desirable? Better than the current white-filled version?
> Should we have both?
This sounds very cool !
We need to keep both versions, though: I can see areas where a hollow,
transparent triangle head where the line doesn't show through is useful, as
many as I can see areas where I'd want a bg-filled triangle head.
(do you have time to refactor the arrow selector code so that there is only
one arrow selector widget instead of two, and one which uses the actual
arrow-drawing code rather than custom, fixed-size code ? That'd help cut
down the amount of code in a very nice way !)
> I'm planning to start out with a non-caching transformation handled by the
> objects themselves. It seems that by keeping the inherited points, things
> like loading and saving will still work. Renderers that know about arrows
> will have to untransform the lines, but that's ok.
>
> -Lars
>
> --
> Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
> "I do not agree with a word that you say, but I |----------------------------
> will defend to the death your right to say it." | Where are we going, and
> --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?
> _______________________________________________
> Dia-list mailing list
> Dia-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/dia-list
--
Grumpf.