Re: gEDA-dev: Hooking into selection changes

[Peter TB Brett <peter-at-NOSPAMpeter-b_dot_co_dot_uk>]

On Thursday 10 August 2006 08:23, Peter TB Brett wrote:

> Hopefully I can get a working patch with these changes out.

Unfortunately it's been a serious uphill battle -- every piece of code that 
interacts with the selection has to change -- and it's looking like I'm going 
to have to put the whole thing on hold for now, because I need to work on a 
rudimentary project manager.  Our shipping date is the end of the month, so 
maybe during September I can look at this again.

If the code mostly used a library of functions for manipulating the selection, 
the job would be much easier.  Since, however, it accesses the selection data 
directly -- and makes assumptions about the data structures and behaviour 
that should be associated with making a change to the active selection -- 
it's impossible to make the behaviour sane and extensible without ripping out 
_all_ of the current code which deals with selections.

diffstat says about my current changeset (which doesn't yet even compile):
 26 files changed, 585 insertions(+), 672 deletions(-)

To counter an obvious objection, "Why don't you just make sure that every 
piece of code that changes the selection run o_select_run_hooks()?"  
Unfortunately, o_select_run_hooks() is a gschem function, and there is code 
in libgeda that needs to modify the selection.  Not to mention that 
o_select_run_hooks() is in itself a total mess: magic constants everywhere, 
and no sensible way to register a C callback function; it's Scheme-hook 
specific.  My changes are going to have to include splitting 
o_select_run_hooks() into a number of more specific callbacks which are then 
connected to each page's GedaSelection object.

A case of breakage of the current system in point: o_copy_end().  This 
currently creates a new selection list, and replaces the current selection 
list with it.  It doesn't call o_select_run_hooks(), although it should.  

I personally believe that the code shouldn't require that when you carry out a 
specific operation, you then must remember to include a few lines of 
boilerplate immediately afterwards to clean up the side-effects.  In order to 
add an object to the selection, you should just be able to do, for 
instance, "add_to_selection (selection, obj);" and then move onto the next 
bit of functional code.  You shouldn't have to remember to change the colour 
of the object and redraw it -- that should be done automatically just by 
making that function call.

</flame>

On the other hand, gschem is perfectly usable, and doesn't crash all that 
often these days.  I guess I shouldn't really complain about the spaghetti 
code, because I certainly haven't shown that I can do any better.  

I'm going to go home now, because I have a headache.

Peter

-- 
Fisher Society publicity officer            http://tinyurl.com/o39w2
CUSBC novices, match and league secretary   http://tinyurl.com/mwrc9
Quake II build tools maintainer             http://tinyurl.com/fkldd

v2sw6YShw7$ln5pr6ck3ma8u6/8Lw3+2m0l7Ci6e4+8t4Eb8Aen5+6g6Pa2Xs5MSr5p4
  hackerkey.com

PGP signature

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