tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dg. 27 de 07 de 2025 a les 11:08 +0100, en/na Bill Kendrick va escriure:
> On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote:
> > El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> > > Hi!
> > > 
> <snip>
> > > > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > > > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > > > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> > > 
> > > SDL3_mixer seems to be under a very active work in progress.
> > > 
> > > I also once succeeded to build it but currently it fails with the same error bill mentioned.
> > > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".
> 
> That commit has a lot fewer source files.  MIX_Track doesn't yet
> exist; there's no "SDL_mixer_internal.h".  That said, it DID build. :-D
> 
> And Tux Paint builds (in its entirety) for me, with only this change
> to Makefile
> 
>   -SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs)
>   +SDL_LIBS+=-lSDL3_gfx
> 
> It knows it's built with SDL3:
> 
>   kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version 
>   
>   Tux Paint
>     Version 0.9.36 (2025-07-27)
>   
>   Built with these options:
>     SDL version 3.2.18
> 
> However, it segfaults after the splash screen appears.
> (It was built WITH all magic tools, this time around.)
> 
> I'll keep investigating when I can :)
> 
> 
> > > I will wait for a while until it would be more stable.
> 
> We might need to, hehe.

I agree too.


> > 
> > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
> > builds fine for me.

The SDL3_mixer library builds fine, but after installed it,   
breaks the Tux Paint build, so Tux Paint would need to be adapted   
to the changes in the mixer lib.

For now, I am going to downgrade the mixer in my box to the  
4e9a308a0daa63b6bd492b0ec616f86337500898 commit until more people   
is able to compile the main branch of SDL3_Mixer.


> > 
> > Starting at the root of the source, rm the "build" directory if it has been created before, then:
> > mkdir build && cd build && cmake -S .. -B . && make
> 
> That commit continued to not build, due to `position3d` and `position`
> differences in the struct described in "SDL_mixer_internal.h", and how
> it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
> on "master" branch.)


Strange, could be that a different compiler/make/whatever would not throw errors?  
It builds here with no complaints.  
In case of that helps:

gcc --version  
gcc (Debian 14.2.0-19) 14.2.0

make --version  
GNU Make 4.4.1

ldd --version  
ldd (Debian GLIBC 2.41-6) 2.41

cmake --version  
cmake version 3.18.4


HTH  
Pere

Re: [Tuxpaint-devel] Started the port to SDL3

[Mark K. <mar...@gm...>]

On Sun, Jul 27, 2025 at 6:08 AM Bill Kendrick <nb...@so...> wrote:
[snip]

> However, it segfaults after the splash screen appears.
> (It was built WITH all magic tools, this time around.)
>

The SDL3 branch of Tux Paint started crashing on macOS, too.  The cause
appears to be commit 499630757dca284de759b86650879763784a94b8 of
magic/src/emitter.c.  Reverting this one file to the prior commit allows
Tux Paint to run on macOS without crashing once again.  Deleting the
emitter.dylib shared library also allows Tux Paint to run on macOS again.

Can you see if the above workarounds for the macOS build also works for the
Linux build?


> I'll keep investigating when I can :)
>
>
> > > I will wait for a while until it would be more stable.
>
> We might need to, hehe.
>
>
> > > Just FYI.
> >
> > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July
> 26
> > builds fine for me.
> >
> > Starting at the root of the source, rm the "build" directory if it has
> been created before, then:
> > mkdir build && cd build && cmake -S .. -B . && make
>
> That commit continued to not build, due to `position3d` and `position`
> differences in the struct described in "SDL_mixer_internal.h", and how
> it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
> on "master" branch.)
>
> Strange!
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Started the port to SDL3

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

On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote:
> El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> > Hi!
> > 
<snip>
> > > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> > 
> > SDL3_mixer seems to be under a very active work in progress.
> > 
> > I also once succeeded to build it but currently it fails with the same error bill mentioned.
> > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".

That commit has a lot fewer source files.  MIX_Track doesn't yet
exist; there's no "SDL_mixer_internal.h".  That said, it DID build. :-D

And Tux Paint builds (in its entirety) for me, with only this change
to Makefile

  -SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs)
  +SDL_LIBS+=-lSDL3_gfx

It knows it's built with SDL3:

  kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version 
  
  Tux Paint
    Version 0.9.36 (2025-07-27)
  
  Built with these options:
    SDL version 3.2.18

However, it segfaults after the splash screen appears.
(It was built WITH all magic tools, this time around.)

I'll keep investigating when I can :)


> > I will wait for a while until it would be more stable.

We might need to, hehe.


> > Just FYI.
> 
> Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
> builds fine for me.
> 
> Starting at the root of the source, rm the "build" directory if it has been created before, then:
> mkdir build && cd build && cmake -S .. -B . && make

That commit continued to not build, due to `position3d` and `position`
differences in the struct described in "SDL_mixer_internal.h", and how
it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
on "master" branch.)

Strange!

