[Pipet Devel] Re: Sodipodi and Loci

J.W. Bizzaro bizzaro at geoserve.net
Mon Jan 17 02:52:46 EST 2000

Hi Lauris!

I'm sorry about the very late reply.  I got a bit distracted by a script
kiddie who broke into our system.  It's all taken care of now.

Lauris Kaplinski wrote:
> I'm very glad to hear about interest in sodipodi. Loci really seems an
> interesting project and I would be glad, if I can help you in any means.
> Still I have to say, that svg support in sodipodi is currently quite
> limited (paths, rects, ellipses, images, texts + corresponding css
> properties), but I hope it could be extended step by step using existing
> framework.

Well, we noticed that Sodipodi is new, since we've been looking for a GPL
vector drawing program for Gnome for almost a year now.  We were considering
Sketch, but it doesn't do SVG.  And Loci is new too, so we understand that all
may not be as functional as desired.

> 1. Widgets
> Currently I'm doing GUI exclusively with glade, but this should change in
> future.

Do you mean that you're using libglade?

> The plan is to switch to GnomeMDI - and it does not do well with
> glade generated application windows. Then the display object will be
> separate widget (GnomeMDIView) anyway.
> The sodipodi view object (desktop) actually only needs accessible
> GnomeCanvas, so it should be possible to make very thin views, if needed.

That's pretty much what we're looking to run in Loci: a thin, non-editing
viewer of SVG-defined graphics (of course, using Gnome/Gtk+ and licensed under
the GPL).  Drag-and-drop from the viewer to Sodipodi would also be nice.

What I didn't mention last time is that Loci is coded in Python and uses
gnome-python.  If we go the 'Sodipodi as a widget' route, we'll have to make
Python bindings to it.

> 2. Corba
> As of bonobo support, is is (of course) planned in both ways (as component
> and container), but at moment I've not touched it yet. This will take some
> time, as I've to familiarize myself with bonobo beforehand.

If you use Bonobo, it would be desirable if we could have a thin view of
Sodipodi and not the whole GUI.  Loci uses little windows called 'windowlets',
and this is where we would put a thin Sodipodi view.  So, the simpler the

> In addition to your two ideas, I can imagine using DOM and DOM Corba
> bindings for manipulating vector objects. Sodipodi does not use DOM at
> moment, as this (gdome) seemed a bit too complicated and incomplete at the
> time I started. But it is designed such way that my own xml wrapper
> (repr) can be replaced with DOM with minimal hazzle. If done, this should
> make possible quite nice document model:
> xml + DOM <-> sodipodi core <-> Sodipodi component
> in server     in client         Embedded in client canvas
> bacbone       |
> |             + - Low latency plugins (affine transforms)
> |
> +- Big latency plugins (setting color, fill etc.)
> The one reason the middle object layer (items) are designed, is to speed
> up interactive modifications when DOM backbone resides across network
> (during dragging only display is updated, if button is released, the xml
> tree is also changed)

We have been looking into similar models for Loci.  XML and DOM will certainly
be used.  We'll likely have some uses for CORBA too.  But much of how we will
generate SVG graphics hasn't been worked out (some of it has been worked out -
see below).

> I downloaded loci-core & tried to look at it, but it hanged after
> displaying big blue window and small one with progressbar. I still hope, I
> can make it work if I tinker with it a bit.

The snapshot you got is fairly old now, but it'll give you the right idea. 
Also, Loci is in the 'embryonic' stage of development, so...there's so little
there that it may _look_ like it's frozen.  The frozen progressbar was just a
test, and the blue workspace is just empty, not frozen.  Everything is
popup-menu-driven in the workspace, so try clicking on the right mouse button

> Meanwhile I'm curious, how complex the vector 'widgets' are supposed to
> be

Well, it'd be nice if we could take full advantage of what SVG is capable of.

> and how much interaction takes place between user and 'widgets'.

Within the 'thin view' that will appear in Loci's workspace, almost no
interaction should take place.  A possible exception would be scaling.

The idea is that the SVG graphic will be computer-generated.  For example, one
program (running under the Loci shell) may need to display a table of some
sort.  Loci would then pull an SVG description of a table out of the library
and add whatever the program specified.  This is why we're calling them
'graphical widgets': They're like GUI widgets in that most of the drawing has
been done; all that's left is filling in some parameters.

> Does
> any graphical editing take place, or is the main function simply
> displaying svg? In latter case it should be useful to make most editing
> part of sodipodi facultative to reduce code bloat.


> As Loci uses xml, what is the internal representation of existing objects
> (DOM?)

Yes, we're using DOM internally.  But these are things we've just started to
implement (within the last few weeks).

> is it exported & so on.

If you're asking about object transfer in Loci, well, we've been arguing over
how that could be done.  XML-RPC, CORBA, Python active objects, and even HTTP
have been considered.

> Also, sodipodi object structure probably still changes a lot. So if you
> have good idea, what component structure/level/interaction would be
> usable for you, chances are that these would be usable to others too.

Yeah, Loci's object structure is changing a lot too.  If I could have my
choice, I'd probably want a thin viewer widget that will do DnD with
Sodipodi.  The other developers involved in Loci (about 30 on the list, with 6
actively involved) might want something else.  I'll ask.

                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |           THE OPEN LAB           |
                      |    Open Source Bioinformatics    |
                      |                                  |
                      |    http://bioinformatics.org/    |

More information about the Pipet-Devel mailing list