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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]