-bill!

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
> > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> > > On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> > > There is not yet a release of SDL3_mixer, 
> > 
> > Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
> > I don't  remember having to do anything special to build it.
> > commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.
> 
> <... snip ...>
> 
> On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
> > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> > > so I cloned the repo
> > > (https://github.com/libsdl-org/SDL_mixer) but unfortunately
> > > cannot build it (`cmake --build build`) due to some compiler
> > > errors:
> > > 
> > >   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
> > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> 
> SDL3_mixer seems to be under a very active work in progress.
> 
> I also once succeeded to build it but currently it fails with the same error bill mentioned.
> Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".
> 
> I will wait for a while until it would be more stable.
> 
> Just FYI.

Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
builds fine for me.

Starting at the root of the source, rm the "build" directory if it has been created before, then:
mkdir build && cd build && cmake -S .. -B . && make

HTH
Pere

Re: [Tuxpaint-devel] Started the port to SDL3

[Shin-ichi T. <dol...@wm...>]

Hi!

On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
>El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
>> On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
>> There is not yet a release of SDL3_mixer, 
>
>Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
>I don't  remember having to do anything special to build it.
>commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.

<... snip ...>

On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
>El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
>> so I cloned the repo
>> (https://github.com/libsdl-org/SDL_mixer) but unfortunately
>> cannot build it (`cmake --build build`) due to some compiler
>> errors:
>> 
>>   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
>>   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
>>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
>>     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.

SDL3_mixer seems to be under a very active work in progress.

I also once succeeded to build it but currently it fails with the same error bill mentioned.
Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".

I will wait for a while until it would be more stable.

Just FYI.

-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Started the port to SDL3

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

On Fri, Jul 25, 2025 at 09:47:22AM +0200, Pere Pujal i Carabantes wrote:
> El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
<snip>
> > I can launch Tux Paint, and see the splash screen, but
> > then it seems to freeze.
> 
> Dropping all magic plugins resulted in a freeze splash screen.
> Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc
> when I wanted to concentrate in other stuff.

Ah, another 'upstream' bug, I suppose! :-)

-bill!

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > About three months ago I started that port, now after the release of 0.9.35 I am continuing it :)
> > 
> > The source code is currently inside the sdl3 branch in my personal fork at SourceForge
> > https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/
> > 
> > It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one:
> > https://github.com/sabdul-khabir/SDL3_gfx
> > 
> > And needs also SDL3_Pango wich I have working but needs a lot of cleaning 
> > before it gets ready for a merge request,
> > I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
> > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/
> > 
> > After installing them, and the SDL3* libraries that come in my distribution, 
> > I am able to compile and run Tux Paint in my box :)
> > Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine.
> > im and labels too but they are not tested hard.
> 
> There is not yet a release of SDL3_mixer, 
> 

Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
I don't  remember having to do anything special to build it.
commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.



> so I cloned the repo
> (https://github.com/libsdl-org/SDL_mixer) but unfortunately
> cannot build it (`cmake --build build`) due to some compiler
> errors:
> 
>   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
>   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
>     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
>         |                       ^~
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’:
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’?
>     218 |                     MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers);
>         |                                                                  ^~~~~~~~~~
>         |                                                                  position
>   [... plus more places where it complaints about `position3d` vs `position` ...]
> 
> 
> If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`),
> I got a number of errors due to parts of the code trying to use the
> mixer library (e.g., #include it, or declare variables of type Mix_Chunk).
> 
> I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project);
> it's just hard for me to notice them because I _have_ SDL_Mixer (version 2)
> installed. :-)  I'll need to sort that out.
> 
> 
> Beyond that, I'm also having trouble with SDL3_gfx.  When I run `make`
> to do _anything_, it seems to always show this:
> 
>   Package sdl3-gfx was not found in the pkg-config search path.
>   Perhaps you should add the directory containing `sdl3-gfx.pc'
>   to the PKG_CONFIG_PATH environment variable
>   Package 'sdl3-gfx', required by 'virtual:world', not found
>   Makefile:340: -lSDL3_Mixer failed, no sound for you!
>   Package sdl3-gfx was not found in the pkg-config search path.
>   Perhaps you should add the directory containing `sdl3-gfx.pc'
>   to the PKG_CONFIG_PATH environment variable
>   Package 'sdl3-gfx', required by 'virtual:world', not found
>   make: *** No rule to make target 'nosound'.  Stop.
> 
> And when I get it to compile, and it goes to link,
> it cannot find `zoomSurface` or `rotozoomSurface`,
> unsurprisingly:
> 
> 
>   ...Linking Tux Paint...
>   cc  -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1  -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1     -I/usr/local/include  -I/usr/include/fribidi  -I/usr/include/libxml2  -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND     \
>           -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \
>           -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3  -lSDL3_image -lSDL3_ttf -lz  -lpng16   -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype  -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo  -lpaper -lfribidi  -lxml2  -limagequant -lm
>   /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface'
>   /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow
>   collect2: error: ld returned 1 exit status
>   make: *** [Makefile:1258: tuxpaint] Error 1
> 
> However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig.
> I just ended up hard-coding it, for now:
> 
> 
>   SDL_LIBS+=-lSDL3_gfx
> 
> Finally, the Magic tools all want SDL_Mixer too,
> so I just dropped "magic-plugins" from Makefile's "all"
> target, and it built!
> 
> I can launch Tux Paint, and see the splash screen, but
> then it seems to freeze.

Dropping all magic plugins resulted in a freeze splash screen.
Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc
when I wanted to concentrate in other stuff.


> 
> Okay, it's very late so I need to stop for now.
> 
> -bill!
> 

Re: [Tuxpaint-devel] Started the port to SDL3

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

On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> About three months ago I started that port, now after the release of 0.9.35 I am continuing it :)
> 
> The source code is currently inside the sdl3 branch in my personal fork at SourceForge
> https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/
> 
> It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one:
> https://github.com/sabdul-khabir/SDL3_gfx
> 
> And needs also SDL3_Pango wich I have working but needs a lot of cleaning 
> before it gets ready for a merge request,
> I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
> https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/
> 
> After installing them, and the SDL3* libraries that come in my distribution, 
> I am able to compile and run Tux Paint in my box :)
> Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine.
> im and labels too but they are not tested hard.

There is not yet a release of SDL3_mixer, so I cloned the repo
(https://github.com/libsdl-org/SDL_mixer) but unfortunately
cannot build it (`cmake --build build`) due to some compiler
errors:

  [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
  In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
    139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
        |                       ^~
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’:
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’?
    218 |                     MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers);
        |                                                                  ^~~~~~~~~~
        |                                                                  position
  [... plus more places where it complaints about `position3d` vs `position` ...]


If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`),
I got a number of errors due to parts of the code trying to use the
mixer library (e.g., #include it, or declare variables of type Mix_Chunk).

I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project);
it's just hard for me to notice them because I _have_ SDL_Mixer (version 2)
installed. :-)  I'll need to sort that out.


