tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] macOS FontConfig `fonts.conf` parsing (Was re: Windows & Android (& others?) FontConfig `fonts.conf` parsing)

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

On Sat, Feb 22, 2025 at 01:41:35PM -0800, Bill Kendrick wrote:
<snip>
> 
> And I think for _now_, we're all set, for Windows at least...?
> I'll attempt to summon Mark to see whether anything else needs to
> be done on the macOS side. :)

Mark, I'm realizing that Tux Paint for macOS also (like Windows)
ships with its own FontConfig "fonts.conf" XML file.

For the purposes of making fonts available in the Text and Label tools,
beyond those in folders that Tux Paint explicitly scans (in fonts.c's
"load_user_fonts()" function), I recently added some very minimimal
support for parsing FontConfig "fonts.conf" files.  For each "<dir>"
it finds, it will try to load fonts from that path.

In the Tux Paint's "macos/fonts.conf", I see:

    <dir prefix="cwd">Resources/share/tuxpaint/fonts</dir>
    <dir prefix="cwd">Resources/share/tuxpaint/fonts/locale</dir>
    <dir prefix="cwd">share/tuxpaint/fonts</dir>
    <dir prefix="cwd">share/tuxpaint/fonts/locale</dir>
    <dir>~/Library/Application Support/TuxPaint/fonts</dir>
    <dir>~/Library/Application Support/TuxPaint/fonts/locale</dir>
    <dir>/Library/Application Support/TuxPaint/fonts</dir>
    <dir>/Library/Application Support/TuxPaint/fonts/locale</dir>

    <dir>/Library/Fonts</dir>
    <dir>/Network/Library/Fonts</dir>
    <dir>/System/Library/Fonts</dir>

And in "load_user_fonts()", inside an "__APPLE__" #ifdef test, I see
we explicitly load fonts from these paths:

    loadfonts(screen, texture, renderer, "/System/Library/Fonts");
    loadfonts(screen, texture, renderer, "/Library/Fonts");
    loadfonts(screen, texture, renderer, apple_fontsPath());
    loadfonts(screen, texture, renderer, "/usr/share/fonts");
    loadfonts(screen, texture, renderer, "/usr/X11R6/lib/X11/fonts");

...where "apple_fontsPath()" comes from "src/macos.m", and simply
plugs the $HOME env. variable into "%s/Library/Fonts".


My assumption is that, in previous versions of Tux Paint, any fonts
that were added to any other folders listed in "macos/fonts.conf" <dir>
tags (but not explicitly in that hard-coded list in "src/fonts.c")
would NOT be loaded and made available to the Text & Label tools.


Moving forward (0.9.35 & beyond), I'd like for us to consult any
relevant "fonts.conf" files, and load fonts found in any of the
directories specified within (in those "<dir> tags).

So for example, on Linux, I am now parsing any "fonts.conf" found
within:

 * $FONTCONFIG_PATH/ (or "/etc/fonts/", if not set)
 * $XDG_CONFIG_HOME/fontconfig/ (or "$HOME/.config/fontconfig/", if not set)


On macOS, we're currently looking here:

 * $FONTCONFIG_PATH/

Are there other places we should look?  I assume we should try loading the
"fonts.conf" that we ship along with Tux Paint.  Since I don't have a Mac,
I can't really hack on this and test it, so I was hoping you could help. :-)


Specifically, it's this block of code inside Tux Paint's "src/fonts.c":

...
    /* See what dirs fontconfig configuration files point to,
       and try loading fonts from those locations */
    
#if defined(__APPLE__)
    fontconfig_config_paths = malloc_fontconfig_config_paths(1, &num_fontconfig_config_paths);
    if (fontconfig_config_paths != NULL)
    { 
      /* Apple: Look for fonts.conf in $FONTCONFIG_PATH */
      fontconfig_config_paths[0] = malloc(1024);
      snprintf(fontconfig_config_paths[0], 1024, "%s/fonts.conf", getenv("FONTCONFIG_PATH"));
      
      /* FIXME: Apple: Look for the fonts.conf that we ship with Tux Paint for macOS */
    } 
...


Thanks in advance!

-bill!

Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

On Sat, Feb 22, 2025 at 12:04:51PM -0800, Bill Kendrick wrote:
<snip>

PS - I just added support for the "prefix" attribute of the "<dir>"
tags in the "fonts.conf" FontConfig files.

If it's `<dir prefix="xdg">PATH</dir>`, the PATH provided will be
prefixed with either "$XDG_DATA_HOME", or if that isn't set, then
(like we do with the Trash feature) prefixed with "$HOME/.local/share/".

And if it's `<dir prefix="relative">PATH</dir>`, then the PATH
provided will be prefixed with the path of the directory _containing_
the "fonts.conf" that's currently being read.

(See https://www.freedesktop.org/software/fontconfig/fontconfig-user.html)


As I mentioned before, I am NOT parsing any of the 'magic string'
paths that FontConfig seems to allow inside the `<dir>...</dir>` tags,
such as "WINDOWSUSERFONTDIR" or "CUSTOMFONTDIR".  I don't even really
see where they're documented, I just see them (1) in our own "fonts.conf"
that gets supplied with the Windows build, and (2) in the FontConfig code
(see https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fcxml.c)
and at least one comment in a tickets or forums somewhere, which is how I
stumbled across the link to "fcxml.c".

So for the moment, please continue including this in Tux Paint's
"load_user_fonts()" function (which I guess should have really been
named "load user and system fonts" :-) )

...
#ifdef WIN32
    /* Windows: Look for fonts in the system font dir (as defined by Windows registry) */
    homedirdir = GetSystemFontDir();
    loadfonts(screen, texture, renderer, homedirdir);
    
    /* Windows: Look for fonts in the user font dir (as defined by Windows registry) */
    homedirdir = GetUserFontDir();
    if (homedirdir != NULL){
      loadfonts(screen, texture, renderer, homedirdir);
    }
    free(homedirdir); 
...


And I think for _now_, we're all set, for Windows at least...?
I'll attempt to summon Mark to see whether anything else needs to
be done on the macOS side. :)

-bill!

Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

On Sat, Feb 22, 2025 at 11:18:50PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I added the specific code to load fonts stored in user's profile because I had
> thought like AI does that Windows does not use fontconfig to load fonts.
> 
> However, 
> 
<snip>
> 
> once reading this part, I thought you may be right.
> 
> Therefore I pulled your hack and disabled the code to read user's font directory.
> Then, unfortunately,  Tuxpaint does NOT load user's font ;-<
> 
> Just a brief report so far.

I actually decided to NOT mess with your system- and user-font loading
routines, and am just allowing the "fonts.conf" parsing code to just
'fail' when it comes across the special "WINDOWSUSERFONTDIR" and
"WINDOWSFONTDIR" strings (in the <dir> path)...  specifically because
you're already loading directly with your method.  :-)
I think this is fine, at least for now. [1]

I think a good test for you would be to place some new fonts in a folder
somewhere _outside_ of the places Tux Paint is already explicitly searching
(which seems to only be those two locations above).

Launch Tux Paint.  It should NOT find the new fonts, since it has no
reason to be searching the folder where you put them.

Then, add the path of that folder to a "<dir>" section of the "fonts.conf"
that Tux Paint is loading.  So far -- assuming I did it right -- it should
be looking in the "etc/fonts/fonts.conf" inside Tux Paint's own folder
(C:\Program Files\TuxPaint\, I guess?)

Launch Tux Paint again.  It should now find the new fonts... hopefully!

If that works, then we're moving in the right direction.
And in the end, perhaps our OWN "fonts.conf" is the only one we need
to look for, on Windows...? [2]

We could consider looking for them via environment variables [3], but
I suppose until a power user comes along asking for that, it's
probably fine to just keep doing the basic thing we're doing so far.

In the end, refactoring all of this and trying to do it more
consistently would probably be a good idea.  For example on Linux/Unix,
we've got 9 hard-coded paths (mostly in "/usr/share/...") where we
look for fonts, from back in the "SDL_ttf" days (before "SDL_pango").
(And on my laptop, most of them no longer exist... see the
"#define DIRWALK_DEBUG" I just added to `dirwalk.c`, it might be helpful!)

[1] Here's someone using GIMP on Windows who did not want the Windows
    fonts loaded, and the trick was to comment out the "<dir>" entry
    in the "fonts.conf" that ships with GIMP:
    https://www.gimp-forum.net/Thread-Where-the-fonts-come-from

[2] Potentially interesting reading?
    https://blob.pureandapplied.com.au/solved-ffmpeg-fontconfig-woes-on-windows/

[3] "Fontconfig error: Cannot load default config file on Windows"
    https://github.com/bleachbit/bleachbit/issues/901 and related fix:
    "Unset FONTCONFIG_FILE on Windows to always use shipped fonts.conf"
    https://github.com/bleachbit/bleachbit/pull/958/commits/3385952b37d7814c13d5b2619150d34a37c77f20


-bill!

Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

Hi!

I added the specific code to load fonts stored in user's profile because I had
thought like AI does that Windows does not use fontconfig to load fonts.

However, 

On Sat, 22 Feb 2025 02:29:32 -0800, Bill Kendrick wrote:
>Tux Paint actually SHIPS with its own "fonts.conf" file for Windows [*],
>which includes these <dir> paths:
>
>  <dir prefix="cwd">data/fonts/locale</dir>
>  <dir prefix="cwd">data/fonts</dir>
>  <dir>WINDOWSFONTDIR</dir> <dir>WINDOWSUSERFONTDIR</dir>
>  <dir prefix="xdg">fonts</dir>
>  <dir>~/.fonts</dir>
>
>Those "WINDOWSFONTDIR" and "WINDOWSUSERFONTDIR" values seem to be magic
>strings used by FontConfig; see:
>
>  https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fcxml.c#L1330
>
>I think at the very least, one place the Windows version of Tux Paint
>should look for "fonts.conf" is own one that ships with Tux Paint:
>`etc/fonts/fonts.conf` (inside Tux Paint).
>
>If we were to mimick the behavior of FontConfig itself when
>those two "WINDOWS...FONTDIR" values are seen, I think that might
>actually remove the need for your user font dir scanning code
>(added in `365ee3ea20af489996e045f97ae2d874e43f5591`).  Wouldn't it?

once reading this part, I thought you may be right.

Therefore I pulled your hack and disabled the code to read user's font directory.
Then, unfortunately,  Tuxpaint does NOT load user's font ;-<

Just a brief report so far.

Thanks.

Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

On Sat, Feb 22, 2025 at 04:10:46PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I had made it to load fonts stored in user's font directory on Windows.
> 
> See commit 365ee3ea20af489996e045f97ae2d874e43f5591
> 
> Then I think there is no more thing to be added so far.

What I'm hoping for is a location (or locations) on Windows to read
FontConfig configuration file(s) -- "fonts.conf" -- which might contain
some <dir>...</dir> clauses that point to other places to find fonts.
(Tux Paint then proceeds to pass each path along to `loadfonts()`.)


For example, on my Linux system, Tux Paint will look for fonts
in three locations, based on two configuration files (user and system):

  $ grep "<dir>" ~/.config/fontconfig/fonts.conf /etc/fonts/fonts.conf
  /home/kendrick/.config/fontconfig/fonts.conf: <dir>~/.fonts</dir>
  /etc/fonts/fonts.conf:  <dir>/usr/share/fonts</dir>
  /etc/fonts/fonts.conf:  <dir>/usr/local/share/fonts</dir>
  /etc/fonts/fonts.conf:  <dir>~/.fonts</dir>

I actually just went in and updated `load_user_fonts()` to utilize
some environment variables, if set, in the 'default' block of code
that's used by Linux (and anything else not __APPLE__ or __HAIKU__).

Specifically,

 * Don't assume `/etc/fonts/fonts.conf`, but use $FONTCONFIG_PATH if set.
 * Don't assume `$HOME/.config/fonts.conf`, but use $XDG_CONFIG_HOME if set.


As a reminder, now that Tux Paint explicitly looks for and loads fonts
found in the "<dir>" paths that my `fonts.conf` files point to, I am now
able to use a lot more fonts in Tux Paint than I could before;
things I'm used to seeing in other apps (Gimp, Inkscape, LibreOffice).


So to summarize my question for you -- is there a location (or set of
locations) -- where one would expect to find FontConfig "fonts.conf" files
on Windows?


Interestingly, when I search Google for the question
"where is fontconfig fonts.conf on windows", it's AI Overview states:

  On Windows, there is no "fonts.conf" file in the traditional sense
  of Fontconfig, as Windows manages fonts through its own system, and
  does not utilize the Fontconfig framework; therefore, you won't find a
  "fonts.conf" file on a Windows system; all fonts are typically stored
  in the "C:\Windows\Fonts" directory.

HOWEVER, I cannot determine how it came to this conclusion, so I don't
trust this answer.  It may be a hallucination. >:-(


Tux Paint actually SHIPS with its own "fonts.conf" file for Windows [*],
which includes these <dir> paths:

  <dir prefix="cwd">data/fonts/locale</dir>
  <dir prefix="cwd">data/fonts</dir>
  <dir>WINDOWSFONTDIR</dir> <dir>WINDOWSUSERFONTDIR</dir>
  <dir prefix="xdg">fonts</dir>
  <dir>~/.fonts</dir>

Those "WINDOWSFONTDIR" and "WINDOWSUSERFONTDIR" values seem to be magic
strings used by FontConfig; see:

  https://gitlab.freedesktop.org/fontconfig/fontconfig/-/blob/main/src/fcxml.c#L1330


I think at the very least, one place the Windows version of Tux Paint
should look for "fonts.conf" is own one that ships with Tux Paint:
`etc/fonts/fonts.conf` (inside Tux Paint).

If we were to mimick the behavior of FontConfig itself when
those two "WINDOWS...FONTDIR" values are seen, I think that might
actually remove the need for your user font dir scanning code
(added in `365ee3ea20af489996e045f97ae2d874e43f5591`).  Wouldn't it?

I think I might drop some FIXME's in there, and I'd appreciate if
you could try implementing and testing. :)  Expect more commits
in a few minutes.

Then, as usual, I REALLY need to get to bed. :-D


-bill!

