tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Is this warning harmless?

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

Hi Bill,

Thank you for the work to supress compiler warning when compiling 
on windows.

I agree with your suggestion about future possibility to replace 
wchar_t with char32_t for the compatibility among various 
platforms.

By the way,

Bill Kendrick wrote in <202...@sh...>
>Regarding those characters that did not appear in the OSK for you,
>I made the above discover by simply replacing the code that converts
>any >= 0x00010000 values in str[] to UTF-8, for sending to SDL_Pango,
>and just doing this:
>
>  utfstr[j++] = 'X';
>
>...But I could still see the symbols (and not an "X"). :)
>
>Perhaps that's a font issue?  Can you play around with it?

In my understanding, we shoud have rectangle shape instead of the 
correct symbol if it is a font issue, wright?

However, nothing appears this case by clicking those simbols on 
the OSK.

I guess this might not be caused by render_text_w(), but by 
something else in the OSK codes.

Thanks!

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

Re: [Tuxpaint-devel] Crash of Tuxpaint

[Marie V. <mar...@gm...>]

Hello, 
I have done this and it worked! Thank you :)
Marie Verdeil
mar...@gm...
http://verdeil.net/



> On 1 Nov 2021, at 15:54, Mark K. Kim <mar...@gm...> wrote:
> 
> Hi Marie,
> 
> Can you try deleting the config files?
> 
> There are two config files:
> /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
> /Library/Application Support/TuxPaint/tuxpaint.cfg
> Thanks!
> 
> 
> On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm... <mailto:mar...@gm...>> wrote:
> hello,
> 
> I am running it in english, right out of the download, with default presets (i did try to change some config with tuxpaint config but as it was crashing, i disinstalled it and downloaded it again). It launches and crashes after 2 seconds on the loading screen. 
> 
> 
> 
>> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm... <mailto:mar...@gm...>> wrote:
>> 
>> 
>> Hi Marie,
>> 
>> I noticed it crashes sometimes in Japanese or Korean mode. In what language are you running Tux Paint in?
>> 
>> 
>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm... <mailto:mar...@gm...>> wrote:
>> Hello, 
>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur but it crashes immediately when I launch it…Has anyone had the same issue? I used no config and no added stamps… Any lead as of what could the issue be? 
>> 
>> Thankyou 
>> Marie 
>> 
>> 
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li... <mailto:Tux...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li... <mailto:Tux...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li... <mailto:Tux...@li...>
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <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] Is this warning harmless?

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

On Wed, Nov 03, 2021 at 09:53:01PM -0700, Bill Kendrick wrote:
<snip>
> Back to the issue at hand, it actually seems like anything about

I mean "above" not "about". :)


> 0xFFFF isn't really useful to us.
> 
>   https://unicodebook.readthedocs.io/unicode.html#unicode-categories
> 
> says:
> 
>   There are 3 ranges reserved for private use (Co subcategory):
>   U+E000 - U+F8FF (6,400 code points), U+F0000 - U+FFFFD (65,534) and
>   U+100000 - U+10FFFD (65,534). Surrogates (Cs subcategory) use the
>   range U+D800 - U+DFFF (2,048 code points).

Ah shoot, I misread.  So it seems like U+10000 through U+0FFFFF
are NOT private use.  I missed that other zero. :)
(The highest code-point is U+10FFFF.)

Things in this high range are non-BMP characters
(BMP = Basic Multilingual Plane).

Up there we have things like Emojis, for example U+1F602,
"Face with tears of joy".

I've actually been thinking about how and if Emojis could be
used with Tux Paint's text tool.  It seems like it will be
impossible, for now at least, with 16-bit wchar systems like Windows.

Opening a ticket for us to sort this out some day...

  https://sourceforge.net/p/tuxpaint/feature-requests/210/


-bill!

> 
> I'm thinking it's probably safe to just ignore str[] values above
> 0xFFFF (which are impossible on environments, like Windows, with
> 16-bit `wchar`).
> 
> I'll see what happens on Linux.  If it seems okay, I'll commit, and
> you can test things on Windows.
> 
> 
> Regarding those characters that did not appear in the OSK for you,
> I made the above discover by simply replacing the code that converts
> any >= 0x00010000 values in str[] to UTF-8, for sending to SDL_Pango,
> and just doing this:
> 
>   utfstr[j++] = 'X';
> 
> ...But I could still see the symbols (and not an "X"). :)
> 
> Perhaps that's a font issue?  Can you play around with it?
> 
> 
> -bill!
> 
> 
> > 
> > I'm digging around the code right now.
> > 
> > -bill!
> > 
> > 
> > > 
> > > 
> > > TOYAMA Shin-ichi wrote in <617e94b2.5007%sh...@wm...>
> > > >Hi,
> > > >
> > > >Recently, I've been dealing with a lot of bugs in the Windows
> > > >version, and I've noticed that many clue of the bugs had been 
> > > >appeared in the compile-time warnings.
> > > >
> > > >So,I checked the warnings again, and the following warning,
> > > >which does not appear when compiling on Linux, caught my 
> > > >attention.
> > > >
> > > >------------------------------------------------------------
> > > >src/tuxpaint.c: In function 'render_text_w':
> > > >src/tuxpaint.c:1685:27: warning: comparison is always true due to limited range 
> > > >of data type [-Wtype-limits]
> > > > 1685 |           else if (str[i] <= 0x0000FFFF)
> > > >------------------------------------------------------------
> > > >
> > > >If this warning is correct, it means that the next conditional
> > > >branch (0x00100000 - 001FFFFF) will never be reached.
> > > >
> > > >How can I confirm if it were a problem or not?
> > > >
> > > >Thanks!
> > > 
> > > -- 
> > > TOYAMA Shin-ichi mailto:sh...@wm...
> > 
> > 
> > 
> > > _______________________________________________
> > > Tuxpaint-devel mailing list
> > > Tux...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > 
> > 
> > -- 
> > -bill!
> > Sent from my computer
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> -- 
> -bill!
> Sent from my computer
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Is this warning harmless?

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

On Wed, Nov 03, 2021 at 09:27:36PM -0700, Bill Kendrick wrote:
> On Tue, Nov 02, 2021 at 09:44:39PM +0900, TOYAMA Shin-ichi wrote:
> > Hi,
> > 
> > I think the reason for this warning is that the size of wchar_t is
> > 4 bytes on linux but 2 bytes on windows.
> > 
> > I don't know what render_text_w() is doing, so I'm not sure if
> > this is the problem or not.
> > 
> > For example, the text circled in red in onscreen_keyboard (see 
> > attached) does not seem to be rendered on windows.
> > 
> > Does this seem relevant ?
> 
> Hrm, we have some clues about this in the code from John P. from
> way back in 2006:
> 
>   https://sourceforge.net/p/tuxpaint/tuxpaint/ci/304f49672/
> 
> Specifically, this part of the commit message:
> 
>   Modified the text gadget so that it correctly handles the 16-bit unicode
>   characters that SDL sends. The text buffer is held internally as an array
>   of wchar_t, and makes uses of various wide-character functions.
>   It is converted back into 16-bit unicode characters to satisfy SDL_ttf.
>   Tested on Windows and Linux.
> 
> And it's this function:
> 
>   // This conversion is required on platforms where Uint16 doesn't match wchar_t.
>   // On Windows, wchar_t is 16-bit, elsewhere it is 32-bit.
>   // Mismatch caused by the use of Uint16 for unicode characters by SDL, SDL_ttf.
>   // I guess wchar_t is really only suitable for internal use ...
>   static Uint16 *wcstou16(const wchar_t *str)
>   ...
> 
> It is used in exactly one place, within render_text_w():
> 
>   if (font->typ == FONT_TYPE_TTF)
>     {
>       ustr = wcstou16(str);
>       ret = TTF_RenderUNICODE_Blended(font->ttf_font, ustr, color);
>       free(ustr);
>     }
> 
> 
> However, we're talking about the bit of code that constructs
> UTF-8 Unicode within Tux Paint, to deliver it to SDL_Pango.
> 
> I think it might be worth replacing `wchar` with something
> like Uint32 for these purposes...

Ugh, so another problem I'm seeing is we actually store strings
in `wchar` form as the Label tool's text inside the PNG images.

I assume that, because of this, Tux Paint pictures drawn on
Linux might not work under Tux Paint on Windows, and vice-versa,
due to the different sizes (16- vs 32-bit).



Back to the issue at hand, it actually seems like anything about
0xFFFF isn't really useful to us.

  https://unicodebook.readthedocs.io/unicode.html#unicode-categories

says:

  There are 3 ranges reserved for private use (Co subcategory):
  U+E000 - U+F8FF (6,400 code points), U+F0000 - U+FFFFD (65,534) and
  U+100000 - U+10FFFD (65,534). Surrogates (Cs subcategory) use the
  range U+D800 - U+DFFF (2,048 code points).

I'm thinking it's probably safe to just ignore str[] values above
0xFFFF (which are impossible on environments, like Windows, with
16-bit `wchar`).

I'll see what happens on Linux.  If it seems okay, I'll commit, and
you can test things on Windows.


Regarding those characters that did not appear in the OSK for you,
I made the above discover by simply replacing the code that converts
any >= 0x00010000 values in str[] to UTF-8, for sending to SDL_Pango,
and just doing this:

  utfstr[j++] = 'X';

...But I could still see the symbols (and not an "X"). :)

Perhaps that's a font issue?  Can you play around with it?


-bill!


> 
> I'm digging around the code right now.
> 
> -bill!
> 
> 
> > 
> > 
> > TOYAMA Shin-ichi wrote in <617e94b2.5007%sh...@wm...>
> > >Hi,
> > >
> > >Recently, I've been dealing with a lot of bugs in the Windows
> > >version, and I've noticed that many clue of the bugs had been 
> > >appeared in the compile-time warnings.
> > >
> > >So,I checked the warnings again, and the following warning,
> > >which does not appear when compiling on Linux, caught my 
> > >attention.
> > >
> > >------------------------------------------------------------
> > >src/tuxpaint.c: In function 'render_text_w':
> > >src/tuxpaint.c:1685:27: warning: comparison is always true due to limited range 
> > >of data type [-Wtype-limits]
> > > 1685 |           else if (str[i] <= 0x0000FFFF)
> > >------------------------------------------------------------
> > >
> > >If this warning is correct, it means that the next conditional
> > >branch (0x00100000 - 001FFFFF) will never be reached.
> > >
> > >How can I confirm if it were a problem or not?
> > >
> > >Thanks!
> > 
> > -- 
> > TOYAMA Shin-ichi mailto:sh...@wm...
> 
> 
> 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> 
> -- 
> -bill!
> Sent from my computer
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Is this warning harmless?

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

On Tue, Nov 02, 2021 at 09:44:39PM +0900, TOYAMA Shin-ichi wrote:
> Hi,
> 
> I think the reason for this warning is that the size of wchar_t is
> 4 bytes on linux but 2 bytes on windows.
> 
> I don't know what render_text_w() is doing, so I'm not sure if
> this is the problem or not.
> 
> For example, the text circled in red in onscreen_keyboard (see 
> attached) does not seem to be rendered on windows.
> 
> Does this seem relevant ?

Hrm, we have some clues about this in the code from John P. from
way back in 2006:

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/304f49672/

Specifically, this part of the commit message:

  Modified the text gadget so that it correctly handles the 16-bit unicode
  characters that SDL sends. The text buffer is held internally as an array
  of wchar_t, and makes uses of various wide-character functions.
  It is converted back into 16-bit unicode characters to satisfy SDL_ttf.
  Tested on Windows and Linux.

And it's this function:

  // This conversion is required on platforms where Uint16 doesn't match wchar_t.
  // On Windows, wchar_t is 16-bit, elsewhere it is 32-bit.
  // Mismatch caused by the use of Uint16 for unicode characters by SDL, SDL_ttf.
  // I guess wchar_t is really only suitable for internal use ...
  static Uint16 *wcstou16(const wchar_t *str)
  ...

It is used in exactly one place, within render_text_w():

  if (font->typ == FONT_TYPE_TTF)
    {
      ustr = wcstou16(str);
      ret = TTF_RenderUNICODE_Blended(font->ttf_font, ustr, color);
      free(ustr);
    }


However, we're talking about the bit of code that constructs
UTF-8 Unicode within Tux Paint, to deliver it to SDL_Pango.

I think it might be worth replacing `wchar` with something
like Uint32 for these purposes...

I'm digging around the code right now.

-bill!


