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

[Stuart Brorson]

Sorry for the top post.

I like the idea of a tabbed schematic.  This might help solve the old
issue that gschem doesn't have the concept of a project.  It only has
the concept of separate, independent pages.   The concept of a tabbed
schematic and the associataed underlying data structures could be used
to implement a "project".  This is a nice usability enhancement,
particularly for newbies.

Some thoughts, in no particular order:

*  Assuming your changes introduce the concept of a "project", instead
of just independent pages being displayed, how to save out the project
into a file?  Right now, each page is an independent file.  How to
signal that a bunch of pages belong to the same project? 

Orcad has a .dsn file which holds all schematics, and also has a .opj
whcih must hold meta information about an entire project.  We could
use this idea to define a .geda file which holds project level
information, like which pages belong to the schematic, in which order,
etc.  It could also hold session info like the last zoom for each
schematic, etc.  Indeed, if we design the .geda parser correctly, we
could also embedd into it info pertainent to other programs like
gsch2pcb and PCB itself.  That is, the .geda parser for gschem would
just have to ignore any tags it didn't understand, the .geda parser
for pcb would just have to ignore any tags it didn't understand, etc.   

An alternative is to just have gschem think that all files with a
common name (foo_*.sch) belong to the same project.  This is what
ViewDraw does: Your project consists of files called foo.1, foo.2,
foo.3, etc.  Then when running ViewDraw, it just loads all pages
called foo.*.  This approach has a couple of difficulties:

  -- The filename suffix doesn't convey any info about the program
     using the files (i.e. like .sch)
  -- It's a PITA to insert a new sheet.  ViewDraw doesn't have the
     facility to insert a new sheet for you, so when you need to
     insert a new sheet, you've got to copy each file from foo.n to
     foo.n+1 by hand before creating a new sheet.
  -- It would be easy to confuse a program working like this since if
     you had a schematic foo.1, foo.2, foo.3, and also a PCB file
     foo.pcb, then the schematic capture program might try to load
     foo.pcb by mistake.  Also, a really dumb user might have a file
     called foo.12 which would also confuse the schematic capture
     program.  Of course, you could always keep the schematic files in
     their own dedicated directory. . . . 

In any event, I think the ViewDraw approach to project files stinks.

*  I take it that your proposal will create a data structure looking
like this:

TOPLEVEL -> GtkTable -> PAGE -> OBJECT -> [object list]
               |          |
               V          V
           [Gtk table    PAGE -> OBJECT->[object list]
            graphical     |
            widgets]      V
                         PAGE -> OBJECT->[object list]
                          |
                          V
                         etc.

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/

Look for "A drawing of the data structures used in libgeda".  I also
have a lot of expository text about how libgeda represents your
schematic in the gEDA source tree under geda/gaf/gattrib/NOTES.   But
you likely have figured this stuff out already.  ;-)

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

Stuart


> 
> Call for ideas / comments:......................
> 
> 
> A neat feature which was suggested to me was to implement "tabbed"
> viewing of pages - possibly to replace the page manager in gschem.
> 
> Simple, I thought,... until I dig a little more into the GtkNotebook
> widget which implements tabbed windows.
> 
> Each tab has to have its own contents... (In the case of gschem, this
> would be a GtkTable for packing, two scrollbars and the drawing area).
> 
> Having played to see if I could fudge the page-swapping by re-parenting
> one set of "contents" as the user switches pages, I quickly realised
> that this is not the way forward.
> 
> So... this means that I want:
> 
> One GtkTable, two scrollbars, a GtkDrawingArea, a backingstore, and the
> associated GdkGC's for drawing, _per page_.
> 
> Whilst I don't see this as a big issue, it does require a fair bit of
> work to separate out the datastructures.
> 
> My initial attempt at this (still not yet fully working) moves the
> appropriate Widgets, backingstores, and GC's into the PAGE structure,
> and adds PAGE.toplevel (which points back to the page's 'parent'
> TOPLEVEL structure).
> 
> This allows me to setup signal handlers / callbacks for the widgets
> which pass the PAGE structure, and they may still retrieve the TOPLEVEL
> specific variables.
> 
> For my first attack at the problem, I've left the drawing operations
> being passed with the w_current TOPLEVEL structure, and then reference
> w_current->page_current->[whatever] for the now per-page X-resources.
> 
> The thought occurs that this is somewhat pointless, since we are only
> actively working with one page at a time. Perhaps I should start
> considering how the TOPLEVEL structure may keep "main window" instance
> specific variables, PAGE may keep schematic page specific variables, and
> perhaps a new structure, say "VIEW" or something more descriptive, could
> contain the gui specifics such as widgets, scrollbars, GC's and stuff
> necessary for an active paintable view of a page. It looks like this
> should tie in ok with the "print to image" code.
> 
> I hope that this will allow pages to be detached into new windows more
> easily, and go a long way to increasing the intuitive usability of
> gschem when multiple pages are open. (New uses often manage to open new
> pages / down heirachy / whatever, then get lost).
> 
> My other thought, is that the drawing area, scrollbars, etc... should
> perhaps form a single subclassed Gtk widget, so they can internally
> catch the realise events, configure events etc..., thus tidying up the
> gui-management code.
> 
> My tab-bar changes look like they will be "fun", and quite major -
> making small changes in practically every ".c" file, and more
> significant changes in x_window.c, x_preview.c and the event handlers /
> callbacks.
> 
> Making a widget for the drawing-area is could be quite major, but should
> be beneficial in the long term. Looking at work by Patrick Bernaud on
> widgetising the file-open / component picker preview, it seems that a
> similar thing for the whole drawing area would be a more generic and
> useful widget. I've not yet thought how the data-structures / object
> boundaries would work.
> 
> A smaller step might be to create a small subclassed widget which
> handles our backingstore regeneration on resizing etc..
> 
> 
> Regards
> 
> Peter Clifton
> 
> 
> 
> 
> _______________________________________________
> geda-dev mailing list
> geda-dev at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>