tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, May 19, 2022 at 09:52:02PM +0900, Shin-ichi TOYAMA wrote:
> On Thu, 19 May 2022 01:59:17 -0700, Bill Kendrick wrote:
> >One problem for me is that I can't get SDL2_Pango working.
> 
<snip>
> I confirmed my SDL2_Pango.spec which I used to create rpm package for SDL_Pango.
> I think it was tweaked based on the spec file for SDL_Pango.
> 
> Seeing the spec file, I could build SDL2_Pango on my ubuntu on VMware as follows.
> 
> $ tar zxvf SDL2_Pango-0.1.2.tar.gz 
> $ cd SDL2_Pango-0.1.2/
> $ autoreconf -i 
> $ libtoolize --copy --force
> $ automake --add-missing
> $ ./configure --disable-static
> $ make
> 
> good luck!!

I was able to build it, and Tux Paint's Makefile found it!
(I had to run "sudo ldconfig", which my brain dug up from the
depths.)

  kendrick@gambit:~/tuxpaint/tuxpaint$ ldd `which tuxpaint` | grep -i pango
          libSDL2_Pango.so.1 => /usr/local/lib/libSDL2_Pango.so.1 (0x00007f22b54ae000)
          libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f22b3c1b000)
          libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f22b3bcc000)
          libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f22b3660000)

(Before running "ldconfig", the above showed a "not found"
error for "libSDL2_Pango.so.1 => ...", and "tuxpaint"
wouldn't run due to a missing library.)

Thanks!

(And thanks to Mark, too; though I didn't use your solution.)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, May 19, 2022 at 8:52 AM Shin-ichi TOYAMA <
dol...@wm...> wrote:

> On Thu, 19 May 2022 01:59:17 -0700, Bill Kendrick wrote:
> >One problem for me is that I can't get SDL2_Pango working.
>
[snip]

> Seeing the spec file, I could build SDL2_Pango on my ubuntu on VMware as
> follows.
>
> $ tar zxvf SDL2_Pango-0.1.2.tar.gz
> $ cd SDL2_Pango-0.1.2/
> $ autoreconf -i
> $ libtoolize --copy --force
> $ automake --add-missing
> $ ./configure --disable-static
> $ make
>

I have a version here that has done the autoconf/automake part. It should
be just configure && make to build it:

https://github.com/markuskimius/SDL2_Pango

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, 19 May 2022 01:59:17 -0700, Bill Kendrick wrote:
>One problem for me is that I can't get SDL2_Pango working.

<snip>

>And when I try to compile the source .tar.gz, I also run
>into trouble:
>
>  kendrick@gambit:~/tuxpaint/SDL2_Pango-0.1.2$ ./configure 
>  checking whether to enable maintainer-specific portions of Makefiles... no
>  checking build system type... x86_64-unknown-linux-gnu
>  checking host system type... x86_64-unknown-linux-gnu
>  checking target system type... x86_64-unknown-linux-gnu
>  checking for a BSD-compatible install... /usr/bin/install -c
>  [...]
>  checking that generated files are newer than configure... done
>  configure: creating ./config.status
>  config.status: error: cannot find input file: `Makefile.in'
>
>It's been a LONG time since I installed anything with autoconf,
>so I'm stumped.  (Googling lands all sorts of different answers,a
>and often project-specific.  Ugh.)

I confirmed my SDL2_Pango.spec which I used to create rpm package for SDL_Pango.
I think it was tweaked based on the spec file for SDL_Pango.

Seeing the spec file, I could build SDL2_Pango on my ubuntu on VMware as follows.

$ tar zxvf SDL2_Pango-0.1.2.tar.gz 
$ cd SDL2_Pango-0.1.2/
$ autoreconf -i 
$ libtoolize --copy --force
$ automake --add-missing
$ ./configure --disable-static
$ make

good luck!!

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Wed, May 18, 2022 at 11:41:40PM -0700, Bill Kendrick wrote:
<snip>
> I notice the sdl-2.0 branch has a LOT of compiler warnings.
> I think I'll try tackling them.  (It looks like that branch
> has DEBUG #define'd, which probably causes a lot of them.
> The main branch has that problem as well.)

I mended most of them.  There are two classes of warnings
which appear multiple times each, but I _believe_ I got
everything else covered.

I came up with some tricks to make sure all of the changes
were done in SDL-agnostic ways.  (i.e., the code is identical
in the SDL 1.2 (master) and SDL 2.0 branches, despite major
differences under those versions' hoods.)

These are the two types of warnings that still linger:

 * ‘rsvg_handle_close’ is deprecated: Use
   'rsvg_handle_read_stream_sync' instead

 * passing argument 3 of ‘autoscale_copy_smear_free’ from incompatible
   pointer type (SDL_BlitSurface)


One problem for me is that I can't get SDL2_Pango working.
I'm on Ubuntu, and tried installing the .deb packages from
Pere's SF.net project page (admittedly old, these days).

When doing so, I get a "pre-dependency problem":

  libsdl2-pango1 pre-depends on multiarch-support
  multiarch-support is not installed.

I'm not sure how to address that.


And when I try to compile the source .tar.gz, I also run
into trouble:

  kendrick@gambit:~/tuxpaint/SDL2_Pango-0.1.2$ ./configure 
  checking whether to enable maintainer-specific portions of Makefiles... no
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking target system type... x86_64-unknown-linux-gnu
  checking for a BSD-compatible install... /usr/bin/install -c
  [...]
  checking that generated files are newer than configure... done
  configure: creating ./config.status
  config.status: error: cannot find input file: `Makefile.in'

It's been a LONG time since I installed anything with autoconf,
so I'm stumped.  (Googling lands all sorts of different answers,a
and often project-specific.  Ugh.)


I'd like to make sure the SDL2_Pango stuff works.

Under SDL 1.2 ("master") branch, when I build I get SDL_Pango:

  kendrick@gambit:~/tuxpaint/tuxpaint$ ldd ./tuxpaint|grep -i pango
          libSDL_Pango.so.1 => /lib/x86_64-linux-gnu/libSDL_Pango.so.1 (0x00007f0cd3472000)
          libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f0cd1ce1000)
          libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f0cd1c92000)
          libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f0cd177a000)