> 
> 
> TOYAMA Shin-ichi wrote in <617e94b2.5007%sh...@wm...>
> >Hi,
> >
> >Recently, I've been dealing with a lot of bugs in the Windows
> >version, and I've noticed that many clue of the bugs had been 
> >appeared in the compile-time warnings.
> >
> >So,I checked the warnings again, and the following warning,
> >which does not appear when compiling on Linux, caught my 
> >attention.
> >
> >------------------------------------------------------------
> >src/tuxpaint.c: In function 'render_text_w':
> >src/tuxpaint.c:1685:27: warning: comparison is always true due to limited range 
> >of data type [-Wtype-limits]
> > 1685 |           else if (str[i] <= 0x0000FFFF)
> >------------------------------------------------------------
> >
> >If this warning is correct, it means that the next conditional
> >branch (0x00100000 - 001FFFFF) will never be reached.
> >
> >How can I confirm if it were a problem or not?
> >
> >Thanks!
> 
> -- 
> TOYAMA Shin-ichi mailto:sh...@wm...



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


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Is this warning harmless?

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

Hi,

I think the reason for this warning is that the size of wchar_t is
4 bytes on linux but 2 bytes on windows.

I don't know what render_text_w() is doing, so I'm not sure if
this is the problem or not.

For example, the text circled in red in onscreen_keyboard (see 
attached) does not seem to be rendered on windows.

Does this seem relevant ?


TOYAMA Shin-ichi wrote in <617e94b2.5007%sh...@wm...>
>Hi,
>
>Recently, I've been dealing with a lot of bugs in the Windows
>version, and I've noticed that many clue of the bugs had been 
>appeared in the compile-time warnings.
>
>So,I checked the warnings again, and the following warning,
>which does not appear when compiling on Linux, caught my 
>attention.
>
>------------------------------------------------------------
>src/tuxpaint.c: In function 'render_text_w':
>src/tuxpaint.c:1685:27: warning: comparison is always true due to limited range 
>of data type [-Wtype-limits]
> 1685 |           else if (str[i] <= 0x0000FFFF)
>------------------------------------------------------------
>
>If this warning is correct, it means that the next conditional
>branch (0x00100000 - 001FFFFF) will never be reached.
>
>How can I confirm if it were a problem or not?
>
>Thanks!

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

Re: [Tuxpaint-devel] Crash of Tuxpaint

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

Hi Marie,

Can you try deleting the config files?

There are two config files:

   - /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
   - /Library/Application Support/TuxPaint/tuxpaint.cfg

Thanks!


On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm...>
wrote:

> hello,
>
> I am running it in english, right out of the download, with default
> presets (i did try to change some config with tuxpaint config but as it was
> crashing, i disinstalled it and downloaded it again). It launches and
> crashes after 2 seconds on the loading screen.
>
>
>
> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm...> wrote:
>
> 
> Hi Marie,
>
> I noticed it crashes sometimes in Japanese or Korean mode. In what
> language are you running Tux Paint in?
>
>
> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm...>
> wrote:
>
>> Hello,
>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur
>> but it crashes immediately when I launch it…Has anyone had the same issue?
>> I used no config and no added stamps… Any lead as of what could the issue
>> be?
>>
>> Thankyou
>> Marie
>>
>>
>> _______________________________________________
>> 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] Crash of Tuxpaint

[Marie V. <mar...@gm...>]

hello,

I am running it in english, right out of the download, with default presets (i did try to change some config with tuxpaint config but as it was crashing, i disinstalled it and downloaded it again). It launches and crashes after 2 seconds on the loading screen. 



> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm...> wrote:
> 
> 
> Hi Marie,
> 
> I noticed it crashes sometimes in Japanese or Korean mode. In what language are you running Tux Paint in?
> 
> 
>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm...> wrote:
>> Hello, 
>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur but it crashes immediately when I launch it…Has anyone had the same issue? I used no config and no added stamps… Any lead as of what could the issue be? 
>> 
>> Thankyou 
>> Marie 
>> 
>> 
>> _______________________________________________
>> 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] Crash of Tuxpaint

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

Hi Marie,

I noticed it crashes sometimes in Japanese or Korean mode. In what language
are you running Tux Paint in?


On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm...>
wrote:

> Hello,
> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur
> but it crashes immediately when I launch it…Has anyone had the same issue?
> I used no config and no added stamps… Any lead as of what could the issue
> be?
>
> Thankyou
> Marie
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Crash of Tuxpaint

[Marie V. <mar...@gm...>]

Hello, 
I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur but it crashes immediately when I launch it…Has anyone had the same issue? I used no config and no added stamps… Any lead as of what could the issue be? 

