gEDA-dev: Random comments consolidated

[Peter Clifton]

> * PeterC, as for your refactoring of the libgeda/gschem data structures, 
>   I'm all for it, however, there are a couple requirements that must be met
>   before I will accept any such patch.  #1  Non-gui programs must be
>   able to create a toplevel object and subsequent underlying structures
>   without requiring the init of the gui (gtk+) libraries.  gnetlist is a
>   prime example of this.  I'm not sure by reading your last few e-mails
>   if this requirement is met.

This requirement is still completely met, but the code I have at present
isn't ready for release. (It still needs work on tidying up some of the
bits I broke, such as freeing the relevant gui bits when a gui page is
closed).

Ok, I'm not clear if requirement #1 also means "no gtk / gdk calls in
libgeda". I guess it doesn't, IIRC there is some drawing code in there?

I would love to see libgeda able to provide a preview / schematic widget
which can be used in other programs, e.g. a library / parts manager?
(This isn't yet on my todo list).

>   Also I'm a little concerned by your statement: 
> 
> 	"... where I can nolonger assume TOPLEVEL->page_current
> 	     points at the correct page to be working with ... "

My changes seperate the drawing contexts and backing stores from the
TOPLEVEL structure. As I have it at the moment (may well change), there
is one per PAGE structure. My intention is to perhaps have one per
"VIEW" structure.

All graphics operations were / are currently passed a TOPLEVEL
structure, and as the first tentative step to a working compile again, I
changed TOPLEVEL->backingstore (etc..) to
TOPLEVEL->page_current->backinstore (etc..)

This is not without difficulty, as (for example), when instanciating a
new GtkNotebook page, the "configure" event is fired for the new gui
object, and associated PAGE structure. The code would then zoom and pan
the TOPLEVEL->page_current schematic rather than the new one.

I appologise for my ill-defined statement earlier, I simply meant that
it was no-longer safe for my code to assume in all instances that it is
operating on the page pointed at by page_current.

>   TOPLEVEL->page_current always points to the current page (now).
>   We will have to have a discussion via irc to hash out all these changes.
>   In the mean-time, please send me a non-ascii art diagram of the changes
>   you want to make.  Thank you.

I don't have a concrete plan yet, as I've been holding back the desire
to get a particular data-structure in my head. I very much wanted to
throw ideas about with people, such that we can get this done in a way
which suits the "grand plan" for gschem / geda, and where it will be
going in the future.

>   Further more, requirement #2, any code refactor must be coordinated. 
>   There are now three developers (Carlos, Patrick, and yourself) who want
>   to make non-trivial changes and I want to minimize any toe stepping.
>   I haven't decided how I'm going to handle this just yet (funny,
>   this has never been a problem in the past, only because the number of
>   developers at any one time has been small :).  It all really depends
>   on who is ready to go first (_AFTER_ I get a snapshot out the door).

Sounds good.

I'm working on this full time (with the exception of the next two weeks
when I'm doing some machinery commissioning, 4th -> 18th Aug), but I
will likely be available in the evenings. Peter Brett is also working in
the same office full time.

I'm not claiming that I have all the answers, but just wanted to note
that I may have the time to do the "leg work" if we can collectively
come up with a design.

Regards

Peter Clifton