...but, obviously, under SDL 2.0, I don't get SDL2_Pango: :-(

  kendrick@gambit:~/tuxpaint/tuxpaint$ ldd ./tuxpaint|grep -i pango
          libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f12a3ac6000)
          libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f12a3a77000)
          libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f12a2ac6000)

Thanks in advance!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, May 19, 2022 at 02:30:01PM +0900, Shin-ichi TOYAMA wrote:
> Thanks!
> 
> By the way, although it is not a critical one, I already have put one (not only for windows)
> 
> https://sourceforge.net/p/tuxpaint/bugs/248/

I was only able to reproduce this in the Open dialog, when
using the Erase opion, as seen in the screenshot.  No other
prompts seemed to leave anything residual.

It seemed the alpha-channel related, in the `backup` surface.
I think I fixed it. :) I'm 'backporting' the fix to the main
"master" (SDL1.2) branch, too, just to keep things in sync.

I notice the sdl-2.0 branch has a LOT of compiler warnings.
I think I'll try tackling them.  (It looks like that branch
has DEBUG #define'd, which probably causes a lot of them.
The main branch has that problem as well.)

Thx!

-bill!

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, May 19, 2022 at 02:30:01PM +0900, Shin-ichi TOYAMA wrote:
> Thanks!
> 
> By the way, although it is not a critical one, I already have put one (not only for windows)
> 
> https://sourceforge.net/p/tuxpaint/bugs/248/

Oh right, I forgot about this.  Does it happen in do_color_sel(),
do_color_picker(), and do_color_mix(), as well?

Does #define'ing NO_PROMPT_SHADOWS affect it?

I'll remind myself how to pull the SDL2.0 branch and see what
I can figure out...

-bill!

