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
Attachment:
pgpYvrc0NrmWf.pgp
Description: PGP signature
_______________________________________________ geda-dev mailing list geda-dev@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev