geda-developers team mailing list archive

[Ivan Stankovic <pokemon@xxxxxxxxxxxxxx>]

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.

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

> 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/5a57c7d2b70d8e1acf683deb7314e9d861fd8271:/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.

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.

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

Yes, that would be nice.

> 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.
[...]
> [2] https://bugs.launchpad.net/geda/+bug/732326

Ouch, that's embarassing.  :-)

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

It's nice that you brought this up since it shows the real problems in current
libgeda implementation that are preventing us from moving forward and doing
cool things. My feeling is that, however you intend to solve these and other
such problems, you will end up with a rewrite of most of gEDA code.

-- 
Ivan Stankovic, pokemon@xxxxxxxxxxxxxx

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