gEDA-dev: Tabbed pages in gschem (and implications)

[Stuart Brorson]

A couple of more notes and replies. . .

> What I've got at the moment:
> 
> TOPLEVEL -> PAGE -> OBJECT -> [ object list ]
>              | |__-> GtkWidgets...
>              V
>             PAGE -> OBJECT -> [ object list ]
>              | |__-> GtkWidgets...
>              V
>              etc..
> 
> There is also
> 
> TOPLEVEL -> GtkNotebook
>      which has Notbook pages relevant to each schematic page in the
> tabbar.

One thing which occured to me is this:  My pet project, gattrib,
piggybacks off the datastructures defined in libgeda.  Gnetlist,
gsymcheck, and others do too.  Therefore, any changes to libgeda
should be at least tested against the other components to gEDA/gaf.
Gattrib expects to see 

TOPLEVEL -> PAGE -> OBJECT -> [ object list ]

so any changes to this structure are bad for gattrib.  What you have
above is better.  In any event, please add gattrib and the other
gEDA/gaf components to your test suite when you change libgeda.

BTW: If you want any explanation about what is going on in gattrib,
please feel free to ask me.

> My proposition for a "VIEW" structure would be that each tab page or
> instance of a widget which shows a schematic page (e.g. preview), would
> have its widget etc... pointers stored here. 

Another thing to worry about:  The preview which shows up in the
component/schematic browser relies on handling a TOPLEVEL.  How will
your stuff interact with that?

> > If it helps you understand what's going on, I have a drawing of
> > gschem's data structures (those relevant to attaching component
> > attribues anyway) available here:
> > 
> > http://www.brorson.com/gEDA/
> 
> Thanks... had the printed copy infront of my kbd whilst debugging my new
> version... It is a fairly big datastructure change, and I'm still
> hammering out the kinks. Mostly on gschem's assumption that there is
> always a page loaded - this isn't true in my working tree at the moment.

If you want, I can get you the Visio original of this drawing for you
to edit/play with.  (Yes, Visio is a [*gag*] Windoze program, but it is
by far the most convenient tool for producing these structure
drawings.  Just MHO.)

> > *  As for widgetizing the drawing area, sounds like fun.  I have no
> > suggestions to offer since I never did much to the drawing code.  I do
> > wonder, though, how that will impact the usability gripes which many
> > newbies have about gschem?  Make it better, or have no effect?  I
> > dunno . . . 
> 
> Should be a lot of code changes for no effect... at least in the first
> instance. BUT, it should make the codebase cleaner if done correctly, so
> potentially redraw bugs caused by odd sequences of events will be fewer.
> Turning it into a fully fledged gschem_canvas widget is a possibility,
> but I'm not volunteering at the moment!

Yeah, my thought was that playing around with the drawing code might
be a distraction from usability enhancements.  Also, Ales has devoted
a lot of effort to the rendering stuff so that it is fast.  It may not
rely upon the most up-to-date widgets (since they didn't exist when
Ales started the project), but the drawing stuff is fast.  Compare it
to the modern GTK drawing code in PCB, which causes some people to
complain about its speed (works for me, but apparently not for
everybody).  

On the other hand, gEDA is an open-source project, so hackers are free
to work on whatever parts fo the code they wish!

Stuart