Re: gEDA-dev: gschem -- Datastructures

[Peter Clifton <pcjc2@xxxxxxxxx>]

> 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 think the refactor would require a re-write of the page handling code,
so re-writing it to support tabbed browsing would be no harder than
re-writing it to support one view per window.

If it were refactored to the datastructures I propose, you would
no-longer be switching schematic pages in the same way, so would get
tied to one schematic page per window.

I will probably start from a clean CVS checkout to do the refactoring.
The tabbed browsing verison I have was / is a nice test case, but still
needs a lot of work. The datastructures I've used in it are barely
changed from CVS in the grand-scheme of things.

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

Sounds like a beneficial change though. Peter Brett and I are looking at
an improved attribute editing widget. (Peter B. is doing the
implementation). Our widget will hopefully make it more obvious to new
users which attributes will need filling in.

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

Cool, thanks.

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

Thanks for pointing this out. I was unaware of this little caveat. Shows
how well I know the drawing bit of the codebase. 

Is this a nice place to eventually integrate scalable objects?

I think the object structure its self ought only contain the information
necessary for defining it in the schematic. Stuff for viewing it on the
screen ought to reside elsewhere.

>     Are you somehow repeating the object hierarchy in VIEWs?

Just off the top of my head, how clean would it be to generate a
per-view object data-set based upon the schematic's data? Its not
something I'm keen on, but for drawing speed, I see why it may be
necessary.

An easy solution (if scalable object drawing is on the horizon) would be
to hard-code 1 Page = 1 View for the moment, but leave the
data-structures capable of multiple views in the future.

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

My intention was to define the datastructures for multiple views, but
probalbly keep one read/write, and having any others as read only views
onto the data. If the user is not performing any action, they will
change the writable view when they switch between them. Perhaps changing
views will cancel an action anyway.

Another question is how signals may be emitted between the views to
repaint the other, assuming multiple views on the same schematic page
may overlap on the schematic page, and may be both visible in different
main gschem windows.

(The simple solution is to send an update signal to the PAGE, which it
then propogates to all VIEWs on that page, (or send to the VIEWs
directly) _after_ an action finishes.

I see it as unnecessarily complex to draw the rubberbanding for actions
on both views simultaneously.

In the future, if it is deemed useful, the ability to continue an action
across multiple views may be added.

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

GObject may make ref-counting and destruction of objects and pages etc..
much cleaner. I'm thinking that its signal handling may be beneficial.

As a first hash, I'd not intended to use GObjects, mostly due to a lack
of experience using them, instead leaving object boundary respectful
function calls, which would roughly map to signals, or methods if
converting to GObject.

Let me know if you think it is best to use GObject from the outset. I
think porting to GObject will be more tricky though, but perhaps ought
to get done as part of the refactor. (This is more a re-write than a
refactor in some places).

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

Rest assured that any refactoring will also patch gattrib, gnetlist and
others so the suite still builds and works correctly.

> 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;

Does this impose any speed limitations?

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

libgeda just for reading the config files?

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

I'd actually LIKE to see more of gschem in libgeda. As I may have
mentioned before, I would actually like to see a gschem_area widget,
like your preview widget implementation, completely inside libgeda such
that it can be linked in from other programs. (Like a library manager
for example).

My "evil" plan for that would be that gschem could then subclass that
widget to add the editability.

(That change feels more of a rewrite than a refactor, and I certainly
don't have the overall knowhow with gschem to make such a huge change
yet!)

I just wanted to keep such long term ideas in mind when designing the
data-structures and potential signal flows.

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

I'm not really sure about scripting in this respect. I guess well
designed widgets and datastructures go a long way to making this more
achievable.

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

I'm not fussed how stuff gets drawn really, so long as its done in a way
which doesn't cross too many class boundaries.

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

Thankyou for the feedback. I can see it being a big challenge, probably
a month or more's solid work to get a gschem which behaves nearly the
same from the users perspective. Perhaps I'm being optimistic saying a
month, I am certainly never to be trusted when quoting times to fix
machinery!

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

Work is in progress to make something available. Peter B. is looking at
that.

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

I wouldn't say re-write from ground up. gschem is good, just needs
tidying up. By refactoring as much as possible, and possibly re-writing
bits like dialogs, widgets etc.. there ought to be less potential for
'x' zillion bugs being introduced!


Peter C.




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