Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

[Albert C. <aca...@gm...>]

On 7/4/07, Bill Kendrick <nb...@so...> wrote:
> On Wed, Jul 04, 2007 at 02:42:31AM -0400, Albert Cahalan wrote:
> > Cleaning up that code is an excellent idea, but the *.so thing
> > doesn't seem so great.
> >
> > The *.so files will slow the start-up time. My rough guess,
> > assuming 2 disk seeks per file and 20 files, is one second.
> > (good ideas to cut startup time would be appreciated)
> > This is also one more thing to go wrong on SE Linux and
> > for portability.
>
> This is the thing I'm concerned about -- portability.

Hey, the other stuff matters too.

It can be surprisingly difficult to make SE Linux happy.
A distribution will of course include the required magic
for the packaged install, but that doesn't help compiling
from source code. (the common killer: text relocations)

Nobody likes start-up time, kid or not.

> One major benefit of making them shared libs is that people can
> create and test new magic tools without needing to download and build
> Tux Paint.  All they'll need is a C compiler and SDL libs, and I guess
> some "libtuxpaint-dev" package for headers and such.
>
> (Similar to 'libgimp2.0-dev' and 'libgimp2.0-docs' for writign GIMP plugins)
>
> Actually, it may even make more sense to sen the Magic tools
> 24bpp or 32bpp data, rather than even usign SDL_Surface and the whole
> getpixel/putpixel mess.

I really can't see this getting used. If somebody really
does want to add stuff, I don't see why they couldn't
just build the whole thing from source. That's probably
even easier to do. Having full source is good anyway.

BTW, designing a stable ABI is really hard. I've never
been able to do it for procps, despite the numerous
requests for general availability of the library.