[*] We also ship a "fonts.conf" inside the macOS build.  Comments in
tuxpaint.c explain:

  /* Pango uses Fontconfig which requires fonts.conf.  By default, Fontconfig
   * searches for this file in a global path (e.g., /opt/local/etc/fonts if
   * using the MacPorts port of Fontconfig) which does not exist on a vanilla
   * macOS install.  As a workaround, the macOS port of Tux Paint provides its
   * own copy, and tells Fontconfig to look inside the Tux Paint app bundle for
   * this file by setting the FONTCONFIG_PATH environment variable here.


> 
> Thanks
> 
> On Sun, 16 Feb 2025 12:57:15 -0800, Bill Kendrick wrote:
> >
> >I've been quite busy lately, and was just trying to remind myself
> >what's up in the in-progress 0.9.35 version of Tux Paint.
> >
> >In CHANGES.txt I spotted this entry:
> >
> > + WIP Checking for fonts in any locations specified by "<dir>"
> >   entries found in system-wide and user-level FontConfig config files.
> >   This allows more fonts, and user-specific fonts, to be found & loaded.
> >   - TODO - Looks in $FONTCONFIG_PATH/fonts.conf on macOS/iOS,
> >     `/boot/system/settings/fonts/fonts.conf` on Haiku, otherwise
> >     the Un*x-specific `/etc/fonts/fonts.conf` and
> >     `~/.config/fontconfig/fonts.conf`.  Should look in the correct
> >     places on other platforms.
> >   - Note: This adds a build dependency on `libxml-2.0`.
> >
> >Pere and Shin-ichi, I'm sure I asked already, but can you let me know
> >what else, if anything, we should add so that Tux Paint can find a user's
> >`fonts.conf` (FontConfig XML configuration file) so the Android & Windows
> >builds of Tux Paint can also take advantage of this new capability...?
> >
> >And of course if anyone else out here has suggestions for more OS-specific
> >paths that we should look at, please speak up!
> >
> >Thanks in advance!
> >
> >-bill!
> >
> >PS - As a reminder, the _other_ things coming in 0.9.35 (so far) are:
> >
> > * "emitter" (heart, stars, sparkles) magic tools
> > * text pasting (copy/paste buffer) in Text & Label tools
> > * UX improvement to HSV color picker
> > * minor doc improvements
> > * some build improvements (NetBSD, Slackware)
> > * less noise to STDOUT
> >
> >
> >
> >_______________________________________________
> >Tuxpaint-devel mailing list
> >Tux...@li...
> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> 
> -- 
> Shin-ichi TOYAMA <dol...@wm...>
> 

Re: [Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

Hi!

I had made it to load fonts stored in user's font directory on Windows.

See commit 365ee3ea20af489996e045f97ae2d874e43f5591

Then I think there is no more thing to be added so far.

Thanks

On Sun, 16 Feb 2025 12:57:15 -0800, Bill Kendrick wrote:
>
>I've been quite busy lately, and was just trying to remind myself
>what's up in the in-progress 0.9.35 version of Tux Paint.
>
>In CHANGES.txt I spotted this entry:
>
> + WIP Checking for fonts in any locations specified by "<dir>"
>   entries found in system-wide and user-level FontConfig config files.
>   This allows more fonts, and user-specific fonts, to be found & loaded.
>   - TODO - Looks in $FONTCONFIG_PATH/fonts.conf on macOS/iOS,
>     `/boot/system/settings/fonts/fonts.conf` on Haiku, otherwise
>     the Un*x-specific `/etc/fonts/fonts.conf` and
>     `~/.config/fontconfig/fonts.conf`.  Should look in the correct
>     places on other platforms.
>   - Note: This adds a build dependency on `libxml-2.0`.
>
>Pere and Shin-ichi, I'm sure I asked already, but can you let me know
>what else, if anything, we should add so that Tux Paint can find a user's
>`fonts.conf` (FontConfig XML configuration file) so the Android & Windows
>builds of Tux Paint can also take advantage of this new capability...?
>
>And of course if anyone else out here has suggestions for more OS-specific
>paths that we should look at, please speak up!
>
>Thanks in advance!
>
>-bill!
>
>PS - As a reminder, the _other_ things coming in 0.9.35 (so far) are:
>
> * "emitter" (heart, stars, sparkles) magic tools
> * text pasting (copy/paste buffer) in Text & Label tools
> * UX improvement to HSV color picker
> * minor doc improvements
> * some build improvements (NetBSD, Slackware)
> * less noise to STDOUT
>
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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

[Tuxpaint-devel] Windows & Android (& others?) FontConfig `fonts.conf` parsing

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

I've been quite busy lately, and was just trying to remind myself
what's up in the in-progress 0.9.35 version of Tux Paint.

In CHANGES.txt I spotted this entry:

 + WIP Checking for fonts in any locations specified by "<dir>"
   entries found in system-wide and user-level FontConfig config files.
   This allows more fonts, and user-specific fonts, to be found & loaded.
   - TODO - Looks in $FONTCONFIG_PATH/fonts.conf on macOS/iOS,
     `/boot/system/settings/fonts/fonts.conf` on Haiku, otherwise
     the Un*x-specific `/etc/fonts/fonts.conf` and
     `~/.config/fontconfig/fonts.conf`.  Should look in the correct
     places on other platforms.
   - Note: This adds a build dependency on `libxml-2.0`.

Pere and Shin-ichi, I'm sure I asked already, but can you let me know
what else, if anything, we should add so that Tux Paint can find a user's
`fonts.conf` (FontConfig XML configuration file) so the Android & Windows
builds of Tux Paint can also take advantage of this new capability...?

And of course if anyone else out here has suggestions for more OS-specific
paths that we should look at, please speak up!

Thanks in advance!

-bill!

PS - As a reminder, the _other_ things coming in 0.9.35 (so far) are:

 * "emitter" (heart, stars, sparkles) magic tools
 * text pasting (copy/paste buffer) in Text & Label tools
 * UX improvement to HSV color picker
 * minor doc improvements
 * some build improvements (NetBSD, Slackware)
 * less noise to STDOUT

Re: [Tuxpaint-devel] UI update

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

On Sat, Jan 11, 2025 at 08:48:14PM -0600, Maple Gjertson via Tuxpaint-devel wrote:
> Are there any plans to update the UI? I understand it is very nostalgic to
> some but as it stands it clashes with everything else on the desktop. If the
> UI does get changed, I suggest an option to bring back the old UI.

I'd definitely like to provide a way to offer different UI themes to
Tux Paint [1], including offering a high-contrast theme [2] and
a "dark mode" [3].

And yes, the original UI would be available, and almost certainly
be set as the default.  Whenever I see someone on social media
complain about how Tux Paint "looks like it's from 2002" (it is :-D),
lots of other people come to its defense. ;-)

-bill!

[1] Ticket #78: "Allow UI to be themed"
    https://sourceforge.net/p/tuxpaint/feature-requests/78/

[2] Ticket #79: "Create a high-contrast theme"
    https://sourceforge.net/p/tuxpaint/feature-requests/79/

[3] Ticket #223: "Dark mode with light-on-dark tools and black background start"
    https://sourceforge.net/p/tuxpaint/feature-requests/223/

[Tuxpaint-devel] UI update

[Maple G. <mgj...@au...>]

Are there any plans to update the UI? I understand it is very nostalgic 
to some but as it stands it clashes with everything else on the 
desktop. If the UI does get changed, I suggest an option to bring back 
the old UI.

Re: [Tuxpaint-devel] Text/Label "paste" functionality

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

On Wed, Dec 25, 2024 at 04:22:42PM -0500, Mark Kim wrote:
> Hi Bill,
> 
> > [1] Mark, should we also support [Option]+[V] on macOS?
> 
> [Command]+[V] is the standard shortcut for pasting on macOS, and it seems
> to work fine out-of-the-box with the latest code in the master branch!
> (FYI, the [Ctrl] modifier is overwritten as the [Command] modifier on macOS
> here
> <https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/src/macos.h#l28>
> since
> anywhere Linux/Windows uses Ctrl is typically where macOS uses Command
> instead.)

Awesome! :)  Thanks for checking & confirming.  Happy holidays!!!

-bill!

Re: [Tuxpaint-devel] Text/Label "paste" functionality

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

Hi Bill,

> [1] Mark, should we also support [Option]+[V] on macOS?

[Command]+[V] is the standard shortcut for pasting on macOS, and it seems
to work fine out-of-the-box with the latest code in the master branch!
(FYI, the [Ctrl] modifier is overwritten as the [Command] modifier on macOS
here
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/src/macos.h#l28>
since
anywhere Linux/Windows uses Ctrl is typically where macOS uses Command
instead.)

Thanks,
Mark

On Wed, Dec 25, 2024 at 3:57 PM Bill Kendrick <nb...@so...> wrote:

>
> I've begun implementing a text clipboard 'paste' function in the Text &
> Label tools,
> via [Ctrl]+[V] on a physical keyboard [1], and a new "Paste" button in the
> on-screen
> keyboard (OSK) built into Tux Paint [2].
>
> Right now, it wraps at a character level, if you paste text that will go
> beyond
> the right edge of the canvas.  If the text continues to the bottom of the
> canvas,
> it will abort (thus truncating the text).  I'm thinking of adding better
> word
> wrapping (via spaces & perhaps punctuation) if I can manage it -- probably
> cribbing code used by the button labelling routine.
>
> I also took the opporunity to update the documentation about the OSK in
> both
> the user-facing "README", and the more technically-inclined "EXTENDING".
>
> I'd appreciate people poking & prodding at it, and reporting back any
> issues
> or ideas for improvement.
>
> Thanks very much!  And happy holidays & new year!
>
> -bill!
>
> [1] Mark, should we also support [Option]+[V] on macOS?
> [2] Pere, does Android need something added to support such a function
> with its
>     OS-level on-screen keyboard?
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Text/Label "paste" functionality

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

I've begun implementing a text clipboard 'paste' function in the Text & Label tools,
via [Ctrl]+[V] on a physical keyboard [1], and a new "Paste" button in the on-screen
keyboard (OSK) built into Tux Paint [2].

Right now, it wraps at a character level, if you paste text that will go beyond
the right edge of the canvas.  If the text continues to the bottom of the canvas,
it will abort (thus truncating the text).  I'm thinking of adding better word
wrapping (via spaces & perhaps punctuation) if I can manage it -- probably
cribbing code used by the button labelling routine.

I also took the opporunity to update the documentation about the OSK in both
the user-facing "README", and the more technically-inclined "EXTENDING".

I'd appreciate people poking & prodding at it, and reporting back any issues
or ideas for improvement.

Thanks very much!  And happy holidays & new year!

-bill!

[1] Mark, should we also support [Option]+[V] on macOS?
[2] Pere, does Android need something added to support such a function with its
    OS-level on-screen keyboard?

Re: [Tuxpaint-devel] Tux Paint 0.9.34 features to try out

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

On Sun, Sep 29, 2024 at 12:31:16AM -0700, Bill Kendrick wrote:
> 
> Hi all!  I was away for a month (big epic vacation for once
> in my life ;-D), but now that I'm back I've gone a little
> nuts adding more features to Tux Paint, as usual...
<snip>

I can't help myself! :D  Three more Magic tools added in the
past week...

 * "Spraypaint"
   Acts like a spraypaint or airbrush, spraying a random
   "mist" of pixels around the cursor.  The further from
   the center, the lighter they are (less opaque; higher alpha
   transparency).
   + Video: [pick your favorite platform]:
     - https://youtu.be/An54e9D80Ak
     - https://www.tumblr.com/tuxpaint/763294820977491968/spray-paint-airbrush-effect-coming-in-tux-paint
     - https://www.instagram.com/reel/DApqNLDp4kz/
   + Screenshot:
     - https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-spraypaint.png

 * "Spiral" & "Square Spiral"
   Draws a spiral, centered around where you initially clicked,
   with a radius based on where you drag.  The "size" setting
   changes the thickness (and hence spacing) of the lines.
   + Video:
     - https://www.youtube.com/watch?v=XDezoFns4LE
     - https://www.instagram.com/reel/DAu15cvpzlz/
   + Screenshots:
     1. Spiral: https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-spiral.png
     2. Square Spiral: https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-square-spiral.png
     3. A mess of both types of spirals: [pick your favorite platform]
        - https://floss.social/@tuxpaint/113252781889291166
        - https://cara.app/post/bd1d00ae-ae84-487a-b66e-58e798c3e60b
     4. A drawing I made using Spiral & other tools: [pick...]
        - https://tuxpaint.org/gallery/image.php?i=spirals-by-bill-kendrick.png
        - https://www.instagram.com/p/DAu5gFfxuna/

:)

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.34 features to try out

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

Hi all,

I've found something with translucent brushes/erasers, 
not sure if it is by design:

Start with a white canvas and paint something solid black,
Change the brush to a translucent one and the color to white,
paint many times with white over the black spot,
you will never get the canvas white again with the translucent brush,
there will always be some shade of grey there.

Same thing happens with translucent erasers.

HTH
Pere

El dg. 29 de 09 de 2024 a les 00:31 -0700, en/na Bill Kendrick va escriure:
> Hi all!  I was away for a month (big epic vacation for once
> in my life ;-D), but now that I'm back I've gone a little
> nuts adding more features to Tux Paint, as usual...
> 
> So far the big things include:
> 
>  * "Eraser" mode of the "Fill" tool
>    What does this mean?  First off, it's most useful if you're using
>    a Starter or Template background as the basis of your drawing (and
>    remember, you can make new ones from WITHIN Tux Paint now!).
>    Instead of flood-filling with the user-selected color, it
>    replaces the contiguous area you've clicked with whatever the
>    background was.  Here's a video [pick your favorite platform]:
>    + https://floss.social/@tuxpaint/113151620050892297
>    + https://www.youtube.com/watch?v=s6Uy9de7AjI
>    + https://bsky.app/profile/tuxpaint.bsky.social/post/3l4dhojfiwe2r
>    + https://www.threads.net/@tuxpaintdevs/post/DAAl-hdJIEj
>    + https://www.instagram.com/reel/DAAljaMpD_D
> 
>  * "Rotate" magic tool
>    Rotate your drawing!  The user-selected color will be used as a
>    'background' at the corners (similar to how plain "Zoom" works).
>    (h/t to Pere for noticing a dumb memory leak I left in there!)
>    Here's a screenshot:
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-rotate.png
> 
>  * "Crescent" magic tool
>    (My son complains it should be in "Shapes", but that's a LOT more
>    work, I think.)  This draws a crescent shape.  Drag away from where
>    you first clicked to adjust both the radius/diameter, as well as
>    the angle of the crescent.  The 'size' options can be used to
>    change how solid or hollow the crescent is.  See this screenshot:
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-crescent.png
> 
>  * "Fractal" magic tools
>    (This feature didn't come out quite as amazingly as I'd hoped, but
>    at the very least it's fun, and could be used for glitch art.)
>    Right now there are four different tool variations, with varying
>    parameters: shrinking (zooming out) or growing (zooming in),
>    and different rotation values (or none).  The 'size' option sets
>    the thickness of what you draw, and also determines how 'deep'
>    the effect will iterate recursively.  Hard to explain so here's
>    a screenshot:
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-fractal.png
>    And a video:
>    + https://floss.social/@tuxpaint/113191183386173044
>    + https://www.youtube.com/watch?v=gk-92FSTqgY
>    + https://www.threads.net/@tuxpaintdevs/post/DASlmfhJHxc
>    + https://www.instagram.com/reel/DASlamDJ3gZ
> 
>  * "ASCII Art" magic tools
>    (This was fun and challenging to write, but came out well!)
>    Convert your picture to ASCII art (letters, numbers, and
>    symbols that reflect the brightness/darkness of the pixels).
>    Three options: typewriter (a typewriter font on white,
>    in the user-selected color), computer (IBM CGA 8x16 pixel
>    font on black, in the user-selected color), and color computer
>    (same as computer, but using 16 horrid CGA colors to represent
>    your picture's colors).  Screenshots!
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-ascii-typewriter.png
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-ascii-color-computer.png
>    And a video:
>    + https://www.youtube.com/watch?v=KV4l1Hn9QUk
>    + https://www.instagram.com/reel/DAc8xJqpmhr
> 
>  * "Comic Docs" magic tool
>    (Somewhat similar to "Halftone", which I'm disappointed with
>    and need to revisit some day.)  This draws a repeating pattern
>    of dots on your picture (using a "multiply" mode of blending)
>    in an attempt to simulate the "Ben Day process" of shading or
>    coloring that was common in early comic books and comic strips.
>    Screenshot:
>    + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-comicdots.png
> 
> Please try them out and let me know if you have any issues!
> 
> -bill!
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Tuxpaint-devel] Tux Paint 0.9.34 features to try out

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

Hi all!  I was away for a month (big epic vacation for once
in my life ;-D), but now that I'm back I've gone a little
nuts adding more features to Tux Paint, as usual...

So far the big things include:

 * "Eraser" mode of the "Fill" tool
   What does this mean?  First off, it's most useful if you're using
   a Starter or Template background as the basis of your drawing (and
   remember, you can make new ones from WITHIN Tux Paint now!).
   Instead of flood-filling with the user-selected color, it
   replaces the contiguous area you've clicked with whatever the
   background was.  Here's a video [pick your favorite platform]:
   + https://floss.social/@tuxpaint/113151620050892297
   + https://www.youtube.com/watch?v=s6Uy9de7AjI
   + https://bsky.app/profile/tuxpaint.bsky.social/post/3l4dhojfiwe2r
   + https://www.threads.net/@tuxpaintdevs/post/DAAl-hdJIEj
   + https://www.instagram.com/reel/DAAljaMpD_D

 * "Rotate" magic tool
   Rotate your drawing!  The user-selected color will be used as a
   'background' at the corners (similar to how plain "Zoom" works).
   (h/t to Pere for noticing a dumb memory leak I left in there!)
   Here's a screenshot:
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-rotate.png

 * "Crescent" magic tool
   (My son complains it should be in "Shapes", but that's a LOT more
   work, I think.)  This draws a crescent shape.  Drag away from where
   you first clicked to adjust both the radius/diameter, as well as
   the angle of the crescent.  The 'size' options can be used to
   change how solid or hollow the crescent is.  See this screenshot:
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-crescent.png

 * "Fractal" magic tools
   (This feature didn't come out quite as amazingly as I'd hoped, but
   at the very least it's fun, and could be used for glitch art.)
   Right now there are four different tool variations, with varying
   parameters: shrinking (zooming out) or growing (zooming in),
   and different rotation values (or none).  The 'size' option sets
   the thickness of what you draw, and also determines how 'deep'
   the effect will iterate recursively.  Hard to explain so here's
   a screenshot:
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-fractal.png
   And a video:
   + https://floss.social/@tuxpaint/113191183386173044
   + https://www.youtube.com/watch?v=gk-92FSTqgY
   + https://www.threads.net/@tuxpaintdevs/post/DASlmfhJHxc
   + https://www.instagram.com/reel/DASlamDJ3gZ

 * "ASCII Art" magic tools
   (This was fun and challenging to write, but came out well!)
   Convert your picture to ASCII art (letters, numbers, and
   symbols that reflect the brightness/darkness of the pixels).
   Three options: typewriter (a typewriter font on white,
   in the user-selected color), computer (IBM CGA 8x16 pixel
   font on black, in the user-selected color), and color computer
   (same as computer, but using 16 horrid CGA colors to represent
   your picture's colors).  Screenshots!
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-ascii-typewriter.png
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-ascii-color-computer.png
   And a video:
   + https://www.youtube.com/watch?v=KV4l1Hn9QUk
   + https://www.instagram.com/reel/DAc8xJqpmhr

 * "Comic Docs" magic tool
   (Somewhat similar to "Halftone", which I'm disappointed with
   and need to revisit some day.)  This draws a repeating pattern
   of dots on your picture (using a "multiply" mode of blending)
   in an attempt to simulate the "Ben Day process" of shading or
   coloring that was common in early comic books and comic strips.
   Screenshot:
   + https://tuxpaint.org/latest/sshots/tuxpaint-0.9.34-comicdots.png

Please try them out and let me know if you have any issues!

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.33-rc1 posted for beta builds

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

On Mon, Jul 08, 2024 at 10:50:12AM +0100, Will Thompson wrote:
> Hi,
> 
> I pushed <https://github.com/flathub/org.tuxpaint.Tuxpaint/tree/beta> this
> to the beta branch on the flathub repo; it should be live on flathub-beta
> <https://docs.flathub.org/docs/for-users/installation/#flathub-beta-repository>
> in
> 3–4 hours.

Cool!

 
> This reminded me that there is 1 buildsystem patch needed there, to find
> the include & link arguments for SDL2_gfx via pkg-config.
> https://github.com/flathub/org.tuxpaint.Tuxpaint/blob/beta/Makefile-sdl2_gfx-pkgconfig.patch
> should be applicable more broadly to fix the build when SDL2_gfx is not on
> the default include/link path.

I've applied it upstream.  HTH!  Thanks!

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.33-rc1 posted for beta builds

[Will T. <wj...@en...>]

Hi,

I pushed <https://github.com/flathub/org.tuxpaint.Tuxpaint/tree/beta> this
to the beta branch on the flathub repo; it should be live on flathub-beta
<https://docs.flathub.org/docs/for-users/installation/#flathub-beta-repository>
in
3–4 hours.

This reminded me that there is 1 buildsystem patch needed there, to find
the include & link arguments for SDL2_gfx via pkg-config.
https://github.com/flathub/org.tuxpaint.Tuxpaint/blob/beta/Makefile-sdl2_gfx-pkgconfig.patch
should be applicable more broadly to fix the build when SDL2_gfx is not on
the default include/link path.

– Will

On Sat, 6 Jul 2024 at 20:40, Bill Kendrick <nb...@so...> wrote:

>
> Hi all!  Today I tagged and cut release candidates of Tux Paint 0.9.33
> and friends:
>
>  * Tux Paint 0.9.33-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.33-beta/tuxpaint-0.9.33-rc1.tar.gz/download
>
>  * Tux Paint Config 0.0.24-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint-config/0.0.24-beta/tuxpaint-config-0.0.24-rc1.tar.gz/download
>
>  * Tux Paint Stamps 2024-07-XX-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint-stamps/2024-07-XX-beta/tuxpaint-stamps-2024.07.06.tar.gz/download
>
> When you have time, please build versions based on these for your favorite
> platform, so we can have people beta test them.
>
> Tux Paint includes a number of changes and bugfixes since the last
> release, back in January:
>
>  * A pair of new "Dither" magic tools
>  * New "Filled Polygon" magic tool
>  * New magic tool API call to retract an undo snapshot
>    (utilized by "Filled Polygon")
>  * Update to "3D Glasses" magic tool
>  * Option to un-group (one big list, no pagination) Magic tools
>  * Some new, transparent, erasers
>  * A few new brushes (Paint & Line tools)
>  * Brushes can have descriptions
>  * Font face/size shown when choosing/changing a font (Text & Label tools)
>  * Click-and-release (no drag) with rotating brush would not draw anything;
>    now it draws as if you dragged "up"
>  * Labels on UI buttons will now also word-wrap on dashes ("-"),
>    and support Unicode soft hyphens to hint where words may be broken
>  * When exporting a drawing (via "Open" dialog), the name of the file
>    is shown, AND is placed in your Copy/Paste buffer
>  * OS Trashcan support ("Erase" in "Open" dialog) on Haiku now, too
>  * Snappier screen refresh on macOS
>  * Workaround for bash-completion (newer versions) bug in some locales
>    (was due to Tux Paint's file being read before bash-completion's own
>    "000_bash_completion_compat.bash")
>  * Some work towards supporting OS/2 builds
>  * Universal bundling simplification for macOS
>  * Appdate metadata updates for Appstream 1.0
>  * Remove final coupla of RSVG library warnings during compliation
>  * Removed some unused text rendering code
>  * Updated Troubleshooting Guide to cover macOS, Haiku, and Linux
>  * Docs made more consistent, re: where files go
>  * Added process to run `indent` on "tp_magic_example.c" regularly
>  * Doc styling modernization in FAQ, Env. Vars., & Advanced Stamp Howto.
>  * Doc corrections re: old usage of "--fullscreen" (with no parameter)
>  * Localization updates
>  * Bugfix: Avoid invalid memory access in Linear Gradient (Fill tool)
>
> WHEW!  It's a lot!  Despite feeling like I haven't done anything with
> Tux Paint for a few months, I guess the truth is we were REALLY busy
> in the beginning of the year. :-)
>
>
> Tux Paint Config. adds a new checkbox (in "Simplification") for the
> magic tool ungrouping feature.  Otherwise, both Config. Tux Paint Stamps
> only had some localization updates since their last releases
> (also back in January).
>
> Thanks in advance!  For others up here in the northern hemisphere,
> I hope you're staying safe & cool!
>
> -bill!
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.33-rc1 posted for beta builds

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

Hi,

Android build at
https://provant.freeddns.org/pere/public_html/Tux%20Paint/0.9.33-RC1/

Best
Pere


El ds. 06 de 07 de 2024 a les 12:40 -0700, en/na Bill Kendrick va escriure:
> Hi all!  Today I tagged and cut release candidates of Tux Paint 0.9.33
> and friends:
> 
>  * Tux Paint 0.9.33-rc1
>    https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.33-beta/tuxpaint-0.9.33-rc1.tar.gz/download
> 
>  * Tux Paint Config 0.0.24-rc1
>    https://sourceforge.net/projects/tuxpaint/files/tuxpaint-config/0.0.24-beta/tuxpaint-config-0.0.24-rc1.tar.gz/download
> 
>  * Tux Paint Stamps 2024-07-XX-rc1
>    https://sourceforge.net/projects/tuxpaint/files/tuxpaint-stamps/2024-07-XX-beta/tuxpaint-stamps-2024.07.06.tar.gz/download
> 
> When you have time, please build versions based on these for your favorite
> platform, so we can have people beta test them.
> 
> Tux Paint includes a number of changes and bugfixes since the last
> release, back in January:
> 
>  * A pair of new "Dither" magic tools
>  * New "Filled Polygon" magic tool
>  * New magic tool API call to retract an undo snapshot
>    (utilized by "Filled Polygon")
>  * Update to "3D Glasses" magic tool
>  * Option to un-group (one big list, no pagination) Magic tools
>  * Some new, transparent, erasers
>  * A few new brushes (Paint & Line tools)
>  * Brushes can have descriptions
>  * Font face/size shown when choosing/changing a font (Text & Label tools)
>  * Click-and-release (no drag) with rotating brush would not draw anything;
>    now it draws as if you dragged "up"
>  * Labels on UI buttons will now also word-wrap on dashes ("-"),
>    and support Unicode soft hyphens to hint where words may be broken
>  * When exporting a drawing (via "Open" dialog), the name of the file
>    is shown, AND is placed in your Copy/Paste buffer
>  * OS Trashcan support ("Erase" in "Open" dialog) on Haiku now, too
>  * Snappier screen refresh on macOS
>  * Workaround for bash-completion (newer versions) bug in some locales
>    (was due to Tux Paint's file being read before bash-completion's own
>    "000_bash_completion_compat.bash")
>  * Some work towards supporting OS/2 builds
>  * Universal bundling simplification for macOS
>  * Appdate metadata updates for Appstream 1.0
>  * Remove final coupla of RSVG library warnings during compliation
>  * Removed some unused text rendering code
>  * Updated Troubleshooting Guide to cover macOS, Haiku, and Linux
>  * Docs made more consistent, re: where files go
>  * Added process to run `indent` on "tp_magic_example.c" regularly
>  * Doc styling modernization in FAQ, Env. Vars., & Advanced Stamp Howto.
>  * Doc corrections re: old usage of "--fullscreen" (with no parameter)
>  * Localization updates
>  * Bugfix: Avoid invalid memory access in Linear Gradient (Fill tool)
> 
> WHEW!  It's a lot!  Despite feeling like I haven't done anything with
> Tux Paint for a few months, I guess the truth is we were REALLY busy
> in the beginning of the year. :-)
> 
> 
> Tux Paint Config. adds a new checkbox (in "Simplification") for the
> magic tool ungrouping feature.  Otherwise, both Config. Tux Paint Stamps
> only had some localization updates since their last releases
> (also back in January).
> 
> Thanks in advance!  For others up here in the northern hemisphere,
> I hope you're staying safe & cool!
> 
> -bill!
> 
> 
> 
> _______________________________________________
> Tuxpaint-maintainers mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers

Re: [Tuxpaint-devel] Tux Paint 0.9.33-rc1 posted for beta builds

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

Hi!

Build for Windows and RHELs are ready.

  https://z1.plala.jp/tuxpaint/testing/windows/0.9.33-rc1/
  https://z1.plala.jp/tuxpaint/testing/rpms/0.9.33-rc1/

Please take note that libunibreak also has been updated this time.


On Sat, 6 Jul 2024 12:40:00 -0700, Bill Kendrick wrote:
>
>Hi all!  Today I tagged and cut release candidates of Tux Paint 0.9.33
>and friends:
>
> * Tux Paint 0.9.33-rc1
>   https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.33-beta/tuxpaint-0.9.33-rc1.tar.gz/download
>
> * Tux Paint Config 0.0.24-rc1
>   https://sourceforge.net/projects/tuxpaint/files/tuxpaint-config/0.0.24-beta/tuxpaint-config-0.0.24-rc1.tar.gz/download
>
> * Tux Paint Stamps 2024-07-XX-rc1
>   https://sourceforge.net/projects/tuxpaint/files/tuxpaint-stamps/2024-07-XX-beta/tuxpaint-stamps-2024.07.06.tar.gz/download
>
>When you have time, please build versions based on these for your favorite
>platform, so we can have people beta test them.
>
>Tux Paint includes a number of changes and bugfixes since the last
>release, back in January:
>
> * A pair of new "Dither" magic tools
> * New "Filled Polygon" magic tool
> * New magic tool API call to retract an undo snapshot
>   (utilized by "Filled Polygon")
> * Update to "3D Glasses" magic tool
> * Option to un-group (one big list, no pagination) Magic tools
> * Some new, transparent, erasers
> * A few new brushes (Paint & Line tools)
> * Brushes can have descriptions
> * Font face/size shown when choosing/changing a font (Text & Label tools)
> * Click-and-release (no drag) with rotating brush would not draw anything;
>   now it draws as if you dragged "up"
> * Labels on UI buttons will now also word-wrap on dashes ("-"),
>   and support Unicode soft hyphens to hint where words may be broken
> * When exporting a drawing (via "Open" dialog), the name of the file
>   is shown, AND is placed in your Copy/Paste buffer
> * OS Trashcan support ("Erase" in "Open" dialog) on Haiku now, too
> * Snappier screen refresh on macOS
> * Workaround for bash-completion (newer versions) bug in some locales
>   (was due to Tux Paint's file being read before bash-completion's own
>   "000_bash_completion_compat.bash")
> * Some work towards supporting OS/2 builds
> * Universal bundling simplification for macOS
> * Appdate metadata updates for Appstream 1.0
> * Remove final coupla of RSVG library warnings during compliation
> * Removed some unused text rendering code
> * Updated Troubleshooting Guide to cover macOS, Haiku, and Linux
> * Docs made more consistent, re: where files go
> * Added process to run `indent` on "tp_magic_example.c" regularly
> * Doc styling modernization in FAQ, Env. Vars., & Advanced Stamp Howto.
> * Doc corrections re: old usage of "--fullscreen" (with no parameter)
> * Localization updates
> * Bugfix: Avoid invalid memory access in Linear Gradient (Fill tool)
>
>WHEW!  It's a lot!  Despite feeling like I haven't done anything with
>Tux Paint for a few months, I guess the truth is we were REALLY busy
>in the beginning of the year. :-)
>
>
>Tux Paint Config. adds a new checkbox (in "Simplification") for the
>magic tool ungrouping feature.  Otherwise, both Config. Tux Paint Stamps
>only had some localization updates since their last releases
>(also back in January).
>
>Thanks in advance!  For others up here in the northern hemisphere,
>I hope you're staying safe & cool!
>
>-bill!
>
>
>
>_______________________________________________
>Tuxpaint-maintainers mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers


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

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.33-rc1 posted for beta builds

[Mark K. <tux...@cb...>]

Hi Bill,

macOS builds have been uploaded here:

   - https://dl.cbreak.org/TuxPaint-0.9.33-rc1.dmg
   - https://dl.cbreak.org/TuxPaint-Config-0.0.24-rc1.dmg
   - https://dl.cbreak.org/TuxPaint-Stamps-2024.07.06.dmg

Thanks,
Mark


On Sat, Jul 6, 2024 at 3:40 PM Bill Kendrick <nb...@so...> wrote:

>
> Hi all!  Today I tagged and cut release candidates of Tux Paint 0.9.33
> and friends:
>
>  * Tux Paint 0.9.33-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.33-beta/tuxpaint-0.9.33-rc1.tar.gz/download
>
>  * Tux Paint Config 0.0.24-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint-config/0.0.24-beta/tuxpaint-config-0.0.24-rc1.tar.gz/download
>
>  * Tux Paint Stamps 2024-07-XX-rc1
>
> https://sourceforge.net/projects/tuxpaint/files/tuxpaint-stamps/2024-07-XX-beta/tuxpaint-stamps-2024.07.06.tar.gz/download
>
> When you have time, please build versions based on these for your favorite
> platform, so we can have people beta test them.
>
> Tux Paint includes a number of changes and bugfixes since the last
> release, back in January:
>
>  * A pair of new "Dither" magic tools
>  * New "Filled Polygon" magic tool
>  * New magic tool API call to retract an undo snapshot
>    (utilized by "Filled Polygon")
>  * Update to "3D Glasses" magic tool
>  * Option to un-group (one big list, no pagination) Magic tools
>  * Some new, transparent, erasers
>  * A few new brushes (Paint & Line tools)
>  * Brushes can have descriptions
>  * Font face/size shown when choosing/changing a font (Text & Label tools)
>  * Click-and-release (no drag) with rotating brush would not draw anything;
>    now it draws as if you dragged "up"
>  * Labels on UI buttons will now also word-wrap on dashes ("-"),
>    and support Unicode soft hyphens to hint where words may be broken
>  * When exporting a drawing (via "Open" dialog), the name of the file
>    is shown, AND is placed in your Copy/Paste buffer
>  * OS Trashcan support ("Erase" in "Open" dialog) on Haiku now, too
>  * Snappier screen refresh on macOS
>  * Workaround for bash-completion (newer versions) bug in some locales
>    (was due to Tux Paint's file being read before bash-completion's own
>    "000_bash_completion_compat.bash")
>  * Some work towards supporting OS/2 builds
>  * Universal bundling simplification for macOS
>  * Appdate metadata updates for Appstream 1.0
>  * Remove final coupla of RSVG library warnings during compliation
>  * Removed some unused text rendering code
>  * Updated Troubleshooting Guide to cover macOS, Haiku, and Linux
>  * Docs made more consistent, re: where files go
>  * Added process to run `indent` on "tp_magic_example.c" regularly
>  * Doc styling modernization in FAQ, Env. Vars., & Advanced Stamp Howto.
>  * Doc corrections re: old usage of "--fullscreen" (with no parameter)
>  * Localization updates
>  * Bugfix: Avoid invalid memory access in Linear Gradient (Fill tool)
>
> WHEW!  It's a lot!  Despite feeling like I haven't done anything with
> Tux Paint for a few months, I guess the truth is we were REALLY busy
> in the beginning of the year. :-)
>
>
> Tux Paint Config. adds a new checkbox (in "Simplification") for the
> magic tool ungrouping feature.  Otherwise, both Config. Tux Paint Stamps
> only had some localization updates since their last releases
> (also back in January).
>
> Thanks in advance!  For others up here in the northern hemisphere,
> I hope you're staying safe & cool!
>
> -bill!
>
>
>
> _______________________________________________
> Tuxpaint-maintainers mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers
>
>

[Tuxpaint-devel] Tux Paint 0.9.33-rc1 posted for beta builds

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

Hi all!  Today I tagged and cut release candidates of Tux Paint 0.9.33
and friends:

 * Tux Paint 0.9.33-rc1
   https://sourceforge.net/projects/tuxpaint/files/tuxpaint/0.9.33-beta/tuxpaint-0.9.33-rc1.tar.gz/download

 * Tux Paint Config 0.0.24-rc1
   https://sourceforge.net/projects/tuxpaint/files/tuxpaint-config/0.0.24-beta/tuxpaint-config-0.0.24-rc1.tar.gz/download

 * Tux Paint Stamps 2024-07-XX-rc1
   https://sourceforge.net/projects/tuxpaint/files/tuxpaint-stamps/2024-07-XX-beta/tuxpaint-stamps-2024.07.06.tar.gz/download

When you have time, please build versions based on these for your favorite
platform, so we can have people beta test them.

Tux Paint includes a number of changes and bugfixes since the last
release, back in January:

 * A pair of new "Dither" magic tools
 * New "Filled Polygon" magic tool
 * New magic tool API call to retract an undo snapshot
   (utilized by "Filled Polygon")
 * Update to "3D Glasses" magic tool
 * Option to un-group (one big list, no pagination) Magic tools
 * Some new, transparent, erasers
 * A few new brushes (Paint & Line tools)
 * Brushes can have descriptions
 * Font face/size shown when choosing/changing a font (Text & Label tools)
 * Click-and-release (no drag) with rotating brush would not draw anything;
   now it draws as if you dragged "up"
 * Labels on UI buttons will now also word-wrap on dashes ("-"),
   and support Unicode soft hyphens to hint where words may be broken
 * When exporting a drawing (via "Open" dialog), the name of the file
   is shown, AND is placed in your Copy/Paste buffer
 * OS Trashcan support ("Erase" in "Open" dialog) on Haiku now, too
 * Snappier screen refresh on macOS
 * Workaround for bash-completion (newer versions) bug in some locales
   (was due to Tux Paint's file being read before bash-completion's own
   "000_bash_completion_compat.bash")
 * Some work towards supporting OS/2 builds
 * Universal bundling simplification for macOS
 * Appdate metadata updates for Appstream 1.0
 * Remove final coupla of RSVG library warnings during compliation
 * Removed some unused text rendering code
 * Updated Troubleshooting Guide to cover macOS, Haiku, and Linux
 * Docs made more consistent, re: where files go
 * Added process to run `indent` on "tp_magic_example.c" regularly
 * Doc styling modernization in FAQ, Env. Vars., & Advanced Stamp Howto.
 * Doc corrections re: old usage of "--fullscreen" (with no parameter)
 * Localization updates
 * Bugfix: Avoid invalid memory access in Linear Gradient (Fill tool)

WHEW!  It's a lot!  Despite feeling like I haven't done anything with
Tux Paint for a few months, I guess the truth is we were REALLY busy
in the beginning of the year. :-)


Tux Paint Config. adds a new checkbox (in "Simplification") for the
magic tool ungrouping feature.  Otherwise, both Config. Tux Paint Stamps
only had some localization updates since their last releases
(also back in January).

Thanks in advance!  For others up here in the northern hemisphere,
I hope you're staying safe & cool!

-bill!

Re: [Tuxpaint-devel] Polygon fill messing with other tools drawing

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

On Sat, Jun 01, 2024 at 03:48:09PM +0200, Pere Pujal i Carabantes wrote:
<snip>
> Better :)
> Could be improved if a click in the starting point closes the polygon, 
> as it is now you have to click outside the starting point and drag into it,
> the following works for me.

Thanks!  For safety, I made the two arrays larger by one, since the
last thing that happens is one _more_ point is created, which has
the same position as the first point (index 0).  So if I were to add
a new point at MAX_PTS index into the array, that would go beyond
its capacity, otherwise.

I also bumped the number of points up to 100. (I did that last night
but forgot to commit. Zzzz)


<snip>
> Works fine as far as I've tested :), the only improvement I could imagine 
> is to use the first Undo just to clear the auxiliary stuff, 
> withouth undoing previous work, other Undo acting as of now.

I think I understand what you mean.  I need to play with it
more to make sure, and then I'll see what I can do.  At this
point, I'm glad that it seems to be working _at all_, though...
so any further improvements are just a bonus, IMO. :-D

 
> 2am, why this doesn't surprises me? XDD

It's the only time I get to really hack on Tux Paint these days.
Maybe once I retire, I can stop being an open source vampire. ;)

-bill!

Re: [Tuxpaint-devel] Polygon fill messing with other tools drawing

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

El ds. 01 de 06 de 2024 a les 01:48 -0700, en/na Bill Kendrick va escriure:
> On Wed, May 29, 2024 at 10:06:07AM +0200, Pere Pujal i Carabantes wrote:
> > Hi Bill, and all,
> > 
> > A problem, start drawing a polygon and do as many points as possible (17?) 
> > then you are blocked, you can either switch out of the tool or drag the 
> > latest point to the origin closing the polygon, which is not very intuitive.
> > Assuming the only thing you can do in the tool is to close the polygon, 
> > I suggest to do this automatically.
> 
> I think we can raise the number of points.  In the meantime, I updated it
> so that clicking again will simply move the end point (rather than silently
> and confusingly doing _nothing_).

Better :)
Could be improved if a click in the starting point closes the polygon, 
as it is now you have to click outside the starting point and drag into it,
the following works for me.


git diff
diff --git a/magic/src/polyfill.c b/magic/src/polyfill.c
index 25e4cc436..6f1d51bd6 100644
--- a/magic/src/polyfill.c
+++ b/magic/src/polyfill.c
@@ -401,7 +401,7 @@ polyfill_release(magic_api * api, int which ATTRIBUTE_UNUSED,
   /* If they simply clicked the first point (without
      drawing to move it), and there are enough points, consider
      it a final placement of a new point! */
