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

[Peter Clifton]

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