Mail Archives: geda-user/2015/07/06/16:37:43
On Mon, Jul 06, 2015 at 10:50:23PM +0300, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Mon, Jul 06, 2015 at 07:49:52PM +0200, Ivan Stankovic (pokemon AT fly DOT srk DOT fer DOT hr) [via geda-user AT delorie DOT com] wrote:
> ...
> > Sadly, my own attempt hasn't been successful, either:
> >
> > http://repo.or.cz/w/geda-gaf/ivan.git/shortlog/refs/heads/libeda
> > (see two last commits on that branch)
> >
> > My original intention wasn't as ambitious as Peter's, but it did
> > begin to show a path toward a better libgeda (with emphasis on
> > documentation and unit testing), that one would then be able to
> > use as a foundation.
>
> A lot of work.
Well, both yes and no. What's on the branch is merely the beginning,
but basically (most of) the skeleton is there. What remains is the
tedious, but straightforward, work of supporting all existing libgeda
objects.
Note that in the first iteration I aimed for complete .sch format
compatibility. Nowadays, I'm not so sure about that, given that it
would be fairly trivial to write a sch-to-anything converter, which
would allow libeda to get a better format. Actually, what I was
later thinking of is to decouple various functionalities roughly this
way:
libeda => core data structures, in-memory representation (data model)
libeda-reader => read .sch files and construct data model
libeda-reader-sqlite => read from a sqlite database and construct data model
...
libeda-renderer => take data model and render (possibly to various targets)
(At some point I even had a proof of concept of how to dynamically
make and register GObject-based renderers, which would allow anyone to
render the data model as they see fit; think previews, thumbnails etc.)
A future version of gschem would, for example, use all these and remain
relatively agnostic of the various details, that it currently knows
very much about.
Finally, for all of these GObject-based libs my idea was to provide
nice Python bindings, so that e.g. making an a new netlist backend
would be trivial.
> FWIW, unlike some other developers, I'd prefer to see
> that work in the main repository (say, as a separate branch) and don't
> see any reason to bury it from others so deeply.
I'm afraid there's much more work out there that we haven't seen yet.
It's been a constant theme through the years.
> At least, other
> developers could look it through and use what they like from the code.
I did ask about help regarding this, but nothing happened. Perhaps
the timing was unfortunate. I remember Peter C and Peter B had both
been very busy at the time, and judging by their current activity, that
hasn't changed.
Myself, I lost motivation at some point and got busy with other things.
But the code is still there and if anyone wants to resume the
effort, I'm willing to join in.
> Otherwise, all those repos on repo.or.cz or github become a lost effort,
> never used and of interest to anybody. (And I believe that little but
> steady steps are better than large jumps from time to time.)
I completely agree. However, I also believe rewriting libgeda
piecewise would be an order of magnitude harder than just coding
a new lib from scratch.
--
Ivan Stankovic, pokemon AT fly DOT srk DOT fer DOT hr
"Protect your digital freedom and privacy, eliminate DRM,
learn more at http://www.defectivebydesign.org/what_is_drm"
- Raw text -