Re: gEDA-user: Code Sprint prep.

[Dan McMahill <dan-atMUNGEDmcmahill_dot_net>]

Lares Moreau wrote:
> Could one of you real devs, as opposed to fake ones like me, point me to the right files.
> 
> (1) for the implementation of the ":foo" process. Specificly this, I would like to change the dialog from a dropdown menu to a more vim-like prompt on the bottom of the window. For now I'd like to give a go at allowing up/down keys for history, so I don't need to use a mouse.

This will be different between the lesstif and the gtk HID's.  For the 
gtk one, see src/hid/gtk/gui-command-window.c for the lesstif one, look 
in src/hid/lesstif/main.c, search for "Command" to get to the right 
section of the file.

On the gtk one, there is already a preferences selection that toggles 
between a seperate window and a prompt on the bottom of the screen.


> (2) for drc() window focus, so you can deal with each DRC individually, as it appears. That way there is no need to re-call drc().

I'm not quite sure what you're looking for here, but src/find.c:DRCAll() 
is the main drc function.

> (3) adding non-90deg rotates.  I found rotate.{ch}, and I think I have a grasp on those routines, but where do I look for the calls to the functions in rotate.c.

Take a look in the sourceforge tracker and in particular I think in the 
patches section.  Some has contributed some code.  There are some extra 
comments there.  The short answer is that at one time, there were 
assumptions in the connectivity scanning code about 90 deg rotations (I 
think).  So you'd want to be sure and verify that things work correctly. 
  Some of the things I'd check are:

non-90 deg rectangular pad on a polygon.  Does the clearance work right?

non-90 deg rectangular pad with some non-touching copper that is within 
the bounding box of the pad.  Does the connection scanner correctly 
determine that the two copper regions do not connect?

non-90 deg rectangular pad with some touching copper that just barely 
touches the corner of the pad.  Does the connection scanner correctly 
determine that there is a connection?

Take a look in src/find.c at LinePadIntersect().  There are several 
other functions in that file that do similar things.  I just point this 
one out as an example of a connection checking function that at least 
needs to be looked at to see how it deals with rotations.

Watch out for errors in the integer math.  In particular, I wonder if 
you actually need to internally keep track of both the current rotation 
as well as the original dimensions for the pad in question.  Then when 
you rotate more, calculate from the original. In other words, I can do 
90 degree rotations forever with integer math, but if I do 360 rotations 
of 1 degree each I'll bet I don't end up back where I started.

> I'm a noob to this code, pls be nice :)

many of us are and all of have have been at some time.  You'll probably 
find that some areas of the code are pretty simple and easy to work with 
and others are more confusing.

-Dan



_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user