> 
> Pere?
> 
> 
> On 2022年5月19日 13:19:14 JST, Bill Kendrick <nb...@so...> wrote:
> >On Thu, May 19, 2022 at 07:48:59AM +0900, Shin-ichi TOYAMA wrote:
> >> On Wed, 18 May 2022 11:27:17 -0700, Bill Kendrick wrote:
> >> >
> >> >Thanks for looking into this and bringing it up, Shin-ichi.
> >> >
> >> >I think like like option B -- SDL2 for Windows10/11, and SDL1 for
> >> >older systems, or perhaps simply as an option "if you have trouble".
> >> 
> >> I like "if you have trouble" approach too!
> >> 
> >> >It may be worth building a beta release of the SDL2-based version
> >> >which I can ask users out in the real world to please test out.
> >> 
> >> Beta builds are ready.
> >> Please see https://z1.plala.jp/tuxpaint/testing/20220519/
> >
> >Thanks!  I have placed them on my FTP and SourceForge
> >(https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.28-beta/windows-2022-05-19/)
> >
> >I'll spread the word!
> >
> >-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

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

Thanks!

By the way, although it is not a critical one, I already have put one (not only for windows)

https://sourceforge.net/p/tuxpaint/bugs/248/

Pere?


On 2022年5月19日 13:19:14 JST, Bill Kendrick <nb...@so...> wrote:
>On Thu, May 19, 2022 at 07:48:59AM +0900, Shin-ichi TOYAMA wrote:
>> On Wed, 18 May 2022 11:27:17 -0700, Bill Kendrick wrote:
>> >
>> >Thanks for looking into this and bringing it up, Shin-ichi.
>> >
>> >I think like like option B -- SDL2 for Windows10/11, and SDL1 for
>> >older systems, or perhaps simply as an option "if you have trouble".
>> 
>> I like "if you have trouble" approach too!
>> 
>> >It may be worth building a beta release of the SDL2-based version
>> >which I can ask users out in the real world to please test out.
>> 
>> Beta builds are ready.
>> Please see https://z1.plala.jp/tuxpaint/testing/20220519/
>
>Thanks!  I have placed them on my FTP and SourceForge
>(https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.28-beta/windows-2022-05-19/)
>
>I'll spread the word!
>
>-bill!
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Thu, May 19, 2022 at 07:48:59AM +0900, Shin-ichi TOYAMA wrote:
> On Wed, 18 May 2022 11:27:17 -0700, Bill Kendrick wrote:
> >
> >Thanks for looking into this and bringing it up, Shin-ichi.
> >
> >I think like like option B -- SDL2 for Windows10/11, and SDL1 for
> >older systems, or perhaps simply as an option "if you have trouble".
> 
> I like "if you have trouble" approach too!
> 
> >It may be worth building a beta release of the SDL2-based version
> >which I can ask users out in the real world to please test out.
> 
> Beta builds are ready.
> Please see https://z1.plala.jp/tuxpaint/testing/20220519/

Thanks!  I have placed them on my FTP and SourceForge
(https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.28-beta/windows-2022-05-19/)

I'll spread the word!

-bill!

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Wed, 18 May 2022 11:27:17 -0700, Bill Kendrick wrote:
>
>Thanks for looking into this and bringing it up, Shin-ichi.
>
>I think like like option B -- SDL2 for Windows10/11, and SDL1 for
>older systems, or perhaps simply as an option "if you have trouble".

I like "if you have trouble" approach too!

>It may be worth building a beta release of the SDL2-based version
>which I can ask users out in the real world to please test out.

Beta builds are ready.
Please see https://z1.plala.jp/tuxpaint/testing/20220519/

>(I almost _never_ get feedback from people when I do that, so I'm not
>sure it'll work... but who knows?!  We're at nearly 1,000 followers on
>Twitter, and over 19,000 "likes" & followers (two different metrics)
>on Facebook... though they make it very hard to get any reach without
>spending money $$$ >:-( )
>
>I know on Twitter you were suggesting we try for a new release
>for our 20th anniversary next month, and we've already got a LOT
>of changes stacked up since the last release, back in November! :-)
>
> * interactive brush spacing option
> * stamp scaling performance improvement
> * circular eraser outline/preview
> * some new polygon shapes
> * improved OSK scaling
> * "apply" button for labels
> * various label bugfixes (:crosses fingers:)
> * Ctrl keyboard shortcut for pipette tool
> * Red/Yellow/Blue color mixer
> * true HSV in color picker
> * two new zoom-y magic tools
> * sorting option for open/slideshow dialogs
> * auto-repeat when click+hold'ing arrow buttons in more places
> * lots of build (mac/win) updates
> * lots of localization updates
> * improved documentation styling
> * various other bugfixes
>
>Whew, it's been a busy 6 months, hasn't it!?  8^o

