tuxpaint-devel

[Tuxpaint-devel] Magic API updated: switchin() and switchout()

[Bill K. <nb...@so...>]

Magic Tools now receive calls to "switchin()" and "switchout()" functions
to tell them when they are being activated and deactivated.

Currently, deactivation includes when temporary events happen,
such as the user clicking Undo or Redo (or hitting Ctrl-Z, etc.),
or using Open, Save, Print, Quit, etc. functionality.
Activation occurs when those activities are finished.

I haven't tested it much, I just added some printf() to one of my tools
to check when the functions are called, but it seems to work.

Please do "cvs update -dPC" to grab the latest from the main CVS
repository.  (GSOC folks in their own branches/sandboxes/whatever,
please talk to your mentor about how to grab this.)

This won't be all -- I plan to add a UI and API for "paint or entire-image"
modes for Magic tools.  But... dinner time!

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

Re: [Tuxpaint-devel] Magic API updated: switchin() and switchout()

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

On Mon, Jul 7, 2008 at 9:57 PM, Bill Kendrick <nb...@so...> wrote:
>
> Magic Tools now receive calls to "switchin()" and "switchout()" functions
> to tell them when they are being activated and deactivated.
>
> Currently, deactivation includes when temporary events happen,
> such as the user clicking Undo or Redo (or hitting Ctrl-Z, etc.),

Quick, before this feature gets abused, add this:

Each history level should have a void* that can be
filled in by a tool, and a void(fn*)(void*,etc) that gets
called when the history level is destroyed. This would
allow tool-private data.

For example, suppose I paint with bricks. At long as
the top-most history level is the bricks tool, I want to
keep using the same old brick connectivity map. When
the user draws with something else, I need a fresh map.
If the user reverts via undo however, I want my old map.

Re: [Tuxpaint-devel] Magic API updated: switchin() and switchout()

[Bill K. <nb...@so...>]

I understand the jist, but could you give me an example chunk of code
(within a Magic tool) where this is used, so I can make sure I do it
properly?  (I don't want to forget to do this, which I will in a matter
of days :^/ )

-bill!

On Tue, Jul 08, 2008 at 04:48:24AM -0400, Albert Cahalan wrote:
> On Mon, Jul 7, 2008 at 9:57 PM, Bill Kendrick <nb...@so...> wrote:
> >
> > Magic Tools now receive calls to "switchin()" and "switchout()" functions
> > to tell them when they are being activated and deactivated.
> >
> > Currently, deactivation includes when temporary events happen,
> > such as the user clicking Undo or Redo (or hitting Ctrl-Z, etc.),
> 
> Quick, before this feature gets abused, add this:
> 
> Each history level should have a void* that can be
> filled in by a tool, and a void(fn*)(void*,etc) that gets
> called when the history level is destroyed. This would
> allow tool-private data.
> 
> For example, suppose I paint with bricks. At long as
> the top-most history level is the bricks tool, I want to
> keep using the same old brick connectivity map. When
> the user draws with something else, I need a fresh map.
> If the user reverts via undo however, I want my old map.
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

Re: [Tuxpaint-devel] Magic API updated: switchin() and switchout()

[foo-script <foo...@o2...>]

This question was to Albert but maybe... (I'm not sure of this solution)
Albert, if I use this signals incorrect let me know please.

void plugin_set_color(magic_api * api, Uint8 r, Uint8 g, Uint8 b)
allow you to fetch RGB values, but doesn't allow to create unified color value using SDL_MapRGB, but switchin() does.

void plugin_switchin(magic_api * api, int which, SDL_Surface * canvas)
{
	plugin_color=SDL_MapRGB(canvas->format, plugin_r, plugin_g, plugin_b);
}


Dnia 9 lipca 2008 2:35 Bill Kendrick <nb...@so...> napisał(a):

> 
> I understand the jist, but could you give me an example chunk of code
> (within a Magic tool) where this is used, so I can make sure I do it
> properly?  (I don't want to forget to do this, which I will in a matter
> of days :^/ )
> 
> -bill!

Re: [Tuxpaint-devel] Magic API updated: switchin() and switchout()

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

On Tue, Jul 8, 2008 at 8:35 PM, Bill Kendrick <nb...@so...> wrote:

> I understand the jist, but could you give me an example chunk of code
> (within a Magic tool) where this is used, so I can make sure I do it
> properly?  (I don't want to forget to do this, which I will in a matter
> of days :^/ )

magic/src/bricks.c

static unsigned char *map;
...
  if (!api->button_down())
  {
    if (map)
      free(map);
    // the "+ 3" allows for both ends and misalignment
    x_count = (canvas->w + nominal_width - 1) / nominal_width + 3;
    y_count = (canvas->h + nominal_height - 1) / nominal_height + 3;
    map = calloc(x_count, y_count);
  }


That "map" variable should be associated with the history.
Better code would be:

When we draw a brick, we start by creating a brick map.
If the top history item is the same size brick, then we do
a memcpy() of that. Otherwise, we zero-initialize the map.
We then push the history stack, attach our brick map to
the newly added history entry, and attach a destructor
(a function pointer) to the newly added history entry.
When the oldest history entry is freed by Tux Paint, the
core code calls that function pointer. That then lets the
magic plug-in free the brick map.

Note that a callback is needed because some tools may
wish to use a linked list or tree. It would be nice to have
a function pointer that is compatible with free() though, so
that magic plug-ins can directly use that. For plug-ins that
do not store state in the history, there should not be any
need to do anything. Tux Paint can initialize the pointer to
a dummy function.