Thread: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Bill K. <nb...@so...> - 2007-07-04 05:55:18
|
I'm putting together a basic (for now) plugin API in Tux Paint 0.9.18 that will replace the hard-coded Magic tool code in tuxpaint.c. A new 'magic' subfolder has been added to the project, with its own Makefile and 'images' subfolder full of icons. I've ported the 'Negative' tool, so far. The code uses SDL's "SDL_LoadObject()" function, and friends (found prototyped in SDL_loadso.h). The 'magic' folder generates ".so" files on Linux, which are then placed in /usr/[local/]lib/tuxpaint/. That directory is scanned by Tux Paint at startup, and any object files it can find and open, and query for the proper set of functions, will appear as Magic tools in Tux Paint. It's all very rough, and somewhat broken, but it was all written while in transit on trains today, on my 100mi trek back from work. Comments? (Other than, "you're insane", thank you :) ) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Bill K. <nb...@so...> - 2007-07-04 05:58:41
|
On Tue, Jul 03, 2007 at 10:55:15PM -0700, Bill Kendrick wrote:
>
> I'm putting together a basic (for now) plugin API in Tux Paint 0.9.18
> that will replace the hard-coded Magic tool code in tuxpaint.c.
BTW, here's the current API as I banged it out at a train station this
evening:
magic plugins must provide:
---------------------------
int get_tool_count(void)
return the number of Magic tools this plugin provides
(below, 0 <= which < get_tool_count())
char * get_name(int which)
return the name of a/the magic tool (for button)
SDL_Surface * get_icon(int which)
return the icon of a/the magic tool (for button)
char * get_description(int which)
return the description of a/the magic tool (for Tux help text)
int requires_colors(int which)
return whether a/the magic tool accepts colors
(activates color palette, or not)
void set_color(Uint8 r, Uint8 g, Uint8 g)
accept the color palette choice from Tux Paint
(only called if requires_colors() for the current tool returned true)
int init(void)
initialization function; should load it the tool icon(s) and any
other data;
return 1 if success, 0 if failure (tool(s) will be disabled in Magic tool);
happens once, at Tux Paint startup
void shutdown(void)
cleanup function; should free any alloc'd memory, icons, etc.;
happens once, at Tux Paint shutdown
void click(int which, SDL_Surface * snapshot, SDL_Surface * canvas,
int x, int y)
should affect 'canvas' at (x,y) location; may use 'snapshot' to fetch
pixels from most recent undo buffer
void drag(int which, SDL_Surface * snapshot, SDL_Surface * canvas,
int ox, int oy, int x, int y)
should affect 'canvas' between (ox,oy) and (x,y) locations;
may use 'snapshot' to fetch pixels from most recent undo buffer
tp provides:
------------
void line(SDL_Surface * snapshot, SDL_Surface * canvas,
int x1, int y1, int x2, int y2, int step, FUNC callback)
function that calls a callback between (x1,y1) and (x2,y2),
stepping 'step' in between; sends an (x,y) and 'snapshot' and 'canvas'
surfaces to the 'callback' function
void playsound(Mix_Chunk * snd, int pan, int dist)
function that plays a sound, panned left/right 'pan'
and at distance 'dist'. pan may be SNDPOS_LEFT, SNDPOS_CENTER or
SNDPOS_RIGHT, and dist may be SNDDIST_NEAR.
void putpixel(SDL_Surface * surf, int x, int y, Uint32 pixel)
function that puts a pixel at an (x,y) position in a surface
Uint32 getpixel(SDL_Surface * surf, int x, int y)
function that returns a pixel value from an (x,y) position on a surface
int in_circle(int x, int y, int radius)
function that returns whether an x/y position (centered at (0,0)) is
within a circle of 'radius'
void show_progress_bar(void)
draws the Tux Paint progress bar animation; use while you're busy
void tuxpaint_version(int * major, int * minor, int * revision)
returns the version of Tux Paint being used
void special_notify(int flag)
notifies tux paint of special events; SPECIAL_FLIP and SPECIAL_MIRROR
flags may be sent
float sRGB_to_linear_table[256]
sRGB-to-linear look-up table
unsigned char linear_to_sRGB(float linear)
linear-to-sRGB look-up helper function
Note that the 'click/drag' stuff hasn't been implemented, nor has almost
_any_ of the TP side of things (except getpixel/putpixel/in_circle, to make
the 'Negative' tool happy).
And right now, inside src/tuxpaint.c, you'll find a lot of:
#if 0 // MAGIC_ME
...
#endif
wrapped around the old Magic tool code.
Hopefully I'll have more time to work on this on my ~8hrs of train
commutting on Thursday. :)
Enjoy!
-bill!
PS - Aside from making it easier for people like _us_ to add new Magic tools
to Tux Paint, my hope is that by providing an API, high school kids in
computer programming classes might get the chance to play with C and SDL
in a way that is fun and entertaining... It would let Tux Paint, as a
project, span all they way from Preschool through to late High School,
if not early college. Awesome, no!?
|
|
From: Albert C. <aca...@gm...> - 2007-07-04 06:42:55
|
On 7/4/07, Bill Kendrick <nb...@so...> wrote: > > I'm putting together a basic (for now) plugin API in Tux Paint 0.9.18 > that will replace the hard-coded Magic tool code in tuxpaint.c. > > A new 'magic' subfolder has been added to the project, with its own Makefile > and 'images' subfolder full of icons. I've ported the 'Negative' tool, so far. > The code uses SDL's "SDL_LoadObject()" function, and friends (found > prototyped in SDL_loadso.h). The 'magic' folder generates ".so" files on > Linux, which are then placed in /usr/[local/]lib/tuxpaint/. 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. I suggest doing a bit like the OO style used in the kernel, where each object is represented by a struct that contains function pointers and other data. Since you don't need to do real modules, you don't need a real registration function. Simply create an array of pointers to these structs, or (better) an array of the structs. |
|
From: Bill K. <nb...@so...> - 2007-07-04 19:58:24
|
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. How does a project like The GIMP handle it? 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 figure I've got 6mo to a year to figure this junk out, before a new release of Tux Paint, but I really _would_ like to try to go the .so/.dll/etc. route. -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Albert C. <aca...@gm...> - 2007-07-05 03:24:01
|
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. |
|
From: Caroline F. <car...@go...> - 2007-07-04 21:19:04
|
On Tue, 2007-07-03 at 22:55 -0700, Bill Kendrick wrote: > I'm putting together a basic (for now) plugin API in Tux Paint 0.9.18 > that will replace the hard-coded Magic tool code in tuxpaint.c. > > A new 'magic' subfolder has been added to the project, with its own Makefile > and 'images' subfolder full of icons. I've ported the 'Negative' tool, so far. > The code uses SDL's "SDL_LoadObject()" function, and friends (found > prototyped in SDL_loadso.h). The 'magic' folder generates ".so" files on > Linux, which are then placed in /usr/[local/]lib/tuxpaint/. > > That directory is scanned by Tux Paint at startup, and any object files it > can find and open, and query for the proper set of functions, will appear > as Magic tools in Tux Paint. > > It's all very rough, and somewhat broken, but it was all written while > in transit on trains today, on my 100mi trek back from work. > > Comments? (Other than, "you're insane", thank you :) ) > I think there are other open source plugin standards that it would be cool to be compliant with, if we can. KDE has something for Krita etc? Does the GIMP? I've no idea if it is viable but I love the idea, an opensource equivalent of the photoshop plugin. BTW have we officially released? Was there a fanfare? ;) Caroline |
|
From: Bill K. <nb...@so...> - 2007-07-05 05:20:33
|
On Wed, Jul 04, 2007 at 10:26:43PM +0100, Caroline Ford wrote: > I think there are other open source plugin standards that it would be > cool to be compliant with, if we can. KDE has something for Krita etc? > Does the GIMP? I'm not sure any of them would be exactly what Tux Paint needs. Tux Paint's API would be an X,Y location (or pair of, for mouse motion) which are meant to affect the current canvas. Most Gimp plugins affect the current layer or selection, and often require additional user input (e.g., "you want to blur... how much? [ 3 ] [OK]" :) ) > I've no idea if it is viable but I love the idea, an opensource > equivalent of the photoshop plugin. > > BTW have we officially released? Was there a fanfare? ;) 0.9.17 was released on July 1st. I posted to tuxpaint-news. Oops, I need to post to tuxpaint-users, too. So busy on the train on Tues/Thurs, working full time 5 days a week, and with a baby at home, that I don't get much online time to do the kind of PR I used to. I do subscribe to Google's Blog Search for "tuxpaint OR 'tux paint'", and noticed a lot of software sites and software and personal blogs mentioning the new release, and hit a few of the standard sites (freshmeat, linuxgames, etc.) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Mark K. K. <mkk...@gm...> - 2007-07-07 17:06:39
|
On Wed, Jul 04, 2007 at 12:57:45PM -0700, Bill Kendrick wrote: [regarding magic tools plugins] > This is the thing I'm concerned about -- portability. Libtool creates cross-platform shared libraries. It's one of the Autotools package (Autoconf, Automake, Libtool). -Mark |
|
From: Bill K. <nb...@so...> - 2007-07-07 19:51:23
|
On Sat, Jul 07, 2007 at 10:06:39AM -0700, Mark K. Kim wrote: > On Wed, Jul 04, 2007 at 12:57:45PM -0700, Bill Kendrick wrote: > [regarding magic tools plugins] > > This is the thing I'm concerned about -- portability. > > Libtool creates cross-platform shared libraries. It's one of the > Autotools package (Autoconf, Automake, Libtool). Was just looking into this, due to John P. mentioning it. I'm not currently using libtool, but am getting this creeping feeling I should. :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
Thanks for helping keep SourceForge clean.
X