geda-developers team mailing list archive

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2012-12-16 at 01:41 +0000, Peter TB Brett wrote:

> Spatial indexing: tiles, R*-trees, and the "world size"
> -------------------------------------------------------

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


Grab my repo.or.cz repository, and look at the "object_rtree" branch. It
is based way back in the git history though, so will perhaps be more use
as inspiration rather direct application. (I imagine your drawing code
re-factor will be the key obstacle to application).

(SCRUB THE ABOVE.. it seems I never hooked it up for rendering
purposes... it "might" still be possible to apply it without too much
coercion).

However.. it should provide a decent drop-in r-tree implementation which
works with libgeda OBJECTs. The implementation is taken directly from
PCB, but has a number of its functions renamed to fit in with the
libgeda naming conventions (of the time ofGrr.. every damn  the branch).
There are then a few patches which make it more libgeda/gschem friendly.


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

It seems every tool ends up inventing their own region / rect type...
grr.. wish there was a standard here.


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

You will need that to keep your spatial index (R-Tree, whatever) up to
date.


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

I have a branch / patch for attribute change notification somewhere, and
I used it to replace the nasty hard-coded checks throughout our code for
slotting related attributes.

The reason I never pushed it was that (IIRC) it caused some race / crash
conditions at close-down time, as it would still be delivering change
notifications as gschem was winding down and free'ing the page contents.
Nothing insurmountable, but worth remembering if you grab my patch.

Look at my repo.or.cz repository, and in the "local_customisation"
branch (where I would often test things before finding a proper home for
them), you will find a commit:

551534f6cc0e951bf23121cd57a91557e9827c6d
Attribute change hooks

And

0bcf8dbc8ce2223876233e1cf0667ac785ae603a
Perform slot updates based on attribute changed hooks


Hmm.. now we have Peter's re-factored cairo rendering branch, we might
want to revisit this one too:

0eef2023a624e962feab3ebaef9c0affa08d5799
gschem: Put SVG data of the current selection onto the clipboard

(It currently relies on a proof-of-concept cairo printing code which I
was testing, but could probably be done cleanly now).


> 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).
> 
> 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.
> 
> I considered adding an EdaObjectSet to libgeda as a "proper" GObject.
> However, it occurred to me that this might not be the best option,
> because in the future it would make sense for a component to be an
> EdaObjectSet but also an EdaObject (if we turned OBJECT into a
> GObject).
> 
> My suggestion is therefore to introduce an EdaObjectSet as a gobject
> "interface" to be implemented wherever it makes sense to handle a set of
> objects.  It would then be possible add a "default" EdaObjectList class
> that provides a default implementation for the interface and could be
> used as the basis for turning the schematic page structure into a
> GObject with useful signals.

Its too late in the day for me to think clearly about OO programming
design, but it sounds OK in concept so far.


> Ideally, we shouldn't expose bare GLists anywhere in the API.  It's too
> much of a temptation to write code which hacks at the list structures
> directly rather than to use accessors that ensure consistency is
> maintained.  I'd like to introduce an EdaObjectIter to be used to
> iterate over object sets.

Sounds like a lot of work just to force people to behave. OTOH, it does
help type safety. I know that I've been undecided between both myself in
the past, and if we didn't already have this design discussion about
some interface or other, I'm surprised. (We probably looked at this
regarding GedaList?)


> Safely loading schematics and symbols
> -------------------------------------
> We have a big crash bug with the current recursive nature of our
> schematic file parser [2].  The only sane way to fix it appears to be to
> resolve and load symbols from the library on a separate pass.

Is this a good opportunity to make symbols load once, and have one
in-memory copy, plus a separate "GedaInstanceOfSymbol" data-structure on
the page?


> This might also be a good opportunity to modify the schematic loading
> logic to support GInputStream from the GIO library.

I have mixed feelings about GIO (for no good reason), but its probably
not going away any time soon. Why not.


> The main problem I have with this at the moment is trying to figure out
> what a sane API might look like.
> 
> Ideally, it would be good to provide user code with a way to get high
> quality feedback on which symbols couldn't be loaded and why they
> failed, and also to have a way to distinguish between symbols that we
> tried and failed to load vs. symbols that we haven't tried to resolve
> yet.  At the moment, if a symbol causes a parse error, 
> 
> [2] https://bugs.launchpad.net/geda/+bug/732326
> 
> 
> 
> That's all for now; it's late at night and I'm pretty knackered.
> Unfortunately, these aren't all the issues that I'm banging my head
> against...


Its a good start for now... hope I was of some help.

Best wishes,

-- 
Peter Clifton <peter.clifton@xxxxxxxxxxxxxxxxxxxxxxxxx>

Clifton Electronics