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

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

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.

**********


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.




_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev