Re: gEDA-dev: SELECTION, component library search order and more

[Patrick Bernaud <b-patrick-at-NOSPAMwanadoo_dot_fr>]

Hi Peter,

Thank you for your comments.

Peter TB Brett writes:
 > [...]
 > I haven't had time to look at your patches I'm afraid, 

The first purpose of this patch was to re-introduce the SELECTION type
before the next release.

It provides two functions in libgeda working on a SELECTION to
select and unselect an object. Nothing more in libgeda.

In gschem there are two similar functions but working on the SELECTION
attached to the current page. These functions are in charge of
invoking the guile hooks and may in the future also redraw the object
after selection/deselection. 

Gschem only make calls to the gschem's selection functions above, not
directly to the libgeda's. This way the internals of the selection is
pretty much hidden from the application (but not perfectly yet).


 > [...]
 > of comments about the way I think selections ought to work.  I'm *very* keen 
 > on moving all selection-manipulation code into libgeda, because it's not good 
 > API practise to have user code aware of the internals of your data 
 > structures.

Very true on hidding the internals.

Still when I started I was more considering the option of moving every
selection stuff to gschem instead of your proposition: gschem is the
only application of the suite actually using it and at that time the
selection was really user- and display-oriented (changing color and
such).

I was also considering the possibility of having more than a single
selection at a time. Hence the final difference between functions in
gschem and libgeda.


 > [...]
 >  * accessor functions, so user code doesn't need to know how the selection is
 >    implemented.  This would be useful if we suddenly decided to switch to
 >    singly-linked lists, but might require the introduction of an iterator
 >    type.  Most of the stuff needed is there already, so all that's needed are
 >    get_iter() and next() functions, although making the remove() accessor
 >    accept an iterator as argument might lead to some speedup for large
 >    selection lists.

I do not think an iterator on selection is really necessary: the way
the selection is used is mostly as a list of objects, applying a
function to each selected objects.

So a 'foreach' kind of function in libgeda is enough.


 > [...]
 >  * callbacks in libgeda.  With the accessor functions, that makes it possible
 >    to ensure that callbacks are executed *every* time the selection changes.
 >    During the summer I was trying to implement a sidebar that changed its
 >    contents depending on what was selected, and it was pretty much impossible
 >    to do with the then-current system.  The Guile callback system currently
 >    used in gschem could easily be adapted as a special case of the proposed
 >    system.

With the patch, the 'callbacks' are in gschem's de/selection
functions (the guile hooks invocations).

What kind of new callbacks are you thinking about?


Regards,


Patrick


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