On Wed, 2008-12-17 at 21:02 -0800, Edward Hennessy wrote: > This patch allows symbols to be selected by clicking anywhere inside > the symbol. Solid and hatched shapes can also be selected by clicking > inside the shape. Hopefully, this eliminates some of the irritation > caused by the current selection behavior. > > Hollow shapes not inside a symbol must still be selected by clicking > on the perimeter. I left it this way so that a user could put dotted > line boxes around other shapes, and select those shapes without > accidentally selecting the surrounding box. An example includes > putting a dotted line box around a set of resistors to label them "no- > pop." The user could subsequently select the resistors without > selecting the surrounding box. > > Currently, shapes composed of lines and arcs that form a closed shape > must still be selected by clicking on the perimeter. Examples of > these shapes include nand gates, nor gates, op-amps, etc... However, > when these symbols get converted to paths, then clicking inside the > shape will select it. If symbol selection behavior continues to be a > source of irritation, symbol selection could revert to bounding-box?
I suspect that will cause irritation, as there are a lot of non-converted symbols. Inconsistency in behaviour could be seen as worse than the current git HEAD behaviour where at least the user gets to know for all symbols, that they have to hit an actual line. One possibility is rather than falling back to overall bounding-box hit-detection for a complex, you could check it if has any arcs or lines inside it, if so, then pretend (for the purposes of hit-detection), that it also has a box, the size of the bounding box of those lines and arcs. Regarding the patch: Each file we compile takes a certain overhead of time. For collecting a few simple routines such as m_*_shortest_distance(), I'd prefer to see one new file, m_gemetry.c rather than several small files. Having lots of very small files also makes navigating and editing the source harder in some cases. gint, gdouble vs. int and double: Please can we use the basic types int and double etc.. where possible. This gives shorter lines, more standard C code (if you ever wanted to port away from depending on glib), and syntax highlighting in some editors works better if you use the standard ones. gEDA also has the convention of using int rather than gboolean in many places. + solid = object->fill_type != FILLING_HOLLOW; /* FIXME */ We should avoid adding "FIXME" comments without any indication of what might need to be fixed. (First of all, avoid adding things which need fixing ;)). I'm not sure what the issue is here, so I doubt anyone looking back at the code in the future will either. I don't really like: +static double special_shortest_distance (OBJECT *object, int x, int y) What about altering the prototype of the o_shortest_distance() routine: +double shortest_distance (OBJECT *object, int x, int y, int override_solid) Passing that override solid as a parameter to all the object specific functions: (NB: As you'll see from my mods, keeping the function signature for all of these identical makes for a shorter dispatch function, so if we did this, we should pass the override for all object types). o_box_shortest_distance (object, x, y, override_solid); Then you can have in o_box_shortest_distance: solid = override_solid || object->fill_type != FILLING_HOLLOW; Doing it this way, you wouldn't necessarily need to split out an m_geometry.c for shortest-distance functions which take BOX * and CIRCLE * parameters. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
