Re: [Sodipodi-list] Some plug-in interface ideas (fwd)

[Alan Horkan <horkana tcd ie>]

Someone mentioned libraries and had to add my few words as he mentioned a
bunch of other vector graphics programs except Dia.
http://www.geocrawler.com/lists/3/SourceForge/2577/0/9511007/

What kind of Sodipodi functionality would it be useful for Dia to take a
chunk out of?  He is considering turning some of the code into libraries,
so now is the time to ask.

Lauris Kaplinski the Sodipodi developer calling my bluff, I dont really
know what would really be most useful for Dia but I know there has got to
be some stuff that could be shared.

You can either contact him and the Sodipodi list directly or respond here
and ill will try and pass on your comments in such as way as to make me
seem smarter ;)

Later
Alan

---------- Forwarded message ----------
Date: 05 Sep 2002 18:14:20 +0200
From: Lauris Kaplinski <lauris@kaplinski.com>
To: Alan Horkan <horkana@tcd.ie>
Cc: Ted Gould <ted@gould.cx>,
     Sodipodi List <sodipodi-list@lists.sourceforge.net>
Subject: Re: [Sodipodi-list] Some plug-in interface ideas

Hello!

Can you outline, please, which kind of functionality and how to
move into given library? The only thing I have been thinking
until now, are very basic things:
- libart replacement (faster, cleaner, smaller)
- SVG parsing library (building libart or similar datatypes)
- Canvas replacement (cleaner and not Gtk-tied)
But is waay to low level for plugins, which need handles to SVG
data (DOM-like or other) and UI structures (which affects the generic
application framework).

Best wishes,
Lauris Kaplinski


On Thu, 2002-09-05 at 14:19, Alan Horkan wrote:
> If even the open source Vector Applictions could find more ways to share
> developement (how about a libsvg?) it would save a lot of work, not to
> mention how much more efficient it would be if this could be done in a way
> that was easily reusable by any Gtk applications.  (Maybe i am being
> unrealistic, but the planning stage is the right time to mention these
> sorts of possibilities).
>
> As for Lauris complaint about libs with changing APIs, design a good clear
> API and stick with it.  So long as you only deprecate the old methods
> rather than remove them it should not be too bad.  It is better than no
> lib at all and having many projects doing redundant work.
> I am just dissapointed that there is not more code/component reuse.
>
> Sincerely
> Alan.
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Sodipodi-list mailing list
> Sodipodi-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sodipodi-list
>




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Sodipodi-list mailing list
Sodipodi-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sodipodi-list