tuxpaint-devel

[Tuxpaint-devel] Kids mode

[Pere P. i C. <per...@gm...>]

Hi all,

In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
It also implements an increasing of the canvas via hide/show the color row and Tux row.

If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.

The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
https://github.com/tux4kids/Tuxpaint-Android/pull/48

The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz


Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
interface, the expert/kids button at the top left of the screen.

Are we interested in anything of this?
Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
As for the increase of canvas I guess the same, let the users choose if they want it.

Thanks for any comments :)
Pere


P.S. The small patch, already applied, that allows to compile and run under Linux

pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
Barkow-Kuder/src 
diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
1329,1332d1328
<     locale = android_locale();
< #endif
< 
<   if (locale == NULL)
1334c1330,1331
< 
---
> #endif
>   
diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
4298a4299
> #ifdef __ANDROID__
4305a4307
> #endif /* #ifndef NOSOUND */
4719a4722
> #ifdef __ANDROID__
4721a4725
> #endif
10064c10068,10069
<         
---
>         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> 	  {
10066c10071
<         SDL_Surface *handle_icon = loadimage(handle_fname);
---
>         SDL_Surface *handle_icon = loadimage(fname);
10090c10095
<         }
---
>         }}

Re: [Tuxpaint-devel] Kids mode

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

On Fri, Oct 17, 2025 at 11:35:07PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
> It also implements an increasing of the canvas via hide/show the color row and Tux row.
> 
> If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.
> 
> The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
> https://github.com/tux4kids/Tuxpaint-Android/pull/48

Hm, this is interesting, though it definitely seems to need some work
before it's ready for prime time...  at least, based on the Linux desktop
version you shared here, Pere:

> The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
> https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz

It compiles fine, though has many warnings.  Is it based off the
latest code in master branch at SourceForge or in GitHub?
(I'm down to a lovely zero compiler warnings when I run `make`
against master :-) )

The UI seems to have a few issues.  When I switch back to default/classic
mode, the icons on the buttons seem to be drawn twice, slightly offset,
giving a double-vision effect.

It seems in some situations, when the color buttons appear, they don't
disappear, or the big button to call them up doesn't reappear.

Also, I have the ability to choose colors in unexpected situations,
e.g. when using the Eraser.

A lot of things don't get removed properly (e.g., I end up with little
chunks of Tux penguin at the bottom left, as he changes postures).

The sound on/off mute button doesn't seem to work, unless the classic
UI is shown.

I tried running it in a 640x480, and see that the toolbar on the left
has scroll buttons, but when I scrolled down, and then tried to scroll
back up, my clicks on the up-arrow at the top were getting misinterpreted.
It looks like the toggle button is being detected a lot lower than it's
appearing visually (i.e., outside of the button graphic), and in fact
within the scroll-up button's realm. :-(

Save never becomes available.  Undo doesn't seem to do anything
(and therefore redo doesn't become available).  If I draw some things
in classic mode, and then hit Undo, then go to child mode, the Redo
button is STILL not available.  So I figure whatever's going on with
these buttons is as-of-yet unfinished...?


> Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
> interface, the expert/kids button at the top left of the screen.
> 
> Are we interested in anything of this?

I find it an interesting idea, but I feel like it takes away a lot of
what makes Tux Paint fun and special (stamps and magic, in particular)
when the "child mode" is in place...  but then they're easily accessible
by toggling back to normal mode.  So, IMO, why bother? :-)

If there's a need for an app that only does paint, eraser, fill,
undo/redo, then it probably makes sense to just create that simple
tool from scratch.

If we need a way for the existing UI to become even simpler, then
we can try and address that within the existing UI code (like we
did when we added more scrollbars, larger button support, etc.)


> Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
> As for the increase of canvas I guess the same, let the users choose if they want it.

I tend to agree.

>From a real-world-usage point of view, one of the things I see people
most confused/annoyed by is Tux Paint's inability to resize on the fly.
(Not realizing its a setting, which admittedly is an akward way of
handling things.  But we started all this with SDL, a game library
from a certain era, hehehe.)

So if I were to spend time on Tux Paint things right now, it would
be (in no particular order):

 * brush sizing (to complement brush spacing)
 * redoing all of the UI graphics (button icons, etc.) "in HD"
 * on-the-fly window resizing
 * SDL 3 port
 * improved tablet support
 * just, like, improving everything :-D


Thanks a lot for your efforts into making this accessible,
and I'm happy to continue talking about it / considering things.
Perhaps once it's all up and running _correctly_, I might be
convinced that it'd be an interesting option to add.
(It'd need to be worth the maintenance costs, of course!)

So far, though, I don't quite see the demand for this particular
feature. :shrug:  I'm curious what others think, though!

-bill!

> Thanks for any comments :)
> Pere
> 
> 
> P.S. The small patch, already applied, that allows to compile and run under Linux
> 
> pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
> Barkow-Kuder/src 
> diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
> 1329,1332d1328
> <     locale = android_locale();
> < #endif
> < 
> <   if (locale == NULL)
> 1334c1330,1331
> < 
> ---
> > #endif
> >   
> diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
> 4298a4299
> > #ifdef __ANDROID__
> 4305a4307
> > #endif /* #ifndef NOSOUND */
> 4719a4722
> > #ifdef __ANDROID__
> 4721a4725
> > #endif
> 10064c10068,10069
> <         
> ---
> >         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> > 	  {
> 10066c10071
> <         SDL_Surface *handle_icon = loadimage(handle_fname);
> ---
> >         SDL_Surface *handle_icon = loadimage(fname);
> 10090c10095
> <         }
> ---
> >         }}
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] Kids mode

[Pere P. i C. <per...@gm...>]

El dv. 17 de 10 de 2025 a les 23:01 +0100, en/na Bill Kendrick va escriure:
> On Fri, Oct 17, 2025 at 11:35:07PM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
> > It also implements an increasing of the canvas via hide/show the color row and Tux row.
> > 
> > If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.
> > 
> > The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
> > https://github.com/tux4kids/Tuxpaint-Android/pull/48
> 
> Hm, this is interesting, though it definitely seems to need some work
> before it's ready for prime time...  at least, based on the Linux desktop
> version you shared here, Pere:
> 
> > The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
> > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz
> 
> It compiles fine, though has many warnings.  Is it based off the
> latest code in master branch at SourceForge or in GitHub?
> (I'm down to a lovely zero compiler warnings when I run `make`
> against master :-) )

It is based on the 0.9.35 code we have at github


> 
> The UI seems to have a few issues.  When I switch back to default/classic
> mode, the icons on the buttons seem to be drawn twice, slightly offset,
> giving a double-vision effect.

Yep, not sure if this is my patch, it touches something related to loading images.


> 
> It seems in some situations, when the color buttons appear, they don't
> disappear, or the big button to call them up doesn't reappear.
> 
> Also, I have the ability to choose colors in unexpected situations,
> e.g. when using the Eraser.
> 
> A lot of things don't get removed properly (e.g., I end up with little
> chunks of Tux penguin at the bottom left, as he changes postures).

Thinking about expanding the canvas, it sounds more for advanced users?


> 
> The sound on/off mute button doesn't seem to work, unless the classic
> UI is shown.

Seems this is intended to avoid small children to play with sound, but then, why a button at all for them?


> 
> I tried running it in a 640x480, and see that the toolbar on the left
> has scroll buttons, but when I scrolled down, and then tried to scroll
> back up, my clicks on the up-arrow at the top were getting misinterpreted.
> It looks like the toggle button is being detected a lot lower than it's
> appearing visually (i.e., outside of the button graphic), and in fact
> within the scroll-up button's realm. :-(
> 
> Save never becomes available.  Undo doesn't seem to do anything
> (and therefore redo doesn't become available).  If I draw some things
> in classic mode, and then hit Undo, then go to child mode, the Redo
> button is STILL not available.  So I figure whatever's going on with
> these buttons is as-of-yet unfinished...?
> 
> 
> > Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
> > interface, the expert/kids button at the top left of the screen.
> > 
> > Are we interested in anything of this?
> 
> I find it an interesting idea, but I feel like it takes away a lot of
> what makes Tux Paint fun and special (stamps and magic, in particular)
> when the "child mode" is in place...  but then they're easily accessible
> by toggling back to normal mode.  So, IMO, why bother? :-)

Well, to toggle to normal mode in Android you have to hit the button for 3 seconds, this is one of the differences with the Linux version.
Another difference is that in Android it starts in child mode.


> 
> If there's a need for an app that only does paint, eraser, fill,
> undo/redo, then it probably makes sense to just create that simple
> tool from scratch.
> 
> If we need a way for the existing UI to become even simpler, then
> we can try and address that within the existing UI code (like we
> did when we added more scrollbars, larger button support, etc.)
> 
> 
> > Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
> > As for the increase of canvas I guess the same, let the users choose if they want it.
> 
> I tend to agree.
> 
> From a real-world-usage point of view, one of the things I see people
> most confused/annoyed by is Tux Paint's inability to resize on the fly.
> (Not realizing its a setting, which admittedly is an akward way of
> handling things.  But we started all this with SDL, a game library
> from a certain era, hehehe.)
> 
> So if I were to spend time on Tux Paint things right now, it would
> be (in no particular order):
> 
>  * brush sizing (to complement brush spacing)
>  * redoing all of the UI graphics (button icons, etc.) "in HD"


>  * on-the-fly window resizing

This needs some thinking, size of the drawing? I assume it will not change when resizing the window, at least not change lossy, but then we will need scrollbars if the canvas ends up smaller than the
drawing, and what to do if the canvas ends larger than the drawing?, let the drawing at its original size in a half empty canvas?, scale the _display_ of the drawing to fit the canvas?, expand the
drawing with empty space?, but then what about starters?
And if we make the canvas size independent of the drawing size then a setting like --drawing-size will make sense...

>  * SDL 3 port
>  * improved tablet support

In progress :)


>  * just, like, improving everything :-D

Ofc :)


Thanks!
Pere

> 
> 
> Thanks a lot for your efforts into making this accessible,
> and I'm happy to continue talking about it / considering things.
> Perhaps once it's all up and running _correctly_, I might be
> convinced that it'd be an interesting option to add.
> (It'd need to be worth the maintenance costs, of course!)
> 
> So far, though, I don't quite see the demand for this particular
> feature. :shrug:  I'm curious what others think, though!
> 
> -bill!
> 
> > Thanks for any comments :)
> > Pere
> > 
> > 
> > P.S. The small patch, already applied, that allows to compile and run under Linux
> > 
> > pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
> > Barkow-Kuder/src 
> > diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
> > 1329,1332d1328
> > <     locale = android_locale();
> > < #endif
> > < 
> > <   if (locale == NULL)
> > 1334c1330,1331
> > < 
> > ---
> > > #endif
> > >   
> > diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
> > 4298a4299
> > > #ifdef __ANDROID__
> > 4305a4307
> > > #endif /* #ifndef NOSOUND */
> > 4719a4722
> > > #ifdef __ANDROID__
> > 4721a4725
> > > #endif
> > 10064c10068,10069
> > <         
> > ---
> > >         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> > > 	  {
> > 10066c10071
> > <         SDL_Surface *handle_icon = loadimage(handle_fname);
> > ---
> > >         SDL_Surface *handle_icon = loadimage(fname);
> > 10090c10095
> > <         }
> > ---
> > >         }}
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel