tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

By the way, workaround for this is to set language to something 
other than (Use system's setting) by tuxpaint-config, so far.

TOYAMA Shin-ichi wrote in <61758024.4995%sh...@wm...>
>Well, I may have found a clue.
>It had nothing to do with the priviledges.
>
>The problem is that 64bit version runs on my account and does not 
>run on the other user's account.
>
>Difference between two users were environmental variable.
>I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has
>not been set on the other user's account.
>
>Then, I tested 64bit package by unsetting 'LANG' on my account,
>and found it does not start. (Strangely 32 bit version starts with 
>no problem....)
>
>The worse is that this problem has nothing to do with the recent 
>changes in source code, but seems to related with some change in 
>tha latest MinGW/MSYS environment, because now I never be able to 
>build 64bit package which runs on the other account even using 
>original tar-ball of version 0.9.26.
>
>You see the first release of 64bit 0.9.26 does not have this 
>problem. (Although it has crash bug regarding osk and label)
>
>Bill, 
>
>Could you test on your son's PC to set LANG to "C" or something in 
>"advanced system properties" dialogue?
>
>  http://www.tenuser.com/spec/properties.htm
>
>(you need to sign out and sign in again after changin system properties)
>
>
>
>TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...>
>>Bill Kendrick wrote in <202...@sh...>
>>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
>>>nothing happens.  No window appears at all.
>>
>>It reproduced by lounching TuxPaint from anoter user who does not 
>>have administrator priviledge.
>>
>>I will have to look into it.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Well, I may have found a clue.
It had nothing to do with the priviledges.

The problem is that 64bit version runs on my account and does not 
run on the other user's account.

Difference between two users were environmental variable.
I have set 'LANG' environmet variable as ja_JP.UTF-8 and LANG has
not been set on the other user's account.

Then, I tested 64bit package by unsetting 'LANG' on my account,
and found it does not start. (Strangely 32 bit version starts with 
no problem....)

The worse is that this problem has nothing to do with the recent 
changes in source code, but seems to related with some change in 
tha latest MinGW/MSYS environment, because now I never be able to 
build 64bit package which runs on the other account even using 
original tar-ball of version 0.9.26.

You see the first release of 64bit 0.9.26 does not have this 
problem. (Although it has crash bug regarding osk and label)

Bill, 

Could you test on your son's PC to set LANG to "C" or something in 
"advanced system properties" dialogue?

  http://www.tenuser.com/spec/properties.htm

(you need to sign out and sign in again after changin system properties)



TOYAMA Shin-ichi wrote in <6175505b.4994%sh...@wm...>
>Bill Kendrick wrote in <202...@sh...>
>>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
>>nothing happens.  No window appears at all.
>
>It reproduced by lounching TuxPaint from anoter user who does not 
>have administrator priviledge.
>
>I will have to look into it.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Bill Kendrick wrote in <202...@sh...>
>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
>nothing happens.  No window appears at all.

It reproduced by lounching TuxPaint from anoter user who does not 
have administrator priviledge.

I will have to look into it.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

[Tuxpaint-devel] Almost all compiler warnings addressed!

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

I've cleaned up a bunch of code here and there that were
throwing warnings when I compile Tux Paint, and am down
to just the following...

When I build Tux Paint (make clean && make) from Git master
on my Ubuntu 20.04.3 LTS system, which comes with
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, I now only get
these warnings:

In file included from /usr/include/string.h:495,
                 from src/tuxpaint.c:182:
In function ‘strncpy’,
    inlined from ‘trash’ at src/tuxpaint.c:26826:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 255 bytes from a string of length 255 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and:

src/parse.gperf: In function ‘parse_one_option’:
src/parse.gperf:306:45: warning: argument to ‘sizeof’ in ‘memcpy’ call is the same pointer type ‘char *’ as the destination; expected ‘char’ or an explicit length [-Wsizeof-pointer-memaccess]
  306 |   memcpy(offset+(char*)tmpcfg, &opt, sizeof(char*)); /* FIXME: This causes a warning; should it be 'sizeof(char)', or do we need to have the warning suppressed? -bjk 2021.10.14 */
      |                                             ^~~~


I'm hesitant to mess with either of them (especially at 1:30am
in the morning :) ), so I'm going to leave it at that, for now.
Any assistance from better-at-C-than-me folks would be appreciated!

And of course, let me know whether any of my tweaks this evening
had unintended consiquences for anyone!

Off to bed,

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Another new magic tool: Stretch

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

I had the idea for a Magic tool that lets you stretch
and squash parts of your picture, kind of like a fun-house
mirror.

I've added it, and you can try it out in master branch from
the Git repo.

Here's a short video I showed of it over on Twitter:

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

Tell me what you think, and if you notice any issues.
Thanks & enjoy!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Fill -> Brush mode

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

I've added a new "Brush" mode to the Fill tool.

It's for filling solid colors, like the classic "Solid" mode,
but it's for filling a constrained area using freehand brush strokes.

(Since the UI in Tux Paint is simplified, it uses the standard
32-pixel diameter circle that we use in many Magic tools.
Want something more sophisticated?  Use Gimp or Krita ;) )

Anyway, feel free to "git pull" and try it out.  Let me know if
you notice any bugs or performance issues with it.

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Not requiring end-users to _accept_ the GPL

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

On Sun, Oct 17, 2021 at 11:02:30PM +0900, TOYAMA Shin-ichi wrote:
> TOYAMA Shin-ichi wrote in <616c207c.4980%sh...@wm...>
> >So, what shall we do ?
> 
> Hehe, by setting COPYING.txt to "InfoBeforeFile" parameter, Setup 
> shows it as follows with only "Next" and "Cancel" buttons.

Awesome, thank you! :)

-bill!

Re: [Tuxpaint-devel] Not requiring end-users to _accept_ the GPL

[TOYAMA Shin-i. <sh...@wm...>]

TOYAMA Shin-ichi wrote in <616c207c.4980%sh...@wm...>
>So, what shall we do ?

Hehe, by setting COPYING.txt to "InfoBeforeFile" parameter, Setup 
shows it as follows with only "Next" and "Cancel" buttons.

     Setup - Tux Paint 0.9.27

      Information
        Please read the following important information before continuing.
    ------------------------------------------------------------------------
        When you are ready to continue with Setup, click Next.

        ---------------------------------
       | COPYING.txt for Tux Paint
       |
       |Tux Paint - A simple drawing program for children.
       |

Commited to the git.

Thanks.

TOYAMA Shin-ichi wrote in <616c207c.4980%sh...@wm...>
>Bill,
>
>I took a quick look at the Inno Setup Documentation.
>
>It says as follows
>
>  License Agreement
>  Shown if LicenseFile is set. Users may proceed to the next page 
>  only if the option "I accept the agreement" is selected. 
>
>in https://jrsoftware.org/ishelp/topic_wizardpages.htm
>
>So I think the only thing we can do is to remove the setting for 
>"LicenseFile" parameter so that it does not bring up the page
>showing the license.
>
>By the way, incidentally, due to my mistake in a recent change to 
>the tuxpaint.iss, we now have the above situation in the current 
>git repo.
>
>License agreement page will come again by adding 
>"LicenseFile={#BdistDir}\{#AppLicense}" to the [Setup] section.
>
>So, what shall we do ?
>
>Thanks.
>
>Bill Kendrick wrote in <202...@sh...>
>>A big complaint from people in-the-know out there (e.g., Foone over on
>>Twitter) is that a lot of open source software seems to require the
>>end user to accept the terms of the GNU General Public License, when
>>their _use_ of the software is not really affected by it.
>>
>>It's the _redistribution_ of any modified version of the software
>>that would be covered by the GPL.
>>
>>So there's a recommendation to remove the "You must accept the terms..."
>>wording, and not force the user to choose "I accept the agreement" to
>>proceed with the installation.  Simply have "Next" and "Cancel" buttons.
>>
>>Shin-ichi (or anyone else familiar with Inno Setup), is there a way
>>we can configure our ISS file to make the Tux Paint installer program
>>do this?
>>
>>Thanks!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Not requiring end-users to _accept_ the GPL

[TOYAMA Shin-i. <sh...@wm...>]

Bill,

I took a quick look at the Inno Setup Documentation.

It says as follows

  License Agreement
  Shown if LicenseFile is set. Users may proceed to the next page 
  only if the option "I accept the agreement" is selected. 

in https://jrsoftware.org/ishelp/topic_wizardpages.htm

So I think the only thing we can do is to remove the setting for 
"LicenseFile" parameter so that it does not bring up the page
showing the license.

By the way, incidentally, due to my mistake in a recent change to 
the tuxpaint.iss, we now have the above situation in the current 
git repo.

License agreement page will come again by adding 
"LicenseFile={#BdistDir}\{#AppLicense}" to the [Setup] section.

So, what shall we do ?

Thanks.

Bill Kendrick wrote in <202...@sh...>
>A big complaint from people in-the-know out there (e.g., Foone over on
>Twitter) is that a lot of open source software seems to require the
>end user to accept the terms of the GNU General Public License, when
>their _use_ of the software is not really affected by it.
>
>It's the _redistribution_ of any modified version of the software
>that would be covered by the GPL.
>
>So there's a recommendation to remove the "You must accept the terms..."
>wording, and not force the user to choose "I accept the agreement" to
>proceed with the installation.  Simply have "Next" and "Cancel" buttons.
>
>Shin-ichi (or anyone else familiar with Inno Setup), is there a way
>we can configure our ISS file to make the Tux Paint installer program
>do this?
>
>Thanks!


-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