-  if (polyfill_editing == 0 && polyfill_dragged == 0 && polyfill_num_pts > 2 && polyfill_num_pts < MAX_PTS)
+  if (polyfill_editing == 0 && polyfill_dragged == 0 && polyfill_num_pts > 2 && polyfill_num_pts <= MAX_PTS)
   {
 #ifdef DEBUG
     printf("Clicked first point to end polygon!\n");



> 
> > Then there is the interaction with the Undo tool: draw say 5 points and go 
> > to another tool without closing the polygon, the helper lines and points 
> > disappear (by design?), hit Undo and they reappear, 
> > I'd suggest to either keep them in the drawing or erase them from the undo stack.
> 
> Okay, I've made an attempt to prevent the previews from landing in the
> undo history.  This is via a new Magic API function that magic tools may
> call: api->retract_undo().  It basically just rolls back `cur_undo` and
> `newest_undo` by one, so whatever was just snapped (during a mousedown
> event, just prior to the Magic tool's `_click()` from being called)
> gets "forgotten".
> 
> So for example, I can click a bunch of times to make a new polygon,
> and when I hit Undo, it goes back to the canvas as it appeared before
> I added the very first point.  And when I hit Redo, the entire polygon
> reappears in its final (non-preview) form.
> 
> HOPEFULLY this works well.  It's almost 2am, and I was tired many hours
> _before_ I tried tackling this. :-D
> 
> Before I go to bed I'm going to add info about this to the API docs.
> Hopefully in the next few days I can see about utilizing this with
> other Magic tools that offer "previews" that live beyond the
> (1) click, (2) drag, (3) release lifespan (e.g., Clone, and the
> Perspective drawing tools)... so they will stop "corrupting" the
> Undo history with their outline and crosshair nonsense. ;-)
> 
> This is quite a hack, I admit, so wish me luck!
> 
> And PLEASE TEST!  Bang on it as much as you can, and report back!

Works fine as far as I've tested :), the only improvement I could imagine 
is to use the first Undo just to clear the auxiliary stuff, 
withouth undoing previous work, other Undo acting as of now.

Best
Pere

2am, why this doesn't surprises me? XDD

> 
> Thanks,
> 
> PS - I also updated the description to mention that points may be
> merged.  (Sorry to translators for asking for updated localizations,
> and then immediately going in and messing with strings :-[ )
> 
> PPS - The commit (so far) that adds this new functionality is:
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/01afb5846c2b9d7c58961d38b27cd597d367d766/
> ("api->retract_undo() added to Magic API; used by Filled Polygon")
> 
> -bill!
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Polygon fill messing with other tools drawing

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

On Wed, May 29, 2024 at 10:06:07AM +0200, Pere Pujal i Carabantes wrote:
> Hi Bill, and all,
> 
> A problem, start drawing a polygon and do as many points as possible (17?) 
> then you are blocked, you can either switch out of the tool or drag the 
> latest point to the origin closing the polygon, which is not very intuitive.
> Assuming the only thing you can do in the tool is to close the polygon, 
> I suggest to do this automatically.

I think we can raise the number of points.  In the meantime, I updated it
so that clicking again will simply move the end point (rather than silently
and confusingly doing _nothing_).


> Then there is the interaction with the Undo tool: draw say 5 points and go 
> to another tool without closing the polygon, the helper lines and points 
> disappear (by design?), hit Undo and they reappear, 
> I'd suggest to either keep them in the drawing or erase them from the undo stack.

Okay, I've made an attempt to prevent the previews from landing in the
undo history.  This is via a new Magic API function that magic tools may
call: api->retract_undo().  It basically just rolls back `cur_undo` and
`newest_undo` by one, so whatever was just snapped (during a mousedown
event, just prior to the Magic tool's `_click()` from being called)
gets "forgotten".

So for example, I can click a bunch of times to make a new polygon,
and when I hit Undo, it goes back to the canvas as it appeared before
I added the very first point.  And when I hit Redo, the entire polygon
reappears in its final (non-preview) form.

HOPEFULLY this works well.  It's almost 2am, and I was tired many hours
_before_ I tried tackling this. :-D

Before I go to bed I'm going to add info about this to the API docs.
Hopefully in the next few days I can see about utilizing this with
other Magic tools that offer "previews" that live beyond the
(1) click, (2) drag, (3) release lifespan (e.g., Clone, and the
Perspective drawing tools)... so they will stop "corrupting" the
Undo history with their outline and crosshair nonsense. ;-)

This is quite a hack, I admit, so wish me luck!

And PLEASE TEST!  Bang on it as much as you can, and report back!

Thanks,

PS - I also updated the description to mention that points may be
merged.  (Sorry to translators for asking for updated localizations,
and then immediately going in and messing with strings :-[ )

PPS - The commit (so far) that adds this new functionality is:
https://sourceforge.net/p/tuxpaint/tuxpaint/ci/01afb5846c2b9d7c58961d38b27cd597d367d766/
("api->retract_undo() added to Magic API; used by Filled Polygon")

-bill!

Re: [Tuxpaint-devel] Polygon fill messing with other tools drawing

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

El dc. 29 de 05 de 2024 a les 10:06 +0200, en/na Pere Pujal i Carabantes va escriure:
> Hi Bill, and all,
> 
> A problem, start drawing a polygon and do as many points as possible (17?) 
> then you are blocked, you can either switch out of the tool or drag the 
> latest point to the origin closing the polygon, which is not very intuitive.
> Assuming the only thing you can do in the tool is to close the polygon, 
> I suggest to do this automatically.

I spoke too fast :( 
There is also the possibility of removing one or more points
that will let you be able to add some new ones.

Removing points is not mentioned in the UI tool description.


Pere


> 
> Then there is the interaction with the Undo tool: draw say 5 points and go 
> to another tool without closing the polygon, the helper lines and points 
> disappear (by design?), hit Undo and they reappear, 
> I'd suggest to either keep them in the drawing or erase them from the undo stack.
> 
> HTH
> Pere
> 
> El dc. 29 de 05 de 2024 a les 00:05 -0700, en/na Bill Kendrick va escriure:
> > On Sun, Apr 07, 2024 at 03:11:09PM +0200, Pere Pujal i Carabantes wrote:
> > > Hi all,
> > > 
> > > Tested the new polyfill stuff, it is nice :)
> > 
> > Hi Pere (and everyone),
> > 
> > I'd appreciate if you could test the Filled Polygon tool some more.
> > Also, please enjoy (and report any issues with!) some sound effects
> > that I just added.
> > 
> > There are different sounds for
> > 
> >  * adding a new point
> >  * dragging the new point / moving an existing one
> >  * dragging either end point next to the other, when 3+ points exist
> >    (you are "at risk" of completing the polygon ;) )
> >  * dragging one point into another, thus merging them
> >    (removing a point)
> >  * completing the polygon
> > 
> > 
> > I'm hoping to release a new version of Tux Paint soon,
> > ahead of a busy summer.  I'll post to -i18n and -maintainers
> > about this fact. :)
> > 
> > -bill!
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>