Beyond that, I'm also having trouble with SDL3_gfx.  When I run `make`
to do _anything_, it seems to always show this:

  Package sdl3-gfx was not found in the pkg-config search path.
  Perhaps you should add the directory containing `sdl3-gfx.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'sdl3-gfx', required by 'virtual:world', not found
  Makefile:340: -lSDL3_Mixer failed, no sound for you!
  Package sdl3-gfx was not found in the pkg-config search path.
  Perhaps you should add the directory containing `sdl3-gfx.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'sdl3-gfx', required by 'virtual:world', not found
  make: *** No rule to make target 'nosound'.  Stop.

And when I get it to compile, and it goes to link,
it cannot find `zoomSurface` or `rotozoomSurface`,
unsurprisingly:


  ...Linking Tux Paint...
  cc  -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1  -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1     -I/usr/local/include  -I/usr/include/fribidi  -I/usr/include/libxml2  -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND     \
          -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \
          -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3  -lSDL3_image -lSDL3_ttf -lz  -lpng16   -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype  -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo  -lpaper -lfribidi  -lxml2  -limagequant -lm
  /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface'
  /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow
  collect2: error: ld returned 1 exit status
  make: *** [Makefile:1258: tuxpaint] Error 1

However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig.
I just ended up hard-coding it, for now:


  SDL_LIBS+=-lSDL3_gfx

Finally, the Magic tools all want SDL_Mixer too,
so I just dropped "magic-plugins" from Makefile's "all"
target, and it built!

I can launch Tux Paint, and see the splash screen, but
then it seems to freeze.

Okay, it's very late so I need to stop for now.

-bill!

> 
> I'd really like reviews  and tests, below some things that would need help:
> 
> im subsystem:
> I don't know the languages we provide im for, so a test about correctness would be welcome.
> Right Alt do not work in the SDL3 version I have installed, so I've added Left Alt to Thai, even if it was explicitly disabled.
> Oher languages made use of both, left and right alt, now in my box, only left works.
> 
> 
> Fill Lineal doesn't work properly on single click inside small circles, without drag, I am currently investigating this...
> 
> 
> Magic tools:
> there are plenty of magic tools in the magic/src/WIP_SDL3 directory that are waiting to be ported.
> 
> 
> Wew, too long message, thanks for reading, and thaks for any help :)
> Pere
> 
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] Started the port to SDL3

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

Hi Bill, and all,

El dc. 16 de 07 de 2025 a les 02:13 +0200, en/na Pere Pujal i Carabantes va escriure:
> El dt. 15 de 07 de 2025 a les 14:06 +0100, en/na Bill Kendrick va escriure:
> > On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote:
> > > El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure:


> > > 
> > And I would definitely want the ability to disable it for
> > users who are not yet familiar/comfortable with pressure
> > (i.e., an option to ignore pressure, and always be 100% opaque).
> 
> Oh, true, currently it starts always enabled, both for size and for transparency,

Added the ability to disable pressure, still needs support for command line and config.



> 
> > Reporting pressure to Magic Tools probably makes sense, but
> > I really need to sit down and think how & when, and how things
> > should behave when pressure is unavailable.
> 
> That would be also a good addition, I imagine many magic tools could benefit from it.
> > 
> > > Still need to decide what to do when the user switches tips to the secondary one, 
> > > maybe hardcode it to the eraser tool?
> > 
> > This is what I've always imagined. :)
> > See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/
> > 
> > I imagine it could just behave like Tux Paint does when holding
> > the [X] key.  From README:
> > 
> >   Hold the [X] key while clicking for quick access to a small sharp round
> >   eraser (not available when the Text or Label tools are selected, when
> >   you're in the process of rotating a stamp or shape, or when using an
> >   interactive magic tool). Release the mouse to return to your
> >   currently-selected tool.
> > 
> > Of course, if pressure is enabled, then we'd want the eraser
> > to behave differently depending on the pressure.

Done in this way.

I could not implement the idea I had in mind of fully switching 
to the Eraser tool when switching pen tips, I could not 
make SDL detect the switching until the pen were already touching 
the tablet, and that would be very confusing to users seeing 
the brush interface and getting the erase results and a sudden 
change of interface to the eraser one when the pen touches the tablet. 


I wanted to play with SDL_PenProximityEvents
https://wiki.libsdl.org/SDL3/SDL_PenProximityEventbut they perform different than explained in the wiki, see
https://github.com/libsdl-org/SDL/issues/12992
and I can't see any info about which pen tip is used.

Also tried with SDL_PenMotionEvents
https://wiki.libsdl.org/SDL3/SDL_PenMotionEvent
but the _first_ time one switches the pen tips,
pen_state don't show the eraser state until 
one touches the tablet with the eraser tip.
Later switches go fine, one can detect the 
pen tip before it touches the tablet, 
but the first one would be confusing.




A report of how are things now:

Paint 
Size seems to work fine with pressure, I see a bug in transparency,
the function used to blit scaled brushes changes slightly the brush 
color with transparency.
For example the light grey c0c0c0 changes to bebebe
Will see what I can do about it.

Eraser
Size of erasers works with pressure, transparency is not used, 
it fully erases to original canvas/starter/background.
Maybe should be made transparency also enabled here?

A small bug also present in 0.9.34 (35 also?):
Ghosts xors appears when CTRL Z - CTRL R. 
In 0.9.34 you must move the mouse around the canvas 
when hitting repeteadly CTRL Z - CTRL R 
They appear about 1/3 of times
In the sdl3 version the ghost xors appears more.


Pen eraser tip
Same behavior as holding X and click and drag the mouse
Size works with pressure, transparency is not used.

Lines
Works with pressure disabled.
I can't imagine how to use pressure here.

Shapes
Works with pressure disabled.
Same as above.

Magic
ToDo?

Stamps, text, open, etc
Do not need pressure to work, assuming they are fine

Command line, config
ToDo