Thankyou 
Marie 

[Tuxpaint-devel] Is this warning harmless?

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

Hi,

Recently, I've been dealing with a lot of bugs in the Windows
version, and I've noticed that many clue of the bugs had been 
appeared in the compile-time warnings.

So,I checked the warnings again, and the following warning,
which does not appear when compiling on Linux, caught my 
attention.

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

If this warning is correct, it means that the next conditional
branch (0x00100000 - 001FFFFF) will never be reached.

How can I confirm if it were a problem or not?

Thanks!

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

Re: [Tuxpaint-devel] Added trashcan support for windows

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

Hi, 

Now I think that "Move to recycle bin" is ready for the tests.
I tested it on Windows 11 and Windows 7 (on VMware) and
confirmed it works fine.

Packages prepared for testers (ver. 20211031) are available 
from;

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

Careful tests by users who are using different versions of windows 
are welcome.

Thanks!

TOYAMA Shin-ichi wrote in <617dffba.5005%sh...@wm...>
>Hi,
>
>I think win32_trash() is currently far from  testing stage
>so far.
>It fails sometime but not always on windows 11, and always
>crashes on windows7...
>
>Microsoft says SHFileOperation() is obsolate and recommends
>to use IFileOperation() instead.
>
>https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shfileoperationa
>
>However, I have not been able to find how to use it from C 
>language on MinGW/MSYS2 environment.
>
>I will let you know when it becomes more stable.
>
>Thanks!
>
>Bill Kendrick wrote in <202...@sh...>
>>On Sat, Oct 30, 2021 at 12:54:52PM +0900, TOYAMA Shin-ichi wrote:
>>> Windows packages for the tests built from current git(20211030) 
>>> are now available.
>>> 
>>> See https://z1.plala.jp/tuxpaint/testing/
>>
>>Hi Shin-ichi,
>>
>>I see that you since committed a change that disables the new code,
>>due to instability.
>>
>>Did you need any more specific testing by others?  I'm totally
>>unfamiliar with Win32 development, or how the different versions
>>of Windows differ from each other, so I'm wondering whether you
>>want me to look for more beta testers (say, via Twitter, Facebook,
>>and/or the 'tuxpaint-users' mailing list).  Let me know!
>>
>>-bill!
>>
>>
>>> TOYAMA Shin-ichi wrote in <617aabc7.5001%sh...@wm...>
>>> >Hi,
>>> >
>>> >I created very primitive code to use trashcan on windows and 
>>> >commited it to the git.
>>> >
>>> >It seems to work here, but I think carefull test and review are 
>>> >required.
>>> >
>>> >Just for your information.
>><snip>
>>
>>
>>_______________________________________________
>>Tuxpaint-devel mailing list
>>Tux...@li...
>>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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

Re: [Tuxpaint-devel] Added trashcan support for windows

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

Hi,

I think win32_trash() is currently far from  testing stage
so far.
It fails sometime but not always on windows 11, and always
crashes on windows7...

Microsoft says SHFileOperation() is obsolate and recommends
to use IFileOperation() instead.

https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shfileoperationa

However, I have not been able to find how to use it from C 
language on MinGW/MSYS2 environment.

I will let you know when it becomes more stable.

Thanks!

Bill Kendrick wrote in <202...@sh...>
>On Sat, Oct 30, 2021 at 12:54:52PM +0900, TOYAMA Shin-ichi wrote:
>> Windows packages for the tests built from current git(20211030) 
>> are now available.
>> 
>> See https://z1.plala.jp/tuxpaint/testing/
>
>Hi Shin-ichi,
>
>I see that you since committed a change that disables the new code,
>due to instability.
>
>Did you need any more specific testing by others?  I'm totally
>unfamiliar with Win32 development, or how the different versions
>of Windows differ from each other, so I'm wondering whether you
>want me to look for more beta testers (say, via Twitter, Facebook,
>and/or the 'tuxpaint-users' mailing list).  Let me know!
>
>-bill!
>
>
>> TOYAMA Shin-ichi wrote in <617aabc7.5001%sh...@wm...>
>> >Hi,
>> >
>> >I created very primitive code to use trashcan on windows and 
>> >commited it to the git.
>> >
>> >It seems to work here, but I think carefull test and review are 
>> >required.
>> >
>> >Just for your information.
><snip>
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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

Re: [Tuxpaint-devel] Added trashcan support for windows

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

On Sat, Oct 30, 2021 at 12:54:52PM +0900, TOYAMA Shin-ichi wrote:
> Windows packages for the tests built from current git(20211030) 
> are now available.
> 
> See https://z1.plala.jp/tuxpaint/testing/

Hi Shin-ichi,

I see that you since committed a change that disables the new code,
due to instability.

Did you need any more specific testing by others?  I'm totally
unfamiliar with Win32 development, or how the different versions
of Windows differ from each other, so I'm wondering whether you
want me to look for more beta testers (say, via Twitter, Facebook,
and/or the 'tuxpaint-users' mailing list).  Let me know!

-bill!


> TOYAMA Shin-ichi wrote in <617aabc7.5001%sh...@wm...>
> >Hi,
> >
> >I created very primitive code to use trashcan on windows and 
> >commited it to the git.
> >
> >It seems to work here, but I think carefull test and review are 
> >required.
> >
> >Just for your information.
<snip>

Re: [Tuxpaint-devel] Added trashcan support for windows

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

Windows packages for the tests built from current git(20211030) 
are now available.

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

Thanks!

TOYAMA Shin-ichi wrote in <617aabc7.5001%sh...@wm...>
>Hi,
>
>I created very primitive code to use trashcan on windows and 
>commited it to the git.
>
>It seems to work here, but I think carefull test and review are 
>required.
>
>Just for your information.
>
>Thanks

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

[Tuxpaint-devel] Added trashcan support for windows

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

Hi,

I created very primitive code to use trashcan on windows and 
commited it to the git.

It seems to work here, but I think carefull test and review are 
required.

Just for your information.

Thanks

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

[Tuxpaint-devel] More Magic tools offering full-image mode

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

A few more Magic tools can now affect the full image
all at once.  (One click to operate on the picture,
rather than having to click and drag all over the entire
picture.)

A few were added this evening.  The following Tweet shows
some of them:

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

Translators, new strings were created and are now in the POT file.
("Click to <do x> to your entire picture.",
versus "Click and drag around to <do x> to your picture.")

Thanks!

PS - I discovered (via a crash!) that Tux Paint was not calling
magic tools' "switchout" and "switchin" functions when you
change between magic tool groups, which was an oversight that
I corrected this evening, as well.

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

On Tue, Oct 26, 2021 at 11:43:34PM +0900, TOYAMA Shin-ichi wrote:
> Thanks bill,
> 
> I think it is fixed.
> What I did was, again, to simply remove the windows-specific 
> parts in which _nl_locale_name() is called.

Great!  (And thanks for noting my late-night #ifdef typo)


> I committed it to the git and prepared 0.9.26-6 packages although 
> I am not sure if it is neccesary.
> 
>   https://z1.plala.jp/tuxpaint/release/0.9.26-6/

Fetching, and will post to SourceForge.


> In these days, multiple bugs on $B#w(Bindows build unrelated to each 

Heh, in Mutt mail client your "W" came out as a bunch of crazy ASCII,
so it looked like you were cursing Windows.  I guess Emacs editor is
better at rendering it.


> other have become apparent, causing a lot of confusion, but I hope
> this will settle things down for a while ;-).

Yes, thanks so much for toiling over this.  And thanks again to Pere
and others for helping, as well!

6th time's the charm?

-bill!


> 
> Thanks,
> 
> 
> Bill Kendrick wrote in <202...@sh...>
> >On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote:
> >> Hi developpers,
> >> 
> >> At first, please take note that the problem is that 64bit
> >> executable for windows crash when it start unless specific locale 
> >> is set by config/command line option/environment variable.
> >> 
> >> I found that the crash occurs in mysetenv() in i18n.c when 
> >> strlen(value) is called.
> >
> >This probably won't "fix" the overall issue that's causing
> >the crash, but I've updated mysetenv() to be lest trusting of
> >its incoming arguments.  If either `name` and/or `value` is NULL,
> >it will avoid doing anything dangerous with them, and spit out
> >a warning to STDERR.
> >
> >  
> >https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/
> >
> >-bill!
> 
> -- 
> TOYAMA Shin-ichi mailto:sh...@wm...

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

Thanks bill,

I think it is fixed.
What I did was, again, to simply remove the windows-specific 
parts in which _nl_locale_name() is called.

I committed it to the git and prepared 0.9.26-6 packages although 
I am not sure if it is neccesary.

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