Sure!!!

- 
Shin-ichi

>
>-bill!
>
>On Wed, May 18, 2022 at 10:34:30PM +0900, Shin-ichi TOYAMA wrote:
>> Hi!
>> 
>> Recently, I am thinking about that the windows build for the next version
>> could be based on the SDL2 branch.
>> 
>> Its good point is that the known issue regarding scaling problem on modern
>> windows system will be fixed. 
>> 
>>   See: https://sourceforge.net/p/tuxpaint/bugs/218/
>> 
>> However, I noticed that SDL2 build often crash when starting it on Windows7
>> despite that it looks quite stable on Windows 10 and 11. 
>> (By the way I do not have test environment for 8 and Vista)
>> 
>> Seeing the panic message when it crash:
>> 
>>  "Panic: VERIFY d:\build\ob\bora-14943755\bora-vmsoft\build\release\svga\wddm\src\usermode\wddmcmdbuf.cpp:763"
>> 
>> This seems like a handling issue around video devices in the library level,
>> and it does not appear to be easy to resolve.
>> 
>> Therefore, I suppose we have three options so far:
>> 
>>  a. Continue using SDL1 for the time being.
>>  b. Use SDL2 for Windows 10 and later. Provide SDL1 version for the old systems.
>>  c. Use SDL2 and discontinue support for those old systems.
>> 
>> Any thoughts?
>> 
>> -- 
>> Shin-ichi TOYAMA <dol...@wm...>
>> 
>> 
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>


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

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

Thanks for looking into this and bringing it up, Shin-ichi.

I think like like option B -- SDL2 for Windows10/11, and SDL1 for
older systems, or perhaps simply as an option "if you have trouble".

It may be worth building a beta release of the SDL2-based version
which I can ask users out in the real world to please test out.

(I almost _never_ get feedback from people when I do that, so I'm not
sure it'll work... but who knows?!  We're at nearly 1,000 followers on
Twitter, and over 19,000 "likes" & followers (two different metrics)
on Facebook... though they make it very hard to get any reach without
spending money $$$ >:-( )

I know on Twitter you were suggesting we try for a new release
for our 20th anniversary next month, and we've already got a LOT
of changes stacked up since the last release, back in November! :-)

 * interactive brush spacing option
 * stamp scaling performance improvement
 * circular eraser outline/preview
 * some new polygon shapes
 * improved OSK scaling
 * "apply" button for labels
 * various label bugfixes (:crosses fingers:)
 * Ctrl keyboard shortcut for pipette tool
 * Red/Yellow/Blue color mixer
 * true HSV in color picker
 * two new zoom-y magic tools
 * sorting option for open/slideshow dialogs
 * auto-repeat when click+hold'ing arrow buttons in more places
 * lots of build (mac/win) updates
 * lots of localization updates
 * improved documentation styling
 * various other bugfixes

Whew, it's been a busy 6 months, hasn't it!?  8^o

-bill!

On Wed, May 18, 2022 at 10:34:30PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> Recently, I am thinking about that the windows build for the next version
> could be based on the SDL2 branch.
> 
> Its good point is that the known issue regarding scaling problem on modern
> windows system will be fixed. 
> 
>   See: https://sourceforge.net/p/tuxpaint/bugs/218/
> 
> However, I noticed that SDL2 build often crash when starting it on Windows7
> despite that it looks quite stable on Windows 10 and 11. 
> (By the way I do not have test environment for 8 and Vista)
> 
> Seeing the panic message when it crash:
> 
>  "Panic: VERIFY d:\build\ob\bora-14943755\bora-vmsoft\build\release\svga\wddm\src\usermode\wddmcmdbuf.cpp:763"
> 
> This seems like a handling issue around video devices in the library level,
> and it does not appear to be easy to resolve.
> 
> Therefore, I suppose we have three options so far:
> 
>  a. Continue using SDL1 for the time being.
>  b. Use SDL2 for Windows 10 and later. Provide SDL1 version for the old systems.
>  c. Use SDL2 and discontinue support for those old systems.
> 
> Any thoughts?
> 
> -- 
> Shin-ichi TOYAMA <dol...@wm...>
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] SDL2 for the next release for windows?

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

Hi!

