tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] iOS port withdrawn

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

Someone on Tumblr noticed that the Apple iOS port of Tux Paint (which
was last updated about 2.5yr ago, last I checked, and was generally
based on Tux Paint 0.9.22, which is now 9 years old) is no longer
showing in the App Store.

I reached out to Mark @ HappyMobile to ask what's up.  In the meantime,
I reminded him that we'd love to get iOS support baked into the upstream
code, and that we've made a ton of new features & enhancements since
0.9.22, especially the port to SDL2 (h/t Pere, Terrence, & Jianwei).

Back in Dec. 2020, he dumped the full source behind his iOS port onto
GitHub, here: https://github.com/happymobilecq/paint -- the date
listed at the top of `src/tuxpaint.c` was April 16, 2014, and
`VER_VERSION` in `Makefile` is `0.9.22`, unsurprisingly.

Presumably, since his iOS port had a few revisions since then (most
recently being Feb. 2021, last I time checked; the App Store page has
gone dark), there might be other changes that didn't land in that
GitHub repo. :shrug:

I'm guessing, with the sea changes in Tux Paint over the past 9 years,
_especially_ the transition from SDL1.2 to SDL2, I'm _guessing_ that
code wouldn't be particularly useful.  But there you have it.

Anyway, I don't know what action to take at this time, other than
remove the iOS link from the main Download page (done), and removing
the link to the dead App Store page at itunes.apple.com (done),
and waiting to hear back from Mark @ HM.

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Fwd: Interviews with Tux Paint artists

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

I just posted this to the tuxpaint-users list, but wanted to
share with the other developers as well.  There are some really
great stories that I think you'll enjoy. :)

----- Forwarded message from Bill Kendrick <nb...@so...> -----

I've been interviewing artists who use Tux Paint, to find out their
backstory, how and why they use it, their favorite tools, what
inspires their art, etc.

They were done as a kind of Q&A over email.  I've asked over a dozen
people to participate, and so far 11 have agreed!  Eight of them have
sent their responses back already, and I've been posting them to the
Tux Paint website once every day or so.  (Three are live so far.)

You can find them here.  Check back now and then for new ones!

  https://tuxpaint.org/interviews/


-- 
-bill!
Sent from my computer

----- End forwarded message -----

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Doesn't compile on Rocky9

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

On Fri, Jun 23, 2023 at 05:34:16PM -0400, Mark Kim wrote:
> On Fri, Jun 23, 2023 at 2:26 AM Bill Kendrick <nb...@so...> wrote:
> 
> > How's the macOS side of things, warning-wise?
> 
> 
> Needed to upgrade librsvg (was on librsvg 2.40) but it's ok now.
> (Unfortunately upgrading a single library involved recompiling 96 packages
> from source over 2 evenings but it's done!)

Oh wow!  Yikes, thanks for your efforts!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Doesn't compile on Rocky9

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

On Fri, Jun 23, 2023 at 2:26 AM Bill Kendrick <nb...@so...> wrote:

> How's the macOS side of things, warning-wise?


Needed to upgrade librsvg (was on librsvg 2.40) but it's ok now.
(Unfortunately upgrading a single library involved recompiling 96 packages
from source over 2 evenings but it's done!)

Re: [Tuxpaint-devel] Doesn't compile on Rocky9

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

On Thu, Jun 22, 2023 at 10:48:57PM -0400, Mark Kim wrote:
> I'm getting a warning on Ubuntu 20.04.1 LTS about the use of a deprecated
> function "rsvg_handle_close".  Ubuntu 20.04.1 LTS  comes with librsvg
> 2.48.9.
> The warning occurs several times while compiling tuxpaint.c but here is one
> example:
> 
> src/tuxpaint.c:21011:5: warning: ‘rsvg_handle_close’ is deprecated: Use
> 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
> 21011 |     rsvg_handle_close(rsvg_handle, &gerr);
>       |     ^~~~~~~~~~~~~~~~~
> In file included from src/tuxpaint.c:516:
> /usr/include/librsvg-2.0/librsvg/rsvg.h:192:14: note: declared here
>   192 | gboolean     rsvg_handle_close  (RsvgHandle *handle, GError
> **error);
>       |              ^~~~~~~~~~~~~~~~~
> 
> 
> librsvg source says
> <https://gitlab.gnome.org/GNOME/librsvg/-/blob/main/include/librsvg/rsvg.h#L599>
> rsvg_handle_close
> was deprecated in librsvg 2.46.

Thanks.  Yeah, this is a known one.  I still need to work to replace it.

How's the macOS side of things, warning-wise?

Thanks!

-bill!

Re: [Tuxpaint-devel] Doesn't compile on Rocky9

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

I'm getting a warning on Ubuntu 20.04.1 LTS about the use of a deprecated
function "rsvg_handle_close".  Ubuntu 20.04.1 LTS  comes with librsvg
2.48.9.
The warning occurs several times while compiling tuxpaint.c but here is one
example:

src/tuxpaint.c:21011:5: warning: ‘rsvg_handle_close’ is deprecated: Use
'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21011 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
In file included from src/tuxpaint.c:516:
/usr/include/librsvg-2.0/librsvg/rsvg.h:192:14: note: declared here
  192 | gboolean     rsvg_handle_close  (RsvgHandle *handle, GError
**error);
      |              ^~~~~~~~~~~~~~~~~


librsvg source says
<https://gitlab.gnome.org/GNOME/librsvg/-/blob/main/include/librsvg/rsvg.h#L599>
rsvg_handle_close
was deprecated in librsvg 2.46.

Mark

On Thu, Jun 22, 2023 at 1:20 AM Bill Kendrick <nb...@so...> wrote:

> On Thu, Jun 22, 2023 at 08:24:41AM +0900, Shin-ichi TOYAMA wrote:
> > Just a brief report
> >
> > Current git tree fails to link due to an "undefined reference" error
> > to `rsvg_handle_get_intrinsic_size_in_pixels' on Rocky Linux 9
> >
> > May be a library bug on the distro??
>
> Hrm, that function was apparently added in RSVG 2.52.
> What version does Rocky Linux 9 have?  Perhaps, for a while at least,
> we may need to support using either rsvg_handle_get_dimensions()
> (deprecated nowadays) or rsvg_handle_get_intrinsic_size_in_pixels(),
> depending on which version of RSVG is in use.
>
> I'll see if I can figure out an #ifdef test.  Thanks for reporting!
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Moving from SDL 1.2 to SDL 2.0

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

On Thu, Jun 22, 2023 at 07:40:00PM +0200, Karl Ove Hufthammer wrote:
> I stumbled upon this:
> https://www.phoronix.com/news/SDL2-To-Maintenance-Mode
> 
> But there’s no rush in updating the code to SDL 3. There haven’t
> even been an official release yet. And there will be an
> ‘sdl2-compat’ compatibility library.

Yeah.  We survived on SDL1.2 for such a long time, that hopefully
we can stick with SDL2 for a while... I like remaining compatible
with older platforms & equipment, since not everyone (esp. schools)
have the luxury to upgrade to the latest gear. :)

I _am_ a little disappointed that it seems we won't get pressure
sensitivity for a while, but oh well, it's not world-ending (see above).

The SDL project has always impressed me (I've also had the pleasure of
meeting a few of the fine folks who maintain it!), and I'm glad I
stumbled upon it oh-so-many-years-ago :)

-bill!

Re: [Tuxpaint-devel] Moving from SDL 1.2 to SDL 2.0

[Karl O. H. <ka...@hu...>]

I stumbled upon this:
https://www.phoronix.com/news/SDL2-To-Maintenance-Mode

But there’s no rush in updating the code to SDL 3. There haven’t even 
been an official release yet. And there will be an ‘sdl2-compat’ 
compatibility library.


Karl Ove Hufthammmer


scottmc skreiv 29.09.2021 19:33:
>> Looks fine to me, we will have to decide what to do with SDL2_Pango,
>> I include its sources in the Android port but it is not in any Linux
>> distribution that I know, and the original SDL_Pango project seems
>> stalled long ago.
>>
>> my 2 cents
>> Pere
>>
>>
> @Pere,
> Maybe try contacting the last known maintainer for SDL_Pango and see
> what they think?  Did you convert it to be SDL2_Pango, and if not who
> did?  Maybe SDL org can add SDL2_Pango to their github
> (https://github.com/libsdl-org), that way distributions wishing to
> have it available can have somewhere to send pull requests to add any
> patches they may need.
>
> -Scott
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Per-locale default font

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

On Thu, Jun 22, 2023 at 11:03:05PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> On Wed, 21 Jun 2023 22:57:59 -0700, Bill Kendrick wrote:
> 
> >Please tell me if it throws fewer warnings now, and hopefully
> >also still builds and runs properly.
> >
> >This goes for everyone!  (Mark, Pere, Luc :) )
> 
> All your fix worked as expected and it builds and runs properly
> both on Windows and Rocky9.

<WHEW!>  Thanks. :)  Tim has some additonal Makefile tweaks related
to icons/launchers (affects Linux (POSIX I suppose I should say?) only).

I'll work on integrating those changes this evening.

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Per-locale default font

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

Hi!

On Wed, 21 Jun 2023 22:57:59 -0700, Bill Kendrick wrote:

>Please tell me if it throws fewer warnings now, and hopefully
>also still builds and runs properly.
>
>This goes for everyone!  (Mark, Pere, Luc :) )

All your fix worked as expected and it builds and runs properly
both on Windows and Rocky9.

Thanks!

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

Re: [Tuxpaint-devel] Per-locale default font

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

On Mon, Jun 19, 2023 at 08:26:46AM +0900, Shin-ichi TOYAMA wrote:
> On Sun, 18 Jun 2023 13:38:35 -0700, Bill Kendrick wrote:
> >It's doubtful I'll get to it today, as I've got an engagement in a
> >bit, but it's nice to get use closer to 'zero warnings' when
> >compiling.
> >
> >At least, that's what it looks like for ME, just doing a plain
> >`make` here on my Kubuntu 22.04 system.  If anyone else is still
> >seeing compiler warnings, please share them so we can try and
> >clean up the codebase.  It's nice for _real_ errors to not be
> >buried in a sea of warnings. :)
> 
> Here are warnings on Windows so far.
> I will see them when I have time.
> 
> src/tuxpaint.c:234:2: warning: #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR" [-Wcpp]
>   234 | #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR"
>       |  ^~~~~~~

Oh, this is our own warning.  It's informative, and wow it's
from forever ago! :^D

  /* Check if features.h did its 'magic', in which case strcasestr() is
     likely available; if not using GNU, you can set HAVE_STRCASESTR to
     avoid trying to redefine it -bjk 2006.06.02 */

  #if !defined(__USE_GNU) && !defined(HAVE_STRCASESTR)
  #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR"

  ... then we declare our own strcasestr() func ...

I, uh, don't see a "features.h" in 'tuxpaint' source these days.
I'm not sure the best solution here, but I'll ignore it for now. :)


> src/tuxpaint.c: In function 'mainloop':
> src/tuxpaint.c:3747:21: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress]
>  3747 |                 if (magics[magic_group][cur_thing].sizes)
>       |                     ^~~~~~
> src/tuxpaint.c:1581:7: note: 'sizes' declared here
>  1581 |   int sizes[MAX_MODES];         /* Whether magic tool accepts sizes */
>       |       ^~~~~
<snip repeats of similar warnigns>

Ah whoops wow yes, these are places where I forgot to change the
reference from "sizes" to "sizes[...]", when I turned it into an
array.  My 'gcc' shows no complaints, unless I actually make it
explicitly test whether it == 1, in which case I get

  warning: comparison between pointer and integer

Just committed an attempt to mend this. :whew:


> src/tuxpaint.c: In function '_load_svg':
> src/tuxpaint.c:21025:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
> 21025 |     rsvg_handle_close(rsvg_handle, &gerr);
>       |     ^~~~~~~~~~~~~~~~~
> In file included from src/tuxpaint.c:517:
> C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
>   605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
>       |          ^~~~~~~~~~~~~~~~~
<snip>

Same for me; see https://sourceforge.net/p/tuxpaint/bugs/278/ :)

I still need to work on it.


> src/tuxpaint.c:26894:15: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> 26894 |       ttffont = TTF_FontFaceFamilyName(getfonthandle(i)->ttf_font);
>       |               ^
> src/tuxpaint.c: In function 'load_embedded_data':

Casting to (char *); see if that helps.


> src/tuxpaint.c:27585:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free]
> 27585 |               free(unc_buff);
>       |               ^~~~~~~~~~~~~~
> src/tuxpaint.c:27581:15: note: call to 'free' here
> 27581 |               free(unc_buff);
>       |               ^~~~~~~~~~~~~~
> src/tuxpaint.c:27646:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free]
> 27646 |               free(unc_buff);
>       |               ^~~~~~~~~~~~~~
> src/tuxpaint.c:27642:15: note: call to 'free' here
> 27642 |               free(unc_buff);
>       |               ^~~~~~~~~~~~~~

I think I fixed it; see if that helps. :)


> src/fonts.c: In function 'TuxPaint_Font_OpenFont':
> src/fonts.c:342:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   342 |     familyname = TTF_FontFaceFamilyName(ttf_font);      /* N.B.: I don't believe we're supposed to free() this... -bjk 2021.10.26 */
>       |                ^

[See above]


> src/fonts.c: In function 'getfonthandle':
> src/fonts.c:1357:20: warning: the comparison will always evaluate as 'true' for the address of 'filename' will never be NULL [-Waddress]
>  1357 |   if (fi->filename != NULL)
>       |                    ^~
> In file included from src/fonts.c:60:
> src/fonts.h:152:9: note: 'filename' declared here
>   152 |   char *filename[4];
>       |         ^~~~~~~~

Attempted a fix (was supposed to be indexing into that array).


> src/dirwalk.c: In function 'tp_ftw':
> src/dirwalk.c:436:2: warning: #warning Failed to see DT_UNKNOWN [-Wcpp]
>   436 | #warning Failed to see DT_UNKNOWN
>       |  ^~~~~~~

This is another case of us echoing a warning.  The comment here is:

  // Linux and BSD can often provide file type info w/o the stat() call

Then it tests for that existing, and does a 'switch/case' block,
testing the "d_type" of the file we see with 'readdir()'.

I don't really remember what's supposed to be going on in here
(or, in fact, if I had much to do with it!  20 years is a long time!),
so I'm going to ignore this one as well.  :shrug:

Please tell me if it throws fewer warnings now, and hopefully
also still builds and runs properly.

This goes for everyone!  (Mark, Pere, Luc :) )

Thanks!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Doesn't compile on Rocky9

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

On Thu, Jun 22, 2023 at 08:24:41AM +0900, Shin-ichi TOYAMA wrote:
> Just a brief report
> 
> Current git tree fails to link due to an "undefined reference" error
> to `rsvg_handle_get_intrinsic_size_in_pixels' on Rocky Linux 9
> 
> May be a library bug on the distro??

Hrm, that function was apparently added in RSVG 2.52.
What version does Rocky Linux 9 have?  Perhaps, for a while at least,
we may need to support using either rsvg_handle_get_dimensions()
(deprecated nowadays) or rsvg_handle_get_intrinsic_size_in_pixels(),
depending on which version of RSVG is in use.

I'll see if I can figure out an #ifdef test.  Thanks for reporting!

-bill!

[Tuxpaint-devel] Doesn't compile on Rocky9

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

Just a brief report

Current git tree fails to link due to an "undefined reference" error
to `rsvg_handle_get_intrinsic_size_in_pixels' on Rocky Linux 9

May be a library bug on the distro??

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

Re: [Tuxpaint-devel] Per-locale default font

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

On Sun, 18 Jun 2023 13:38:35 -0700, Bill Kendrick wrote:
>It's doubtful I'll get to it today, as I've got an engagement in a
>bit, but it's nice to get use closer to 'zero warnings' when
>compiling.
>
>At least, that's what it looks like for ME, just doing a plain
>`make` here on my Kubuntu 22.04 system.  If anyone else is still
>seeing compiler warnings, please share them so we can try and
>clean up the codebase.  It's nice for _real_ errors to not be
>buried in a sea of warnings. :)

Here are warnings on Windows so far.
I will see them when I have time.

src/tuxpaint.c:234:2: warning: #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR" [-Wcpp]
  234 | #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR"
      |  ^~~~~~~
src/tuxpaint.c: In function 'mainloop':
src/tuxpaint.c:3747:21: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress]
 3747 |                 if (magics[magic_group][cur_thing].sizes)
      |                     ^~~~~~
src/tuxpaint.c:1581:7: note: 'sizes' declared here
 1581 |   int sizes[MAX_MODES];         /* Whether magic tool accepts sizes */
      |       ^~~~~
src/tuxpaint.c:4369:23: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress]
 4369 |                   if (magics[magic_group][cur_thing].sizes)
      |                       ^~~~~~
src/tuxpaint.c:1581:7: note: 'sizes' declared here
 1581 |   int sizes[MAX_MODES];         /* Whether magic tool accepts sizes */
      |       ^~~~~
src/tuxpaint.c:5109:21: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress]
 5109 |                 if (magics[grp][cur].sizes)
      |                     ^~~~~~
src/tuxpaint.c:1581:7: note: 'sizes' declared here
 1581 |   int sizes[MAX_MODES];         /* Whether magic tool accepts sizes */
      |       ^~~~~
src/tuxpaint.c: In function '_load_svg':
src/tuxpaint.c:21025:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21025 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
In file included from src/tuxpaint.c:517:
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c:21039:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21039 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c:21053:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21053 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c:21097:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21097 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c:21113:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21113 |     rsvg_handle_close(rsvg_handle, &gerr);
      |     ^~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c:21126:3: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations]
21126 |   rsvg_handle_close(rsvg_handle, &gerr);
      |   ^~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here
  605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error);
      |          ^~~~~~~~~~~~~~~~~
src/tuxpaint.c: In function 'set_label_fonts':
src/tuxpaint.c:26894:15: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
26894 |       ttffont = TTF_FontFaceFamilyName(getfonthandle(i)->ttf_font);
      |               ^
src/tuxpaint.c: In function 'load_embedded_data':
src/tuxpaint.c:27585:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free]
27585 |               free(unc_buff);
      |               ^~~~~~~~~~~~~~
src/tuxpaint.c:27581:15: note: call to 'free' here
27581 |               free(unc_buff);
      |               ^~~~~~~~~~~~~~
src/tuxpaint.c:27646:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free]
27646 |               free(unc_buff);
      |               ^~~~~~~~~~~~~~
src/tuxpaint.c:27642:15: note: call to 'free' here
27642 |               free(unc_buff);
      |               ^~~~~~~~~~~~~~
echo


src/fonts.c: In function 'TuxPaint_Font_OpenFont':
src/fonts.c:342:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  342 |     familyname = TTF_FontFaceFamilyName(ttf_font);      /* N.B.: I don't believe we're supposed to free() this... -bjk 2021.10.26 */
      |                ^
src/fonts.c: In function 'getfonthandle':
src/fonts.c:1357:20: warning: the comparison will always evaluate as 'true' for the address of 'filename' will never be NULL [-Waddress]
 1357 |   if (fi->filename != NULL)
      |                    ^~
In file included from src/fonts.c:60:
src/fonts.h:152:9: note: 'filename' declared here
  152 |   char *filename[4];
      |         ^~~~~~~~


src/dirwalk.c: In function 'tp_ftw':
src/dirwalk.c:436:2: warning: #warning Failed to see DT_UNKNOWN [-Wcpp]
  436 | #warning Failed to see DT_UNKNOWN
      |  ^~~~~~~


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

Re: [Tuxpaint-devel] Per-locale default font

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

On Sun, Jun 18, 2023 at 01:29:55PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> It builds on Windows with no problem. Thanks!
> 
> On linux, it still did not use the fake inkscape.
> 
> I set an executable flag to it and confirmed this seems to work.
> 
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/76a2c5f3fdd8a2ff5c606f373fb134750844208d/

Thanks to you and Mark for testing!  Tim also noticed the
missing chmod (oops, sorry!).  I've asked him to confirm
whether it works as expected when doing a Slackware build
(the goal was to avoid polluting the local system with
fontcache stuff, which Inkscape was causing).

So that leaves Luc confirming whether it still works alright when
building on Haiku.  (And possibly Pere for Android, but maybe not
relevant?)

Speaking of SVG, I've just replaced a couple of the deprecated libRSVG
function calls we've been using, but I haven't dealt with how things
are opened (and hence replacing the rsvg_handle_close() call).
(See https://sourceforge.net/p/tuxpaint/bugs/278/)

It's doubtful I'll get to it today, as I've got an engagement in a
bit, but it's nice to get use closer to 'zero warnings' when
compiling.

At least, that's what it looks like for ME, just doing a plain
`make` here on my Kubuntu 22.04 system.  If anyone else is still
seeing compiler warnings, please share them so we can try and
clean up the codebase.  It's nice for _real_ errors to not be
buried in a sea of warnings. :)

Thanks!

-bill!

Re: [Tuxpaint-devel] Per-locale default font

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

Hi!

It builds on Windows with no problem. Thanks!

On linux, it still did not use the fake inkscape.

I set an executable flag to it and confirmed this seems to work.

https://sourceforge.net/p/tuxpaint/tuxpaint/ci/76a2c5f3fdd8a2ff5c606f373fb134750844208d/


On Sat, 17 Jun 2023 11:46:28 -0700, Bill Kendrick wrote:
>
>Okay, I've created a kind of hybrid solution...
>a shell script, `convert-wrapper.sh`, that Makefile will now
>call (instead of `convert` directly).
>
>_It_ will do the trick of creating a dummy './inkscape'
>and adding '.' (PWD) to $PATH so `convert` will see it.
>
>Please tell me whether this works (I've also asked Tim to test it
>when doing the Slackware build)
>
>  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/
>
>Luc & Mark, can you check it too?  WORST case, there can be
>OS-specific values for the new $(CONVERT) variable in Makefile.
>(I replaced direct calls to "convert" with that, a la $(CC),
>and set the variable to "./convert-wrapper.sh").
>
>Whew, I hope this solves it!  Hoping to get back to fun stuff now!
>
>-bill!
>
>On Sat, Jun 17, 2023 at 10:01:17PM +0900, Shin-ichi TOYAMA wrote:
>> Hi!
>> 
>> On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote:
>> >How do I check if the fake incscape method is working correctly?
>> 
>> I tweaked the fake inkscape to write debug log as follows.
>> 
>> -----------------------------------------------------------------------
>> echo-thumb-starters:
>>         @echo
>>         @echo "...Generating thumbnails for starters..."
>>         @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape
>>         @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape
>>         @echo "exit 1" >> ./inkscape
>>         @chmod 755 ./inkscape
>>         @(eval export PATH="$(shell pwd)":"$(PATH)")
>> -----------------------------------------------------------------------
>> 
>> At first, I tested it on Rocky 9 linux.
>> 
>> It looks like the fake inkscape is not called because the "fake.log" file
>> is not created. I guess modified PATH environment variable here affects only
>> to the subshell.
>> 
>> Next I replaced the "eval" line with the one Mark suggested,
>> 
>> -----------------------------------------------------------------------
>>        $(eval export PATH=$(shell pwd):$(PATH))
>> -----------------------------------------------------------------------
>> 
>> and *got* the "fake.log" file.
>> 
>> On the other hand, both original code and Mark's one did not create the 
>> "fake.log" file on Windows.
>> 
>> Therefore, I simply ran convert command on Linux and Windows. The result was
>> 
>> [ Linux ]
>> ---------------
>> [toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg
>> 'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1
>> /tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008
>> starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000
>> starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022
>> ---------------
>> 
>> [ Windows ]
>> ---------------
>> mingw64:$ convert -verbose  starters/fish_icon.svg fish_icon2.svg
>> starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011
>> starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032
>> ---------------
>> 
>> So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed.
>> 
>> Judging from all above, I suppose we should adopt Mark's correction for "eval" line.
>> 
>> Thanks.
>> 
>> 
>> 
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>


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

Re: [Tuxpaint-devel] Per-locale default font

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

Hi Bill,

On Sat, Jun 17, 2023 at 2:46 PM Bill Kendrick <nb...@so...> wrote:

> Please tell me whether this works (I've also asked Tim to test it
> when doing the Slackware build)
>
>
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/
>
> Luc & Mark, can you check it too?


It builds and runs fine on the macOS.

Thanks,
Mark

Re: [Tuxpaint-devel] Per-locale default font

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

Okay, I've created a kind of hybrid solution...
a shell script, `convert-wrapper.sh`, that Makefile will now
call (instead of `convert` directly).

_It_ will do the trick of creating a dummy './inkscape'
and adding '.' (PWD) to $PATH so `convert` will see it.

Please tell me whether this works (I've also asked Tim to test it
when doing the Slackware build)

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/

Luc & Mark, can you check it too?  WORST case, there can be
OS-specific values for the new $(CONVERT) variable in Makefile.
(I replaced direct calls to "convert" with that, a la $(CC),
and set the variable to "./convert-wrapper.sh").

Whew, I hope this solves it!  Hoping to get back to fun stuff now!

-bill!

On Sat, Jun 17, 2023 at 10:01:17PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote:
> >How do I check if the fake incscape method is working correctly?
> 
> I tweaked the fake inkscape to write debug log as follows.
> 
> -----------------------------------------------------------------------
> echo-thumb-starters:
>         @echo
>         @echo "...Generating thumbnails for starters..."
>         @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape
>         @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape
>         @echo "exit 1" >> ./inkscape
>         @chmod 755 ./inkscape
>         @(eval export PATH="$(shell pwd)":"$(PATH)")
> -----------------------------------------------------------------------
> 
> At first, I tested it on Rocky 9 linux.
> 
> It looks like the fake inkscape is not called because the "fake.log" file
> is not created. I guess modified PATH environment variable here affects only
> to the subshell.
> 
> Next I replaced the "eval" line with the one Mark suggested,
> 
> -----------------------------------------------------------------------
>        $(eval export PATH=$(shell pwd):$(PATH))
> -----------------------------------------------------------------------
> 
> and *got* the "fake.log" file.
> 
> On the other hand, both original code and Mark's one did not create the 
> "fake.log" file on Windows.
> 
> Therefore, I simply ran convert command on Linux and Windows. The result was
> 
> [ Linux ]
> ---------------
> [toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg
> 'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1
> /tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008
> starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000
> starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022
> ---------------
> 
> [ Windows ]
> ---------------
> mingw64:$ convert -verbose  starters/fish_icon.svg fish_icon2.svg
> starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011
> starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032
> ---------------
> 
> So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed.
> 
> Judging from all above, I suppose we should adopt Mark's correction for "eval" line.
> 
> Thanks.
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Per-locale default font

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

Hi!

On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote:
>How do I check if the fake incscape method is working correctly?

I tweaked the fake inkscape to write debug log as follows.

-----------------------------------------------------------------------
echo-thumb-starters:
        @echo
        @echo "...Generating thumbnails for starters..."
        @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape
        @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape
        @echo "exit 1" >> ./inkscape
        @chmod 755 ./inkscape
        @(eval export PATH="$(shell pwd)":"$(PATH)")
-----------------------------------------------------------------------

At first, I tested it on Rocky 9 linux.

It looks like the fake inkscape is not called because the "fake.log" file
is not created. I guess modified PATH environment variable here affects only
to the subshell.

Next I replaced the "eval" line with the one Mark suggested,

-----------------------------------------------------------------------
       $(eval export PATH=$(shell pwd):$(PATH))
-----------------------------------------------------------------------

and *got* the "fake.log" file.

On the other hand, both original code and Mark's one did not create the 
"fake.log" file on Windows.

Therefore, I simply ran convert command on Linux and Windows. The result was

[ Linux ]
---------------
[toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg
'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1
/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008
starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000
starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022
---------------

[ Windows ]
---------------
mingw64:$ convert -verbose  starters/fish_icon.svg fish_icon2.svg
starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011
starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032
---------------

So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed.

Judging from all above, I suppose we should adopt Mark's correction for "eval" line.

Thanks.

Re: [Tuxpaint-devel] Per-locale default font

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

Hi Mark,

It stopped the error, thanks!

Bill, 

Now I newly installed inkscape on the build system.
How do I check if the fake incscape method is working correctly?


On Fri, 16 Jun 2023 14:55:13 -0400, Mark Kim wrote:
>Would this work?
>
>diff --git a/Makefile b/Makefile
>index 331604b1..f5b1497f 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -886,7 +886,7 @@ echo-thumb-starters:
>        @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert
>instead" > ./inkscape
>        @echo "exit 1" >> ./inkscape
>        @chmod 755 ./inkscape
>-       @(eval export PATH="$(shell pwd)":"$(PATH)")
>+       $(eval export PATH=$(shell pwd):$(PATH))
>
> # Create thumbnails for starters
> .PHONY: thumb-starters
>
>
>On Fri, Jun 16, 2023 at 2:00 PM Bill Kendrick <nb...@so...> wrote:
>
>> On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote:
>> > Hi!
>> >
>> > As a workaround on my build environment, I've purged paths containing
>> > spaces and parentheses from the "$PATH" and added paths of symbolic
>> > links from /usr/local/* to actual directories.
>> >
>> > It looks O.K. so far.
>>
>> Thanks.
>>
>> I was actually just thinking out loud in an email to Tim, suggesting
>> perhaps
>> we can just create our own tiny shell script that gets invoked
>> (call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH,
>> so we can have full control over how it works...
>>
>> ...either by doing a similar "inkscape => exit 1", to convince
>> ImageMagick's
>> `convert` to fall back to using `rsvgconvert`...
>>
>> ...or by simply looking at the filename extension of what's being fed to
>> the script by Makefile (we control these files, they are the ones that
>> ship with the source .tar.gz), and either run ImageMagick's `convert` if
>> it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file.
>>
>> Another idea I mulled over was somehow overriding ImageMagick's
>> delegate for SVG, or adding a new delegate and using some kind of prefix,
>> but (1) this is getting way over complicated (compared to a tiny .sh
>> script),
>> and (2) I'm not [very quickly] figuring out how to do that, or whether it's
>> even possible.  (Apparently, ImageMagick can look at a user's personal
>> delegates file, but we'd want it to be even _more_ "local" than that,
>> a file right inside the `tuxpaint` source tree somewhere.)
>> (Basically, after a minute of Googling, I gave up trying to find out. ;) )
>>
>> -bill!
>>
>> >
>> > Thanks.
>> >
>> > On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote:
>> > >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote:
>> > >>> By the way, I had to revert the commit
>> "cf94635713b9dc7977af131a6b3ec89cc872d0e1"
>> > >>> to build Tux Paint on Windows from current git repo because of the
>> error as follows.
>> > >>
>> > >>Ah, I wonder if adding quotes would help.  (I get the feeling the "("
>> in question
>> > >>might be from the "(x86)"?)
>> > >
>> > >Sure, I confirmed that the parentheses and whitespaces in the PATH,
>> which are common
>> > >on Windows, are the evil.
>> > >
>> > >>Does
>> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/
>> > >>help?
>> > >
>> > >Unfortunately it doesn't.
>> > >
>> > >I confirmed that not using 'eval' causes no error after trial and error
>> aproach, but
>> > >I'm not sure if it is a right way or not.
>> > >
>> > >----------------------------------------------------
>> > >-       @(eval export PATH="$(shell pwd)":"$(PATH)")
>> > >+       @export PATH="$(shell pwd)":"$(PATH)"
>> > >----------------------------------------------------
>> > >
>> > >
>> > >_______________________________________________
>> > >Tuxpaint-devel mailing list
>> > >Tux...@li...
>> > >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>> >
>> >
>> > --
>> > Shin-ichi TOYAMA <dol...@wm...>
>> >
>> >
>> > _______________________________________________
>> > Tuxpaint-devel mailing list
>> > Tux...@li...
>> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>> --
>> -bill!
>> Sent from my computer
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>


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

Re: [Tuxpaint-devel] Per-locale default font

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

Would this work?

diff --git a/Makefile b/Makefile
index 331604b1..f5b1497f 100644
--- a/Makefile
+++ b/Makefile
@@ -886,7 +886,7 @@ echo-thumb-starters:
        @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert
instead" > ./inkscape
        @echo "exit 1" >> ./inkscape
        @chmod 755 ./inkscape
-       @(eval export PATH="$(shell pwd)":"$(PATH)")
+       $(eval export PATH=$(shell pwd):$(PATH))

 # Create thumbnails for starters
 .PHONY: thumb-starters


On Fri, Jun 16, 2023 at 2:00 PM Bill Kendrick <nb...@so...> wrote:

> On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote:
> > Hi!
> >
> > As a workaround on my build environment, I've purged paths containing
> > spaces and parentheses from the "$PATH" and added paths of symbolic
> > links from /usr/local/* to actual directories.
> >
> > It looks O.K. so far.
>
> Thanks.
>
> I was actually just thinking out loud in an email to Tim, suggesting
> perhaps
> we can just create our own tiny shell script that gets invoked
> (call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH,
> so we can have full control over how it works...
>
> ...either by doing a similar "inkscape => exit 1", to convince
> ImageMagick's
> `convert` to fall back to using `rsvgconvert`...
>
> ...or by simply looking at the filename extension of what's being fed to
> the script by Makefile (we control these files, they are the ones that
> ship with the source .tar.gz), and either run ImageMagick's `convert` if
> it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file.
>
> Another idea I mulled over was somehow overriding ImageMagick's
> delegate for SVG, or adding a new delegate and using some kind of prefix,
> but (1) this is getting way over complicated (compared to a tiny .sh
> script),
> and (2) I'm not [very quickly] figuring out how to do that, or whether it's
> even possible.  (Apparently, ImageMagick can look at a user's personal
> delegates file, but we'd want it to be even _more_ "local" than that,
> a file right inside the `tuxpaint` source tree somewhere.)
> (Basically, after a minute of Googling, I gave up trying to find out. ;) )
>
> -bill!
>
> >
> > Thanks.
> >
> > On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote:
> > >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote:
> > >>> By the way, I had to revert the commit
> "cf94635713b9dc7977af131a6b3ec89cc872d0e1"
> > >>> to build Tux Paint on Windows from current git repo because of the
> error as follows.
> > >>
> > >>Ah, I wonder if adding quotes would help.  (I get the feeling the "("
> in question
> > >>might be from the "(x86)"?)
> > >
> > >Sure, I confirmed that the parentheses and whitespaces in the PATH,
> which are common
> > >on Windows, are the evil.
> > >
> > >>Does
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/
> > >>help?
> > >
> > >Unfortunately it doesn't.
> > >
> > >I confirmed that not using 'eval' causes no error after trial and error
> aproach, but
> > >I'm not sure if it is a right way or not.
> > >
> > >----------------------------------------------------
> > >-       @(eval export PATH="$(shell pwd)":"$(PATH)")
> > >+       @export PATH="$(shell pwd)":"$(PATH)"
> > >----------------------------------------------------
> > >
> > >
> > >_______________________________________________
> > >Tuxpaint-devel mailing list
> > >Tux...@li...
> > >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >
> >
> > --
> > Shin-ichi TOYAMA <dol...@wm...>
> >
> >
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Per-locale default font

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

On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> As a workaround on my build environment, I've purged paths containing
> spaces and parentheses from the "$PATH" and added paths of symbolic
> links from /usr/local/* to actual directories.
> 
> It looks O.K. so far.

Thanks.

I was actually just thinking out loud in an email to Tim, suggesting perhaps
we can just create our own tiny shell script that gets invoked
(call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH,
so we can have full control over how it works...

...either by doing a similar "inkscape => exit 1", to convince ImageMagick's
`convert` to fall back to using `rsvgconvert`...

...or by simply looking at the filename extension of what's being fed to
the script by Makefile (we control these files, they are the ones that
ship with the source .tar.gz), and either run ImageMagick's `convert` if
it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file.

Another idea I mulled over was somehow overriding ImageMagick's
delegate for SVG, or adding a new delegate and using some kind of prefix,
but (1) this is getting way over complicated (compared to a tiny .sh script),
and (2) I'm not [very quickly] figuring out how to do that, or whether it's
even possible.  (Apparently, ImageMagick can look at a user's personal
delegates file, but we'd want it to be even _more_ "local" than that,
a file right inside the `tuxpaint` source tree somewhere.)
(Basically, after a minute of Googling, I gave up trying to find out. ;) )

-bill!

> 
> Thanks.
> 
> On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote:
> >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote:
> >>> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1"
> >>> to build Tux Paint on Windows from current git repo because of the error as follows.
> >>
> >>Ah, I wonder if adding quotes would help.  (I get the feeling the "(" in question
> >>might be from the "(x86)"?)
> >
> >Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common
> >on Windows, are the evil.
> >
> >>Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/
> >>help?
> >
> >Unfortunately it doesn't.
> >
> >I confirmed that not using 'eval' causes no error after trial and error aproach, but
> >I'm not sure if it is a right way or not.
> >
> >----------------------------------------------------
> >-       @(eval export PATH="$(shell pwd)":"$(PATH)")
> >+       @export PATH="$(shell pwd)":"$(PATH)"
> >----------------------------------------------------
> >
> >
> >_______________________________________________
> >Tuxpaint-devel mailing list
> >Tux...@li...
> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> 
> -- 
> Shin-ichi TOYAMA <dol...@wm...>
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Per-locale default font

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

Hi!

As a workaround on my build environment, I've purged paths containing
spaces and parentheses from the "$PATH" and added paths of symbolic
links from /usr/local/* to actual directories.

It looks O.K. so far.

Thanks.

On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote:
>On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote:
>>> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1"
>>> to build Tux Paint on Windows from current git repo because of the error as follows.
>>
>>Ah, I wonder if adding quotes would help.  (I get the feeling the "(" in question
>>might be from the "(x86)"?)
>
>Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common
>on Windows, are the evil.
>
>>Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/
>>help?
>
>Unfortunately it doesn't.
>
>I confirmed that not using 'eval' causes no error after trial and error aproach, but
>I'm not sure if it is a right way or not.
>
>----------------------------------------------------
>-       @(eval export PATH="$(shell pwd)":"$(PATH)")
>+       @export PATH="$(shell pwd)":"$(PATH)"
>----------------------------------------------------
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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

Re: [Tuxpaint-devel] Per-locale default font

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

On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote:
>> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1"
>> to build Tux Paint on Windows from current git repo because of the error as follows.
>
>Ah, I wonder if adding quotes would help.  (I get the feeling the "(" in question
>might be from the "(x86)"?)

Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common
on Windows, are the evil.

>Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/
>help?

Unfortunately it doesn't.

I confirmed that not using 'eval' causes no error after trial and error aproach, but
I'm not sure if it is a right way or not.

----------------------------------------------------
-       @(eval export PATH="$(shell pwd)":"$(PATH)")
+       @export PATH="$(shell pwd)":"$(PATH)"
----------------------------------------------------

[Tuxpaint-devel] Tux Paint Config. uifont allows manual input, too

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

I've added a "[manual]" entry to the list of UI fonts
in Tux Paint Config.  If you select it, a type-in field
appears below which allows you to enter a price font name.

Useful in case Pango isn't showing you the font (perhaps
you're using TPC on one machine to make a config to share
on a set of other machines with different fonts installed?!)

Also, as you type, if any fonts in the list DO match
(basic strcasestr() comparison), they will be made visible,
encouraging you to just click in the selection box, if they
match what you're looking for.  (e.g., type "free" and
you'll see "FreeMono", "FreeSans", and "FreeSerif" appear.)

It's not super complicated.  It IS a lot better than trying
to use Fl_Input_Choice pulldown menu for this.  (On my system,
any pulldown showing my fonts is a mile long!)

Note: If the manually-entered font matches a font actually
found by pango, then the next time you launch Tux Paint Config.,
it will be simply selected in the menu.

However, if the "uifont" setting doesn't match any of the fonts
found by pango, the menu will automatically have "[manual]"
selected, and the font's name entered in the type-in field.

Hope that all makes sense... I'm pretty beat & need to get
to bed!

-- 
-bill!
Sent from my computer