Thanks for any comments
Pere

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dt. 15 de 07 de 2025 a les 14:06 +0100, en/na Bill Kendrick va escriure:
> On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote:
> > El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure:
> > > I've see them, thanks.
> > > 
> > > Now I am slowly porting the magic tools, one by one.
> > 
> > Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c
> > 
> > Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity,
> > can be enabled/disabled with CTRL T for transparency and CTRL W for width.
> > There are some values that may/should? be made available in tuxpaint-config 
> > but for now they are set to what works in my system.
> 
> In this case, by "width" you mean "spacing", correct?

I mean the size of the brush blit on the canvas, 
max pressure results in full size, less pressure results in less size.
Obviously, I had to _also_ scale spacing according to the size,
otherwise the results were incorrect. 

See the picture of 6 first brushes and the sphere drawing 
with and without pressure affecting width and transparency.
https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250716/pressure_tests.png



> There's a feature I'd like to add that allows brush sizes
> to be altered via the UI as well.  I feel as though that
> forthcoming feature would be better served by pressure
> sensitivity, than the spacing feature.  (I admit, I don't
> actually do much art myself, and rarely with a tablet.
> It just 'feels' like pressure changing spacing would be
> confusing.)

If I understand right, this is exactly what I have implemented?
well, just the half of what is implemented, the other half is transparency.


BTW, I am not happy with transparency, one sees the different blits of the brushes in the line,
still investigating...



> For now, until we can add the brush sizing feature
> (or perhaps forever?), I think transparency makes the most
> sense.
> 
> And I would definitely want the ability to disable it for
> users who are not yet familiar/comfortable with pressure
> (i.e., an option to ignore pressure, and always be 100% opaque).

Oh, true, currently it starts always enabled, both for size and for transparency,


> 
> Reporting pressure to Magic Tools probably makes sense, but
> I really need to sit down and think how & when, and how things
> should behave when pressure is unavailable.

That would be also a good addition, I imagine many magic tools could benefit from it.


> 
> Obviously, right now -- for the past 23 years -- pressure has NOT
> been available.  However, once we start adding pressure sensitivity
> to existing tools, and adidng new tools that support it, we'll want
> them all to behave intuitively and sensibly when the input lacks
> pressure (i.e., a regular mouse, a joystick, the keyboard, or a
> tablet with pressure disabled).

Yes, of course, most people don't use tablets/pens to draw.
BTW, are there any touchscreen that is pressure sensitive? (with finger I mean)


> 
> 
> > Still need to decide what to do when the user switches tips to the secondary one, 
> > maybe hardcode it to the eraser tool?
> 
> This is what I've always imagined. :)
> See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/
> 
> I imagine it could just behave like Tux Paint does when holding
> the [X] key.  From README:
> 
>   Hold the [X] key while clicking for quick access to a small sharp round
>   eraser (not available when the Text or Label tools are selected, when
>   you're in the process of rotating a stamp or shape, or when using an
>   interactive magic tool). Release the mouse to return to your
>   currently-selected tool.
> 
> Of course, if pressure is enabled, then we'd want the eraser
> to behave differently depending on the pressure.
> 
> Right now, Erasers are basically just hard-coded shapes (the old
> "whiteboard eraser" square, then more recently circles, fuzzy
> circles, and transparent circles).  While somewhat limiting in
> many ways, this also means we can just go in and code things how
> we want, for this special stylus version of the [X]-key-held
> eraser.

Will see what I can do :), my first idea was to implement pressure in the Eraser tool, 
fully switch to it when switching pen tip, let the user do its stuff, 
then return to the previous tool when switching the pen again to the main tip.
but as you say in the feature request, what should happen if the user is already in the Eraser tool?

Oh, wait, I see Krita changing to eraser mode when switching from main tip to secondary one, 
but doing nothing if already in eraser mode, it continues in eraser mode and do not changes 
to paint mode when switching again back to the main tip of the pen.

Maybe we can do the same...

> 
> 
> > I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again.
> > If somebody has a spare graphics tablet that can send my way I will be very grateful :)
> 
> I've asked Pere how I can help here. :-)

Yeah!, Thanks :)

Pere


> 
> -bill!
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Started the port to SDL3

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

On Tue, Jul 15, 2025 at 01:53:49AM +0200, Pere Pujal i Carabantes wrote:
> El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure:
> > I've see them, thanks.
> > 
> > Now I am slowly porting the magic tools, one by one.
> 
> Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c
> 
> Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity,
> can be enabled/disabled with CTRL T for transparency and CTRL W for width.
> There are some values that may/should? be made available in tuxpaint-config 
> but for now they are set to what works in my system.

In this case, by "width" you mean "spacing", correct?
There's a feature I'd like to add that allows brush sizes
to be altered via the UI as well.  I feel as though that
forthcoming feature would be better served by pressure
sensitivity, than the spacing feature.  (I admit, I don't
actually do much art myself, and rarely with a tablet.
It just 'feels' like pressure changing spacing would be
confusing.)

For now, until we can add the brush sizing feature
(or perhaps forever?), I think transparency makes the most
sense.

And I would definitely want the ability to disable it for
users who are not yet familiar/comfortable with pressure
(i.e., an option to ignore pressure, and always be 100% opaque).

Reporting pressure to Magic Tools probably makes sense, but
I really need to sit down and think how & when, and how things
should behave when pressure is unavailable.

Obviously, right now -- for the past 23 years -- pressure has NOT
been available.  However, once we start adding pressure sensitivity
to existing tools, and adidng new tools that support it, we'll want
them all to behave intuitively and sensibly when the input lacks
pressure (i.e., a regular mouse, a joystick, the keyboard, or a
tablet with pressure disabled).


> Still need to decide what to do when the user switches tips to the secondary one, 
> maybe hardcode it to the eraser tool?

This is what I've always imagined. :)
See ancient ticket https://sourceforge.net/p/tuxpaint/feature-requests/8/

I imagine it could just behave like Tux Paint does when holding
the [X] key.  From README:

  Hold the [X] key while clicking for quick access to a small sharp round
  eraser (not available when the Text or Label tools are selected, when
  you're in the process of rotating a stamp or shape, or when using an
  interactive magic tool). Release the mouse to return to your
  currently-selected tool.

