geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

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:
> > Spatial indexing: tiles, R*-trees, and the "world size"
> > -------------------------------------------------------
> 
> [...]
> 
> > As you may be aware, I'm in the process of converting the config
> > system over from Scheme functions to parsed configuration files,
> > and I'd very much like to get rid of the "world size" settings
> > entirely.  At the moment, it is only used to determine the
> > scrollable region in gschem and the extents of the tile system.
> > 
> > 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.

> > Relatedly, we also have a bunch of functions for handling
> > rectangular
> > bounding boxes.  They currently work by passing around coordinates
> > of
> > the bounding box corners as separate integers; I would like to
> > introduce an EdaRectangle structure to simplify these APIs.
> 
> I absolutely agree.

Since that's something that can be done relatively quickly, maybe I'll 
crack on with it.

> > Sets of objects
> > ---------------
> > 
> > I have been trying to upgrade the gschem multi-attribute editor to
> > show unattached attributes when the selection is empty or an
> > unattached attribute is selected.  I have also been trying to
> > figure out how to add an indication to the gschem window title of
> > whether the current page has unsaved changes. Unfortunately, this
> > has been stymied by the fact that it's not currently possible to
> > receive a signal when an object is added to or removed from a page.
> > 
> > I noticed that this problem doesn't just affect the contents of
> > pages. It's also not possible to reliably be notified when objects
> > are attached or detached as attributes, nor when objects are added
> > to or removed from components or selections.
> > 
> > Using a GedaList doesn't really solve the problem.  It's not
> > possible to get notified of *which* items were added or removed via
> > the "changed" signal.  It would be ideal to be able to hook into
> > insertion or removal of objects from a collection so as to be able
> > to ensure that state is maintained (e.g. spatial indexing in PAGEs;
> > parent/owner references; and automatically removing an object from
> > a page's selection when it is removed from the page itself).
> 
> Eh.... I totally feel your pain. Sadly, this is one of the major
> problems with libgeda, and also one of the reasons why I started on
> working on an alternate GObject-based library for handling objects.
> See
> 
> http://repo.or.cz/w/geda-gaf/ivan.git/shortlog/refs/heads/libeda
> 
> and a basic EdaObject:
> 
> http://repo.or.cz/w/geda-gaf/ivan.git/blob/5a57c7d2b70d8e1acf683deb731
> 4e9d861fd8271:/libeda/src/edaobject.c
> 
> So far I only implemented EdaObject, EdaPage, EdaNet and EdaPin and
> I'm able to load very simple schematics. Attributes willl be perhaps
> the most work, but even that should be relatively straightforward.
> Every object emits an event when something interesting happens, such
> as adding or removing an object to/from a page, rotating an object
> etc.

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.

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.

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

> In any case, I think this is the way we should move forward, but I
> don't see it as too realistic since it would imply e.g. rewriting
> most of gschem, or writing a new schematic editor from scratch
> (honestly, I'm not sure what would be easier).
> 
> > A further consideration is that in all of the places where
> > collections of objects are handled, a *set* is needed, not a simple
> > list; inserting an object into any of these collections more than
> > once makes the datastructures inconsistent.
> 
> Yes, although you may want to care about ordering.

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?

                                      Peter

-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

Attachment: signature.asc
Description: This is a digitally signed message part.