tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] [Tuxpaint-users] Difference between 'Text' and 'Label'

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

On Mon, Feb 07, 2022 at 02:46:54AM +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote:
> Hello there,
> I was working on tux paint this days and I was testing especially on the
> 'text' and 'label' tools. What I recognized is that these 2 tools have very
> similar uses. Also, I figured that the 'label' tool is more useful than the
> 'text'. I think that these things that can be done with 'text' can easily
> be done with 'label' too.
> I would be glad if you tell me what your opinions are and if you think that
> the 'text' tool should be replaced by 'label'.
> Thank you!

>From a historical perspective, the Text tool came first.

It is simpler to use -- once you are done adding text
to your drawing, there are no extra UI elements, which could
potentially cause confusion in younger users.  (This is why
the Label tool can be explicitly disabled, as a simplification
option.)

Many requests came in over the years to add a way to edit and
manipulate text after the fact (move it, correct a typo, etc.),
beyond simply using the Undo feature, and typing it again.
Based on these requests, we added the Label tool.

>From a practical perspective, the Label tool provides something
different from the Text tool, beyond simply the ability to edit
the text after the fact.

With the original Text tool, the text becomes "blitted" into the
drawing.  You may paint over it, manipulate it with various
Magic tool effects (blur, blocks, perspective, etc.), just
as you can with most everything else that ends up on the canvas.

Imagine the Text tool as though you were literally painting
words onto your canvas.  You can smear or paint over them
later.

The Label tool is like a clear sheet of glass hovering just
in front of your painting, where you can place little
stickers containing text.  You can move them around after
the fact, without changing your painting.  However, you cannot
paint _over_ them.

>From a technical perspective, Label is like a text layer in GIMP.
The Text tool is as if you the took your text layer and issue
a "Layer -> Discard Text Information" command, followed by
a "Layer -> Merge Down" command.

So there's definitely no reason to get rid of the Text tool.

I do see how it could be useful to provide an option, that caused the
same effect as those two GIMP commands above.  In other words, a way
to take a piece of text written with the Label tool and "apply" it to
the canvas, as if it were originally entered using the Text tool
("painted onto the canvas"), once you are happy with it.

(Also, I see that the Label tool's interactions lack very many hints
(text at the bottom, next to Tux the penguin) on how to use it, which
I think should be addressed!)

Thanks for your thoughts on this!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Difference between 'Text' and 'Label'

[ΑΡΕΤΗ Τ. <tso...@gm...>]

Hello there,
I was working on tux paint this days and I was testing especially on the
'text' and 'label' tools. What I recognized is that these 2 tools have very
similar uses. Also, I figured that the 'label' tool is more useful than the
'text'. I think that these things that can be done with 'text' can easily
be done with 'label' too.
I would be glad if you tell me what your opinions are and if you think that
the 'text' tool should be replaced by 'label'.
Thank you!

Re: [Tuxpaint-devel] Some recent improvements

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

On Fri, Feb 04, 2022 at 11:36:52AM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> On Fri, 28 Jan 2022 02:40:42 -0800, Bill Kendrick wrote:
> >Finally, the color proportions shown at the bottom
> >(e.g., "Your color is 1/3 red, 1/3 yellow, and 1/3 blue")
> >will now show simplified fractions as alternatives, when possible.
> >For example:
> >
> >  Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/5 black.
> 
> I translated ja.po hoping
> 
>  "5/10 (1/2) $B$,(B $B$"$+(B $B$G(B 4/10 (2/5) $B$,(B $B$-$$$m(B $B$G(B 1/10 $B$,(B $B$/$m(B $B$N(B $B$$$m$G$9(B"
> 
> for 
> 
>  "Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/10 black."
> 
> but, it appears like
> 
>  "Your color is 5/10 (1/2) $B$"$+(B, 4/10 (2/5) $B$-$$$m(B, and 1/10 $B$/$m(B."

Hrm, very odd, I see it too!  I'll investigate.  Thanks,

-bill!

Re: [Tuxpaint-devel] Some recent improvements

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

Hi!

On Fri, 28 Jan 2022 02:40:42 -0800, Bill Kendrick wrote:
>Finally, the color proportions shown at the bottom
>(e.g., "Your color is 1/3 red, 1/3 yellow, and 1/3 blue")
>will now show simplified fractions as alternatives, when possible.
>For example:
>
>  Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/5 black.

I translated ja.po hoping

 "5/10 (1/2) が あか で 4/10 (2/5) が きいろ で 1/10 が くろ の いろです"

for 

 "Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/10 black."

but, it appears like

 "Your color is 5/10 (1/2) あか, 4/10 (2/5) きいろ, and 1/10 くろ."

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

Hi!

On Sun, 30 Jan 2022 20:28:10 +0100, Pere Pujal i Carabantes wrote:
>After some more tests with bindtextdomain, I couldn't make it working 
>with any of the combinations of the locale string I tested, 
>maybe you could have more luck.
>
>What works for me is to use the full path, 
>copying/adapting some code from chdir_to_binary from tuxpaint.c 
>and get_fname from fname.c:
>
>
>       char curdir[256];
>       char f[512];
>
>     getcwd(curdir, sizeof(curdir));
>     #ifdef DEBUG
>     printf("Current directory at launchtime: %s\n", curdir);
>     #endif
>
> snprintf(f, sizeof(f),
>           "%s%s",
>           curdir, "\\\\locale\\\\");
>
>
> bindtextdomain("tuxpaint", f);

Committed it to the master branch as follows.

+#ifdef WIN32
+  // FIXME: After the update of MinGW/MSYS2 in January 2022, gettext() no longer find
+  //        translation (.mo) files unless dirname is specified by full path.
+  //
+  //                      -- 2022/02/02: Shin-ichi TOYAMA & Pere Pujal i Carabantes
+  char curdir[256];
+  char f[512];
+  getcwd(curdir, sizeof(curdir));
+  snprintf(f, sizeof(f), "%s%s", curdir, "\\locale");
+#ifdef DEBUG
+  printf("Current directory at launchtime: %s\n", curdir);
+  printf("Localedir is set to: %s\n", f);
+#endif
+  bindtextdomain("tuxpaint", f);
+#else
   bindtextdomain("tuxpaint", LOCALEDIR);
+#endif


Thanks!!

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

On Sun, 30 Jan 2022 20:28:10 +0100, Pere Pujal i Carabantes wrote:
>> Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw
>> 
>> maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test
>
>After some more tests with bindtextdomain, I couldn't make it working 
>with any of the combinations of the locale string I tested, 
>maybe you could have more luck.
>
>What works for me is to use the full path, 
>copying/adapting some code from chdir_to_binary from tuxpaint.c 
>and get_fname from fname.c:
>
>
>       char curdir[256];
>       char f[512];
>
>     getcwd(curdir, sizeof(curdir));
>     #ifdef DEBUG
>     printf("Current directory at launchtime: %s\n", curdir);
>     #endif
>
> snprintf(f, sizeof(f),
>           "%s%s",
>           curdir, "\\\\locale\\\\");
>
>
> bindtextdomain("tuxpaint", f);

It worked also for me, thanks!!

However, considering the fact that the translation works fine in tuxpaint-config without these efforts, there might be some hidden problem in tuxpaint.

Anyway, I will commit your's if we really could not find any other fundamental solution.

Thanks!!

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

El dg. 30 de 01 de 2022 a les 17:23 +0100, en/na Pere Pujal i Carabantes va escriure:
> El dg. 30 de 01 de 2022 a les 22:18 +0900, en/na Shin-ichi TOYAMA va escriure:
> > Hi!
> > 
> > I tried a test code as follows.
> > 
> > $ cat test.c
> > #include <stdio.h>
> > #include <libintl.h>
> > 
> > int main(void)
> > {
> >   setlocale(LC_ALL, "");
> >   bindtextdomain("tuxpaint", "locale");
> >   bind_textdomain_codeset("tuxpaint", "UTF-8");
> >   textdomain("tuxpaint");
> >   puts(gettext("Yes, I'm done!"));
> >   return 0;
> > }
> > 
> > $ gcc test.c -o test.exe -lintl
> > 
> > I copied this .exe file to the bdist directory and executed it from
> > windows command prompt.
> > 
> > Then, it DOES translate.
> > 
> > I am quite at a loss what is happening....
> 
> Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw
> 
> maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test

After some more tests with bindtextdomain, I couldn't make it working 
with any of the combinations of the locale string I tested, 
maybe you could have more luck.

What works for me is to use the full path, 
copying/adapting some code from chdir_to_binary from tuxpaint.c 
and get_fname from fname.c:


       char curdir[256];
       char f[512];

     getcwd(curdir, sizeof(curdir));
     #ifdef DEBUG
     printf("Current directory at launchtime: %s\n", curdir);
     #endif

 snprintf(f, sizeof(f),
           "%s%s",
           curdir, "\\\\locale\\\\");


 bindtextdomain("tuxpaint", f);


> 
> HTH
> Pere
> > 
> > 
> > On Sun, 30 Jan 2022 00:31:53 +0100, Pere Pujal i Carabantes wrote:
> > > El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure:
> > > > Hi!
> > > > 
> > > > I noticed an interesting thing about this issue.
> > > > 
> > > > You can install tuxpaint in /usr/local/bin on MSYS2 environment
> > > > as follows.
> > > > 
> > > >   $ make && make install
> > > 
> > > I get permission denied, strange
> > > /usr/local/bin/tuxpaint.exe --help
> > > bash: /usr/local/bin/tuxpaint.exe: Permission denied
> > > 
> > > > 
> > > > Then it has NO problem with translation!!
> > > > 
> > > > Next, I tried deleting all the .dll files in /mingw64/bin/ except
> > > > for those are copied to the win32/bdist directory, suspecting that
> > > > there might be some dll(s) newly required by gettext.
> > > > 
> > > > As a result, it still worked fine!
> > > > 
> > > > Considering above, it may not be a library loading issue.
> > > 
> > > I did a different test that seems to lead also to this conclusion:
> > > compile a bdist dir with the old mingw, make a backup of it
> > > compile another bdist with the new mingw, also backup it
> > > create an empty dir and copy there the backup of the non working bdist, 
> > > then one by one copy the dlls of the working bdist into it 
> > > until the translations works.
> > > 
> > > the least dlls that I had to copy from the old, working bdist dir are
> > > libintl and harfbuzz(wich depends on libintl)
> > > 
> > > > 
> > > > Could it be that tuxpaint fails to find the translation (.mo) files ?
> > > 
> > > Maybe, but even putting the full locale path in i18n.c I could not get it working
> > > 
> > > Replacing bindtextdomain("tuxpaint", LOCALEDIR);  with
> > > bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/");
> > > did not solve things for me.
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

El dg. 30 de 01 de 2022 a les 22:18 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> I tried a test code as follows.
> 
> $ cat test.c
> #include <stdio.h>
> #include <libintl.h>
> 
> int main(void)
> {
>   setlocale(LC_ALL, "");
>   bindtextdomain("tuxpaint", "locale");
>   bind_textdomain_codeset("tuxpaint", "UTF-8");
>   textdomain("tuxpaint");
>   puts(gettext("Yes, I'm done!"));
>   return 0;
> }
> 
> $ gcc test.c -o test.exe -lintl
> 
> I copied this .exe file to the bdist directory and executed it from
> windows command prompt.
> 
> Then, it DOES translate.
> 
> I am quite at a loss what is happening....

Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw

maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test

HTH
Pere
> 
> 
> On Sun, 30 Jan 2022 00:31:53 +0100, Pere Pujal i Carabantes wrote:
> > El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure:
> > > Hi!
> > > 
> > > I noticed an interesting thing about this issue.
> > > 
> > > You can install tuxpaint in /usr/local/bin on MSYS2 environment
> > > as follows.
> > > 
> > >   $ make && make install
> > 
> > I get permission denied, strange
> > /usr/local/bin/tuxpaint.exe --help
> > bash: /usr/local/bin/tuxpaint.exe: Permission denied
> > 
> > > 
> > > Then it has NO problem with translation!!
> > > 
> > > Next, I tried deleting all the .dll files in /mingw64/bin/ except
> > > for those are copied to the win32/bdist directory, suspecting that
> > > there might be some dll(s) newly required by gettext.
> > > 
> > > As a result, it still worked fine!
> > > 
> > > Considering above, it may not be a library loading issue.
> > 
> > I did a different test that seems to lead also to this conclusion:
> > compile a bdist dir with the old mingw, make a backup of it
> > compile another bdist with the new mingw, also backup it
> > create an empty dir and copy there the backup of the non working bdist, 
> > then one by one copy the dlls of the working bdist into it 
> > until the translations works.
> > 
> > the least dlls that I had to copy from the old, working bdist dir are
> > libintl and harfbuzz(wich depends on libintl)
> > 
> > > 
> > > Could it be that tuxpaint fails to find the translation (.mo) files ?
> > 
> > Maybe, but even putting the full locale path in i18n.c I could not get it working
> > 
> > Replacing bindtextdomain("tuxpaint", LOCALEDIR);  with
> > bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/");
> > did not solve things for me.
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

Hi!

I tried a test code as follows.

$ cat test.c
#include <stdio.h>
#include <libintl.h>

int main(void)
{
  setlocale(LC_ALL, "");
  bindtextdomain("tuxpaint", "locale");
  bind_textdomain_codeset("tuxpaint", "UTF-8");
  textdomain("tuxpaint");
  puts(gettext("Yes, I'm done!"));
  return 0;
}

$ gcc test.c -o test.exe -lintl

I copied this .exe file to the bdist directory and executed it from
windows command prompt.

Then, it DOES translate.

I am quite at a loss what is happening....


On Sun, 30 Jan 2022 00:31:53 +0100, Pere Pujal i Carabantes wrote:
>El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure:
>> Hi!
>> 
>> I noticed an interesting thing about this issue.
>> 
>> You can install tuxpaint in /usr/local/bin on MSYS2 environment
>> as follows.
>> 
>>   $ make && make install
>
>I get permission denied, strange
> /usr/local/bin/tuxpaint.exe --help
>bash: /usr/local/bin/tuxpaint.exe: Permission denied
>
>> 
>> Then it has NO problem with translation!!
>> 
>> Next, I tried deleting all the .dll files in /mingw64/bin/ except
>> for those are copied to the win32/bdist directory, suspecting that
>> there might be some dll(s) newly required by gettext.
>> 
>> As a result, it still worked fine!
>> 
>> Considering above, it may not be a library loading issue.
>
>I did a different test that seems to lead also to this conclusion:
>compile a bdist dir with the old mingw, make a backup of it
>compile another bdist with the new mingw, also backup it
>create an empty dir and copy there the backup of the non working bdist, 
>then one by one copy the dlls of the working bdist into it 
>until the translations works.
>
>the least dlls that I had to copy from the old, working bdist dir are
>libintl and harfbuzz(wich depends on libintl)
>
>> 
>> Could it be that tuxpaint fails to find the translation (.mo) files ?
>
>Maybe, but even putting the full locale path in i18n.c I could not get it working
>
> Replacing bindtextdomain("tuxpaint", LOCALEDIR);  with
> bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/");
>did not solve things for me.

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

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

Confirmed it works for the master branch, committed.

Thanks!

On Sat, 29 Jan 2022 23:31:36 +0100, Pere Pujal i Carabantes wrote:
>El ds. 29 de 01 de 2022 a les 00:56 -0800, en/na Bill Kendrick va escriure:
>> On Fri, Jan 28, 2022 at 06:42:41PM +0800, 雷阳 wrote:
>> > Hi, bill,
>> > 
>> > 
>> > I just found the reproducible step:
>> > 1. in settings, check 'simplification' - 'show upper case text only'. this is default. if unchecked, text shows correctly.
>> > 2. env: win10 (also win11). 0.9.27(actually reproduciable since at least 0.9.25)
>> 
>> Hrm, interesting.  I tried "tuxpaint --uppercase --lang chinese",
>> and it still seems to work fine for me.  I wonder if it has
>> something to do with how wide characters are handled under
>> Tux Paint on Windows (versus Linxu).
>
>I remember about a month ago there was a fix for uppercase in Windows by Shin-ichi, 
>it is in the sdl2.0 branch, maybe is worth backporting it to master?
>
>
>
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> I noticed an interesting thing about this issue.
> 
> You can install tuxpaint in /usr/local/bin on MSYS2 environment
> as follows.
> 
>   $ make && make install

I get permission denied, strange
 /usr/local/bin/tuxpaint.exe --help
bash: /usr/local/bin/tuxpaint.exe: Permission denied

> 
> Then it has NO problem with translation!!
> 
> Next, I tried deleting all the .dll files in /mingw64/bin/ except
> for those are copied to the win32/bdist directory, suspecting that
> there might be some dll(s) newly required by gettext.
> 
> As a result, it still worked fine!
> 
> Considering above, it may not be a library loading issue.

I did a different test that seems to lead also to this conclusion:
compile a bdist dir with the old mingw, make a backup of it
compile another bdist with the new mingw, also backup it
create an empty dir and copy there the backup of the non working bdist, 
then one by one copy the dlls of the working bdist into it 
until the translations works.

the least dlls that I had to copy from the old, working bdist dir are
libintl and harfbuzz(wich depends on libintl)

> 
> Could it be that tuxpaint fails to find the translation (.mo) files ?

Maybe, but even putting the full locale path in i18n.c I could not get it working

 Replacing bindtextdomain("tuxpaint", LOCALEDIR);  with
 bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/");
did not solve things for me.

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

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

El ds. 29 de 01 de 2022 a les 00:56 -0800, en/na Bill Kendrick va escriure:
> On Fri, Jan 28, 2022 at 06:42:41PM +0800, 雷阳 wrote:
> > Hi, bill,
> > 
> > 
> > I just found the reproducible step:
> > 1. in settings, check 'simplification' - 'show upper case text only'. this is default. if unchecked, text shows correctly.
> > 2. env: win10 (also win11). 0.9.27(actually reproduciable since at least 0.9.25)
> 
> Hrm, interesting.  I tried "tuxpaint --uppercase --lang chinese",
> and it still seems to work fine for me.  I wonder if it has
> something to do with how wide characters are handled under
> Tux Paint on Windows (versus Linxu).

I remember about a month ago there was a fix for uppercase in Windows by Shin-ichi, 
it is in the sdl2.0 branch, maybe is worth backporting it to master?

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

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

On Fri, Jan 28, 2022 at 06:42:41PM +0800, 雷阳 wrote:
> Hi, bill,
> 
> 
> I just found the reproducible step:
> 1. in settings, check 'simplification' - 'show upper case text only'. this is default. if unchecked, text shows correctly.
> 2. env: win10 (also win11). 0.9.27(actually reproduciable since at least 0.9.25)

Hrm, interesting.  I tried "tuxpaint --uppercase --lang chinese",
and it still seems to work fine for me.  I wonder if it has
something to do with how wide characters are handled under
Tux Paint on Windows (versus Linxu).

Also, "show uppercase only" is not the default.
(And I confirmed that "Tux Paint Config." clears that
checkmark under 'Simplification', if I click the "Defaults"
button.)  Can double-check that this is the case for you?

(Basically, if a non-default option is _not_ set, then the
configuration file should not include a line about it,
generally.)

Thanks!

-bill!

> 
> 
> 
> 
> 
> 
> 
> Regards,
> Yang
> 
> 
> 
> 
> At 2022-01-28 12:44:39, "Bill Kendrick" <nb...@so...> wrote:
> >On Thu, Jan 27, 2022 at 07:37:23AM +0800, ���� wrote:
> >> Hi I also found some icon text missing in some recent versions, but it wasn't blocking issue since i already knew what the icons mean in old version.
> >
> >Hi, can you tell me what version of Tux Paint you're on, and
> >which operating system?  I tried "tuxpaint --lang chinese"
> >and see all of the expected strings.  (This is on Linux
> >using the Git repo version, which will become 0.9.28.)
> >
> >I wonder if perhaps there's a deficiency in the font being
> >utilized for Chinese strings in your system...?
> >
> >(Usually, when a string is untranslated, you'll see the
> >English version found in the source-code.  I don't believe
> >any strings have been explicitly translated to 'nothing' (""),
> >in other words. :) )
> >
> >Thanks in advance,
> >
> >-bill!
> >
> >
> >_______________________________________________
> >Tuxpaint-users mailing list
> >Tux...@li...
> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-users




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


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

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

On Fri, Jan 28, 2022 at 06:21:12PM +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote:
> Hi,
> I understand everything you said.
> Do you thing that this issue needs to be written in a new ticket or not?

No, it's not necessary.  Translation is an ongoing thing that will
be an endless part of the normal process of development (especially
when new features & other content is added).

Thanks, though,

-bill!

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

Hi!

I noticed an interesting thing about this issue.

You can install tuxpaint in /usr/local/bin on MSYS2 environment
as follows.

  $ make && make install

Then it has NO problem with translation!!

Next, I tried deleting all the .dll files in /mingw64/bin/ except
for those are copied to the win32/bdist directory, suspecting that
there might be some dll(s) newly required by gettext.

As a result, it still worked fine!

Considering above, it may not be a library loading issue.

Could it be that tuxpaint fails to find the translation (.mo) files ?

On Fri, 28 Jan 2022 09:51:57 +0900, Shin-ichi TOYAMA wrote:
>>> > El dg. 23 de 01 de 2022 a les 23:53 +0900, en/na Shin-ichi TOYAMA va escriure:
>>> > > Hi!
>>> > > 
>>> > > I recently noticed that translation of SDL2 version become not working after updating the packages of MinGW/MSYS2 development environment.
>>> > > 
>>> > > I also confirmed the same problem occurs with the build environment constructed from the scratch.

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

[雷阳 <lei...@16...>]

Hi,


Nope. I think it is not impacting any function, so priority should be low. no need new bug. 
just someone can remember and fix in new release if easy. thanks!


Regards,
Yang
















在 2022-01-29 00:21:12，"ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ" <tso...@gm...> 写道：

Hi,
I understand everything you said. 
Do you thing that this issue needs to be written in a new ticket or not? 


Thanks. 



Στις Τετ, 26 Ιαν 2022, 23:30 ο χρήστης Bill Kendrick <nb...@so...> έγραψε:

On Wed, Jan 26, 2022 at 04:28:48PM +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote:
> Hello again,
>
> I was testing if the translation in Greek works appropriately in as many
> cases as possible. What I figured out was that:
>
> a) when I pick "shapes", the mascot's words on the bottom of the window are
> not translated in greek
> b) when I pick "fill", the mascot's words on the bottom of the window are
> not translated in greek (just like in "shapes"), and the options of filling
> in the right part of the window are not translated in greek either.
>
>
> Do you find these translation problems in other languages too?

Hi there.  Yes, definitely!  Not all translations are 100% up-to-date.
Most are not, in fact.  Our project is maintained by volunteers, who
come and go, and have various amounts of free time to help
(or interest in helping).

While it requires a manual process being run on the webserver, I do my
best to keep the translation statistics (and mirrored copies of the
gettext ".po" files) updated, over on this page of the website:

  https://tuxpaint.org/help/po/

The Greek translation of the Tux Paint app itself (at this point, what
will become 0.9.28, which is still a work in progress, as I and others
add new features) is currently at about 85% completion.  It was last
updated back in September (about 4 months ago).

The Greek translation of the Stamps collection of artwork is much more
complete (but we have also not added many new stamps in a very long time).
It's just under 100% complete.

Similar to Tux Paint itself, the Greek translation of the "Tux Paint Config."
tool is about 85% complete.

The translation files for the website were very recently split into two parts.
I made a decision on which pages are "high-priority" versus "low-priority",
in terms of a translation being necessary at all.  Greek is at 50% and 23%
completion rates for those, respectively.

Finally, in the past year or so, I completely reworked Tux Paint's documentation
to be driven by gettext-translatable PHP files, which are then built into
individual HTML files (one per locale).  There is _no_ Greek translation of
the documentation, at this time.

If you'd like to help, or know someone who can, please feel free!
(A little more info is also provided on https://tuxpaint.org/help/)

Take care,

--
-bill!
Sent from my computer


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

Re: [Tuxpaint-devel] Translation in tux paint for v0.9.27

[ΑΡΕΤΗ Τ. <tso...@gm...>]

Hi,
I understand everything you said.
Do you thing that this issue needs to be written in a new ticket or not?

Thanks.


Στις Τετ, 26 Ιαν 2022, 23:30 ο χρήστης Bill Kendrick <nb...@so...> έγραψε:

> On Wed, Jan 26, 2022 at 04:28:48PM +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote:
> > Hello again,
> >
> > I was testing if the translation in Greek works appropriately in as many
> > cases as possible. What I figured out was that:
> >
> > a) when I pick "shapes", the mascot's words on the bottom of the window
> are
> > not translated in greek
> > b) when I pick "fill", the mascot's words on the bottom of the window are
> > not translated in greek (just like in "shapes"), and the options of
> filling
> > in the right part of the window are not translated in greek either.
> >
> >
> > Do you find these translation problems in other languages too?
>
> Hi there.  Yes, definitely!  Not all translations are 100% up-to-date.
> Most are not, in fact.  Our project is maintained by volunteers, who
> come and go, and have various amounts of free time to help
> (or interest in helping).
>
> While it requires a manual process being run on the webserver, I do my
> best to keep the translation statistics (and mirrored copies of the
> gettext ".po" files) updated, over on this page of the website:
>
>   https://tuxpaint.org/help/po/
>
> The Greek translation of the Tux Paint app itself (at this point, what
> will become 0.9.28, which is still a work in progress, as I and others
> add new features) is currently at about 85% completion.  It was last
> updated back in September (about 4 months ago).
>
> The Greek translation of the Stamps collection of artwork is much more
> complete (but we have also not added many new stamps in a very long time).
> It's just under 100% complete.
>
> Similar to Tux Paint itself, the Greek translation of the "Tux Paint
> Config."
> tool is about 85% complete.
>
> The translation files for the website were very recently split into two
> parts.
> I made a decision on which pages are "high-priority" versus "low-priority",
> in terms of a translation being necessary at all.  Greek is at 50% and 23%
> completion rates for those, respectively.
>
> Finally, in the past year or so, I completely reworked Tux Paint's
> documentation
> to be driven by gettext-translatable PHP files, which are then built into
> individual HTML files (one per locale).  There is _no_ Greek translation of
> the documentation, at this time.
>
> If you'd like to help, or know someone who can, please feel free!
> (A little more info is also provided on https://tuxpaint.org/help/)
>
> Take care,
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

[雷阳 <lei...@16...>]

Hi, bill,


I just found the reproducible step:
1. in settings, check 'simplification' - 'show upper case text only'. this is default. if unchecked, text shows correctly.
2. env: win10 (also win11). 0.9.27(actually reproduciable since at least 0.9.25)







Regards,
Yang




At 2022-01-28 12:44:39, "Bill Kendrick" <nb...@so...> wrote:
>On Thu, Jan 27, 2022 at 07:37:23AM +0800, ���� wrote:
>> Hi I also found some icon text missing in some recent versions, but it wasn't blocking issue since i already knew what the icons mean in old version.
>
>Hi, can you tell me what version of Tux Paint you're on, and
>which operating system?  I tried "tuxpaint --lang chinese"
>and see all of the expected strings.  (This is on Linux
>using the Git repo version, which will become 0.9.28.)
>
>I wonder if perhaps there's a deficiency in the font being
>utilized for Chinese strings in your system...?
>
>(Usually, when a string is untranslated, you'll see the
>English version found in the source-code.  I don't believe
>any strings have been explicitly translated to 'nothing' (""),
>in other words. :) )
>
>Thanks in advance,
>
>-bill!
>
>
>_______________________________________________
>Tuxpaint-users mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-users

Re: [Tuxpaint-devel] Some recent improvements

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

On Thu, Jan 27, 2022 at 03:43:16PM -0800, Bill Kendrick wrote:
> 
> Following-up... last night I began work on a new color selection tool,
> which is allows you to mix (combine) Red[*], Yellow, Blue[*],
> White, Gray/Grey, and Black, to come up with new colors, just as you
> would using real paints or pastel chalk!

I've improved this a bunch this evening, having it average the
colors more correctly every time you add one.  (Before, it was
taking the current color, and adding some of the new one.
This lead to Red+Yellow+Blue resulting in a different
color than Red+Blue+Yellow, Yellow+Blue+Red, etc.!)

(GIF: https://twitter.com/TuxPaintTweets/status/1486978095475134464)


I've also added multiple levels of Undo/Redo.  Please test it out
and let me know if you come across any bugs!

(Video: https://twitter.com/TuxPaintTweets/status/1486996877396434944)


Finally, the color proportions shown at the bottom
(e.g., "Your color is 1/3 red, 1/3 yellow, and 1/3 blue")
will now show simplified fractions as alternatives, when possible.
For example:

  Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/5 black.

(Video: https://twitter.com/TuxPaintTweets/status/1487005339312553984)


Enjoy!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] [Tuxpaint-users] Translation in tux paint for v0.9.27

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

On Thu, Jan 27, 2022 at 07:37:23AM +0800, ���� wrote:
> Hi I also found some icon text missing in some recent versions, but it wasn't blocking issue since i already knew what the icons mean in old version.

Hi, can you tell me what version of Tux Paint you're on, and
which operating system?  I tried "tuxpaint --lang chinese"
and see all of the expected strings.  (This is on Linux
using the Git repo version, which will become 0.9.28.)

I wonder if perhaps there's a deficiency in the font being
utilized for Chinese strings in your system...?

(Usually, when a string is untranslated, you'll see the
English version found in the source-code.  I don't believe
any strings have been explicitly translated to 'nothing' (""),
in other words. :) )

Thanks in advance,

-bill!

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

On Thu, 27 Jan 2022 21:18:12 +0100, Pere Pujal i Carabantes wrote:
>El dj. 27 de 01 de 2022 a les 19:01 +0900, en/na Shin-ichi TOYAMA va escriure:
>> > El dg. 23 de 01 de 2022 a les 23:53 +0900, en/na Shin-ichi TOYAMA va escriure:
>> > > Hi!
>> > > 
>> > > I recently noticed that translation of SDL2 version become not working after updating the packages of MinGW/MSYS2 development environment.
>> > > 
>> > > I also confirmed the same problem occurs with the build environment constructed from the scratch.
>> > > 
>> > > Notable difference in the latest environment seems to be that the version of gettext became 0.9.21 from 0.9.18.
>> 
>> Woops! This was wrong.
>> It was updated to 0.21 from 0.19.8.1
>> 
>> > > Fortunately, I have kept a backup of the previous development tree before updating, it's not a problem so far, but I would like to specify the problem and get rid of it.
>> 
>> On Thu, 27 Jan 2022 01:01:42 +0100, Pere Pujal i Carabantes wrote:
>> > The only thing that I get different from you is that I get no translations in *any* branch,
>> > this is with an updated environent(as oposed to build from scratch)
>> 
>> Confirmed on Windows 10.
>> 
>> On Windows 11, build on main branch does not translate at first, but strangely enough, it DOES translate from the second time execution after the boot. However build on sdl2 branch never translate.
>> 
>> It looks like some problem regarding library loading, doesn't it?
>> 
>
>Looks like so, I've found something that looks weird to me:
>
>in the msys shell: pacman -S gettext-devel says 0.19.8.1-1 is uptodate 
>and offers to reinstall it, it doesn't offer 0.9.21
>gettext --version also is 0.19.8.1
>
>In the mingw64 shell pacman -S gettext-devel also says 0.19.8.1-1 is uptodate
>but gettext is 0.21
>
>I really don't know if this version mismatch is correct or not

Please take note that you have

 *) Basic tools of MSYS2 under /usr
 *) 64 bit MinGW devel tools under /mingw64
 *) 32 bit MinGW devel tools under /mingw32

Then you must have

 * /usr/bin/gettext which belongs to the package 'gettext'
 * /mingw64/bin/gettext which belongs to the package 'mingw-w64-x86_64-gettext'
 * /mingw32/bin/gettext which belongs to the package 'mingw-w64-i686-gettext'

Please try a package search command like 

 $ pacman -Ss gettext

and see your command search path. Then you will see what is happening.

By the way, I tested to update ONLY mingw-w64-x86_64-gettext and confirmed the
problem reproduces.

Considering that there is no problem with tuxpaint-config, there must be some
way to solve this problem.

Hrm...

Re: [Tuxpaint-devel] Some recent improvements

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

Following-up... last night I began work on a new color selection tool,
which is allows you to mix (combine) Red[*], Yellow, Blue[*],
White, Gray/Grey, and Black, to come up with new colors, just as you
would using real paints or pastel chalk!

[*] The red & blue are closer to magenta & cyan, respectively, to
    space them more equally around the 360-degrees of the color circle.
    We're looking at the colors more from a CMYK standpoint than RGB.
    This tool uses the HSV values of the colors and shades, and
    averages them (taking 2/3rd of the current color, and adding the
    color you picked to make up the other 1/3rd)

Right now it works, and I encourage you to play with it!  At any time,
you can use the 'trash' button to erase the color and start over.
(You don't start with any particular color.  It's simply in a state
where the first color you add gets applied 100% (3/3rd) to your
target color.)

Here's a short video demonstrating it, over on Twitter:

  https://twitter.com/TuxPaintTweets/status/1486651478903123971


Since you need to interact with it a bit more than the other two
special color selection tools (the "color picker" aka rainbow palette,
and the "color selector" aka pipette tool for grabbing a color from
the canvas), it has both a "Back" button, as well as a green checkmark
button you use to indicate that you're done mixing.

While this all works and is "production ready", I'd really like to add
Undo/Redo buttons to it, to allow you to correct a mistake.
Say, for example, you want Red+Red+Red+Yellow+Grey, but you accidentally
click White at the end.  Rather than having to start over, I'd like
you to be be able to hit Undo, and get back to the R+R+R+Y state.

I'm guessing this will prove tricky, but I've been on a roll lately,
so I may be able to get it going this evening!  I'll try my best
(as usual) to not commit anything that's totally broken / not working.
(I guess this is why people invented branches? :-D )

Enjoy & tell me what you think!

So far, the response I've seen on Twitter, my personal Facebook, and
from my wife, have been:

 * this is the first time i've seen this concept put into something,
   very cool addition

 * Okay, this is cool because it is not "open source kids' drawing
   app trying to be professional art sofware" it's a color theory lesson.

 * That is a super cool idea.

Yay :)


-bill!

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

El dj. 27 de 01 de 2022 a les 19:01 +0900, en/na Shin-ichi TOYAMA va escriure:
> > El dg. 23 de 01 de 2022 a les 23:53 +0900, en/na Shin-ichi TOYAMA va escriure:
> > > Hi!
> > > 
> > > I recently noticed that translation of SDL2 version become not working after updating the packages of MinGW/MSYS2 development environment.
> > > 
> > > I also confirmed the same problem occurs with the build environment constructed from the scratch.
> > > 
> > > Notable difference in the latest environment seems to be that the version of gettext became 0.9.21 from 0.9.18.
> 
> Woops! This was wrong.
> It was updated to 0.21 from 0.19.8.1
> 
> > > Fortunately, I have kept a backup of the previous development tree before updating, it's not a problem so far, but I would like to specify the problem and get rid of it.
> 
> On Thu, 27 Jan 2022 01:01:42 +0100, Pere Pujal i Carabantes wrote:
> > The only thing that I get different from you is that I get no translations in *any* branch,
> > this is with an updated environent(as oposed to build from scratch)
> 
> Confirmed on Windows 10.
> 
> On Windows 11, build on main branch does not translate at first, but strangely enough, it DOES translate from the second time execution after the boot. However build on sdl2 branch never translate.
> 
> It looks like some problem regarding library loading, doesn't it?
> 

Looks like so, I've found something that looks weird to me:

in the msys shell: pacman -S gettext-devel says 0.19.8.1-1 is uptodate 
and offers to reinstall it, it doesn't offer 0.9.21
gettext --version also is 0.19.8.1

In the mingw64 shell pacman -S gettext-devel also says 0.19.8.1-1 is uptodate
but gettext is 0.21

I really don't know if this version mismatch is correct or not

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

>El dg. 23 de 01 de 2022 a les 23:53 +0900, en/na Shin-ichi TOYAMA va escriure:
>> Hi!
>> 
>> I recently noticed that translation of SDL2 version become not working after updating the packages of MinGW/MSYS2 development environment.
>> 
>> I also confirmed the same problem occurs with the build environment constructed from the scratch.
>> 
>> Notable difference in the latest environment seems to be that the version of gettext became 0.9.21 from 0.9.18.

Woops! This was wrong.
It was updated to 0.21 from 0.19.8.1

>> Fortunately, I have kept a backup of the previous development tree before updating, it's not a problem so far, but I would like to specify the problem and get rid of it.

On Thu, 27 Jan 2022 01:01:42 +0100, Pere Pujal i Carabantes wrote:
>The only thing that I get different from you is that I get no translations in *any* branch,
>this is with an updated environent(as oposed to build from scratch)

Confirmed on Windows 10.

On Windows 11, build on main branch does not translate at first, but strangely enough, it DOES translate from the second time execution after the boot. However build on sdl2 branch never translate.

It looks like some problem regarding library loading, doesn't it?

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

Re: [Tuxpaint-devel] *SDL2* translation does not work on the latest MinGW/MSYS2

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

El dg. 23 de 01 de 2022 a les 23:53 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> I recently noticed that translation of SDL2 version become not working after updating the packages of MinGW/MSYS2 development environment.
> 
> I also confirmed the same problem occurs with the build environment constructed from the scratch.
> 
> Notable difference in the latest environment seems to be that the version of gettext became 0.9.21 from 0.9.18.
> 
> There must be some problem specific to the SDL2 version because SDL1 version of Tux Paint and tuxpaint-config has no problem with the updated environment.
> 
> Fortunately, I have kept a backup of the previous development tree before updating, it's not a problem so far, but I would like to specify the problem and get rid of it.
> 
> Hoping any suggestion from you all.
> 
> Thanks.
> 

Hi, Thanks for the warning, I wouldn't have kept a backup of my MinGW/MSYS environment without it.

I'be been a couple of days trying to debug but haven't found anything relevant, sorry.

The only thing that I get different from you is that I get no translations in *any* branch,
this is with an updated environent(as oposed to build from scratch)

Will investigate further

Thanks
Pere