Of course, if pressure is enabled, then we'd want the eraser
to behave differently depending on the pressure.

Right now, Erasers are basically just hard-coded shapes (the old
"whiteboard eraser" square, then more recently circles, fuzzy
circles, and transparent circles).  While somewhat limiting in
many ways, this also means we can just go in and code things how
we want, for this special stylus version of the [X]-key-held
eraser.


> I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again.
> If somebody has a spare graphics tablet that can send my way I will be very grateful :)

I've asked Pere how I can help here. :-)

-bill!

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dc. 02 de 07 de 2025 a les 10:37 +0200, en/na Pere Pujal i Carabantes va escriure:
> I've see them, thanks.
> 
> Now I am slowly porting the magic tools, one by one.

Magic tools have been ported, I am currently adding PEN pressure support to tuxpaint.c

Pressure draw with the main tip of the pen seems to work, both brush size and brush opacity,
can be enabled/disabled with CTRL T for transparency and CTRL W for width.
There are some values that may/should? be made available in tuxpaint-config 
but for now they are set to what works in my system.

Still need to decide what to do when the user switches tips to the secondary one, 
maybe hardcode it to the eraser tool?

I use an old Wacom graphire to test, but the pen is very used, I already had to solder it to get it working again.
If somebody has a spare graphics tablet that can send my way I will be very grateful :)

Thanks
Pere

Re: [Tuxpaint-devel] Started the port to SDL3

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

I've see them, thanks.

Now I am slowly porting the magic tools, one by one.

Thanks
Pere



El dt. 01 de 07 de 2025 a les 22:41 -0400, en/na Mark Kim va escriure:
> Hi Pere,
> 
> Patches for the macOS port using SDL3 have been committed to the sdl3 branch of your personal fork.
> 
> Thanks,
> Mark

Re: [Tuxpaint-devel] Started the port to SDL3

[Mark K. <mar...@gm...>]

Hi Pere,

Patches for the macOS port using SDL3 have been committed to the sdl3
branch of your personal fork.

Thanks,
Mark

On Mon, Jun 30, 2025 at 9:20 PM Mark Kim <mar...@gm...> wrote:

> > I've just added you as developer, please test.
>
> It worked! Thank you.
>
>
> On Mon, Jun 30, 2025 at 2:23 AM Pere Pujal i Carabantes <
> per...@gm...> wrote:
>
>> El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure:
>> > Hi Pere,
>> >
>> > Thank you for working on this.  Can you grant the user `vindaci` access
>> to the sdl3 branch so I can add the macOS changes?
>> >
>> > Thanks,
>> > Mark
>>
>> I've just added you as developer, please test.
>>
>> Thanks
>> Pere
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>

Re: [Tuxpaint-devel] Started the port to SDL3

[Mark K. <mar...@gm...>]

> I've just added you as developer, please test.

It worked! Thank you.


On Mon, Jun 30, 2025 at 2:23 AM Pere Pujal i Carabantes <per...@gm...>
wrote:

> El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure:
> > Hi Pere,
> >
> > Thank you for working on this.  Can you grant the user `vindaci` access
> to the sdl3 branch so I can add the macOS changes?
> >
> > Thanks,
> > Mark
>
> I've just added you as developer, please test.
>
> Thanks
> Pere
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Started the port to SDL3

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

El dg. 29 de 06 de 2025 a les 21:38 -0400, en/na Mark Kim va escriure:
> Hi Pere,
> 
> Thank you for working on this.  Can you grant the user `vindaci` access to the sdl3 branch so I can add the macOS changes?
> 
> Thanks,
> Mark

I've just added you as developer, please test.

Thanks
Pere

Re: [Tuxpaint-devel] Started the port to SDL3

[Mark K. <mar...@gm...>]

Hi Pere,

Thank you for working on this.  Can you grant the user `vindaci` access to
the sdl3 branch so I can add the macOS changes?

Thanks,
Mark

On Sun, Jun 29, 2025 at 8:03 AM Pere Pujal i Carabantes <per...@gm...>
wrote:

> Hi all,
>
> About three months ago I started that port, now after the release of
> 0.9.35 I am continuing it :)
>
> The source code is currently inside the sdl3 branch in my personal fork at
> SourceForge
> https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/
>
> It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've
> picked this one:
> https://github.com/sabdul-khabir/SDL3_gfx
>
> And needs also SDL3_Pango wich I have working but needs a lot of cleaning
> before it gets ready for a merge request,
> I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
> https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/
>
> After installing them, and the SDL3* libraries that come in my
> distribution,
> I am able to compile and run Tux Paint in my box :)
> Painting, lines, shapes, stamps, text, open, save, slideshow, erase and
> magic alien seems to work fine.
> im and labels too but they are not tested hard.
>
> I'd really like reviews  and tests, below some things that would need help:
>
> im subsystem:
> I don't know the languages we provide im for, so a test about correctness
> would be welcome.
> Right Alt do not work in the SDL3 version I have installed, so I've added
> Left Alt to Thai, even if it was explicitly disabled.
> Oher languages made use of both, left and right alt, now in my box, only
> left works.
>
>
> Fill Lineal doesn't work properly on single click inside small circles,
> without drag, I am currently investigating this...
>
>
> Magic tools:
> there are plenty of magic tools in the magic/src/WIP_SDL3 directory that
> are waiting to be ported.
>
>
> Wew, too long message, thanks for reading, and thaks for any help :)
> Pere
>
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Started the port to SDL3

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

Hi all,

About three months ago I started that port, now after the release of 0.9.35 I am continuing it :)

The source code is currently inside the sdl3 branch in my personal fork at SourceForge
https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/

It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one:
https://github.com/sabdul-khabir/SDL3_gfx

And needs also SDL3_Pango wich I have working but needs a lot of cleaning 
before it gets ready for a merge request,
I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/

