tuxpaint-devel Mailing List for Tux Paint
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(15) |
Apr
(5) |
May
(12) |
Jun
(15) |
Jul
(21) |
Aug
(2) |
Sep
(14) |
Oct
(32) |
Nov
(47) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(33) |
Feb
(59) |
Mar
(17) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(19) |
Sep
(64) |
Oct
(161) |
Nov
(9) |
Dec
(23) |
2007 |
Jan
(6) |
Feb
(46) |
Mar
(55) |
Apr
(41) |
May
(43) |
Jun
(44) |
Jul
(46) |
Aug
(25) |
Sep
(16) |
Oct
(29) |
Nov
(50) |
Dec
(64) |
2008 |
Jan
(11) |
Feb
(18) |
Mar
(52) |
Apr
(37) |
May
(40) |
Jun
(78) |
Jul
(85) |
Aug
(31) |
Sep
(23) |
Oct
(13) |
Nov
(19) |
Dec
(37) |
2009 |
Jan
(36) |
Feb
(24) |
Mar
(86) |
Apr
(43) |
May
(36) |
Jun
(151) |
Jul
(23) |
Aug
(40) |
Sep
(11) |
Oct
(91) |
Nov
(68) |
Dec
(27) |
2010 |
Jan
|
Feb
(11) |
Mar
(79) |
Apr
(50) |
May
(26) |
Jun
(44) |
Jul
(31) |
Aug
(6) |
Sep
(2) |
Oct
(16) |
Nov
(11) |
Dec
(4) |
2011 |
Jan
(14) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(13) |
Aug
(1) |
Sep
(3) |
Oct
(18) |
Nov
(15) |
Dec
(25) |
2012 |
Jan
(1) |
Feb
(9) |
Mar
(41) |
Apr
(32) |
May
|
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2013 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(21) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(3) |
2014 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
(35) |
May
|
Jun
(12) |
Jul
(35) |
Aug
(98) |
Sep
(3) |
Oct
(8) |
Nov
(4) |
Dec
(1) |
2015 |
Jan
(4) |
Feb
(9) |
Mar
(58) |
Apr
(9) |
May
(15) |
Jun
(23) |
Jul
|
Aug
(32) |
Sep
(12) |
Oct
(21) |
Nov
(5) |
Dec
(14) |
2016 |
Jan
(6) |
Feb
(3) |
Mar
(37) |
Apr
(18) |
May
(5) |
Jun
(8) |
Jul
|
Aug
(21) |
Sep
(5) |
Oct
(20) |
Nov
(4) |
Dec
(6) |
2017 |
Jan
(2) |
Feb
|
Mar
|
Apr
(19) |
May
(8) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(6) |
2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
(14) |
Oct
(2) |
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(9) |
Nov
(11) |
Dec
(7) |
2021 |
Jan
(12) |
Feb
(2) |
Mar
(16) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
(4) |
Sep
(24) |
Oct
(68) |
Nov
(61) |
Dec
|
2022 |
Jan
(42) |
Feb
(17) |
Mar
(20) |
Apr
(2) |
May
(23) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(27) |
Oct
(4) |
Nov
(10) |
Dec
(31) |
2023 |
Jan
(4) |
Feb
(18) |
Mar
(8) |
Apr
(11) |
May
(18) |
Jun
(47) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
2024 |
Jan
(10) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(3) |
2025 |
Jan
(2) |
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(22) |
Jun
(5) |
Jul
(10) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bill K. <nb...@so...> - 2025-07-25 10:40:31
|
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! |
From: Pere P. i C. <per...@gm...> - 2025-07-25 07:47:37
|
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! > |
From: Bill K. <nb...@so...> - 2025-07-25 00:42:49
|
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 > |
From: Pere P. i C. <per...@gm...> - 2025-07-24 17:12:56
|
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 |
From: Pere P. i C. <per...@gm...> - 2025-07-16 00:13:39
|
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 |
From: Bill K. <nb...@so...> - 2025-07-15 13:06:25
|
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! |
From: Pere P. i C. <per...@gm...> - 2025-07-14 23:53:58
|
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 |
From: Pere P. i C. <per...@gm...> - 2025-07-02 08:37:17
|
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 |
From: Mark K. <mar...@gm...> - 2025-07-02 02:42:00
|
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 >> > |
From: Mark K. <mar...@gm...> - 2025-07-01 01:20:25
|
> 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 > |
From: Pere P. i C. <per...@gm...> - 2025-06-30 06:22:54
|
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 |
From: Mark K. <mar...@gm...> - 2025-06-30 01:39:15
|
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 > |
From: Pere P. i C. <per...@gm...> - 2025-06-29 12:03:20
|
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 |
From: Pere P. i C. <per...@gm...> - 2025-06-16 23:09:34
|
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 |
From: Bill K. <nb...@so...> - 2025-06-16 08:28:52
|
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! |
From: Bill K. <nb...@so...> - 2025-05-25 16:23:00
|
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> |
From: Pere P. i C. <per...@gm...> - 2025-05-24 22:15:56
|
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 |
From: Terrence S. <ter...@gm...> - 2025-05-24 20:27:33
|
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 > |
From: Bill K. <nb...@so...> - 2025-05-24 10:04:39
|
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 > |
From: Pere P. i C. <per...@gm...> - 2025-05-10 09:31:57
|
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 |
From: Terrence S. <ter...@gm...> - 2025-05-09 23:46:01
|
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. 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 > |
From: Pere P. i C. <per...@gm...> - 2025-05-09 23:01:45
|
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 |
From: Bill K. <nb...@so...> - 2025-05-09 20:47:44
|
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? Thanks. Sorry that I'm a bit less than useful here. :-D -bill! |
From: Pere P. i C. <per...@gm...> - 2025-05-08 22:52:23
|
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 |
From: Pere P. i C. <per...@gm...> - 2025-05-08 22:46:52
|
El dv. 09 de 05 de 2025 a les 00:38 +0200, en/na Pere Pujal i Carabantes va escriure: > > lastly look for the magic .so files, there are some that are not there. BTW, the ones lacking compared to a 0.9.35rc1 are libascii.so libcomicdot.so libcrescent.so libemitter.so libfractal.so librotate.so libspiral.so libspraypaint.so libtessell.so |