Recently, I am thinking about that the windows build for the next version
could be based on the SDL2 branch.

Its good point is that the known issue regarding scaling problem on modern
windows system will be fixed. 

  See: https://sourceforge.net/p/tuxpaint/bugs/218/

However, I noticed that SDL2 build often crash when starting it on Windows7
despite that it looks quite stable on Windows 10 and 11. 
(By the way I do not have test environment for 8 and Vista)

Seeing the panic message when it crash:

 "Panic: VERIFY d:\build\ob\bora-14943755\bora-vmsoft\build\release\svga\wddm\src\usermode\wddmcmdbuf.cpp:763"

This seems like a handling issue around video devices in the library level,
and it does not appear to be easy to resolve.

Therefore, I suppose we have three options so far:

 a. Continue using SDL1 for the time being.
 b. Use SDL2 for Windows 10 and later. Provide SDL1 version for the old systems.
 c. Use SDL2 and discontinue support for those old systems.

Any thoughts?

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

[Tuxpaint-devel] History of Tux Paint, celebrating 20 years

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

Tux Paint turns 20 years old next month (June 2022), so I put together
a not-so-brief history (in three parts!) covering the development
milestones of the project.  (Basically a very condensed version of the
changelog and press releases.)

  https://tuxpaint.org/history/

Enjoy!  If anyone notices any incorrect statements, or think I missed
something important, let me know!  It's been my late night hobby
project, so I've gotten a bit groggy working on it over the past
week.  ;-) Thanks!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] "Rush" magic tool

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

I created a variation of the Zoom tool that applies the
zoom in steps, and blends them together, to create a blur.

Extreme example:
  https://pbs.twimg.com/media/FSHgmK3UcAAcyvV?format=png&name=900x900

More subtle examples (zooming both in & out):
  https://pbs.twimg.com/media/FSEEU4iVUAAP3XN?format=png&name=small
  https://pbs.twimg.com/media/FSEEU5hUUAAus6l?format=png&name=small


It could be better, and more efficient, so if anyone has ideas
or suggestions on how to improve it, let me know!  I basically
brute-forced it. :)

Thanks & enjoy,

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Some videos made using Tux Paint

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

Some kids in South Africa have been using Tux Paint (sometimes
together with Blender, and other tools) to create some rather silly
cartoons and videos, including a music video (coming soon).

I thought folks out on these lists might enjoy seeing them.
(Tux Paint users: for inspiration... Tux Paint developers: to see what
kids are capable of doing with our little drawing app! :-) )

  The Jewel of Kramalot
  https://www.youtube.com/watch?v=TP1dlNdpiqA

  The Magic Hair Comb
  https://www.youtube.com/watch?v=wmydIOsDZbI

  (Preview) Music video for Flying Squid's "All Out of Riddles"
  https://twitter.com/GabeTYJ/status/1517578970543411202

(It makes me so happy to see my "Flower" Magic Tool making its
appearance so many places. :-D )


And, as usual, keep an eye on the new Gallery over on the Tux Paint
website, where I'm regularly adding new artwork as I come across it
on Twitter and Tumblr (or receive it directly via email):

  https://tuxpaint.org/gallery/


Enjoy!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Question about aspect ratio on Android

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

On Wed, Mar 30, 2022 at 01:39:14AM +0200, Pere Pujal i Carabantes wrote:
> El dt. 29 de 03 de 2022 a les 00:49 -0700, en/na Bill Kendrick va escriure:
> > On Sun, Mar 27, 2022 at 11:55:41PM +0200, Pere Pujal i Carabantes wrote:
> > > El dg. 27 de 03 de 2022 a les 12:44 -0700, en/na Bill Kendrick va escriure:
> > > > Hi all (esp. Pere),
> > > > 
> > > > This question came in via Twitter:
> > > > 
> > > >   I'd like to ask why I can't force the app into a 16:9 aspect ratio
> > > >   on these new, wider-than-wide phones
> > > > 
> > > > Any ideas?  Thanks in advance,
> > > > 
> > > 
> > > Tuxpaint on Android runs with --fullscreen native, so it gets what SDL2 passes on.
> > > 
> > > I've never tried to launch it windowed(if that is possible in Android), 
> > > and the small configuration tool for Android doesn't handle window size.
> > > Anyway one could manually edit the config file in 
> > > /sdcard/Android/data/org.tuxpaint/files/tuxpaint.cfg and try that.
> > > 
> > > That said, IIRC the SDL2 version used in the builds is the 2.0.14, not sure if a newer version would help with wider screens.
> > > 
> > > A screenshot of the problem?
> > 
> > They wrote back:
> > 
> >   I can test out a sorta Windowed mode on my phone
> > 
> > I wonder if perhaps we should open a ticket at SourceForge for this?
> > Can you?  Shall I?  Or should I ask them to?  (I hate being the
> > middleman :-) )
> > 
> > -bill!
> 
> I've made some tests in a emulator, about 2:1 ratio, and tuxpaint perfoms fine using all availabe space.
> Re-reading the question seems they want to _discard_ some of the wide space in order to get a 16:9 ratio.

That's an interesting thought.


> If that is what they want, they need to modify the fullscreen line to read something like
> fullscreen=1600x900
> then change the native line to
> native=no
> With that in place I get two black bands at each side of the tuxpaint window.
> 
> 
> 
> It is not obvious to manually change/edit the config file in Android, 
> one must 'su' to the user who owns the tuxpaint.cfg file(u0_a153 in the case of my emulator) 
> and edit the file as that user, so I don't expect any non rooted phone being able to do this.
> 
> Is it worth to extend the config tool to be able to cope with this requirement? 
> Looks doable but it will take some time...
> 
> About the ticket at SF I was going to open it when I re-readed the message, 
> I'd want to be sure I do not missunderstand the problem :)

It sounds like it would make sense to add some options to the
Android mini-version of Tux Paint Config. to support some of
these kinds of settings.

That said, this has been the one and only time anyone has asked
about this. *shrug*

Sorry it took me a month to finally remember to come back and
reply to this!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Question about aspect ratio on Android

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

El dc. 30 de 03 de 2022 a les 01:39 +0200, en/na Pere Pujal i Carabantes va escriure:

> If that is what they want, they need to modify the fullscreen line to read something like
> fullscreen=1600x900
> then change the native line to
> native=no

Sorry, should be

fullscreen=yes
windowsize=1600x900
native=no

Sorry for the noise
Pere

Re: [Tuxpaint-devel] Question about aspect ratio on Android

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

El dt. 29 de 03 de 2022 a les 00:49 -0700, en/na Bill Kendrick va escriure:
> On Sun, Mar 27, 2022 at 11:55:41PM +0200, Pere Pujal i Carabantes wrote:
> > El dg. 27 de 03 de 2022 a les 12:44 -0700, en/na Bill Kendrick va escriure:
> > > Hi all (esp. Pere),
> > > 
> > > This question came in via Twitter:
> > > 
> > >   I'd like to ask why I can't force the app into a 16:9 aspect ratio
> > >   on these new, wider-than-wide phones
> > > 
> > > Any ideas?  Thanks in advance,
> > > 
> > 
> > Tuxpaint on Android runs with --fullscreen native, so it gets what SDL2 passes on.
> > 
> > I've never tried to launch it windowed(if that is possible in Android), 
> > and the small configuration tool for Android doesn't handle window size.
> > Anyway one could manually edit the config file in 
> > /sdcard/Android/data/org.tuxpaint/files/tuxpaint.cfg and try that.
> > 
> > That said, IIRC the SDL2 version used in the builds is the 2.0.14, not sure if a newer version would help with wider screens.
> > 
> > A screenshot of the problem?
> 
> They wrote back:
> 
>   I can test out a sorta Windowed mode on my phone
> 
> I wonder if perhaps we should open a ticket at SourceForge for this?
> Can you?  Shall I?  Or should I ask them to?  (I hate being the
> middleman :-) )
> 
> -bill!

I've made some tests in a emulator, about 2:1 ratio, and tuxpaint perfoms fine using all availabe space.
Re-reading the question seems they want to _discard_ some of the wide space in order to get a 16:9 ratio.

If that is what they want, they need to modify the fullscreen line to read something like
fullscreen=1600x900
then change the native line to
native=no
With that in place I get two black bands at each side of the tuxpaint window.



It is not obvious to manually change/edit the config file in Android, 
one must 'su' to the user who owns the tuxpaint.cfg file(u0_a153 in the case of my emulator) 
and edit the file as that user, so I don't expect any non rooted phone being able to do this.

Is it worth to extend the config tool to be able to cope with this requirement? 
Looks doable but it will take some time...

About the ticket at SF I was going to open it when I re-readed the message, 
I'd want to be sure I do not missunderstand the problem :)

Best
Pere

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

Re: [Tuxpaint-devel] Question about aspect ratio on Android

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

On Sun, Mar 27, 2022 at 11:55:41PM +0200, Pere Pujal i Carabantes wrote:
> El dg. 27 de 03 de 2022 a les 12:44 -0700, en/na Bill Kendrick va escriure:
> > Hi all (esp. Pere),
> > 
> > This question came in via Twitter:
> > 
> >   I'd like to ask why I can't force the app into a 16:9 aspect ratio
> >   on these new, wider-than-wide phones
> > 
> > Any ideas?  Thanks in advance,
> > 
> 
> Tuxpaint on Android runs with --fullscreen native, so it gets what SDL2 passes on.
> 
> I've never tried to launch it windowed(if that is possible in Android), 
> and the small configuration tool for Android doesn't handle window size.
> Anyway one could manually edit the config file in 
> /sdcard/Android/data/org.tuxpaint/files/tuxpaint.cfg and try that.
> 
> That said, IIRC the SDL2 version used in the builds is the 2.0.14, not sure if a newer version would help with wider screens.
> 
> A screenshot of the problem?

They wrote back:

  I can test out a sorta Windowed mode on my phone

I wonder if perhaps we should open a ticket at SourceForge for this?
Can you?  Shall I?  Or should I ask them to?  (I hate being the
middleman :-) )

-bill!

Re: [Tuxpaint-devel] Question about aspect ratio on Android

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

El dg. 27 de 03 de 2022 a les 12:44 -0700, en/na Bill Kendrick va escriure:
> Hi all (esp. Pere),
> 
> This question came in via Twitter:
> 
>   I'd like to ask why I can't force the app into a 16:9 aspect ratio
>   on these new, wider-than-wide phones
> 
> Any ideas?  Thanks in advance,
> 

Tuxpaint on Android runs with --fullscreen native, so it gets what SDL2 passes on.

I've never tried to launch it windowed(if that is possible in Android), 
and the small configuration tool for Android doesn't handle window size.
Anyway one could manually edit the config file in 
/sdcard/Android/data/org.tuxpaint/files/tuxpaint.cfg and try that.

That said, IIRC the SDL2 version used in the builds is the 2.0.14, not sure if a newer version would help with wider screens.

A screenshot of the problem?

Best
Pere

[Tuxpaint-devel] Question about aspect ratio on Android

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

Hi all (esp. Pere),

This question came in via Twitter:

  I'd like to ask why I can't force the app into a 16:9 aspect ratio
  on these new, wider-than-wide phones

Any ideas?  Thanks in advance,

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Updated 'rainbow' color picker

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

El dt. 22 de 03 de 2022 a les 20:46 -0700, en/na Bill Kendrick va escriure:
> On Thu, Mar 17, 2022 at 08:43:51PM +0100, Pere Pujal i Carabantes wrote:
> <snip> 
> > I've just compiled an Android apk, it also has the patch suggested by 
> > Shin-ichi applied so you can test that too. Looks fine as far as I can tell :)
> > 
> > http://provant.freeddns.org/pere/public_html/developing/20220317/tuxpaint-debug.apk
> > 
> > Note that it is a debug build, so the signature will not match with the official ones we release.
> > you will have to uninstall any installed tuxpaint before install this one.
> 
> Whoops!  Your server is down right now.  (I tried both HTTP & HTTPS,
> and checked for any typos by comparing to earlier posts you made
> with similar URLs.)
> 
> I'll try again another day.  Hope all is well!
> 

Ouch! Thanks!, 
Apache was not working, it is working again

Thanks
Pere

Re: [Tuxpaint-devel] Updated 'rainbow' color picker

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

On Thu, Mar 17, 2022 at 08:43:51PM +0100, Pere Pujal i Carabantes wrote:
<snip> 
> I've just compiled an Android apk, it also has the patch suggested by 
> Shin-ichi applied so you can test that too. Looks fine as far as I can tell :)
> 
> http://provant.freeddns.org/pere/public_html/developing/20220317/tuxpaint-debug.apk
> 
> Note that it is a debug build, so the signature will not match with the official ones we release.
> you will have to uninstall any installed tuxpaint before install this one.

Whoops!  Your server is down right now.  (I tried both HTTP & HTTPS,
and checked for any typos by comparing to earlier posts you made
with similar URLs.)

I'll try again another day.  Hope all is well!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Updated 'rainbow' color picker

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

Hi,

El dj. 17 de 03 de 2022 a les 10:47 -0700, en/na Bill Kendrick va escriure:
> 
> 
> Hopefully this works okay.  I'd appreciate it if people could hammer
> on the updated UI, and let me know how your systems handle it.
> (Pere, I'd especially appreciate testing on a mobile device.
> If you want to build a non-release-candidate test version for me
> to play with on my phone and maybe some other Androids around my
> house, I'd be happy to.)

I've just compiled an Android apk, it also has the patch suggested by 
Shin-ichi applied so you can test that too. Looks fine as far as I can tell :)

http://provant.freeddns.org/pere/public_html/developing/20220317/tuxpaint-debug.apk

Note that it is a debug build, so the signature will not match with the official ones we release.
you will have to uninstall any installed tuxpaint before install this one.

HTH
Pere

Re: [Tuxpaint-devel] Updated 'rainbow' color picker

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

On Sat, Mar 05, 2022 at 12:48:57AM +0100, Pere Pujal i Carabantes wrote:
> Hi,
> 
> El dj. 03 de 03 de 2022 a les 00:09 -0800, en/na Bill Kendrick va escriure:
> 
> > 
> > Please pull from the Git repo and try it out and
> > let me know what you think and (especially) if
> > you notice any issues with it!
> 
> Just tested in the sdl2.0 branch, looks nice :)
> Found some things:
> 
> When you start it with the default values there are 
> a couple of ghost markers at the top left of colors 
> and top of the value box.

Mended.  I'm not actually doing the clipping, but letting
the lack of a wider UpdateRect or Flip prevent the extraneous
bits from appearing on the screen. ;)

I also made the crosshairs bigger, and scale up based on `button_scale`
(a float multiplier based on --buttonsize option).


> When the mouse is over the value box maybe it should 
> have a different cursor, a cross, a hand?

Oops, yep.  Made it a hand.


> When you click and drag in the value box the color 
> doesn't updates until you release, this is different 
> from clicking and dragging in the colored square.

I've implemented this -- a few days ago, actually.

Yesterday, though, I realized that re-rendering the entire Hue/Sat
rainbow rectangle for every mousemotion was very CPU intensive.
In fact, on a larger UI (I tried --1920x960 --buttonsize=128, though
it scales back to buttonsize of ~70), even on my relatively fast &
modern laptop, if I wiggled the mouse around the grey Value slider,
Tux Paint would take a second or two to catch up.

Therefore, every time it re-renders the rainbow (all of the relatively
intensive HSV->RGB floating point math and pixel-putting), it will
spin in a tight while() loop, eating SDL events until it runs out,
or lands on something that isn't a MOTION.  (It then puts the very
last event back into the queue via a PushEvent call.)

Hopefully this works okay.  I'd appreciate it if people could hammer
on the updated UI, and let me know how your systems handle it.
(Pere, I'd especially appreciate testing on a mobile device.
If you want to build a non-release-candidate test version for me
to play with on my phone and maybe some other Androids around my
house, I'd be happy to.)

My main regret is I was up too late fighting with the crosshair code.
(In the end, it's flexible... the size and thickness of the inner
white "+" shape, and the thickness of the black border, are all
variable now!)

Thanks for the feedback!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] conversion from wchar to utfstream

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

On Tue, Mar 15, 2022 at 06:10:24PM +0900, Shin-ichi TOYAMA wrote:
> Thanks pere,
> 
> I looked around it again.
> 
> The function render_text_w() looks like to be called only from text/label tools,
> and the process never go into the block "if (font->typ == FONT_TYPE_PANGO)" in it.
> 
> If it is correct, there is no need to do somethinge here currently.

"CURRENTLY"  ;-D

-bill!