gEDA-dev: gschem -- Datastructures

[Patrick Bernaud]

Hi Peter,

Peter Clifton writes:
 > [...]
 > Many of these gotchas would be far easier to fix if the data-structures
 > were refactored at the same time.
 
Agreed.


 > I am really searching for some encoragement / criticism / advice about
 > how best to procede with this work in a way which can be sensibly merged
 > with CVS head in the future.

I really like your idea of tabbed browsing and refactoring
structures.


 > I am _convinced_ that some data-structure changes are necessary to make
 > gschem managable in the future. Anything which makes gschem more
 > maintainable / understandable / future proof is (as far as I'm
 > concerned) completely compatible with my employers interests, and I will
 > be able to devote time to doing it.

Yes obviously you will have to change the data structures quite a
lot. You will also have to change a lot of code elsewhere especially
when drawing or in action stuff.


 > [...]
 > Is it acceptable to make the transition to tabbed browsing at the same
 > time as a patch to refactor the data-structures? (I started out making
 > tabbed browsing changes, and then had to start the refactoring).

Well I would want to say no as it is not good practice and would
render tracking of problems much more difficult. Still one is pretty
much dependant on the other and separating them to make the
refactoring work alone would increase the amount of work necessary.

I have been doing that at a lower level for the changes I made to the
attributes (to change ATTRIB into a useful structure that contains
name and value and rely less on TEXT objects). It has been quite a
nightmare and I left behind a lot of things I would have wanted to
change/improve.


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

Did I say I like your reorganization? Just a few questions:

  - what is your solution for objects in pages? I mean since you can
    have several views on a single page, you can have different zoom
    level on a single page for example.

    Every object is recalc-ed every time the zoom is modified and they
    have only one set of screen_* fields.

    Are you somehow repeating the object hierarchy in VIEWs?

  - similar problem with actions. The view has to save its current
    state of action. What would happen when a user leaves a view
    during an action and move to another on the same page.

  - are you using or do you plan to use GObject for your new types?
    (TAB, VIEW...)

As Ales stated, also keep in mind that libgeda is at the root of
gnetlist too. Your refactoring is good and looks like it would not be
a problem for gnetlist. But it still requires pretty severe changes to
gnetlist as well.


I have been thinking of a complete rewrite of libgeda for a
while. At least four objectives to this rewrite:

  - move to GObject's almost every structures, especially OBJECT;

  - separate libgeda from the schematics stuff: creating a libgschem
    and a libgnetlist C libraries on top of libgeda would be a good
    thing. It has already been discussed before on the list.

  - remove the dependency of libgeda on gtk and guile (for guile see
    next point).

  - provide more scripting possibilities even on the GUI level: I am
    considering guile-gnome for that part (to avoid a new flamewar
    on the list, yes it adds a new dependency but no it does not
    require gnome, the project is modular (binary packages too as far
    as I can say)).

    A full wrapper of libgeda could be possible and it would make it
    easy for user to extend gschem/gnetlist or write its own plugin or
    even application.

  - support of newer GTK versions with Cairo since it is a long term
    project.

Note that it would not interfere much with your refactoring since it
is on a lower level (libraries, not application stuff).


Your proposition is very good. However it is a pretty big change to a
working but not optimal existing code base. That alone will make it
quite difficult. 

If you need any help, if you see anything I can do in your reorg,
let me know as I have time at least for the month to play with
gEDA. Also consider posting your changes regularly (patches or VCS).

After all, it may be time for a full rewrite?


Patrick


Note: I am almost 'disconnected' from the Internet as my modem died
last Friday. I am back to the old awfully slow and pretty expensive
analog modem times.
Please forgive me if I am a bit late or slow to answer. My website
(home-hosted) is offline until I get my new modem it which may not
happen earlier than Thursday or Friday.