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 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!

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

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

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.


On Tue, 15 Mar 2022 07:54:46 +0100, Pere Pujal i Carabantes wrote:
>Seems Pango is only used for the UI currently and not for Text and Label tools.
>https://sourceforge.net/p/tuxpaint/bugs/232/
>
>HTH
>Pere
>
>El 15 de març de 2022 4:58:15 CET, Shin-ichi TOYAMA <dol...@wm...> ha escrit:
>>Hi!
>>
>>As far as I tested,  I did not come upon any issue with label stuff on
>>windows and linux.
>>
>>However, what I felt strange  was that the program never went thorough
>>the block in "if (font->typ == FONT_TYPE_PANGO){...}" even I tried all
>>the font loaded. Here, I've enabled both 'Load System Fonts' and 'Load
>>All Locale Fonts'.
>>
>>Therefore, unfortunately I can not say "There is no problem!" so far.
>>
>>I sould figure out what case that block will be executed in, and test
>>if such conversion block can be replaced with mbstowcs() actually.
>>
>>I will appreciate any help from you all.
>>
>>Thanks.
>>
>>
>>On Wed, 9 Mar 2022 00:21:28 -0800, Bill Kendrick wrote:
>>>On Wed, Mar 09, 2022 at 01:13:23AM +0100, Pere Pujal i Carabantes wrote:
>>>> El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure:
>>>> > Hi!
>>>> > 
>>>> > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740.
>>>> > 
>>>> > -----------------------------------------------------------------
>>>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>>>> > 
>>>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>>>> > utfstr = (char *)malloc(utfstr_max);
>>>> > memset(utfstr, 0, utfstr_max);
>>>> > 
>>>> >   < ... many lines ... >
>>>> > 
>>>> > utfstr[j] = '\0';
>>>> > -----------------------------------------------------------------
>>>> > 
>>>> > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms.
>>>> > 
>>>> > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte().
>>>> > 
>>>> > -----------------------------------------------------------------
>>>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>>>> > 
>>>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>>>> > utfstr = (char *)malloc(utfstr_max);
>>>> > 
>>>> > wcstombs(utfstr, str, utfstr_max);
>>>> > -----------------------------------------------------------------
>>>> > 
>>>> > How do you think of it?
>>>> > 
>>>> 
>>>> Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing
>>>> Note that I've just tested your approach in Linux.
>>>> 
>>>> My 2 cents
>>>> Pere
>>>
>>>Thanks, you two!  This stuff is a bit outside my expertise
>>>(and I'm also very busy with some big changes at my day job,
>>>so my brain is pretty fried by the evening, when I can spend
>>>any time on Tux Paint :-D )... so I appreciate your efforts.
>>>
>>>It would be good, of course, to make sure changes work as
>>>expected.  Alas, we don't have any kind of unit testing
>>>in Tux Paint, so it would have to be manual.
>>>
>>>So perhaps we can put together a list of things to test,
>>>and the process to test each.  For example, say:
>>>
>>>Test 1
>>> * Create 1 label using basic ASCII
>>> * Save image
>>> * Load image
>>> * Confirm label is correct
>>>
>>>Test 2
>>> * Create 1 label using multibyte characters
>>> * Save image
>>> * Load image
>>> * Confirm label is correct
>>>
>>>Test 3
>>> * Create 1 label using ASCII
>>> * Edit label using ASCII
>>> * Save image
>>> * Load image
>>> * Confirm label is correct
>>>
>>>...and so on.
>>>
>>>I suppose if it were to be put into a big matrix, the things
>>>I'm concerned about are:
>>>
>>> * does it work properly in ASCII? with multibyte? mixed?
>>> * does it work properly with one label? multiple labels?
>>> * does it work properly after editing a label?
>>>
>>>And we'd want to ensure it works on our currently-supported platforms:
>>>
>>> * Linux
>>> * Windows
>>> * macoS
>>> * Android
>>> * Haiku
>>>
>>>Of course, I welcome any other ideas (or alternatives) here!
>>>
>>>Thanks!
>>>
>>
>>
>>-- 
>>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] conversion from wchar to utfstream

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

Seems Pango is only used for the UI currently and not for Text and Label tools.
https://sourceforge.net/p/tuxpaint/bugs/232/

HTH
Pere

El 15 de març de 2022 4:58:15 CET, Shin-ichi TOYAMA <dol...@wm...> ha escrit:
>Hi!
>
>As far as I tested,  I did not come upon any issue with label stuff on
>windows and linux.
>
>However, what I felt strange  was that the program never went thorough
>the block in "if (font->typ == FONT_TYPE_PANGO){...}" even I tried all
>the font loaded. Here, I've enabled both 'Load System Fonts' and 'Load
>All Locale Fonts'.
>
>Therefore, unfortunately I can not say "There is no problem!" so far.
>
>I sould figure out what case that block will be executed in, and test
>if such conversion block can be replaced with mbstowcs() actually.
>
>I will appreciate any help from you all.
>
>Thanks.
>
>
>On Wed, 9 Mar 2022 00:21:28 -0800, Bill Kendrick wrote:
>>On Wed, Mar 09, 2022 at 01:13:23AM +0100, Pere Pujal i Carabantes wrote:
>>> El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure:
>>> > Hi!
>>> > 
>>> > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740.
>>> > 
>>> > -----------------------------------------------------------------
>>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>>> > 
>>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>>> > utfstr = (char *)malloc(utfstr_max);
>>> > memset(utfstr, 0, utfstr_max);
>>> > 
>>> >   < ... many lines ... >
>>> > 
>>> > utfstr[j] = '\0';
>>> > -----------------------------------------------------------------
>>> > 
>>> > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms.
>>> > 
>>> > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte().
>>> > 
>>> > -----------------------------------------------------------------
>>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>>> > 
>>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>>> > utfstr = (char *)malloc(utfstr_max);
>>> > 
>>> > wcstombs(utfstr, str, utfstr_max);
>>> > -----------------------------------------------------------------
>>> > 
>>> > How do you think of it?
>>> > 
>>> 
>>> Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing
>>> Note that I've just tested your approach in Linux.
>>> 
>>> My 2 cents
>>> Pere
>>
>>Thanks, you two!  This stuff is a bit outside my expertise
>>(and I'm also very busy with some big changes at my day job,
>>so my brain is pretty fried by the evening, when I can spend
>>any time on Tux Paint :-D )... so I appreciate your efforts.
>>
>>It would be good, of course, to make sure changes work as
>>expected.  Alas, we don't have any kind of unit testing
>>in Tux Paint, so it would have to be manual.
>>
>>So perhaps we can put together a list of things to test,
>>and the process to test each.  For example, say:
>>
>>Test 1
>> * Create 1 label using basic ASCII
>> * Save image
>> * Load image
>> * Confirm label is correct
>>
>>Test 2
>> * Create 1 label using multibyte characters
>> * Save image
>> * Load image
>> * Confirm label is correct
>>
>>Test 3
>> * Create 1 label using ASCII
>> * Edit label using ASCII
>> * Save image
>> * Load image
>> * Confirm label is correct
>>
>>...and so on.
>>
>>I suppose if it were to be put into a big matrix, the things
>>I'm concerned about are:
>>
>> * does it work properly in ASCII? with multibyte? mixed?
>> * does it work properly with one label? multiple labels?
>> * does it work properly after editing a label?
>>
>>And we'd want to ensure it works on our currently-supported platforms:
>>
>> * Linux
>> * Windows
>> * macoS
>> * Android
>> * Haiku
>>
>>Of course, I welcome any other ideas (or alternatives) here!
>>
>>Thanks!
>>
>
>
>-- 
>Shin-ichi TOYAMA <dol...@wm...>
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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

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

Hi!

As far as I tested,  I did not come upon any issue with label stuff on
windows and linux.

However, what I felt strange  was that the program never went thorough
the block in "if (font->typ == FONT_TYPE_PANGO){...}" even I tried all
the font loaded. Here, I've enabled both 'Load System Fonts' and 'Load
All Locale Fonts'.

Therefore, unfortunately I can not say "There is no problem!" so far.

I sould figure out what case that block will be executed in, and test
if such conversion block can be replaced with mbstowcs() actually.

I will appreciate any help from you all.

Thanks.


On Wed, 9 Mar 2022 00:21:28 -0800, Bill Kendrick wrote:
>On Wed, Mar 09, 2022 at 01:13:23AM +0100, Pere Pujal i Carabantes wrote:
>> El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure:
>> > Hi!
>> > 
>> > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740.
>> > 
>> > -----------------------------------------------------------------
>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>> > 
>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>> > utfstr = (char *)malloc(utfstr_max);
>> > memset(utfstr, 0, utfstr_max);
>> > 
>> >   < ... many lines ... >
>> > 
>> > utfstr[j] = '\0';
>> > -----------------------------------------------------------------
>> > 
>> > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms.
>> > 
>> > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte().
>> > 
>> > -----------------------------------------------------------------
>> > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */
>> > 
>> > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1));
>> > utfstr = (char *)malloc(utfstr_max);
>> > 
>> > wcstombs(utfstr, str, utfstr_max);
>> > -----------------------------------------------------------------
>> > 
>> > How do you think of it?
>> > 
>> 
>> Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing
>> Note that I've just tested your approach in Linux.
>> 
>> My 2 cents
>> Pere
>
>Thanks, you two!  This stuff is a bit outside my expertise
>(and I'm also very busy with some big changes at my day job,
>so my brain is pretty fried by the evening, when I can spend
>any time on Tux Paint :-D )... so I appreciate your efforts.
>
>It would be good, of course, to make sure changes work as
>expected.  Alas, we don't have any kind of unit testing
>in Tux Paint, so it would have to be manual.
>
>So perhaps we can put together a list of things to test,
>and the process to test each.  For example, say:
>
>Test 1
> * Create 1 label using basic ASCII
> * Save image
> * Load image
> * Confirm label is correct
>
>Test 2
> * Create 1 label using multibyte characters
> * Save image
> * Load image
> * Confirm label is correct
>
>Test 3
> * Create 1 label using ASCII
> * Edit label using ASCII
> * Save image
> * Load image
> * Confirm label is correct
>
>...and so on.
>
>I suppose if it were to be put into a big matrix, the things
>I'm concerned about are:
>
> * does it work properly in ASCII? with multibyte? mixed?
> * does it work properly with one label? multiple labels?
> * does it work properly after editing a label?
>
>And we'd want to ensure it works on our currently-supported platforms:
>
> * Linux
> * Windows
> * macoS
> * Android
> * Haiku
>
>Of course, I welcome any other ideas (or alternatives) here!
>
>Thanks!
>


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

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

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

El dc. 09 de 03 de 2022 a les 00:24 -0800, en/na Bill Kendrick va escriure:
> 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 :)
> 
> Thanks! :)  How does it fair on an Android device,
> have you tried?

Looks nice there too :)
Have to put out there a build for people to test...

I am starting to test the wcstombs stuff in Android and 
in the small tests I've already done perform right :)
crossing fingers

Best
Pere


> 
> > 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.
> 
> Yes.  I need to address this.  They are also _tiny_, and I'd like them
> to scale up a bit, based on the overall UI scaling.
> 
> 
> > When the mouse is over the value box maybe it should 
> > have a different cursor, a cross, a hand?
> 
> Oops, yes, I probably forgot that!  The trouble with us "rolling our
> own" UI. :^Z
> 
> 
> > 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.
> 
> Yes, the action is on release.  I suppose, as long as the constant
> re-generation of the large rectangular hue/sat palette isn't too CPU
> intensive, doing the action on click+drag would make sense, for
> consistency's sake.
> 
> I was hoping to poke at these (or at least reply to your email) this
> past weekend, but life has gotten VERY busy. :-D
> 

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 :)

Thanks! :)  How does it fair on an Android device,
have you tried?


> 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.

Yes.  I need to address this.  They are also _tiny_, and I'd like them
to scale up a bit, based on the overall UI scaling.


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

Oops, yes, I probably forgot that!  The trouble with us "rolling our
own" UI. :^Z


> 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.

Yes, the action is on release.  I suppose, as long as the constant
re-generation of the large rectangular hue/sat palette isn't too CPU
intensive, doing the action on click+drag would make sense, for
consistency's sake.

I was hoping to poke at these (or at least reply to your email) this
past weekend, but life has gotten VERY busy. :-D

-- 
-bill!
Sent from my computer