El dg. 17 de 10 de 2021 a les 01:04 -0700, en/na Bill Kendrick va escriure:
> On Sun, Oct 17, 2021 at 12:01:51AM -0700, Bill Kendrick wrote:
> > On Sat, Oct 16, 2021 at 04:15:39PM +0200, Pere Pujal i Carabantes wrote:
> > <snip>
> > > As far as I've tested it works fine in W10:
> > > No need to enable compatibility to W8 to make it running.
> > > No crashes with labels.
> > > No crashes with onscreen keyboard.
> > > Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted.
> > > 
> > > BIG THANKS :)
> > 
> > Big thanks indeed!!!  Sorry I haven't been helping more; while I have
> > (limited ;) ) access to my kids' Windows laptops, I don't yet have
> > any development stuff installed on either of them.  Also, I've been
> > knocked out a bit due to a wisdom tooth that needs removal.  X^[
> > 
> > So I'm very glad you all were able to sort it out!  Thanks again,
> 
> Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
> nothing happens.  No window appears at all.  I tried using the
> "troubleshoot compatibility" option, and it suggested Windows 8 mode,
> but running the test did nothing.  I tried running as administrator,
> and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint,
> but they are both empty.
> 
> I tried uninstalling and re-installing completely (vs. installing over
> the existing version), but that didn't help.
> 
> I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\
> out of the way (renamed to "TuxPaintXYZ") and launching again.
> Tux Paint got as far as creating a new "TuxPaint" folder in there, but
> 
> Settings -> System -> About says it's a 64-bit OS, with x64-based processor.
> Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features
> Experience Pack 120.2212.3920.0.
> 
> I WAS able to get the i686 32-bit version to install and run.
> 
> So, yikes, this might not be working properly, still!?
> 

Did you by chance install 0.9.26-5 64bit just to current user or to all users?
I've just found stalled direct accesses on the screen who still points to
C:\Program Files (x86)\TuxPaint when, if installed to current user, Tux Paint 
is in C:\Users\USERNAME\Programs\TuxPaint.
Or maybe the inverse?

Otherwise, Tux Paint runs fine here,
This is in an vboxed W10
Edición	Windows 10 Home
Versión	20H2
Instalado el	‎28/‎12/‎2020
Compilación del sistema operativo	19042.1237
Experiencia	Windows Feature Experience Pack 120.2212.3530.0

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

So bad...

I am almost exhousted.
Sorry about that, but please give me some more time.

Bill Kendrick wrote in <202...@sh...>
>Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
>nothing happens.  No window appears at all.  I tried using the
>"troubleshoot compatibility" option, and it suggested Windows 8 mode,
>but running the test did nothing.  I tried running as administrator,
>and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint,
>but they are both empty.
>
>I tried uninstalling and re-installing completely (vs. installing over
>the existing version), but that didn't help.
>
>I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\
>out of the way (renamed to "TuxPaintXYZ") and launching again.
>Tux Paint got as far as creating a new "TuxPaint" folder in there, but
>
>Settings -> System -> About says it's a 64-bit OS, with x64-based processor.
>Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features
>Experience Pack 120.2212.3920.0.
>
>I WAS able to get the i686 32-bit version to install and run.
>
>So, yikes, this might not be working properly, still!?

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Hi,

TOYAMA Shin-ichi wrote in <616ba929.4976%sh...@wm...>
>Until now, I have just ignored such warnings when compiling 
>TuxPaint on windows, but it might be better to look them more 
>carefully and try to reduce warnings as possible I can.

So, I have overviewed many warnings when compiling on MinGW/MSYS.

Most of the warnings are,

 * impllicit declaration
 * unused variable
 * variable xxx set but not used
 * comparison of distinct pointer types lacks a cast
   - which comes from macro min()/max() in tp_magic_api.h

I think these are not so harmful so far.

Then, I will show you other warnings which does not appear
when compiling on linux only for tuxpaint.c so far, for which
I am not sure if I could leave it as it is.

Escpecially the first one may break some important logic?

Please let me know if you find something I have to do.

------------------------------------------------------------
[1]
src/tuxpaint.c: In function 'render_text_w':
src/tuxpaint.c:1679:27: warning: comparison is always true due to limited range of data type [-Wtype-limits]
 1679 |           else if (str[i] <= 0x0000FFFF)
      |                           ^~

[2]
src/tuxpaint.c: In function 'do_png_embed_data':
src/tuxpaint.c:14571:41: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
14571 |                   iconv(trans, (char **)&wch, &in, &conv, &out);
      |                                         ^~~~

[3]
src/tuxpaint.c: In function 'load_magic_plugins':
src/tuxpaint.c:19206:38: warning: assignment to 'Uint32 (*)(SDL_Surface *, int,  int)' {aka 'unsigned int (*)(SDL_Surface *, int,  int)'} from incompatible pointer type 'void (*)(SDL_Surface *, int,  int)' [-Wincompatible-pointer-types]
19206 |           magic_api_struct->xorpixel = magic_xorpixel;
      |                                      ^

[4]
src/tuxpaint.c: In function 'trash':
src/tuxpaint.c:25956:40: warning: unknown conversion type character 'F' in format [-Wformat=]
25956 |   strftime(deldate, sizeof(deldate), "%FT%T", &tim);
      |                                        ^
src/tuxpaint.c:25956:43: warning: unknown conversion type character 'T' in format [-Wformat=]
25956 |   strftime(deldate, sizeof(deldate), "%FT%T", &tim);
      |                                           ^

[5]
In function 'safe_strncpy',
    inlined from 'trash' at src/tuxpaint.c:25883:3:
src/tuxpaint.c:26820:9: warning: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Wstringop-truncation]
26820 |   ptr = strncpy(dest, src, n - 1);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Hi,

I investigated more to understand why this happened by checking 
original 0.9.26's code.

In old build system for Windows 2000/XP,
----------------
msys:$ make obj/onscreen_keyboard.o

...Compiling on screen keyboard support...
msys:$
----------------

You see no warning and no error.

However, in the latest MinGW/MSYS2 build environment,
----------------
mingw64:$ make obj/onscreen_keyboard.o

...Compiling on screen keyboard support...
src/onscreen_keyboard.c: In function 'mtw':
src/onscreen_keyboard.c:76:16: warning: passing argument 2 of 'libiconv' from 
incompatible pointer type [-Wincompatible-pointer-types]
   76 |   iconv(trans, (const char **)&tok, &in, &wrptr, &out);
      |                ^~~~~~~~~~~~~~~~~~~
      |                |
      |                const char **
In file included from src/onscreen_keyboard.c:55:
C:/msys64/mingw64/include/iconv.h:82:43: note: expected 'char **' but argument 
is of type 'const char **'
   82 | extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, 
char* * outbuf, size_t *outbytesleft);
      |                                   ~~~~~~~~^~~~~
src/onscreen_keyboard.c:78:18: warning: passing argument 2 of 'swprintf' makes 
integer from pointer without a cast [-Wint-conversion]
   78 |   swprintf(wtok, L"%ls", ui16);
      |                  ^~~~~~
      |                  |
      |                  const short unsigned int *
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/wchar.h:1192,
                 from src/onscreen_keyboard.h:1,
                 from src/onscreen_keyboard.c:23:
C:/msys64/mingw64/x86_64-w64-mingw32/include/swprintf.inl:34:41: note: expected 
'size_t' {aka 'long long unsigned int'} but argument is of type 'const short 
unsigned int *'
   34 | int swprintf (wchar_t *__stream, size_t __count, const wchar_t 
*__format, ...)
      |                                  ~~~~~~~^~~~~~~
src/onscreen_keyboard.c:66:10: warning: variable 'n' set but not used 
[-Wunused-but-set-variable]
   66 |   size_t n, in, out;
      |          ^
mingw64:$
----------------

Interestingly, changing the second argument of 'swprintf()' to 
the integer valiable results completely the opposite.

This result says that the type of second argument to swprintf() 
becomes completely different in MinGW/MSYS2.

Although I am not sure why this works on Windows 8 and before, 
it must be one of the reason for the crash on Windows10.

And you see another warning regarding iconv() which is now 
unused in onscreen_keyboard.c but still used in tuxpaint.c

Until now, I have just ignored such warnings when compiling 
TuxPaint on windows, but it might be better to look them more 
carefully and try to reduce warnings as possible I can.

Thanks!

TOYAMA Shin-ichi wrote in 
<616b70f2.4975%sh...@wm...>
>Hi Bill,
>
>Pere Pujal i Carabantes wrote in 
><041...@gm...>
>>> Packages compiled as 0.9.26-5 are available in 
>>> 
>>>  https://z1.plala.jp/tuxpaint/release/0.9.26-5/  (5!!)
>>> 
>>> Could you give them final tests ?
>>> I pray that this will work out this time.
>>
>>As far as I've tested it works fine in W10:
>>No need to enable compatibility to W8 to make it running.
>>No crashes with labels.
>>No crashes with onscreen keyboard.
>>Drawings can be exported/imported from/to Linux/Windows without
>>labels being corrupted.
>
>So, I believe  those two crash bug on windows10  have been fixed 
>finally.
>
>By the way, patched 0.9.26 also compiled on the old build system
>for 2000 and XP, but it did not run.
>Then, I think that  the initial tweak for windows on the OSK was
>not a mistake.
>
>I guess that this bug has been existing since when I changed the 
>build system to MinGW/MSYS2 and become apparent in Windows10.
>
>I think  every windows user, except XP/2000,  would be suggested
>to upgrade to 0.9.26-5.
>
>Thanks.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

On Sun, Oct 17, 2021 at 12:01:51AM -0700, Bill Kendrick wrote:
> On Sat, Oct 16, 2021 at 04:15:39PM +0200, Pere Pujal i Carabantes wrote:
> <snip>
> > As far as I've tested it works fine in W10:
> > No need to enable compatibility to W8 to make it running.
> > No crashes with labels.
> > No crashes with onscreen keyboard.
> > Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted.
> > 
> > BIG THANKS :)
> 
> Big thanks indeed!!!  Sorry I haven't been helping more; while I have
> (limited ;) ) access to my kids' Windows laptops, I don't yet have
> any development stuff installed on either of them.  Also, I've been
> knocked out a bit due to a wisdom tooth that needs removal.  X^[
> 
> So I'm very glad you all were able to sort it out!  Thanks again,

Hum, so I installed 0.9.26-5 via the installer EXE, but when I launch it,
nothing happens.  No window appears at all.  I tried using the
"troubleshoot compatibility" option, and it suggested Windows 8 mode,
but running the test did nothing.  I tried running as administrator,
and I saw "stderr" and "stdout" files appear in C:\Program Files (x86)\TuxPaint,
but they are both empty.

I tried uninstalling and re-installing completely (vs. installing over
the existing version), but that didn't help.

I tried moving the "TuxPaint" folder in C:\Users\USERNAME\AppData\Roaming\
out of the way (renamed to "TuxPaintXYZ") and launching again.
Tux Paint got as far as creating a new "TuxPaint" folder in there, but

Settings -> System -> About says it's a 64-bit OS, with x64-based processor.
Windows 10 Home, version 20H2, OS Build 19042.1288, with Windows Features
Experience Pack 120.2212.3920.0.

I WAS able to get the i686 32-bit version to install and run.

So, yikes, this might not be working properly, still!?

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Not requiring end-users to _accept_ the GPL

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

A big complaint from people in-the-know out there (e.g., Foone over on
Twitter) is that a lot of open source software seems to require the
end user to accept the terms of the GNU General Public License, when
their _use_ of the software is not really affected by it.

It's the _redistribution_ of any modified version of the software
that would be covered by the GPL.

So there's a recommendation to remove the "You must accept the terms..."
wording, and not force the user to choose "I accept the agreement" to
proceed with the installation.  Simply have "Next" and "Cancel" buttons.

Shin-ichi (or anyone else familiar with Inno Setup), is there a way
we can configure our ISS file to make the Tux Paint installer program
do this?

Thanks!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

On Sat, Oct 16, 2021 at 04:15:39PM +0200, Pere Pujal i Carabantes wrote:
<snip>
> As far as I've tested it works fine in W10:
> No need to enable compatibility to W8 to make it running.
> No crashes with labels.
> No crashes with onscreen keyboard.
> Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted.
> 
> BIG THANKS :)

Big thanks indeed!!!  Sorry I haven't been helping more; while I have
(limited ;) ) access to my kids' Windows laptops, I don't yet have
any development stuff installed on either of them.  Also, I've been
knocked out a bit due to a wisdom tooth that needs removal.  X^[

So I'm very glad you all were able to sort it out!  Thanks again,

-bill!

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Hi Bill,

Pere Pujal i Carabantes wrote in <041...@gm...>
>> Packages compiled as 0.9.26-5 are available in 
>> 
>>  https://z1.plala.jp/tuxpaint/release/0.9.26-5/  (5!!)
>> 
>> Could you give them final tests ?
>> I pray that this will work out this time.
>
>As far as I've tested it works fine in W10:
>No need to enable compatibility to W8 to make it running.
>No crashes with labels.
>No crashes with onscreen keyboard.
>Drawings can be exported/imported from/to Linux/Windows without
>labels being corrupted.

So, I believe  those two crash bug on windows10  have been fixed 
finally.

By the way, patched 0.9.26 also compiled on the old build system
for 2000 and XP, but it did not run.
Then, I think that  the initial tweak for windows on the OSK was
not a mistake.

I guess that this bug has been existing since when I changed the 
build system to MinGW/MSYS2 and become apparent in Windows10.

I think  every windows user, except XP/2000,  would be suggested
to upgrade to 0.9.26-5.

Thanks.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

Hi everybody,

El ds. 16 de 10 de 2021 a les 22:11 +0900, en/na TOYAMA Shin-ichi va escriure:
> # Cc'ing to Vincent who kindly gave us crash reports.
> 
> Hi, Pere
> 
> Thank you for testing the FixOSK version.
> It still has crash bug here as follows;
> 
>   * Launch it, draw label, save and quit.
>   * Launch it again.
>   * Crash ;-<
> 
> I have carefully reviewed mtw() in tuxpaint.c and made some 
> changes (patch attached), which works fine here.
> 
> Packages compiled as 0.9.26-5 are available in 
> 
>  https://z1.plala.jp/tuxpaint/release/0.9.26-5/  (5!!)
> 
> Could you give them final tests ?
> I pray that this will work out this time.

As far as I've tested it works fine in W10:
No need to enable compatibility to W8 to make it running.
No crashes with labels.
No crashes with onscreen keyboard.
Drawings can be exported/imported from/to Linux/Windows withouth labels being corrupted.

BIG THANKS :)

Pere


> 
> Hi Vincent!
> 
> Although you reported me that you could run official release 
> 0.9.26 by removing user's directory and re-installing it, it surly 
> has problems regarding onscreen keyboard and labels.
> 
> Now I believe we are almost close to the final solution.
> Please wait a little more until next bugfix version released.
> 
> Sorry for your inconvenience.
> 
> Hi Bill,
> 
> Please release 0.9.26-5 if Pere would give us  a positive 
> report and you don't see any problem in onscreen_keyboard.c and 
> mtw() in tuxpaint.c.
> Then, I will commit the changes to the latest git repo.
> 
> Thanks in advance!
> 
> -- 
> shin1
> 
> Pere Pujal i Carabantes wrote in <e5a...@gm...>
> > Hi Shin-ichi
> > 
> > El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va escriure:
> > > Hi,
> > > 
> > > mbstowcs_s() seemed to improve the behavior of AltGr modifire, but
> > > the composer did not work correctly.
> > > 
> > > So, I tried to use another Windows library function 
> > > MultiByteToWideChar(),
> > > 
> > > 
> > https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> > > Then, I think the onscreen keyboard now works quickly, correctly, 
> > > and does not crash! (A patch attached)
> > 
> > I've tried to apply to current git master and it failed to apply, 
> > then I checked out 527fc27a and it applied fine.
> > Compiled it whith make bdist-win32 and it runs fine, no crashes 
> > at all, even opening a file with labels :)
> > 
> > > Although it still crashes when opening a drawing that contains 
> > > label(s), could you please confirm if the onscreen keyboard works 
> > > perfectly in the mean time?
> > > 
> > >  https://z1.plala.jp/tuxpaint/testing/windows10/
> > 
> > Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe
> > The onscreen keyboard looks fine :)
> > And more, it seems to not need the compatibility to W8 setted, 
> > I have to reboot W10 to make sure but looks great :)
> > 
> > Thanks
> > Pere
> > 
> > > Step by step ....
> > > 
> > > -- 
> > > Shin-ichi
> > > 
> > > TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...>
> > > > Thanks Pere!
> > > > 
> > > > Then I should get all the mtw() staff back and dig into the 
> > > > deep.
> > > > 
> > > > I will focus on Onscreen Keyboard at first.
> > > > I am wondering if it might be worth trying to directly use 
> > > > mbstowcs_s() on Windows to avoid using iconv().
> > > > 
> > > > 
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160
> > > > Hrm...
> > > > 
> > > > Pere Pujal i Carabantes wrote in 
> > > > <b7c...@gm...>
> > > > > Hi, 
> > > > > 
> > > > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va 
> > escriure:
> > > > > > Hi,
> > > > > > 
> > > > > > I strongly hope this will be a final report.
> > > > > > 
> > > > > > Here is a brief (long?) history;
> > > > > > 
> > > > > > 1) OSK crash regarding libiconv reported in,
> > > > > >    https://sourceforge.net/p/tuxpaint/bugs/235/
> > > > > > 2) Win32 specific codes mtw() using iconv(), alternative to
> > > > > >    mbstowcs(), were removed and once seemed to work fine.
> > > > > > 3) Found that it still crash only on Windows10 and later.
> > > > > > 4) Trial to sepalate mtw() to single lib failed.
> > > > > > 5) Found that it crash not when using OSK, but when loading
> > > > > >    labels embedded in png drowings.
> > > > > > 
> > > > > > At this point, I remember that Bill mentiond that iconv() is 
> > > > > > also used in do_png_embed_data() in bugs/235 above.
> > > > > > 
> > > > > > Then, I also removed "#ifdef WIN32" part in this function, and 
> > > > > > it seems to work quite fine!
> > > > > > 
> > > > > > Patch to 0.9.26 is attached and binary packages are available 
> > > > > > from,
> > > > > > 
> > > > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
> > > > > 
> > > > > I am sorry to say it still doesn't work fine with labels,
> > > > > it seems to work fine if the drawing stays in Windows, but when you
> > > > > import/export a drawing between Linux and Windows then there are
> > > > > problems.
> > > > > 
> > > > > I've made a drawing in Linux (800x600) with all the strings duplicated, 
> > > > > once as text and again as labels, you could get it at
> > > > > 
> > https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
> > > > > See how only the first label string, made with the plain abcd row 
> > > > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
> > > > > displays and edits all labels correctly(both with compatibility 
> > > > > mode activated in W10).
> > > > > 
> > > > > 
> > > > > 
> > > > > > By the way, I am quite at a loss what for those WIN32 specific 
> > > > > > code were needed, because patched code also compiled on the old 
> > > > > > mingw/msys environment and works fine on Windows XP just by
> > > > > > defining lacking strtok_r() in onscreen_keyboard.c as follows.
> > > > > > 
> > > > > >   #define strtok_r(line, delim, pointer) strtok(line, delim)
> > > > > > 
> > > > > > I am not sure but those code might have been tweaked when 
> > > > > > compiling in older build environment.
> > > > > 
> > > > > I really don't know, I remember struggling and testing tons of things 
> > > > > until found something that seemed to make labels compatible 
> > > > > between Linux and Windows, not sure if we are talking about the same code.
> > > > > 
> > > > > 
> > > > > Thanks
> > > > > Pere
> > > > > 
> > > > > 
> > > > > > Anyway, I think very carefull review and tests are required
> > > > > > before releasing them.
> > > > > > 
> > > > > > Hope your help!
> > > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > 
> > > > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
> > > > > > > Just a brief report.
> > > > > > > 
> > > > > > > Deleting mtw() seems to be OK.
> > > > > > > 
> > > > > > > I found crash when loading drowing with labels occur in other 
> > > > > > > part.
> > > > > > > 
> > > > > > > ------------------------------------------------------------
> > > > > > > Thread 1 received signal SIGSEGV, Segmentation fault.
> > > > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from 
> > C:\WINDOWS\System32\msvcrt.dll
> > > > > > > (gdb) backtrace
> > > > > > > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
> > > > > > >   from C:\WINDOWS\System32\msvcrt.dll
> > > > > > > #1  0x00007ff6e502743e in load_embedded_data ()
> > > > > > > #2  0x00007ff6e50281f2 in load_current ()
> > > > > > > #3  0x00007ff6e5036842 in SDL_main ()
> > > > > > > #4  0x00007ff6e504461b in console_main ()
> > > > > > > #5  0x00007ff6e50446f8 in WinMain ()
> > > > > > > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
> > > > > > >    at 
> > C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
> > > > > > > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
> > > > > > >    at 
> > C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
> > > > > > > ------------------------------------------------------------
> > > > > > > 
> > > > > > > Thanks.
> > > > > > > 
> > > > > > > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
> > > > > > > > I was wrong again ;-<
> > > > > > > > 
> > > > > > > > It crash when re-opening drawing with labels.....
> > > > > > > > 
> > > > > > > > Sorry for the mess.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > It is becoming clear.
> > > > > > > > > 
> > > > > > > > > I suppose it was wrong to delete WIN32 specific code in 
> > > > > > > > > load_info_about_label_surface() function for 0.9.26-2.
> > > > > > > > > 
> > > > > > > > > Pere Pujal i Carabantes wrote in 
> > > > > > > > > <693...@gm...>
> > > > > > > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
> > > > > > > > > 
> > > > > > > > > Because I am not so sure about this, I removed mtw() from 
> > > > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
> > > > > > > > > in the label function with mbstowcs() not deleting all the 
> > > > > > > > > windows specific part.
> > > > > > > > > 
> > > > > > > > > It seems to work fine for me.
> > > > > > > > > No crash, rapid osk layout change and no problem when using 
> > labels 
> > > > > > > > > and osk with Japanese characters!
> > > > > > > > > 
> > > > > > > > > Could you please give a try to 0.9.26-3 packages in 
> > > > > > > > > 
> > > > > > > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
> > > > > > > > > 
> > > > > > > > > If they are fine also for you, I will commit the changes to the 
> > > > > > > > > git repo.
> > > > > > > > > 
> > > > > > > > > Thanks!
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Great!

Thanks!

Vincent Putranto wrote in <CAJ...@ma...>
>Hi Shin-ichi,
>this one seems work on me.
>
>Many Thanks.
>Vincent
>
>On Sat, Oct 16, 2021 at 8:11 PM TOYAMA Shin-ichi <sh...@wm...>
>wrote:
>
>> # Cc'ing to Vincent who kindly gave us crash reports.
>>
>> Hi, Pere
>>
>> Thank you for testing the FixOSK version.
>> It still has crash bug here as follows;
>>
>>   *  Launch it, draw label, save and quit.
>>    *   Launch it again.
>>   * Crash ;-<
>>
>> I have carefully reviewed mtw() in tuxpaint.c and made some
>> changes (patch attached), which works fine here.
>>
>> Packages compiled as 0.9.26-5 are available in
>>
>>  https://z1.plala.jp/tuxpaint/release/0.9.26-5/  (5!!)
>>
>> Could you give them final tests ?
>> I pray that this will work out this time.
>>
>> Hi Vincent!
>>
>> Although you reported me that you could run official release
>> 0.9.26 by removing user's directory and re-installing it, it surly
>> has problems regarding onscreen keyboard and labels.
>>
>> Now I believe we are almost close to the final solution.
>> Please wait a little more until next bugfix version released.
>>
>> Sorry for your inconvenience.
>>
>> Hi Bill,
>>
>> Please release 0.9.26-5 if Pere would give us  a positive
>> report and you don't see any problem in onscreen_keyboard.c and
>> mtw() in tuxpaint.c.
>> Then, I will commit the changes to the latest git repo.
>>
>> Thanks in advance!
>>
>> --
>> shin1
>>
>> Pere Pujal i Carabantes wrote in <
>> e5a...@gm...>
>> >Hi Shin-ichi
>> >
>> >El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va
>> escriure:
>> >> Hi,
>> >>
>> >> mbstowcs_s() seemed to improve the behavior of AltGr modifire, but
>> >> the composer did not work correctly.
>> >>
>> >> So, I tried to use another Windows library function
>> >> MultiByteToWideChar(),
>> >>
>> >>
>> >
>> 
>https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> >>
>> >> Then, I think the onscreen keyboard now works quickly, correctly,
>> >> and does not crash! (A patch attached)
>> >
>> >I've tried to apply to current git master and it failed to apply,
>> >then I checked out 527fc27a and it applied fine.
>> >Compiled it whith make bdist-win32 and it runs fine, no crashes
>> >at all, even opening a file with labels :)
>> >
>> >>
>> >> Although it still crashes when opening a drawing that contains
>> >> label(s), could you please confirm if the onscreen keyboard works
>> >> perfectly in the mean time?
>> >>
>> >>  https://z1.plala.jp/tuxpaint/testing/windows10/
>> >
>> >Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe
>> >The onscreen keyboard looks fine :)
>> >And more, it seems to not need the compatibility to W8 setted,
>> >I have to reboot W10 to make sure but looks great :)
>> >
>> >Thanks
>> >Pere
>> >
>> >>
>> >> Step by step ....
>> >>
>> >> --
>> >> Shin-ichi
>> >>
>> >> TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...>
>> >> > Thanks Pere!
>> >> >
>> >> > Then I should get all the mtw() staff back and dig into the
>> >> > deep.
>> >> >
>> >> > I will focus on Onscreen Keyboard at first.
>> >> > I am wondering if it might be worth trying to directly use
>> >> > mbstowcs_s() on Windows to avoid using iconv().
>> >> >
>> >> >
>> >
>> 
>https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160
>> >> >
>> >> > Hrm...
>> >> >
>> >> > Pere Pujal i Carabantes wrote in
>> >> > <b7c...@gm...>
>> >> > > Hi,
>> >> > >
>> >> > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi
>> va
>> >escriure:
>> >> > > > Hi,
>> >> > > >
>> >> > > > I strongly hope this will be a final report.
>> >> > > >
>> >> > > > Here is a brief (long?) history;
>> >> > > >
>> >> > > > 1) OSK crash regarding libiconv reported in,
>> >> > > >    https://sourceforge.net/p/tuxpaint/bugs/235/
>> >> > > > 2) Win32 specific codes mtw() using iconv(), alternative to
>> >> > > >    mbstowcs(), were removed and once seemed to work fine.
>> >> > > > 3) Found that it still crash only on Windows10 and later.
>> >> > > > 4) Trial to sepalate mtw() to single lib failed.
>> >> > > > 5) Found that it crash not when using OSK, but when loading
>> >> > > >    labels embedded in png drowings.
>> >> > > >
>> >> > > > At this point, I remember that Bill mentiond that iconv() is
>> >> > > > also used in do_png_embed_data() in bugs/235 above.
>> >> > > >
>> >> > > > Then, I also removed "#ifdef WIN32" part in this function, and
>> >> > > > it seems to work quite fine!
>> >> > > >
>> >> > > > Patch to 0.9.26 is attached and binary packages are available
>> >> > > > from,
>> >> > > >
>> >> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
>> >> > >
>> >> > > I am sorry to say it still doesn't work fine with labels,
>> >> > > it seems to work fine if the drawing stays in Windows, but when you
>> >> > > import/export a drawing between Linux and Windows then there are
>> >> > > problems.
>> >> > >
>> >> > > I've made a drawing in Linux (800x600) with all the strings
>> duplicated,
>> >> > > once as text and again as labels, you could get it at
>> >> > >
>> >
>> 
>https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
>> >> > >
>> >> > > See how only the first label string, made with the plain abcd row
>> >> > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26
>> >> > > displays and edits all labels correctly(both with compatibility
>> >> > > mode activated in W10).
>> >> > >
>> >> > >
>> >> > >
>> >> > > > By the way, I am quite at a loss what for those WIN32 specific
>> >> > > > code were needed, because patched code also compiled on the old
>> >> > > > mingw/msys environment and works fine on Windows XP just by
>> >> > > > defining lacking strtok_r() in onscreen_keyboard.c as follows.
>> >> > > >
>> >> > > >   #define strtok_r(line, delim, pointer) strtok(line, delim)
>> >> > > >
>> >> > > > I am not sure but those code might have been tweaked when
>> >> > > > compiling in older build environment.
>> >> > >
>> >> > > I really don't know, I remember struggling and testing tons of
>> things
>> >> > > until found something that seemed to make labels compatible
>> >> > > between Linux and Windows, not sure if we are talking about the
>> same code.
>> >> > >
>> >> > >
>> >> > > Thanks
>> >> > > Pere
>> >> > >
>> >> > >
>> >> > > > Anyway, I think very carefull review and tests are required
>> >> > > > before releasing them.
>> >> > > >
>> >> > > > Hope your help!
>> >> > > >
>> >> > > > Thanks.
>> >> > > >
>> >> > > >
>> >> > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
>> >> > > > > Just a brief report.
>> >> > > > >
>> >> > > > > Deleting mtw() seems to be OK.
>> >> > > > >
>> >> > > > > I found crash when loading drowing with labels occur in other
>> >> > > > > part.
>> >> > > > >
>> >> > > > > ------------------------------------------------------------
>> >> > > > > Thread 1 received signal SIGSEGV, Segmentation fault.
>> >> > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from
>> >C:\WINDOWS\System32\msvcrt.dll
>> >> > > > > (gdb) backtrace
>> >> > > > > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
>> >> > > > >   from C:\WINDOWS\System32\msvcrt.dll
>> >> > > > > #1  0x00007ff6e502743e in load_embedded_data ()
>> >> > > > > #2  0x00007ff6e50281f2 in load_current ()
>> >> > > > > #3  0x00007ff6e5036842 in SDL_main ()
>> >> > > > > #4  0x00007ff6e504461b in console_main ()
>> >> > > > > #5  0x00007ff6e50446f8 in WinMain ()
>> >> > > > > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
>> >> > > > >    at
>> >C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
>> >> > > > > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
>> >> > > > >    at
>> >C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
>> >> > > > > ------------------------------------------------------------
>> >> > > > >
>> >> > > > > Thanks.
>> >> > > > >
>> >> > > > > TOYAMA Shin-ichi wrote in <
>> 61681fa6.4962%sh...@wm...>
>> >> > > > > > I was wrong again ;-<
>> >> > > > > >
>> >> > > > > > It crash when re-opening drawing with labels.....
>> >> > > > > >
>> >> > > > > > Sorry for the mess.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > TOYAMA Shin-ichi wrote in <
>> 61681264.4961%sh...@wm...>
>> >> > > > > > > Hi,
>> >> > > > > > >
>> >> > > > > > > It is becoming clear.
>> >> > > > > > >
>> >> > > > > > > I suppose it was wrong to delete WIN32 specific code in
>> >> > > > > > > load_info_about_label_surface() function for 0.9.26-2.
>> >> > > > > > >
>> >> > > > > > > Pere Pujal i Carabantes wrote in
>> >> > > > > > > <693...@gm...>
>> >> > > > > > > > Unfortunately msys mbstowcs() seems not work outside
>> ascii :(
>> >> > > > > > >
>> >> > > > > > > Because I am not so sure about this, I removed mtw() from
>> >> > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced
>> mtw()
>> >> > > > > > > in the label function with mbstowcs() not deleting all the
>> >> > > > > > > windows specific part.
>> >> > > > > > >
>> >> > > > > > > It seems to work fine for me.
>> >> > > > > > > No crash, rapid osk layout change and no problem when using
>> >labels
>> >> > > > > > > and osk with Japanese characters!
>> >> > > > > > >
>> >> > > > > > > Could you please give a try to 0.9.26-3 packages in
>> >> > > > > > >
>> >> > > > > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>> >> > > > > > >
>> >> > > > > > > If they are fine also for you, I will commit the changes to
>> the
>> >> > > > > > > git repo.
>> >> > > > > > >
>> >> > > > > > > Thanks!
>> >> > > >
>> >_______________________________________________
>> >Tuxpaint-devel mailing list
>> >Tux...@li...
>> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>> --
>> TOYAMA Shin-ichi mailto:sh...@wm...
>
>
>
>-- 
>
>
>Regards,
>
>
>*Vincentius A.P.*
>
>
>The information contained in this communication is intended solely for the
>use of the individual or entity to whom it is addressed and others
>authorized to receive it. It may contain confidential or legally privileged
>information. If you are not the intended recipient you are notified that
>any disclosure, copying, distribution or taking any action in reliance on
>the contents of this information is strictly prohibited and may be illegal.
>
>*PT. Indosari Makmur Persada* is not liable if an e-mail or attachment is
>altered without its written consent. The limitations of liability contained
>in this disclaimer may not apply in your jurisdiction, where not allowed by
>the law.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

# Cc'ing to Vincent who kindly gave us crash reports.

Hi, Pere

Thank you for testing the FixOSK version.
It still has crash bug here as follows;

  * Launch it, draw label, save and quit.
  * Launch it again.
  * Crash ;-<

I have carefully reviewed mtw() in tuxpaint.c and made some 
changes (patch attached), which works fine here.

Packages compiled as 0.9.26-5 are available in 

 https://z1.plala.jp/tuxpaint/release/0.9.26-5/  (5!!)

Could you give them final tests ?
I pray that this will work out this time.

Hi Vincent!

Although you reported me that you could run official release 
0.9.26 by removing user's directory and re-installing it, it surly 
has problems regarding onscreen keyboard and labels.

Now I believe we are almost close to the final solution.
Please wait a little more until next bugfix version released.

Sorry for your inconvenience.

Hi Bill,

Please release 0.9.26-5 if Pere would give us  a positive 
report and you don't see any problem in onscreen_keyboard.c and 
mtw() in tuxpaint.c.
Then, I will commit the changes to the latest git repo.

Thanks in advance!

-- 
shin1

Pere Pujal i Carabantes wrote in <e5a...@gm...>
>Hi Shin-ichi
>
>El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va escriure:
>> Hi,
>> 
>> mbstowcs_s() seemed to improve the behavior of AltGr modifire, but
>> the composer did not work correctly.
>> 
>> So, I tried to use another Windows library function 
>> MultiByteToWideChar(),
>> 
>> 
>https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> 
>> Then, I think the onscreen keyboard now works quickly, correctly, 
>> and does not crash! (A patch attached)
>
>I've tried to apply to current git master and it failed to apply, 
>then I checked out 527fc27a and it applied fine.
>Compiled it whith make bdist-win32 and it runs fine, no crashes 
>at all, even opening a file with labels :)
>
>> 
>> Although it still crashes when opening a drawing that contains 
>> label(s), could you please confirm if the onscreen keyboard works 
>> perfectly in the mean time?
>> 
>>  https://z1.plala.jp/tuxpaint/testing/windows10/
>
>Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe
>The onscreen keyboard looks fine :)
>And more, it seems to not need the compatibility to W8 setted, 
>I have to reboot W10 to make sure but looks great :)
>
>Thanks
>Pere
>
>> 
>> Step by step ....
>> 
>> -- 
>> Shin-ichi
>> 
>> TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...>
>> > Thanks Pere!
>> > 
>> > Then I should get all the mtw() staff back and dig into the 
>> > deep.
>> > 
>> > I will focus on Onscreen Keyboard at first.
>> > I am wondering if it might be worth trying to directly use 
>> > mbstowcs_s() on Windows to avoid using iconv().
>> > 
>> > 
>https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160
>> > 
>> > Hrm...
>> > 
>> > Pere Pujal i Carabantes wrote in 
>> > <b7c...@gm...>
>> > > Hi, 
>> > > 
>> > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va 
>escriure:
>> > > > Hi,
>> > > > 
>> > > > I strongly hope this will be a final report.
>> > > > 
>> > > > Here is a brief (long?) history;
>> > > > 
>> > > > 1) OSK crash regarding libiconv reported in,
>> > > >    https://sourceforge.net/p/tuxpaint/bugs/235/
>> > > > 2) Win32 specific codes mtw() using iconv(), alternative to
>> > > >    mbstowcs(), were removed and once seemed to work fine.
>> > > > 3) Found that it still crash only on Windows10 and later.
>> > > > 4) Trial to sepalate mtw() to single lib failed.
>> > > > 5) Found that it crash not when using OSK, but when loading
>> > > >    labels embedded in png drowings.
>> > > > 
>> > > > At this point, I remember that Bill mentiond that iconv() is 
>> > > > also used in do_png_embed_data() in bugs/235 above.
>> > > > 
>> > > > Then, I also removed "#ifdef WIN32" part in this function, and 
>> > > > it seems to work quite fine!
>> > > > 
>> > > > Patch to 0.9.26 is attached and binary packages are available 
>> > > > from,
>> > > > 
>> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
>> > > 
>> > > I am sorry to say it still doesn't work fine with labels,
>> > > it seems to work fine if the drawing stays in Windows, but when you
>> > > import/export a drawing between Linux and Windows then there are
>> > > problems.
>> > > 
>> > > I've made a drawing in Linux (800x600) with all the strings duplicated, 
>> > > once as text and again as labels, you could get it at
>> > > 
>https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
>> > > 
>> > > See how only the first label string, made with the plain abcd row 
>> > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
>> > > displays and edits all labels correctly(both with compatibility 
>> > > mode activated in W10).
>> > > 
>> > > 
>> > > 
>> > > > By the way, I am quite at a loss what for those WIN32 specific 
>> > > > code were needed, because patched code also compiled on the old 
>> > > > mingw/msys environment and works fine on Windows XP just by
>> > > > defining lacking strtok_r() in onscreen_keyboard.c as follows.
>> > > > 
>> > > >   #define strtok_r(line, delim, pointer) strtok(line, delim)
>> > > > 
>> > > > I am not sure but those code might have been tweaked when 
>> > > > compiling in older build environment.
>> > > 
>> > > I really don't know, I remember struggling and testing tons of things 
>> > > until found something that seemed to make labels compatible 
>> > > between Linux and Windows, not sure if we are talking about the same code.
>> > > 
>> > > 
>> > > Thanks
>> > > Pere
>> > > 
>> > > 
>> > > > Anyway, I think very carefull review and tests are required
>> > > > before releasing them.
>> > > > 
>> > > > Hope your help!
>> > > > 
>> > > > Thanks.
>> > > > 
>> > > > 
>> > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
>> > > > > Just a brief report.
>> > > > > 
>> > > > > Deleting mtw() seems to be OK.
>> > > > > 
>> > > > > I found crash when loading drowing with labels occur in other 
>> > > > > part.
>> > > > > 
>> > > > > ------------------------------------------------------------
>> > > > > Thread 1 received signal SIGSEGV, Segmentation fault.
>> > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from 
>C:\WINDOWS\System32\msvcrt.dll
>> > > > > (gdb) backtrace
>> > > > > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
>> > > > >   from C:\WINDOWS\System32\msvcrt.dll
>> > > > > #1  0x00007ff6e502743e in load_embedded_data ()
>> > > > > #2  0x00007ff6e50281f2 in load_current ()
>> > > > > #3  0x00007ff6e5036842 in SDL_main ()
>> > > > > #4  0x00007ff6e504461b in console_main ()
>> > > > > #5  0x00007ff6e50446f8 in WinMain ()
>> > > > > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
>> > > > >    at 
>C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
>> > > > > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
>> > > > >    at 
>C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
>> > > > > ------------------------------------------------------------
>> > > > > 
>> > > > > Thanks.
>> > > > > 
>> > > > > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
>> > > > > > I was wrong again ;-<
>> > > > > > 
>> > > > > > It crash when re-opening drawing with labels.....
>> > > > > > 
>> > > > > > Sorry for the mess.
>> > > > > > 
>> > > > > > 
>> > > > > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
>> > > > > > > Hi,
>> > > > > > > 
>> > > > > > > It is becoming clear.
>> > > > > > > 
>> > > > > > > I suppose it was wrong to delete WIN32 specific code in 
>> > > > > > > load_info_about_label_surface() function for 0.9.26-2.
>> > > > > > > 
>> > > > > > > Pere Pujal i Carabantes wrote in 
>> > > > > > > <693...@gm...>
>> > > > > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
>> > > > > > > 
>> > > > > > > Because I am not so sure about this, I removed mtw() from 
>> > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
>> > > > > > > in the label function with mbstowcs() not deleting all the 
>> > > > > > > windows specific part.
>> > > > > > > 
>> > > > > > > It seems to work fine for me.
>> > > > > > > No crash, rapid osk layout change and no problem when using 
>labels 
>> > > > > > > and osk with Japanese characters!
>> > > > > > > 
>> > > > > > > Could you please give a try to 0.9.26-3 packages in 
>> > > > > > > 
>> > > > > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>> > > > > > > 
>> > > > > > > If they are fine also for you, I will commit the changes to the 
>> > > > > > > git repo.
>> > > > > > > 
>> > > > > > > Thanks!
>> > > > 
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

Hi Shin-ichi

El ds. 16 de 10 de 2021 a les 16:57 +0900, en/na TOYAMA Shin-ichi va escriure:
> Hi,
> 
> mbstowcs_s() seemed to improve the behavior of AltGr modifire, but
> the composer did not work correctly.
> 
> So, I tried to use another Windows library function 
> MultiByteToWideChar(),
> 
> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> 
> Then, I think the onscreen keyboard now works quickly, correctly, 
> and does not crash! (A patch attached)

I've tried to apply to current git master and it failed to apply, 
then I checked out 527fc27a and it applied fine.
Compiled it whith make bdist-win32 and it runs fine, no crashes 
at all, even opening a file with labels :)

> 
> Although it still crashes when opening a drawing that contains 
> label(s), could you please confirm if the onscreen keyboard works 
> perfectly in the mean time?
> 
>  https://z1.plala.jp/tuxpaint/testing/windows10/

Installed the tuxpaint-0.9.26-windows-x86_64-FixOSK-installer.exe
The onscreen keyboard looks fine :)
And more, it seems to not need the compatibility to W8 setted, 
I have to reboot W10 to make sure but looks great :)

Thanks
Pere

> 
> Step by step ....
> 
> -- 
> Shin-ichi
> 
> TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...>
> > Thanks Pere!
> > 
> > Then I should get all the mtw() staff back and dig into the 
> > deep.
> > 
> > I will focus on Onscreen Keyboard at first.
> > I am wondering if it might be worth trying to directly use 
> > mbstowcs_s() on Windows to avoid using iconv().
> > 
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160
> > 
> > Hrm...
> > 
> > Pere Pujal i Carabantes wrote in 
> > <b7c...@gm...>
> > > Hi, 
> > > 
> > > El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure:
> > > > Hi,
> > > > 
> > > > I strongly hope this will be a final report.
> > > > 
> > > > Here is a brief (long?) history;
> > > > 
> > > > 1) OSK crash regarding libiconv reported in,
> > > >    https://sourceforge.net/p/tuxpaint/bugs/235/
> > > > 2) Win32 specific codes mtw() using iconv(), alternative to
> > > >    mbstowcs(), were removed and once seemed to work fine.
> > > > 3) Found that it still crash only on Windows10 and later.
> > > > 4) Trial to sepalate mtw() to single lib failed.
> > > > 5) Found that it crash not when using OSK, but when loading
> > > >    labels embedded in png drowings.
> > > > 
> > > > At this point, I remember that Bill mentiond that iconv() is 
> > > > also used in do_png_embed_data() in bugs/235 above.
> > > > 
> > > > Then, I also removed "#ifdef WIN32" part in this function, and 
> > > > it seems to work quite fine!
> > > > 
> > > > Patch to 0.9.26 is attached and binary packages are available 
> > > > from,
> > > > 
> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
> > > 
> > > I am sorry to say it still doesn't work fine with labels,
> > > it seems to work fine if the drawing stays in Windows, but when you
> > > import/export a drawing between Linux and Windows then there are
> > > problems.
> > > 
> > > I've made a drawing in Linux (800x600) with all the strings duplicated, 
> > > once as text and again as labels, you could get it at
> > > https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
> > > 
> > > See how only the first label string, made with the plain abcd row 
> > > of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
> > > displays and edits all labels correctly(both with compatibility 
> > > mode activated in W10).
> > > 
> > > 
> > > 
> > > > By the way, I am quite at a loss what for those WIN32 specific 
> > > > code were needed, because patched code also compiled on the old 
> > > > mingw/msys environment and works fine on Windows XP just by
> > > > defining lacking strtok_r() in onscreen_keyboard.c as follows.
> > > > 
> > > >   #define strtok_r(line, delim, pointer) strtok(line, delim)
> > > > 
> > > > I am not sure but those code might have been tweaked when 
> > > > compiling in older build environment.
> > > 
> > > I really don't know, I remember struggling and testing tons of things 
> > > until found something that seemed to make labels compatible 
> > > between Linux and Windows, not sure if we are talking about the same code.
> > > 
> > > 
> > > Thanks
> > > Pere
> > > 
> > > 
> > > > Anyway, I think very carefull review and tests are required
> > > > before releasing them.
> > > > 
> > > > Hope your help!
> > > > 
> > > > Thanks.
> > > > 
> > > > 
> > > > TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
> > > > > Just a brief report.
> > > > > 
> > > > > Deleting mtw() seems to be OK.
> > > > > 
> > > > > I found crash when loading drowing with labels occur in other 
> > > > > part.
> > > > > 
> > > > > ------------------------------------------------------------
> > > > > Thread 1 received signal SIGSEGV, Segmentation fault.
> > > > > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
> > > > > (gdb) backtrace
> > > > > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
> > > > >   from C:\WINDOWS\System32\msvcrt.dll
> > > > > #1  0x00007ff6e502743e in load_embedded_data ()
> > > > > #2  0x00007ff6e50281f2 in load_current ()
> > > > > #3  0x00007ff6e5036842 in SDL_main ()
> > > > > #4  0x00007ff6e504461b in console_main ()
> > > > > #5  0x00007ff6e50446f8 in WinMain ()
> > > > > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
> > > > >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
> > > > > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
> > > > >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
> > > > > ------------------------------------------------------------
> > > > > 
> > > > > Thanks.
> > > > > 
> > > > > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
> > > > > > I was wrong again ;-<
> > > > > > 
> > > > > > It crash when re-opening drawing with labels.....
> > > > > > 
> > > > > > Sorry for the mess.
> > > > > > 
> > > > > > 
> > > > > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
> > > > > > > Hi,
> > > > > > > 
> > > > > > > It is becoming clear.
> > > > > > > 
> > > > > > > I suppose it was wrong to delete WIN32 specific code in 
> > > > > > > load_info_about_label_surface() function for 0.9.26-2.
> > > > > > > 
> > > > > > > Pere Pujal i Carabantes wrote in 
> > > > > > > <693...@gm...>
> > > > > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
> > > > > > > 
> > > > > > > Because I am not so sure about this, I removed mtw() from 
> > > > > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
> > > > > > > in the label function with mbstowcs() not deleting all the 
> > > > > > > windows specific part.
> > > > > > > 
> > > > > > > It seems to work fine for me.
> > > > > > > No crash, rapid osk layout change and no problem when using labels 
> > > > > > > and osk with Japanese characters!
> > > > > > > 
> > > > > > > Could you please give a try to 0.9.26-3 packages in 
> > > > > > > 
> > > > > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
> > > > > > > 
> > > > > > > If they are fine also for you, I will commit the changes to the 
> > > > > > > git repo.
> > > > > > > 
> > > > > > > Thanks!
> > > > 
> > > > _______________________________________________
> > > > Tuxpaint-devel mailing list
> > > > Tux...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > > 
> > > 
> > > _______________________________________________
> > > Tuxpaint-devel mailing list
> > > Tux...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Hi,

mbstowcs_s() seemed to improve the behavior of AltGr modifire, but
the composer did not work correctly.

So, I tried to use another Windows library function 
MultiByteToWideChar(),

https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar

Then, I think the onscreen keyboard now works quickly, correctly, 
and does not crash! (A patch attached)

Although it still crashes when opening a drawing that contains 
label(s), could you please confirm if the onscreen keyboard works 
perfectly in the mean time?

 https://z1.plala.jp/tuxpaint/testing/windows10/

Step by step ....

-- 
Shin-ichi

TOYAMA Shin-ichi wrote in <616a170e.4969%sh...@wm...>
>Thanks Pere!
>
>Then I should get all the mtw() staff back and dig into the 
>deep.
>
>I will focus on Onscreen Keyboard at first.
>I am wondering if it might be worth trying to directly use 
>mbstowcs_s() on Windows to avoid using iconv().
>
>https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160
>
>Hrm...
>
>Pere Pujal i Carabantes wrote in 
><b7c...@gm...>
>>Hi, 
>>
>>El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure:
>>> Hi,
>>> 
>>> I strongly hope this will be a final report.
>>> 
>>> Here is a brief (long?) history;
>>> 
>>> 1) OSK crash regarding libiconv reported in,
>>>    https://sourceforge.net/p/tuxpaint/bugs/235/
>>> 2) Win32 specific codes mtw() using iconv(), alternative to
>>>    mbstowcs(), were removed and once seemed to work fine.
>>> 3) Found that it still crash only on Windows10 and later.
>>> 4) Trial to sepalate mtw() to single lib failed.
>>> 5) Found that it crash not when using OSK, but when loading
>>>    labels embedded in png drowings.
>>> 
>>> At this point, I remember that Bill mentiond that iconv() is 
>>> also used in do_png_embed_data() in bugs/235 above.
>>> 
>>> Then, I also removed "#ifdef WIN32" part in this function, and 
>>> it seems to work quite fine!
>>> 
>>> Patch to 0.9.26 is attached and binary packages are available 
>>> from,
>>> 
>>>  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
>>
>>I am sorry to say it still doesn't work fine with labels,
>>it seems to work fine if the drawing stays in Windows, but when you
>>import/export a drawing between Linux and Windows then there are
>>problems.
>>
>>I've made a drawing in Linux (800x600) with all the strings duplicated, 
>>once as text and again as labels, you could get it at
>>https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
>>
>>See how only the first label string, made with the plain abcd row 
>>of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
>>displays and edits all labels correctly(both with compatibility 
>>mode activated in W10).
>>
>>
>>
>>> 
>>> By the way, I am quite at a loss what for those WIN32 specific 
>>> code were needed, because patched code also compiled on the old 
>>> mingw/msys environment and works fine on Windows XP just by
>>> defining lacking strtok_r() in onscreen_keyboard.c as follows.
>>> 
>>>   #define strtok_r(line, delim, pointer) strtok(line, delim)
>>> 
>>> I am not sure but those code might have been tweaked when 
>>> compiling in older build environment.
>>
>>I really don't know, I remember struggling and testing tons of things 
>>until found something that seemed to make labels compatible 
>>between Linux and Windows, not sure if we are talking about the same code.
>>
>>
>>Thanks
>>Pere
>>
>>
>>> 
>>> Anyway, I think very carefull review and tests are required
>>> before releasing them.
>>> 
>>> Hope your help!
>>> 
>>> Thanks.
>>> 
>>> 
>>> TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
>>> > Just a brief report.
>>> > 
>>> > Deleting mtw() seems to be OK.
>>> > 
>>> > I found crash when loading drowing with labels occur in other 
>>> > part.
>>> > 
>>> > ------------------------------------------------------------
>>> > Thread 1 received signal SIGSEGV, Segmentation fault.
>>> > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
>>> > (gdb) backtrace
>>> > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
>>> >   from C:\WINDOWS\System32\msvcrt.dll
>>> > #1  0x00007ff6e502743e in load_embedded_data ()
>>> > #2  0x00007ff6e50281f2 in load_current ()
>>> > #3  0x00007ff6e5036842 in SDL_main ()
>>> > #4  0x00007ff6e504461b in console_main ()
>>> > #5  0x00007ff6e50446f8 in WinMain ()
>>> > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
>>> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
>>> > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
>>> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
>>> > ------------------------------------------------------------
>>> > 
>>> > Thanks.
>>> > 
>>> > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
>>> > > I was wrong again ;-<
>>> > > 
>>> > > It crash when re-opening drawing with labels.....
>>> > > 
>>> > > Sorry for the mess.
>>> > > 
>>> > > 
>>> > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
>>> > > > Hi,
>>> > > > 
>>> > > > It is becoming clear.
>>> > > > 
>>> > > > I suppose it was wrong to delete WIN32 specific code in 
>>> > > > load_info_about_label_surface() function for 0.9.26-2.
>>> > > > 
>>> > > > Pere Pujal i Carabantes wrote in 
>>> > > > <693...@gm...>
>>> > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
>>> > > > 
>>> > > > Because I am not so sure about this, I removed mtw() from 
>>> > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
>>> > > > in the label function with mbstowcs() not deleting all the 
>>> > > > windows specific part.
>>> > > > 
>>> > > > It seems to work fine for me.
>>> > > > No crash, rapid osk layout change and no problem when using labels 
>>> > > > and osk with Japanese characters!
>>> > > > 
>>> > > > Could you please give a try to 0.9.26-3 packages in 
>>> > > > 
>>> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>>> > > > 
>>> > > > If they are fine also for you, I will commit the changes to the 
>>> > > > git repo.
>>> > > > 
>>> > > > Thanks!
>>> 
>>> _______________________________________________
>>> 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

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Thanks Pere!

Then I should get all the mtw() staff back and dig into the 
deep.

I will focus on Onscreen Keyboard at first.
I am wondering if it might be worth trying to directly use 
mbstowcs_s() on Windows to avoid using iconv().

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/mbstowcs-s-mbstowcs-s-l?view=msvc-160

Hrm...

Pere Pujal i Carabantes wrote in <b7c...@gm...>
>Hi, 
>
>El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure:
>> Hi,
>> 
>> I strongly hope this will be a final report.
>> 
>> Here is a brief (long?) history;
>> 
>> 1) OSK crash regarding libiconv reported in,
>>    https://sourceforge.net/p/tuxpaint/bugs/235/
>> 2) Win32 specific codes mtw() using iconv(), alternative to
>>    mbstowcs(), were removed and once seemed to work fine.
>> 3) Found that it still crash only on Windows10 and later.
>> 4) Trial to sepalate mtw() to single lib failed.
>> 5) Found that it crash not when using OSK, but when loading
>>    labels embedded in png drowings.
>> 
>> At this point, I remember that Bill mentiond that iconv() is 
>> also used in do_png_embed_data() in bugs/235 above.
>> 
>> Then, I also removed "#ifdef WIN32" part in this function, and 
>> it seems to work quite fine!
>> 
>> Patch to 0.9.26 is attached and binary packages are available 
>> from,
>> 
>>  https://z1.plala.jp/tuxpaint/release/0.9.26-4/
>
>I am sorry to say it still doesn't work fine with labels,
>it seems to work fine if the drawing stays in Windows, but when you
>import/export a drawing between Linux and Windows then there are
>problems.
>
>I've made a drawing in Linux (800x600) with all the strings duplicated, 
>once as text and again as labels, you could get it at
>https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png
>
>See how only the first label string, made with the plain abcd row 
>of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
>displays and edits all labels correctly(both with compatibility 
>mode activated in W10).
>
>
>
>> 
>> By the way, I am quite at a loss what for those WIN32 specific 
>> code were needed, because patched code also compiled on the old 
>> mingw/msys environment and works fine on Windows XP just by
>> defining lacking strtok_r() in onscreen_keyboard.c as follows.
>> 
>>   #define strtok_r(line, delim, pointer) strtok(line, delim)
>> 
>> I am not sure but those code might have been tweaked when 
>> compiling in older build environment.
>
>I really don't know, I remember struggling and testing tons of things 
>until found something that seemed to make labels compatible 
>between Linux and Windows, not sure if we are talking about the same code.
>
>
>Thanks
>Pere
>
>
>> 
>> Anyway, I think very carefull review and tests are required
>> before releasing them.
>> 
>> Hope your help!
>> 
>> Thanks.
>> 
>> 
>> TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
>> > Just a brief report.
>> > 
>> > Deleting mtw() seems to be OK.
>> > 
>> > I found crash when loading drowing with labels occur in other 
>> > part.
>> > 
>> > ------------------------------------------------------------
>> > Thread 1 received signal SIGSEGV, Segmentation fault.
>> > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
>> > (gdb) backtrace
>> > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
>> >   from C:\WINDOWS\System32\msvcrt.dll
>> > #1  0x00007ff6e502743e in load_embedded_data ()
>> > #2  0x00007ff6e50281f2 in load_current ()
>> > #3  0x00007ff6e5036842 in SDL_main ()
>> > #4  0x00007ff6e504461b in console_main ()
>> > #5  0x00007ff6e50446f8 in WinMain ()
>> > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
>> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
>> > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
>> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
>> > ------------------------------------------------------------
>> > 
>> > Thanks.
>> > 
>> > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
>> > > I was wrong again ;-<
>> > > 
>> > > It crash when re-opening drawing with labels.....
>> > > 
>> > > Sorry for the mess.
>> > > 
>> > > 
>> > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
>> > > > Hi,
>> > > > 
>> > > > It is becoming clear.
>> > > > 
>> > > > I suppose it was wrong to delete WIN32 specific code in 
>> > > > load_info_about_label_surface() function for 0.9.26-2.
>> > > > 
>> > > > Pere Pujal i Carabantes wrote in 
>> > > > <693...@gm...>
>> > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
>> > > > 
>> > > > Because I am not so sure about this, I removed mtw() from 
>> > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
>> > > > in the label function with mbstowcs() not deleting all the 
>> > > > windows specific part.
>> > > > 
>> > > > It seems to work fine for me.
>> > > > No crash, rapid osk layout change and no problem when using labels 
>> > > > and osk with Japanese characters!
>> > > > 
>> > > > Could you please give a try to 0.9.26-3 packages in 
>> > > > 
>> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>> > > > 
>> > > > If they are fine also for you, I will commit the changes to the 
>> > > > git repo.
>> > > > 
>> > > > Thanks!
>> 
>> _______________________________________________
>> 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

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Hidden bug on Windows?

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

Hi, 

El dv. 15 de 10 de 2021 a les 13:43 +0900, en/na TOYAMA Shin-ichi va escriure:
> Hi,
> 
> I strongly hope this will be a final report.
> 
> Here is a brief (long?) history;
> 
> 1) OSK crash regarding libiconv reported in,
>    https://sourceforge.net/p/tuxpaint/bugs/235/
> 2) Win32 specific codes mtw() using iconv(), alternative to
>    mbstowcs(), were removed and once seemed to work fine.
> 3) Found that it still crash only on Windows10 and later.
> 4) Trial to sepalate mtw() to single lib failed.
> 5) Found that it crash not when using OSK, but when loading
>    labels embedded in png drowings.
> 
> At this point, I remember that Bill mentiond that iconv() is 
> also used in do_png_embed_data() in bugs/235 above.
> 
> Then, I also removed "#ifdef WIN32" part in this function, and 
> it seems to work quite fine!
> 
> Patch to 0.9.26 is attached and binary packages are available 
> from,
> 
>  https://z1.plala.jp/tuxpaint/release/0.9.26-4/

I am sorry to say it still doesn't work fine with labels,
it seems to work fine if the drawing stays in Windows, but when you
import/export a drawing between Linux and Windows then there are
problems.

I've made a drawing in Linux (800x600) with all the strings duplicated, 
once as text and again as labels, you could get it at
https://provant.freeddns.org/pere/public_html/developing/20211015/20211015205933.png

See how only the first label string, made with the plain abcd row 
of the onscreen keyboard is displayed in 0.9.26-4, instead 0.9.26 
displays and edits all labels correctly(both with compatibility 
mode activated in W10).



> 
> By the way, I am quite at a loss what for those WIN32 specific 
> code were needed, because patched code also compiled on the old 
> mingw/msys environment and works fine on Windows XP just by
> defining lacking strtok_r() in onscreen_keyboard.c as follows.
> 
>   #define strtok_r(line, delim, pointer) strtok(line, delim)
> 
> I am not sure but those code might have been tweaked when 
> compiling in older build environment.

I really don't know, I remember struggling and testing tons of things 
until found something that seemed to make labels compatible 
between Linux and Windows, not sure if we are talking about the same code.


Thanks
Pere


> 
> Anyway, I think very carefull review and tests are required
> before releasing them.
> 
> Hope your help!
> 
> Thanks.
> 
> 
> TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
> > Just a brief report.
> > 
> > Deleting mtw() seems to be OK.
> > 
> > I found crash when loading drowing with labels occur in other 
> > part.
> > 
> > ------------------------------------------------------------
> > Thread 1 received signal SIGSEGV, Segmentation fault.
> > 0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
> > (gdb) backtrace
> > #0  0x00007ffd86ab7f09 in msvcrt!memmove ()
> >   from C:\WINDOWS\System32\msvcrt.dll
> > #1  0x00007ff6e502743e in load_embedded_data ()
> > #2  0x00007ff6e50281f2 in load_current ()
> > #3  0x00007ff6e5036842 in SDL_main ()
> > #4  0x00007ff6e504461b in console_main ()
> > #5  0x00007ff6e50446f8 in WinMain ()
> > #6  0x00007ff6e50013b1 in __tmainCRTStartup ()
> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
> > #7  0x00007ff6e50014c6 in WinMainCRTStartup ()
> >    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
> > ------------------------------------------------------------
> > 
> > Thanks.
> > 
> > TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
> > > I was wrong again ;-<
> > > 
> > > It crash when re-opening drawing with labels.....
> > > 
> > > Sorry for the mess.
> > > 
> > > 
> > > TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
> > > > Hi,
> > > > 
> > > > It is becoming clear.
> > > > 
> > > > I suppose it was wrong to delete WIN32 specific code in 
> > > > load_info_about_label_surface() function for 0.9.26-2.
> > > > 
> > > > Pere Pujal i Carabantes wrote in 
> > > > <693...@gm...>
> > > > > Unfortunately msys mbstowcs() seems not work outside ascii :(
> > > > 
> > > > Because I am not so sure about this, I removed mtw() from 
> > > > onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
> > > > in the label function with mbstowcs() not deleting all the 
> > > > windows specific part.
> > > > 
> > > > It seems to work fine for me.
> > > > No crash, rapid osk layout change and no problem when using labels 
> > > > and osk with Japanese characters!
> > > > 
> > > > Could you please give a try to 0.9.26-3 packages in 
> > > > 
> > > >  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
> > > > 
> > > > If they are fine also for you, I will commit the changes to the 
> > > > git repo.
> > > > 
> > > > Thanks!
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Hidden bug on Windows?

[TOYAMA Shin-i. <sh...@wm...>]

Hi,

I strongly hope this will be a final report.

Here is a brief (long?) history;

1) OSK crash regarding libiconv reported in,
   https://sourceforge.net/p/tuxpaint/bugs/235/
2) Win32 specific codes mtw() using iconv(), alternative to
   mbstowcs(), were removed and once seemed to work fine.
3) Found that it still crash only on Windows10 and later.
4) Trial to sepalate mtw() to single lib failed.
5) Found that it crash not when using OSK, but when loading
   labels embedded in png drowings.

At this point, I remember that Bill mentiond that iconv() is 
also used in do_png_embed_data() in bugs/235 above.

Then, I also removed "#ifdef WIN32" part in this function, and 
it seems to work quite fine!

Patch to 0.9.26 is attached and binary packages are available 
from,

 https://z1.plala.jp/tuxpaint/release/0.9.26-4/

By the way, I am quite at a loss what for those WIN32 specific 
code were needed, because patched code also compiled on the old 
mingw/msys environment and works fine on Windows XP just by
defining lacking strtok_r() in onscreen_keyboard.c as follows.

  #define strtok_r(line, delim, pointer) strtok(line, delim)

I am not sure but those code might have been tweaked when 
compiling in older build environment.

Anyway, I think very carefull review and tests are required
before releasing them.

Hope your help!

Thanks.


TOYAMA Shin-ichi wrote in <6168e3c0.4965%sh...@wm...>
>Just a brief report.
>
>Deleting mtw() seems to be OK.
>
>I found crash when loading drowing with labels occur in other 
>part.
>
>------------------------------------------------------------
>Thread 1 received signal SIGSEGV, Segmentation fault.
>0x00007ffd86ab7f09 in msvcrt!memmove () from C:\WINDOWS\System32\msvcrt.dll
>(gdb) backtrace
>#0  0x00007ffd86ab7f09 in msvcrt!memmove ()
>   from C:\WINDOWS\System32\msvcrt.dll
>#1  0x00007ff6e502743e in load_embedded_data ()
>#2  0x00007ff6e50281f2 in load_current ()
>#3  0x00007ff6e5036842 in SDL_main ()
>#4  0x00007ff6e504461b in console_main ()
>#5  0x00007ff6e50446f8 in WinMain ()
>#6  0x00007ff6e50013b1 in __tmainCRTStartup ()
>    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:321
>#7  0x00007ff6e50014c6 in WinMainCRTStartup ()
>    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:176
>------------------------------------------------------------
>
>Thanks.
>
>TOYAMA Shin-ichi wrote in <61681fa6.4962%sh...@wm...>
>>I was wrong again ;-<
>>
>>It crash when re-opening drawing with labels.....
>>
>>Sorry for the mess.
>>
>>
>>TOYAMA Shin-ichi wrote in <61681264.4961%sh...@wm...>
>>>Hi,
>>>
>>>It is becoming clear.
>>>
>>>I suppose it was wrong to delete WIN32 specific code in 
>>>load_info_about_label_surface() function for 0.9.26-2.
>>>
>>>Pere Pujal i Carabantes wrote in 
>>><693...@gm...>
>>>>Unfortunately msys mbstowcs() seems not work outside ascii :(
>>>
>>>Because I am not so sure about this, I removed mtw() from 
>>>onscreen_keyboard.c and tuxpaint.c again and just replaced mtw() 
>>>in the label function with mbstowcs() not deleting all the 
>>>windows specific part.
>>>
>>>It seems to work fine for me.
>>>No crash, rapid osk layout change and no problem when using labels 
>>>and osk with Japanese characters!
>>>
>>>Could you please give a try to 0.9.26-3 packages in 
>>>
>>>  https://z1.plala.jp/tuxpaint/release/0.9.26-3/
>>>
>>>If they are fine also for you, I will commit the changes to the 
>>>git repo.
>>>
>>>Thanks!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...