On Fri, 2006-12-15 at 17:48 +0100, Patrick Bernaud wrote:
> Peter Clifton writes:
[snip]

>  > That commit may cause you grief. It shouldn't be insurmountable though.
>  > There may be others.
> 
> The question is not if this in surmountable or not. By now you know my
> opinion.

I'm new at this branching stuff. Indeed, basing off head would have been
a better plan which I know for the future.

> The question in the first place is WTF are these functions doing here?
> Where is the screen coords get_bounds function for complex? And
> believe it or not they are likely to be merged as is in HEAD.

I'm not sure I understand that last point. As I understand your comment,
your WTF is regarding the fact that these functions exist (or are in
gschem rather then libgeda?). I agree that they aren't ideally placed,
and can be made better.

The noscreen branch actually removes all get_bounds functions in screen
coordinates, so the complex won't miss its lack of a function.

> Really apart from the get_bounds problem (the commit you mention and
> the changes on prototypes to work on objects) and the changes on
> function casts by Dan in HEAD (considering you are rebasing on HEAD)
> there is not much conflicts.

Many of the 3-way merge conflicts I highlighted before are not difficult
to resolve. Some are more complicated than others though! What is more
difficult is making sure all code is updated as necessary.

For example, in noscreen (later changes) objects re-calc their
world-bounds as and when they are altered. Instead of get_...._bounds
recalcing every time, you can just retrieve the stored value. Draw
functions no-longer recalc before drawing.

It means I need to ensure that all places an object may have its bounds
modified, a recalc is called.

(I may introduce a regression test in my code which before drawing says:
        1. What does the stored bounds say?
        2. Recalc the object
        3. Are the stored bounds still the same, or was there a bug?
)

Regards,

Peter C.




_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev

Reply via email to