In these days, multiple bugs on ｗindows build unrelated to each 
other have become apparent, causing a lot of confusion, but I hope
this will settle things down for a while ;-).

Thanks,


Bill Kendrick wrote in <202...@sh...>
>On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote:
>> Hi developpers,
>> 
>> At first, please take note that the problem is that 64bit
>> executable for windows crash when it start unless specific locale 
>> is set by config/command line option/environment variable.
>> 
>> I found that the crash occurs in mysetenv() in i18n.c when 
>> strlen(value) is called.
>
>This probably won't "fix" the overall issue that's causing
>the crash, but I've updated mysetenv() to be lest trusting of
>its incoming arguments.  If either `name` and/or `value` is NULL,
>it will avoid doing anything dangerous with them, and spit out
>a warning to STDERR.
>
>  
>https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/
>
>-bill!

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

Re: [Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

On Mon, Oct 25, 2021 at 01:30:01PM -0400, Mark K. Kim wrote:
> >  I found that the crash occurs in mysetenv() in i18n.c when
> > strlen(value) is called.
> 
> I'm not sure if it's related, but getenv/putenv are known to be not
> thread-safe, and we do use them liberally and do use threads at
> initialization.

Well here it sounds like `value` is coming back as NULL or garbage,
hence Shin-ichi's `printf("%s", loc);` also crashing.

The place where `_nl_locale_name()` is called is within `i18n.c`'s
`set_current_language()` function, which in turn is called by that
same source file's `setup_i18n()` function.

`setup_i18n` is called, in `tuxpaint.c`, within `setup_config()`.
This gets called in `main()` _before_ our own threading stuff happens
("FORKED_FONTS").

So I don't think that's the issue...


Shin-ichi, I wonder if it'd be sufficient to just check whether
`_nl_locale_name()` returns NULL.  If so, we can set `loc` to "C",
like so (maybe? I'm struggling to remember how all this works):

...
#ifdef _WIN32
  if (!*loc) {
    loc = _nl_locale_name(LC_MESSAGES, "");
    if (loc == NULL) {
      loc = strdup("C");
    }
  }
#else           
...


-bill!


> On Mon, Oct 25, 2021 at 11:24 AM TOYAMA Shin-ichi <sh...@wm...>
> wrote:
> 
> > Hi developpers,
> >
> > At first, please take note that the problem is that 64bit
> > executable for windows crash when it start unless specific locale
> > is set by config/command line option/environment variable.
> >
> > I found that the crash occurs in mysetenv() in i18n.c when
> > strlen(value) is called.
> >
> > The address of the string 'value' is passed from 'loc' which is
> > set by calling _nl_locale_name() in set_current_language().
> >
> > I checked the return value 'loc' from _nl_locale_name() by;
> >
> >   printf("%s", loc);
> >
> > It results "ja_JP" on 32bit executable but, crash occurs on 64bit
> > version.
> >
> > I am quite at a loss how I should do so far.
> >
> > Anyway, I think it would be better to stop releasing the 64bit
> > version until this will be fixed.
> >
> > Thanks.
> >
> > Bill Kendrick wrote in <202...@sh...>
> > >On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
> > >> By the way, workaround for this is to set language to something
> > >> other than (Use system's setting) by tuxpaint-config, so far.
> > >
> > >Very interesting!  Thanks, Shin-ichi.  I had a person email me
> > >this evening mentioning TP won't start on their new Win11 system,
> > >so I've suggested this work-around.  (I'll let you know if they
> > >tell me that it _didn't_ help :) )
> > >
> > >-bill!
> > >
> > >
> > >>
> > >> 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...
> > >>
> > >>
> > >> _______________________________________________
> > >> Tuxpaint-devel mailing list
> > >> Tux...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >
> > --
> > TOYAMA Shin-ichi mailto:sh...@wm...
> >
> >
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Angles displayed when drawing lines & rotating shapes

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

Tux Paint will now tell the user the angle of their line,
in the Lines tool, or the angle they have rotated their shape,
in the Shapes tool (normal, non-simplified mode).

Developers, please try it out and let me know if you notice
any issues.

Translators, a pair of new strings have been added that include
the angle messages for these tools.  (There have also been a few
other new strings added recently.)

Please "git pull" and update your PO files, or download an updated
POT and PO file from http://www.tuxpaint.org/help/po/, and send
your updates to me (or the list) so I (or someone else out here)
can commit them for you.

Thanks! :)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

On Tue, Oct 26, 2021 at 12:23:45AM +0900, TOYAMA Shin-ichi wrote:
> Hi developpers,
> 
> At first, please take note that the problem is that 64bit
> executable for windows crash when it start unless specific locale 
> is set by config/command line option/environment variable.
> 
> I found that the crash occurs in mysetenv() in i18n.c when 
> strlen(value) is called.

This probably won't "fix" the overall issue that's causing
the crash, but I've updated mysetenv() to be lest trusting of
its incoming arguments.  If either `name` and/or `value` is NULL,
it will avoid doing anything dangerous with them, and spit out
a warning to STDERR.

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/1bee12246eedd6ddc4790bb5dacdec6b50685a6e/

-bill!

Re: [Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

>  I found that the crash occurs in mysetenv() in i18n.c when
> strlen(value) is called.

I'm not sure if it's related, but getenv/putenv are known to be not
thread-safe, and we do use them liberally and do use threads at
initialization.


On Mon, Oct 25, 2021 at 11:24 AM TOYAMA Shin-ichi <sh...@wm...>
wrote:

> Hi developpers,
>
> At first, please take note that the problem is that 64bit
> executable for windows crash when it start unless specific locale
> is set by config/command line option/environment variable.
>
> I found that the crash occurs in mysetenv() in i18n.c when
> strlen(value) is called.
>
> The address of the string 'value' is passed from 'loc' which is
> set by calling _nl_locale_name() in set_current_language().
>
> I checked the return value 'loc' from _nl_locale_name() by;
>
>   printf("%s", loc);
>
> It results "ja_JP" on 32bit executable but, crash occurs on 64bit
> version.
>
> I am quite at a loss how I should do so far.
>
> Anyway, I think it would be better to stop releasing the 64bit
> version until this will be fixed.
>
> Thanks.
>
> Bill Kendrick wrote in <202...@sh...>
> >On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
> >> By the way, workaround for this is to set language to something
> >> other than (Use system's setting) by tuxpaint-config, so far.
> >
> >Very interesting!  Thanks, Shin-ichi.  I had a person email me
> >this evening mentioning TP won't start on their new Win11 system,
> >so I've suggested this work-around.  (I'll let you know if they
> >tell me that it _didn't_ help :) )
> >
> >-bill!
> >
> >
> >>
> >> 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...
> >>
> >>
> >> _______________________________________________
> >> Tuxpaint-devel mailing list
> >> Tux...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
> --
> TOYAMA Shin-ichi mailto:sh...@wm...
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Locale detection problem on 64bit version for windows.

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

Hi developpers,

At first, please take note that the problem is that 64bit
executable for windows crash when it start unless specific locale 
is set by config/command line option/environment variable.

I found that the crash occurs in mysetenv() in i18n.c when 
strlen(value) is called.

The address of the string 'value' is passed from 'loc' which is
set by calling _nl_locale_name() in set_current_language().

I checked the return value 'loc' from _nl_locale_name() by;

  printf("%s", loc);

It results "ja_JP" on 32bit executable but, crash occurs on 64bit 
version.

I am quite at a loss how I should do so far.

Anyway, I think it would be better to stop releasing the 64bit
version until this will be fixed.

Thanks.

Bill Kendrick wrote in <202...@sh...>
>On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
>> By the way, workaround for this is to set language to something 
>> other than (Use system's setting) by tuxpaint-config, so far.
>
>Very interesting!  Thanks, Shin-ichi.  I had a person email me
>this evening mentioning TP won't start on their new Win11 system,
>so I've suggested this work-around.  (I'll let you know if they
>tell me that it _didn't_ help :) )
>
>-bill!
>
>
>> 
>> 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...
>> 
>> 
>> _______________________________________________
>> 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?

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

On Mon, Oct 25, 2021 at 12:53:48AM +0900, TOYAMA Shin-ichi wrote:
> By the way, workaround for this is to set language to something 
> other than (Use system's setting) by tuxpaint-config, so far.

Very interesting!  Thanks, Shin-ichi.  I had a person email me
this evening mentioning TP won't start on their new Win11 system,
so I've suggested this work-around.  (I'll let you know if they
tell me that it _didn't_ help :) )

-bill!


> 
> 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...
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer