geda-developers team mailing list archive

[Ivan Stankovic <pokemon@xxxxxxxxxxxxxx>]

On Sun, Dec 16, 2012 at 07:10:45PM +0000, Peter TB Brett wrote:
> On Sunday 16 December 2012 19:18:58 Ivan Stankovic wrote:
> > On Sun, Dec 16, 2012 at 01:41:55AM +0000, Peter TB Brett wrote:
> > > What I suggest is to replace the tile system with an R*-tree [1],
> > > and to determine gschem's scrollable region using a heuristic based
> > > on the drawn extents.
> > 
> > Sounds good, although it seems to me that this is no small amount of
> > work.
> 
> I've got most of an R*-tree implemented so far... just lost a bit of 
> energy dealing with the deletion algorithms.

:-)

> Looks interesting.  A few comments/queries:
> 
> 1) Why not pull the full EdaConfig class from libgeda? It should be able 
> to slot in to your libeda code pretty much intact.

Umm, I'm not aware of any EdaConfig class in libgeda (master).
Is this on a branch somewhere?

> 2) You also really need some sort of EdaObjectSet concept, because 
> experience shows that it's often desirable to be able to pass sets of 
> objects around without a page.

Sure, that makes sense.

> 3) I think that you may be in danger of repeating our recursive design 
> load crash bug (that I described in my original e-mail) with your 
> eda_page_new_from_file() function etc.

Indeed, the moment I saw that bug report you were referring to in your mail,
I thought the same thing. The thing is, I didn't even come to that part to
be able to fail in such a way.  :-)

> I would strongly recommend adding 
> separate EdaReader/EdaWriter classes, and thinking of some way to add 
> indirection between "loading a schematic" and "loading the symbols 
> needed by the schematic".

Yes, you're right.  One could even provide readers/writers for other formats
(with some limits, of course), and one could also design a new format while
keeping compatibility with the old one.

Originally, I also had an idea to factor out rendering, previews, postscript
generation and such into separate components (even libraries if needed), but as
I'm working occasionally on it, progress is slow.  One thing that turned out to
be very, very useful to me is unit testing (glib has some support for it) and I
don't think developing a new library without a comprehensive test suite is
reasonable.  This coming from a guy who didn't think much of testing in
general until recently.

> Yes. I guess an important question is whether the basic EdaObjectSet 
> type should be ordered, or whether it should be left up to 
> implementations of the type.  Obviously, an unordered set only requires 
> a small number of fundamental operations (e.g. "add", "remove", 
> "contains", and "foreach"); it's much less clear what an ordered set 
> requires, especially if you add the concept of an iterator into the mix. 
> 
> Is a separate EdaOrderedObjectSet type needed, or should the fundamental 
> type be ordered?  Any suggestions about what minimal operations are 
> required?  How should we structure the iteration API?

Well, I guess it would be nice if the fundamental type were ordered,
but you might want to consider the cost (time and space). (Personally,
I would not worry about that cost right now.)

As for the API, how about this:

        EdaObject *obj;
        EdaObjectSetIterator *it = eda_object_set_get_iter(objects);

        while(eda_object_set_iterator_valid(it)) {
                obj = eda_object_set_iterator_get(it);
                it = eda_object_set_iterator_next(it);
        }

        eda_object_set_iterator_destroy(it);

This is similar to iterator APIs in Pango, GTK+ etc.

-- 
Ivan Stankovic, pokemon@xxxxxxxxxxxxxx

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm";