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
>