After installing them, and the SDL3* libraries that come in my distribution, 
I am able to compile and run Tux Paint in my box :)
Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine.
im and labels too but they are not tested hard.

I'd really like reviews  and tests, below some things that would need help:

im subsystem:
I don't know the languages we provide im for, so a test about correctness would be welcome.
Right Alt do not work in the SDL3 version I have installed, so I've added Left Alt to Thai, even if it was explicitly disabled.
Oher languages made use of both, left and right alt, now in my box, only left works.


Fill Lineal doesn't work properly on single click inside small circles, without drag, I am currently investigating this...


Magic tools:
there are plenty of magic tools in the magic/src/WIP_SDL3 directory that are waiting to be ported.


Wew, too long message, thanks for reading, and thaks for any help :)
Pere

Re: [Tuxpaint-devel] Happy 23rd birthday! :)

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

El dl. 16 de 06 de 2025 a les 01:28 -0700, en/na Bill Kendrick va escriure:
> Tux Paint's first release was 23 years ago today (2002-06-16) :)
> 
> Thanks, everyone, for all your help and encouragemet along the way.
> 
> -bill!

Hey, congrats :)
Pere

[Tuxpaint-devel] Happy 23rd birthday! :)

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

Tux Paint's first release was 23 years ago today (2002-06-16) :)

Thanks, everyone, for all your help and encouragemet along the way.

-bill!

Re: [Tuxpaint-devel] Some Magic tools missing on Android (0.9.34)

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

On Sun, May 25, 2025 at 12:15:38AM +0200, Pere Pujal i Carabantes wrote:
> Hi, yes, I'd also say go ahead and see what happens.

Alright! :-)

-bill!

<snip>
> El ds. 24 de 05 de 2025 a les 16:27 -0400, en/na Terrence Sheflin va escriure:
> > Since I'm not sure the cause, I'd say we can just build it and see
> > what happens. I can follow the same procedure I have been and hopefully
> > they'll be there.
<snip>

Re: [Tuxpaint-devel] Some Magic tools missing on Android (0.9.34)

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

Hi, yes, I'd also say go ahead and see what happens.

Pere

El ds. 24 de 05 de 2025 a les 16:27 -0400, en/na Terrence Sheflin va escriure:
> Since I'm not sure the cause, I'd say we can just build it and see what happens. I can follow the same procedure I have been and hopefully they'll be there.
> 
> Terrence
> 
> On Sat, May 24, 2025, 6:04 a.m. Bill Kendrick <nb...@so...> wrote:
> > 
> > Hi all!  Pere & Terrence, do you feel comfortable with my moving
> > ahead with final 0.9.35 release for you (and others) to build?
> > 
> > Or is there something on the Android side that still might need
> > figuring out (re: the missing Magic tools, for some users / versions)?
> > 
> > Thanks in advance!
> > 
> > -bill!
> > 
> > On Sat, May 10, 2025 at 11:31:42AM +0200, Pere Pujal i Carabantes wrote:
> > > Hi Terrence,
> > > 
> > > El dv. 09 de 05 de 2025 a les 19:45 -0400, en/na Terrence Sheflin va escriure:
> > > > I haven't run the sh in a while as I lost the machine capable of doing it. Instead I download the build you create Pere and copy / paste the data folder and then run the Android studio build.
> > > 
> > > Copy/pasting the assets is fine too, and indeed, Play serves the spiral, ascii, crescent, etc icons and sounds.
> > > What I don't understand is why it don't serves their corresponding .so libs that should have been generated at compilation time.
> > > 
> > > Note, in case that matters, my phone only acesses Play via Aurora store, 
> > > so I can only talk about the things Aurora download from Play
> > > 
> > > HTH
> > > Pere
> > > 
> > > 
> > > > 
> > > > Terrence
> > > > 
> > > > On Fri, May 9, 2025, 7:01 p.m. Pere Pujal i Carabantes <per...@gm...> wrote:
> > > > > El dv. 09 de 05 de 2025 a les 21:47 +0100, en/na Bill Kendrick va escriure:
> > > > > > On Fri, May 09, 2025 at 12:52:06AM +0200, Pere Pujal i Carabantes wrote:
> > > > > > > El dv. 09 de 05 de 2025 a les 00:38 +0200, en/na Pere Pujal i Carabantes va escriure:
> > > > > > > > 
> > > > > > > > but what I do not understand is that you said having problems too with 0.9.34-rc1 
> > > > > > > > and if I am not wrong, 0.9.34-rc1 comes from sourceforge and it showed all magic tools here?
> > > > > > > 
> > > > > > > Nevermind, I see that 0.9.34 from Play displays 0.9.34-rc1 at the initial screen
> > > > > > 
> > > > > > Ah!  That explains it I guess!?  Terrence, it _seems_ as though you
> > > > > > posted the 0.9.34 release candidate ("beta") (0.9.34-rc1) to Google Play Store,
> > > > > > rather than the final (0.9.34).
> > > > > > 
> > > > > > Though looking at https://github.com/tux4kids/Tuxpaint-Android/commits/master/
> > > > > > I'm not quite understanding how that would have happened?  (I see first
> > > > > > commit 0d2a101, "Updating Tux Paint to 0.9.34" by Pere, on 2024-11-03,
> > > > > > followed by commit commit 7a1a761, "Updating PlayStore version." by
> > > > > > Terrence, on 2024-11-13.)
> > > > > > 
> > > > > > Also, to both of you, is there something that needs to be done when new
> > > > > > Magic tools are added "upstream", to get include them in the Android
> > > > > > build?  I assumed not, and that it would simply collect everything
> > > > > > built from the source; i.e., there's not some file containing a list
> > > > > > of all of the ".so" files that needs to be kept in sync.  Correct?
> > > > > 
> > > > > The images and sounds need to be copied to the assets, this is made with 
> > > > > the mkzip_assets.sh script that must be run manually. It does plenty of 
> > > > > other things like downloading stamps, compiling translations, converting SVGs...
> > > > > so it is difficult to miss it.
> > > > > 
> > > > > .so files get automatically included in the apk at build time, I know nothing
> > > > > about how "bundles" are managed in the Play Store.
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Thanks.  Sorry that I'm a bit less than useful here. :-D
> > > > > 
> > > > > Well, knowing something is broken is the first step to fix it ;)
> > > > > I'd never dig into this if I had not been warned :)
> > > > > 
> > > > > Pere
> > > > > 
> > > > > > 
> > > > > > -bill!
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 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
> > > > _______________________________________________
> > > > 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
> > > 
> > 
> > 
> > _______________________________________________
> > 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

