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

[Peter Clifton]

> 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 ]

I would always anticipate that this stays, unless a major overhaul of
the datastructure were made. There could of course, be another route:

TOPLEVEL -> VIEW -> PAGE -> OBJECT -> ...
             |
             V
            VIEW -> PAGE -> OBJECT -> ...
             |
             V
            etc..

But keeping the existing TOPLEVEL -> PAGE linked list. For the most
part, my changes are innocuous to gattrib, in that they move widgets
between TOPLEVEL and PAGE.

I've not actually tried to implement a "VIEW" structure, its just piled
into "PAGE" at the moment, but if it were wanted to have pages in memory
without widgets and GUI stuff attached, "VIEW" might be a way to do it.

My source does cause compile breakage to gattrib - but these are more
down to initialisers such as TOPLEVEL->foo = NULL (once I've moved foo
into PAGE).

> 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.

Will ensure a complete build and usability test (as far as I can) before
claiming anything I have works properly.

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

It does look very interesting. I've not played with it much, but I'd
imageine it becoming an invaluable part of the workflow.

> > 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?

I've looked at the preview stuff too. I'd hoped eventually to homogenise
the preview "widget" with the normal schematic page code. That was what
I was working on initially, along with a revised GUI for the component
picker.

Until my patch to move the component picker separate from x_fileselect.c
(or someone else's similar patch) gets applied, I don't see a great deal
of point in continuing with that work incase merging it becomes a
nightmare.

> 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.)

Microsoft have written (and in the case of Visio, bought) some good
office apps. I may have access to a copy "somewhere", but not
immediatly. By all means, send me a copy if you have it handy though.

> 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).  

This is the rub.. fully abstracted, object oriented code often has high
overheads. This is not to say that the widgetised version wouldn't be
just as fast, it would just have to be carefully done.

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

I'm not interested in working on bits of code which aren't of use to
people. The purpose of sending my long email, one day into the "tab bar"
project was to feel the waters, to see if any plans were afoot to revise
datastructures in the near / longterm future, and if any patch I
produced which had to move things about would ever get merged.

Many thanks for your help,

Peter C