gEDA-dev: gschem -- Datastructures

[Peter Clifton]

Hi,

I'm posting this again as a new thread incase the last post on Friday
got lost in a threaded message view (I'd replied to one of my old
messags).

I've had a chance to think a little more about datastructures.

I'm not committing to implementing such changes yet, but wanted to see
what people thought to the following arrangement.

I'm _very_ interested to hear comments from the gschem developers.

**********


gschem window <-> view <-> page detachment.


[ TRUE GLOBAL VARIABLES ]
        |
        |------------------------  (Do we keep track of VIEW objects at
        |                        |  the global level, or leave as
children?)
        ---- WINDOW              |
        |       |_NB____TAB <-> VIEW --------------
        |            |__TAB <-> VIEW ---------     |
        |                        |            |    | 
        ---- WINDOW              |            |    | 
        |       |_NB____TAB <-> VIEW -------- |    |
        |            |__TAB <-> VIEW -----   ||    |
        |            |__TAB <-> VIEW ---  |  ||    |
        |                               | |  ||    |
        |                               | |  ||    |
        |                               | |  ||    |
        |            (Multiple views)   | |  ||    |
        |___ PAGE  <====================--   ||    |
       (head) n                              ||    |
        |     |                              ||    |
        |     p      (Multiple views)        ||    |
        |    PAGE  <==========================     |
        |     n                                    |
        |     |                                    |
        |     p                                    |
        |___ PAGE  <-------------------------------
       (tail)


(WINDOWs are data-structures associated with each main window.)
(NBs are GtkNotebook widgets which allow the user to switch between
various pages of widgets)
(TABs are actually GtkNotebook pages, and needn't have their own
data-structure)
(VIEWs are datastructures representing a "view" of a PAGE, there can be
multiple VIEWs on the same page)
(PAGEs are the data-structure associated with each schematic page / file
- could change to a glist)

With GtkNotebook paging, we may be "forced" to keep one drawing area
widget, scrollbars, backingstore, set of GC's per view.

Need to make a decision... do we _ever_ create a page without an
associated view?

Is there such a thing as a "virtual view", where we "consider" where we
are looking on the schematic page, but without any associated GUI
widgets? (e.g. printing to .png, where a backing store is associated
with a VIEW/TOPLEVEL, and other widgets are either NULL, or point to the
main window's)
... Either NULL the gui fields in a big VIEW structure, or split another
distinction, VIEW != GUI, and have a GUI_VIEW structure which represents
the "physical" gui widgets, which are displaying / interacting with
EXACTLY ONE "VIEW" onto a schematic PAGE.

Need to produce a set of helper functions which switch between active
views (change tabs on the GtkNotebook). Until the code fully accomodates
these data-structures, these helper functions will have to update
TOPLEVEL->page_current, so drawing operations may pass to the correct
PAGE data-structure.


Thoughts:

What is the logical program flow for creating a new, GUI viewed page, or
opening a file?
----------------------------------------------------------------------------------------

Is it:

Open file, (or new page)
Create PAGE structure (and associated OBJECT structures)
Create a VIEW structure
Instanciate gui widgets and populate the VIEW structure
Attach the gui widgets to the main_window's GtkNotebook, storing
reference to the VIEW structure
Attach the VIEW structure into the TOPLEVEL structure?

How much of this data-structure filling goes into libgeda?
How much of it goes into one function? - I'd like to remove a lot of the
duplication, e.g. the existing code for switching prev / next / new
pages has a lot of duplication of this sort of procedure.

(Should libgeda be / is libgeda) aware of any GUI creation / objects,
other than initialising data-structures to NULL?

How much backend stuff for manipulating data-structures of pages / views
might be used with no gui?
(Clearly this affects how the functions for creating pages, views etc..
are separated / joined with gui creation).




Ramble over,...

Comments welcome.

Peter C.