Re: [Tuxpaint-devel] Some Magic tools missing on Android (0.9.34)

[Terrence S. <ter...@gm...>]

Since I'm not sure the cause, I'd say we can just build it and see what
happens. I can follow the same procedure I have been and hopefully they'll
be there.

Terrence

On Sat, May 24, 2025, 6:04 a.m. Bill Kendrick <nb...@so...> wrote:

>
> Hi all!  Pere & Terrence, do you feel comfortable with my moving
> ahead with final 0.9.35 release for you (and others) to build?
>
> Or is there something on the Android side that still might need
> figuring out (re: the missing Magic tools, for some users / versions)?
>
> Thanks in advance!
>
> -bill!
>
> On Sat, May 10, 2025 at 11:31:42AM +0200, Pere Pujal i Carabantes wrote:
> > Hi Terrence,
> >
> > El dv. 09 de 05 de 2025 a les 19:45 -0400, en/na Terrence Sheflin va
> escriure:
> > > I haven't run the sh in a while as I lost the machine capable of doing
> it. Instead I download the build you create Pere and copy / paste the data
> folder and then run the Android studio build.
> >
> > Copy/pasting the assets is fine too, and indeed, Play serves the spiral,
> ascii, crescent, etc icons and sounds.
> > What I don't understand is why it don't serves their corresponding .so
> libs that should have been generated at compilation time.
> >
> > Note, in case that matters, my phone only acesses Play via Aurora store,
> > so I can only talk about the things Aurora download from Play
> >
> > HTH
> > Pere
> >
> >
> > >
> > > Terrence
> > >
> > > On Fri, May 9, 2025, 7:01 p.m. Pere Pujal i Carabantes <
> per...@gm...> wrote:
> > > > El dv. 09 de 05 de 2025 a les 21:47 +0100, en/na Bill Kendrick va
> escriure:
> > > > > On Fri, May 09, 2025 at 12:52:06AM +0200, Pere Pujal i Carabantes
> wrote:
> > > > > > El dv. 09 de 05 de 2025 a les 00:38 +0200, en/na Pere Pujal i
> Carabantes va escriure:
> > > > > > >
> > > > > > > but what I do not understand is that you said having problems
> too with 0.9.34-rc1
> > > > > > > and if I am not wrong, 0.9.34-rc1 comes from sourceforge and
> it showed all magic tools here?
> > > > > >
> > > > > > Nevermind, I see that 0.9.34 from Play displays 0.9.34-rc1 at
> the initial screen
> > > > >
> > > > > Ah!  That explains it I guess!?  Terrence, it _seems_ as though you
> > > > > posted the 0.9.34 release candidate ("beta") (0.9.34-rc1) to
> Google Play Store,
> > > > > rather than the final (0.9.34).
> > > > >
> > > > > Though looking at
> https://github.com/tux4kids/Tuxpaint-Android/commits/master/
> > > > > I'm not quite understanding how that would have happened?  (I see
> first
> > > > > commit 0d2a101, "Updating Tux Paint to 0.9.34" by Pere, on
> 2024-11-03,
> > > > > followed by commit commit 7a1a761, "Updating PlayStore version." by
> > > > > Terrence, on 2024-11-13.)
> > > > >
> > > > > Also, to both of you, is there something that needs to be done
> when new
> > > > > Magic tools are added "upstream", to get include them in the
> Android
> > > > > build?  I assumed not, and that it would simply collect everything
> > > > > built from the source; i.e., there's not some file containing a
> list
> > > > > of all of the ".so" files that needs to be kept in sync.  Correct?
> > > >
> > > > The images and sounds need to be copied to the assets, this is made
> with
> > > > the mkzip_assets.sh script that must be run manually. It does plenty
> of
> > > > other things like downloading stamps, compiling translations,
> converting SVGs...
> > > > so it is difficult to miss it.
> > > >
> > > > .so files get automatically included in the apk at build time, I
> know nothing
> > > > about how "bundles" are managed in the Play Store.
> > > >
> > > >
> > > > >
> > > > > Thanks.  Sorry that I'm a bit less than useful here. :-D
> > > >
> > > > Well, knowing something is broken is the first step to fix it ;)
> > > > I'd never dig into this if I had not been warned :)
> > > >
> > > > Pere
> > > >
> > > > >
> > > > > -bill!
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > > _______________________________________________
> > > 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
> >
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Some Magic tools missing on Android (0.9.34)

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

Hi all!  Pere & Terrence, do you feel comfortable with my moving
ahead with final 0.9.35 release for you (and others) to build?

Or is there something on the Android side that still might need
figuring out (re: the missing Magic tools, for some users / versions)?

Thanks in advance!

-bill!

On Sat, May 10, 2025 at 11:31:42AM +0200, Pere Pujal i Carabantes wrote:
> Hi Terrence,
> 
> El dv. 09 de 05 de 2025 a les 19:45 -0400, en/na Terrence Sheflin va escriure:
> > I haven't run the sh in a while as I lost the machine capable of doing it. Instead I download the build you create Pere and copy / paste the data folder and then run the Android studio build.
> 
> Copy/pasting the assets is fine too, and indeed, Play serves the spiral, ascii, crescent, etc icons and sounds.
> What I don't understand is why it don't serves their corresponding .so libs that should have been generated at compilation time.
> 
> Note, in case that matters, my phone only acesses Play via Aurora store, 
> so I can only talk about the things Aurora download from Play
> 
> HTH
> Pere
> 
> 
> > 
> > Terrence
> > 
> > On Fri, May 9, 2025, 7:01 p.m. Pere Pujal i Carabantes <per...@gm...> wrote:
> > > El dv. 09 de 05 de 2025 a les 21:47 +0100, en/na Bill Kendrick va escriure:
> > > > On Fri, May 09, 2025 at 12:52:06AM +0200, Pere Pujal i Carabantes wrote:
> > > > > El dv. 09 de 05 de 2025 a les 00:38 +0200, en/na Pere Pujal i Carabantes va escriure:
> > > > > > 
> > > > > > but what I do not understand is that you said having problems too with 0.9.34-rc1 
> > > > > > and if I am not wrong, 0.9.34-rc1 comes from sourceforge and it showed all magic tools here?
> > > > > 
> > > > > Nevermind, I see that 0.9.34 from Play displays 0.9.34-rc1 at the initial screen
> > > > 
> > > > Ah!  That explains it I guess!?  Terrence, it _seems_ as though you
> > > > posted the 0.9.34 release candidate ("beta") (0.9.34-rc1) to Google Play Store,
> > > > rather than the final (0.9.34).
> > > > 
> > > > Though looking at https://github.com/tux4kids/Tuxpaint-Android/commits/master/
> > > > I'm not quite understanding how that would have happened?  (I see first
> > > > commit 0d2a101, "Updating Tux Paint to 0.9.34" by Pere, on 2024-11-03,
> > > > followed by commit commit 7a1a761, "Updating PlayStore version." by
> > > > Terrence, on 2024-11-13.)
> > > > 
> > > > Also, to both of you, is there something that needs to be done when new
> > > > Magic tools are added "upstream", to get include them in the Android
> > > > build?  I assumed not, and that it would simply collect everything
> > > > built from the source; i.e., there's not some file containing a list
> > > > of all of the ".so" files that needs to be kept in sync.  Correct?
> > > 
> > > The images and sounds need to be copied to the assets, this is made with 
> > > the mkzip_assets.sh script that must be run manually. It does plenty of 
> > > other things like downloading stamps, compiling translations, converting SVGs...
> > > so it is difficult to miss it.
> > > 
> > > .so files get automatically included in the apk at build time, I know nothing
> > > about how "bundles" are managed in the Play Store.
> > > 
> > > 
> > > > 
> > > > Thanks.  Sorry that I'm a bit less than useful here. :-D
> > > 
> > > Well, knowing something is broken is the first step to fix it ;)
> > > I'd never dig into this if I had not been warned :)
> > > 
> > > Pere
> > > 
> > > > 
> > > > -bill!
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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
> > _______________________________________________
> > 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
> 

Re: [Tuxpaint-devel] Some Magic tools missing on Android (0.9.34)

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

Hi Terrence,

El dv. 09 de 05 de 2025 a les 19:45 -0400, en/na Terrence Sheflin va escriure:
> I haven't run the sh in a while as I lost the machine capable of doing it. Instead I download the build you create Pere and copy / paste the data folder and then run the Android studio build.

Copy/pasting the assets is fine too, and indeed, Play serves the spiral, ascii, crescent, etc icons and sounds.
What I don't understand is why it don't serves their corresponding .so libs that should have been generated at compilation time.

Note, in case that matters, my phone only acesses Play via Aurora store, 
so I can only talk about the things Aurora download from Play

HTH
Pere


> 
> Terrence
> 
> On Fri, May 9, 2025, 7:01 p.m. Pere Pujal i Carabantes <per...@gm...> wrote:
> > El dv. 09 de 05 de 2025 a les 21:47 +0100, en/na Bill Kendrick va escriure:
> > > On Fri, May 09, 2025 at 12:52:06AM +0200, Pere Pujal i Carabantes wrote:
> > > > El dv. 09 de 05 de 2025 a les 00:38 +0200, en/na Pere Pujal i Carabantes va escriure:
> > > > > 
> > > > > but what I do not understand is that you said having problems too with 0.9.34-rc1 
> > > > > and if I am not wrong, 0.9.34-rc1 comes from sourceforge and it showed all magic tools here?
> > > > 
> > > > Nevermind, I see that 0.9.34 from Play displays 0.9.34-rc1 at the initial screen
> > > 
> > > Ah!  That explains it I guess!?  Terrence, it _seems_ as though you
> > > posted the 0.9.34 release candidate ("beta") (0.9.34-rc1) to Google Play Store,
> > > rather than the final (0.9.34).
> > > 
> > > Though looking at https://github.com/tux4kids/Tuxpaint-Android/commits/master/
> > > I'm not quite understanding how that would have happened?  (I see first
> > > commit 0d2a101, "Updating Tux Paint to 0.9.34" by Pere, on 2024-11-03,
> > > followed by commit commit 7a1a761, "Updating PlayStore version." by
> > > Terrence, on 2024-11-13.)
> > > 
> > > Also, to both of you, is there something that needs to be done when new
> > > Magic tools are added "upstream", to get include them in the Android
> > > build?  I assumed not, and that it would simply collect everything
> > > built from the source; i.e., there's not some file containing a list
> > > of all of the ".so" files that needs to be kept in sync.  Correct?
> > 
> > The images and sounds need to be copied to the assets, this is made with 
> > the mkzip_assets.sh script that must be run manually. It does plenty of 
> > other things like downloading stamps, compiling translations, converting SVGs...
> > so it is difficult to miss it.
> > 
> > .so files get automatically included in the apk at build time, I know nothing
> > about how "bundles" are managed in the Play Store.
> > 
> > 
> > > 
> > > Thanks.  Sorry that I'm a bit less than useful here. :-D
> > 
> > Well, knowing something is broken is the first step to fix it ;)
> > I'd never dig into this if I had not been warned :)
> > 
> > Pere
> > 
> > > 
> > > -bill!
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel