tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] Template export from Open dialog

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

For a while now we've had the ability to export drawings to a location
'outside' of Tux Paint, and easier to access (e.g., on Linux, under
$HOME/Pictures/TuxPaint/) -- via the "Export" button in the "Open"
dialog.  (There's also an animated GIF export feature, if you drill
down into the "Slides" slideshow section, that arrived at the same time.)

I've now added the ability to export a saved image into the user's
personal Templates directory (e.g., on Linux, $HOME/.tuxpaint/templates/)

This way, together with the Eraser tool (which now has a set of
fuzzy-edged options), you can make a new picture in layers.
It's obviously not as sophisticated as real Layers (capital-L) in apps
like Photoshop & GIMP, but it will be helpful to some users.

I can also see it being utilized for animations.  Right now, you can
create a background, and save it (let's call this picture #0).
Then add your foreground options, and save out to a new drawing
(picture #1; the first frame of the animation).  Then you need to
reload picture #0, redraw EVERYTHING in its new place, and save out to
another new drawing (picture #2).  Repeat.

With a template, you can create a new picture using the background,
draw things, and save it (picture #1).  Then use the eraser, clone
tool, etc. to make adjustments, and the save to a new drawing
(picture #2).

Anyway, along with the new feature, I've updated the docs (README,
EXTENDING, manpage, etc.).  This feature can be disabled with a new
"notemplateexport" option.  I'm about to add that to Tux Paint Config.

Note - Tux Paint will do its best to avoid saving the same unmodified
picture out to multiple new Templates.  Each template's filename uses
the original drawing's filename (which was the timestamp of the moment
it was _first_ saved) as a prefix.  For any image which matches that
name, it will check if the files are an identical size (via stat()).
If they happen to be, then it will check the image's dimensions
(via libPNG).  In the likely event that they are identical, it will
then calculate a CRC checksum (via zlib) of the images to see if the
file contents are the same.  If they are, it will avoid exporting a
new template, and state as much to the end user.

Please try it out (`git pull` master branch), and let me know if there
are any issues!  Thanks!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Mesh deforming / warp transform tools

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

I'd love to add some tools to Tux Paint like GIMP's Warp Transform
tools ("push", "swirl", "shrink", and "grow").  If anyone out here
happens to be good at that kind of math, let me know! :)
(See https://sourceforge.net/p/tuxpaint/feature-requests/239/)

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Beta release of Tux Paint 0.9.30 & friends

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

Beta builds of Tux Paint 0.9.30 & friends are available for testing
for Windows, macOS, Android, and RHEL Linux (with Haiku hopefully
coming soon).  You can download it now!  Please see:

  https://tuxpaint.org/beta/

The main new features of Tux Paint itself, coming in 0.9.30, are:

 * Many Magic tools now offer sizing options!
 * A few other Magic tools improved
 * Documentation for Magic tools include example screenshots
 * Labels on UI buttons word-wrap, for improved legibility

Please test, and report back any bugs ASAP, so we can try to fix
them ahead of the final 0.9.30 release.

Thanks in advance & enjoy!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Radio ads for Tux Paint (school project)

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

Friends, I wanted to share something that I hope brightens your day.

A few weeks back, I received a message from Stu Keroff ("Stu Does Linux"),
a social studies & technology teacher who does a lot to promote Linux
clubs for kids (here's more about him: https://opensource.com/users/stu-keroff)

  In my Grade 7 Tech class, students were instructed to use Audacity to
  record and edit radio ads for Open Source programs. A few of my
  students chose Tux Paint. I thought I would send a couple to you to
  put a smile on your faces. Have a great day.

Hey said that it was fine to share them (he asked the kids, and only
provided their first names), so here are the links:

  https://tuxpaint.org/files/ads/7thgrade-radio-ads/Gr%207%20Tux%20Paint%20Radio%20Ad%20Saranya%20&%20Ayushi.mp3
  https://tuxpaint.org/files/ads/7thgrade-radio-ads/Gr%207%20Tux%20Paint%20Radio%20Ad%20Wapte.mp3

In case you want to 'like' or share them yourselves on social media,
I've posted them:

 * Twitter
   https://twitter.com/TuxPaintTweets/status/1657453683196715008
   https://twitter.com/TuxPaintTweets/status/1657456178467864577

 * Facebook
   https://www.facebook.com/reel/232030689439418
   https://www.facebook.com/reel/1275324233415782

 * Instagram
   https://www.instagram.com/reel/CsMWyDUuznK/?utm_source=ig_web_copy_link&igshid=MzRlODBiNWFlZA==
   https://www.instagram.com/reel/CsMaxovr3wI/?utm_source=ig_web_copy_link&igshid=MzRlODBiNWFlZA==

 * Tumblr
   https://www.tumblr.com/tuxpaint/717227097898221568/a-7th-grade-tech-class-run-by-stu-keroff-stu?source=share
   https://www.tumblr.com/tuxpaint/717229737380085760/a-7th-grade-tech-class-run-by-stu-keroff-was?source=share

 * Mastodon
   https://floss.social/@tuxpaint/110362723485821719
   https://floss.social/@tuxpaint/110362867422546582


And here are the transcripts (I made these; hopefully with not too
many mistakes):

 * Saranya & Ayushi
   - Today's weather is very cold and it will be snowing the whole day.
   - Oh man, I wish my kids had something fun to do on a snowy day.
   - Are your kids feeling bored as it's snowing outside? Well no problem!
   - Did you just hear what I said from the TV?
   - Tux Paint: It's fun, efficient, and exciting. You can also use
     this for your kids when you're working and your kids just can't
     leave you alone.
   - Oh wow, my kids are having so much fun! I can also work peacefully
     without having to worry about them.
   - Woo-hoo! So fun!
   - You're welcome!
   - Tux Paint: Build a new world!

 * Wapte
   Hello, my name is Wapte, and I'm here to ask: have you ever wanted a
   good place to draw and express yourself but you just can't find one?
   Well Tux Paint is here to fix that. This app is by far one of the
   most clever and useful apps I've ever worked with. It truly is
   everything you can imagine; you can draw and paint, you can type,
   you can use real-life images to add to your paintings. Now you may
   ask: is that really all that it has? And well I say to that is no,
   it has so much more than that more. It has so many tools and so much
   depth that I couldn't name everything, even if I wanted to. Download
   this software today. It will change the way you feel about drawing
   forever.

Enjoy :)

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.30 Magic size feature -- please test git master!

[Luc S. <be...@gm...>]

Checked out the sources for both tuxpaint and tuxpaint-stamps, build and
install is fine.
Running TuxPaint is fine here too, about the new features, I'm not sure
what I should be checking, so far things look good to me.

Luc

Op ma 1 mei 2023 om 07:56 schreef Bill Kendrick <nb...@so...>:

> On Fri, Apr 28, 2023 at 08:35:26PM +0200, Pere Pujal i Carabantes wrote:
> > Got a couple of hours to test, all magic tools I've tested work fine
> here :)
>
> Great!
>
>
> > As suggestion, for rails and fretwork, you could try to
> increase/decrease
> > the size of PNGs.
>
> Maybe later. :^D  I would also like to add interlinked metal chains
> and metal pipes, which would be similar to these two tools, so
> maybe I'll try to add size capabilities at that time.
>
>
> > I found also that blind has fullscreen mode which seems unusefull,
> > as paint mode fullfills its purposes, but this has nothing to do with
> size.
>
> Oh wow, I never noticed!  I'll drop that. :)  Thanks!
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-maintainers mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers
>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

On Mon, May 01, 2023 at 07:51:19PM -0400, Mark Kim wrote:
> > sizing options, which appear as a little triangularly-shaped
> > set of buttons (similar to what we've had for Stamps scaling,
> 
> I don't see any triangularly shaped buttons when I select one of the tools
> that is supposed to have this feature (googly eyes).  (Screenshot below.)

Sorry, they are rectangular buttons, in a triangular shape,
kind of like a volume meter or wifi signal strength.
I see it at the bottom right of your screenshot, and that you
seemed to be able to make multiple sizes of googly eyes on your
canvas, so you've got it! :-)


> > Most (if not all) tools only offer this in the "paint" mode
> > (versus the full-canvas / entire-picture / MODE_FULLSCREEN mode),
> 
> Maybe I need to figure out how to get into this "paint" mode but I'm
> unclear what mode this is, because... isn't the normal mode the paint
> mode?  I mean... it's in the name of the application :)

Hah, sorry.  So for forever now, there's been the ability to, for example,
either blur parts of the picture by 'painting' over it, freehand style,
or choosing the option that applies the blur effect to the entire canvas
all at once.  It has the somewhat confusing name, internally, of
"MODE_FULLSCREEN".


> I checked Tux Paint config but don't see any mode called "paint" mode under
> the Video tab.  Just full screen and different window sizes.
<snip>

The option to disable both of these features are found in Tux Paint Config.
under the "Simplification" tab, in the section the right labeled
"Control Simplification".  Look for "Disable Magic Controls" and the
newly-added "Disable Magic Sizes" checkboxes.

(I'm seeing that the former also uses the confusing terminology of
"fullscreen" rather than "entire picture" or "entire canvas", that
I've been trying to train myself to use.  I'll go address that.)

HTH!

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

> sizing options, which appear as a little triangularly-shaped
> set of buttons (similar to what we've had for Stamps scaling,

I don't see any triangularly shaped buttons when I select one of the tools
that is supposed to have this feature (googly eyes).  (Screenshot below.)

> Most (if not all) tools only offer this in the "paint" mode
> (versus the full-canvas / entire-picture / MODE_FULLSCREEN mode),

Maybe I need to figure out how to get into this "paint" mode but I'm
unclear what mode this is, because... isn't the normal mode the paint
mode?  I mean... it's in the name of the application :)

I checked Tux Paint config but don't see any mode called "paint" mode under
the Video tab.  Just full screen and different window sizes.


This is what I see when I select Googly Eyes:
[image: image.png]

On Mon, May 1, 2023 at 4:41 PM Bill Kendrick <nb...@so...> wrote:

> On Mon, May 01, 2023 at 07:15:05AM -0400, Mark Kim wrote:
> > > Awesome!  Did you happen to toy with the new size functionality
> > > of the Magic tools?  Any feedback?
> >
> > I'm sorry but how do you use it? I couldn't figure it out.
>
> Many of the tools (see docs/CHANGES.txt for a list) now offer
> sizing options, which appear as a little triangularly-shaped
> set of buttons (similar to what we've had for Stamps scaling,
> slideshow playback speed (and animated GIF export speed), and
> brush spacing).
>
> Most (if not all) tools only offer this in the "paint" mode
> (versus the full-canvas / entire-picture / MODE_FULLSCREEN mode),
> as they affect the radius of the application of the Magic tool's
> effect (be it filter-like tools, such as Blur, Darken, Lighten;
> or drawing-like tools, like Kaleidoscope and the Symmetry painting
> tools, Toothpaste, and Light).
>
> For other tools, the sizing option doesn't apply (e.g., Zoom, Shift,
> or Fold (folded paper corner)) or there were other ways to change the
> size or intensity of the effect (e.g., Waves & Wavelets, and Blind
> (window blinds)).
>
> Tux Paint accepts a "--nomagicsizes" command-line option, or
> "nomagicsizes=yes" config. file option (also exposed and manipulable
> by Tux Paint Config.) which disables this feature.  Magic Tools,
> for the most part, revert back to the behavior seen in earlier
> versions of Tux Paint.
>
> In two cases, this actually causes the plugin to act differently.
> (During "..._init()", plugins are informed whether or not this feature
> has been deactivated.)  Both the Bricks and Googly Eyes tools now each
> only appear as a single tool, with various sizing options, rather than
> as two separate tools that draw "small" or "large" bricks or eyes.
> HOWEVER, if the sizing feature is disabled, they go back to appearing
> as two separate tools each like they had done previously.
>
> One way I've tracked down a few bugs was to basically 'spam' Tux Paint,
> by just scribbling all over and flipping between the different tools,
> their modes (paint vs fullscreeen), the different sizes, etc.
> This of course makes it a little hard to determine how to reproduce
> the issue.  (Perhaps I should use a screen recorder!)  The side effect
> is sometimes I come up with interesting abstract art. :-D
>
> HTH!
>
> PS - Also note that a few other Magic tools were updated slightly,
> beyond adding support for sizing.  They're also noted in docs/CHANGES.txt,
> if anyone feels like hammering on them. :)
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

On Mon, May 01, 2023 at 07:15:05AM -0400, Mark Kim wrote:
> > Awesome!  Did you happen to toy with the new size functionality
> > of the Magic tools?  Any feedback?
> 
> I'm sorry but how do you use it? I couldn't figure it out.

Many of the tools (see docs/CHANGES.txt for a list) now offer
sizing options, which appear as a little triangularly-shaped
set of buttons (similar to what we've had for Stamps scaling,
slideshow playback speed (and animated GIF export speed), and
brush spacing).

Most (if not all) tools only offer this in the "paint" mode
(versus the full-canvas / entire-picture / MODE_FULLSCREEN mode),
as they affect the radius of the application of the Magic tool's
effect (be it filter-like tools, such as Blur, Darken, Lighten;
or drawing-like tools, like Kaleidoscope and the Symmetry painting
tools, Toothpaste, and Light).

For other tools, the sizing option doesn't apply (e.g., Zoom, Shift,
or Fold (folded paper corner)) or there were other ways to change the
size or intensity of the effect (e.g., Waves & Wavelets, and Blind
(window blinds)).

Tux Paint accepts a "--nomagicsizes" command-line option, or
"nomagicsizes=yes" config. file option (also exposed and manipulable
by Tux Paint Config.) which disables this feature.  Magic Tools,
for the most part, revert back to the behavior seen in earlier
versions of Tux Paint.

In two cases, this actually causes the plugin to act differently.
(During "..._init()", plugins are informed whether or not this feature
has been deactivated.)  Both the Bricks and Googly Eyes tools now each
only appear as a single tool, with various sizing options, rather than
as two separate tools that draw "small" or "large" bricks or eyes.
HOWEVER, if the sizing feature is disabled, they go back to appearing
as two separate tools each like they had done previously.

One way I've tracked down a few bugs was to basically 'spam' Tux Paint,
by just scribbling all over and flipping between the different tools,
their modes (paint vs fullscreeen), the different sizes, etc.
This of course makes it a little hard to determine how to reproduce
the issue.  (Perhaps I should use a screen recorder!)  The side effect
is sometimes I come up with interesting abstract art. :-D

HTH!

PS - Also note that a few other Magic tools were updated slightly,
beyond adding support for sizing.  They're also noted in docs/CHANGES.txt,
if anyone feels like hammering on them. :)

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

> Awesome!  Did you happen to toy with the new size functionality
> of the Magic tools?  Any feedback?

I'm sorry but how do you use it? I couldn't figure it out.


On Mon, May 1, 2023, 01:57 Bill Kendrick <nb...@so...> wrote:

> On Sun, Apr 30, 2023 at 07:48:51PM -0400, Mark Kim wrote:
> > Hi,
> >
> > > Porters, please double-check that everything still works right.
> >
> > macOS seems to build and run fine.  Tested in English, Korean, and
> Japanese.
>
> Awesome!  Did you happen to toy with the new size functionality
> of the Magic tools?  Any feedback?
>
> Thanks!
>
> -bill!
>
>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

[Luc S. <be...@gm...>]

Just did a fresh checkout and build on Haiku, running into the next error
(seen it before a while ago).

...Generating thumbnails for starters...
.(starters/.thumbs/bald_eagle-t.png failed)
rm: cannot remove 'starters/.thumbs/bald_eagle-t.png': No such file or
directory
Makefile:853: recipe for target 'starters/.thumbs/bald_eagle-t.png' failed
make: *** [starters/.thumbs/bald_eagle-t.png] Error 1

Luc

Op ma 1 mei 2023 om 07:57 schreef Bill Kendrick <nb...@so...>:

> On Sun, Apr 30, 2023 at 07:48:51PM -0400, Mark Kim wrote:
> > Hi,
> >
> > > Porters, please double-check that everything still works right.
> >
> > macOS seems to build and run fine.  Tested in English, Korean, and
> Japanese.
>
> Awesome!  Did you happen to toy with the new size functionality
> of the Magic tools?  Any feedback?
>
> Thanks!
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-maintainers mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers
>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

On Sun, Apr 30, 2023 at 07:48:51PM -0400, Mark Kim wrote:
> Hi,
> 
> > Porters, please double-check that everything still works right.
> 
> macOS seems to build and run fine.  Tested in English, Korean, and Japanese.

Awesome!  Did you happen to toy with the new size functionality
of the Magic tools?  Any feedback?

Thanks!

-bill!

Re: [Tuxpaint-devel] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

On Fri, Apr 28, 2023 at 08:35:26PM +0200, Pere Pujal i Carabantes wrote:
> Got a couple of hours to test, all magic tools I've tested work fine here :)

Great!


> As suggestion, for rails and fretwork, you could try to increase/decrease 
> the size of PNGs.

Maybe later. :^D  I would also like to add interlinked metal chains
and metal pipes, which would be similar to these two tools, so
maybe I'll try to add size capabilities at that time.


> I found also that blind has fullscreen mode which seems unusefull, 
> as paint mode fullfills its purposes, but this has nothing to do with size.

Oh wow, I never noticed!  I'll drop that. :)  Thanks!

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

Hi,

> Porters, please double-check that everything still works right.

macOS seems to build and run fine.  Tested in English, Korean, and Japanese.

Mark

On Sun, Apr 30, 2023 at 7:33 PM Bill Kendrick <nb...@so...> wrote:

>
> Based on research by Pere, it seems that Tux Paint (as recent as
> version 0.9.28) supplied by Debian (and it appears, based on this,
> Ubuntu) does not render some text properly (e.g., Japanese & Arabic).
>
> This is because they are being built _without_ Pango support
> (which, these days, is supplied by the SDL2 port of the "SDL_Pango"
> library, "SDL2_Pango", as maintained by our own Mark Kim, here:
> https://github.com/markuskimius/SDL2_Pango).
>
> To avoid this in the future, and hopefully encourage the Debian
> maintainers to also get SDL2_Pango packaged, so they can keep
> Tux Paint up-to-date as well, I've just removed support for
> building Tux Paint _without_ Pango.  (Rather than detecting it
> is unavailable, and compiling things with "NO_SDLPANGO" #define'd,
> and using different code to render text using "SDL_ttf" library
> as a fallback, it will just refuse to build!)
>
> Porters, please double-check that everything still works right.
>
> Another benefit of this is the removal of a lot of very old code from
> our codebase, most of which has probably not been maintained much
> lately!
>
> Backstory: https://sourceforge.net/p/tuxpaint/bugs/268/
> The main commit in question:
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/cef773a69493c7c76073bdd59ac49c5bbde21aa9/
>
> (I also updated the INSTALL docs, and the Requirements webpage,
> to reflect this new reality.  Let me know if I missed anything!)
>
> Thanks all!  I'm hoping to get 0.9.30-rc1 rolled into a tarball
> some time soon!!!
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-maintainers mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers
>

[Tuxpaint-devel] Tux Paint will now _require_ SDL2_Pango [0.9.30 & beyond]

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

Based on research by Pere, it seems that Tux Paint (as recent as
version 0.9.28) supplied by Debian (and it appears, based on this,
Ubuntu) does not render some text properly (e.g., Japanese & Arabic).

This is because they are being built _without_ Pango support
(which, these days, is supplied by the SDL2 port of the "SDL_Pango"
library, "SDL2_Pango", as maintained by our own Mark Kim, here:
https://github.com/markuskimius/SDL2_Pango).

To avoid this in the future, and hopefully encourage the Debian
maintainers to also get SDL2_Pango packaged, so they can keep
Tux Paint up-to-date as well, I've just removed support for
building Tux Paint _without_ Pango.  (Rather than detecting it
is unavailable, and compiling things with "NO_SDLPANGO" #define'd,
and using different code to render text using "SDL_ttf" library
as a fallback, it will just refuse to build!)

Porters, please double-check that everything still works right.

Another benefit of this is the removal of a lot of very old code from
our codebase, most of which has probably not been maintained much
lately!

Backstory: https://sourceforge.net/p/tuxpaint/bugs/268/
The main commit in question: https://sourceforge.net/p/tuxpaint/tuxpaint/ci/cef773a69493c7c76073bdd59ac49c5bbde21aa9/

(I also updated the INSTALL docs, and the Requirements webpage,
to reflect this new reality.  Let me know if I missed anything!)

Thanks all!  I'm hoping to get 0.9.30-rc1 rolled into a tarball
some time soon!!!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

Got a couple of hours to test, all magic tools I've tested work fine here :)

As suggestion, for rails and fretwork, you could try to increase/decrease 
the size of PNGs.

I found also that blind has fullscreen mode which seems unusefull, 
as paint mode fullfills its purposes, but this has nothing to do with size.


HTH
Pere


El dg. 23 de 04 de 2023 a les 17:28 -0700, en/na Bill Kendrick va escriure:
> I've spent the past two weeks slowly working through every single
> Magic tool plugin (".c source file") to update them all to work with
> the Magic tool API that I've extended slightly in what will become
> version 0.9.30.
> 
> For about 50 of the Magic tools, I've added support for various sizing
> options. [1]  (For example, different sized flowers, thicker toothpaste,
> chunkier blocks, bigger pixelart pixels, more Googly eye sizes, etc.)
> 
> The new Magic size feature can be disabled using the "nomagicsizes"
> option (e.g., "--nomagicsizes" on the command line, or
> "nomagicsizes=yes" in the config file).
> 
> It would be very helpful if people could test Tux Paint in _both_ the
> standard mode -- where many of the tools offer sizes -- as well as the
> simplified mode -- where the tools should all revert back to acting,
> more or less, like they did in Tux Paint 0.9.29 and earlier. [2]
> 
> I'm thinking of releasing a new version of Tux Paint relatively
> soon (compared to the 10 months between the last two versions,
> or sometimes many _years_ between other versions), therefore...
> 
> As with 0.9.29, before I bother rolling the first release candidate
> ("0.9.30-rc1") to have beta testers out in the wild try out, I'd like
> to ask folks here on the team to help me alpha test it!
> 
> So please "git pull" from master, build it, and try it out!  Let me
> know if you come across any bugs or have any suggestions! [3]
> 
> Thanks in advance!!!
> 
> -bill!
> 
> [1] The full list of Magic tools that gained 'size' support is:
>     + Blocks, Chalk, Drip
>     + Bloom
>     + Blur
>     + Bricks
>     + Cartoon
>     + Clone
>     + Confetti
>     + Darken, Lighten
>     + Distortion
>     + Emboss
>     + Fisheye
>     + Flower
>     + Foam
>     + Googly Eyes
>     + Kaleidoscope, Symmetric L/R & U/D, Pattern, Tiles
>     + Light
>     + Metal Paint
>     + Mosaic
>     + Negative & Opposite
>     + Noise
>     + Pixels
>     + Puzzle
>     + Rain
>     + Rainbow & Smooth Rainbow
>     + Remove Color, Keep Color
>     + Ripples
>     + Rosette, Picasso
>     + Saturate, Desaturate
>     + Sharpen, Edges, Silhouette
>     + Smudge, Wet Paint
>     + Tint, Color & White
>     + Toothpaste
>     + TV
>     + Xor Colors
> 
> [2] I also did update a few of the Magic tools to improve their
>     behavior (e.g., Foam would often show oval bubbles, which was
>     never my intention!  String tools benefitted from XOR previews.
>     And so on...)
> 
> [3] Moments after I thought I was finally all done, I discovered an
>     `update_rect` bug with Pixels that I had to correct. :)
> 

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

On Thu, Apr 27, 2023 at 09:02:14AM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I've tried current git version just last night and did not see any problem in compiling as well as using the new sizing featuer of magic tools.

I was aimlessly playing with Tux Paint some last night and discovered
a bug where sometimes the 'paint' mode of a tool would not draw
anything, and it was because it was inheriting a '0' size from the
'fullscreen' mode of the same tool.

I beleive I've corrected that bug, but there could be other situations
where something like this might happen, because our code is very
large and complicated. ;-(

In other news, I 'ported' Tux Paint's canvas size calculation code
over to Tux Paint Config., in an attempt to have it show it, and
keep it updated as you adjust window/screen size, button size,
color rows, and orentiation (landscape/portrait).  It SEEMS to work,
but I was -- as usuall -- up very late hacking on it.  So I'd
appreciate some alpha testing there, too! :-)

Also, I now have Tux Paint detect the "SDL_VIDEO_WINDOW_POS"
environment variable (which we do manually, since SDL2 does not)
even when running in fullscreen mode.  It seems that if I give it
any coordinates within my upper monitor (Y < 1080), Tux Paint will
appear there.

If I specify anything larger than my external monitor's vertical
resolution (Y >= 1080), or if I don't specify anything (which causes
Tux Paint to send SDL it's "...UNDEFINED" consts for window
positioning), Tux Paint appears on my lower monitor -- my laptop's
built-in display, which I have set in KDE as my "primary".

So that's nice!  It's not as handy as having a command-line setting
or config file option -- or the wishlist item we have for allowing
Tux Paint to 'remember' its window position (which I feel could get
complicated if your monitor configuration changes... e.g., removing
the sole external monitor) -- but at least it lets me easily
position Tux Paint on my larger, easier-to-see display.

(On my system, both my external monitor and laptop have the same
resolution, but the external is larger (so lower DPI), and hence
easier to see.  It's also higher, in a more eronomic position.
Note that I very recently discovered that I can use my KDE
"Alt + left click" combo that I use for quickly grabbing and
repositioning windows!!!  It didn't allow me to position it
precisely, obviously, because it's in fullscreen mode, but it did
let me 'snap' it between the two displays!  I'll need to see what
happens if they are not the _same resolution_ though. 8^o [*])

Thanks all!

-bill!
PS - I also closed a few very very old (14+ years) feature requests
that I don't feel are 'burning needs' and would rather not worry
about.  Sorry if anyone's hopes were dashed. ;)

[*] This also reminds me of an apparent bug in how SDL2 deals
with 'windowshading' effect (collapsing an entire window down
to just its toolbar; different from minimizing it).  A while back
I discovered that when I 'un-windowshade' Tux Paint, I get an
extremely misshappen window with a TINY thumbnail-sized Tux Paint
appearing inside.  The window is the same width (e.g., 800px wide),
but only a few pixels tall!  I mentioned on Twitter, and the SDL
developers said to open a bug, and of course I forgot about it
until right now. :^]  <Makes a note>

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

On Thu, Apr 27, 2023 at 09:02:14AM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I've tried current git version just last night and did not see any problem in compiling as well as using the new sizing featuer of magic tools.
> 
> Just for brief report.

I appreciate it, thanks! :)

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

Hi!

I've tried current git version just last night and did not see any problem in compiling as well as using the new sizing featuer of magic tools.

Just for brief report.

HTH

On 2023年4月27日 8:09:48 JST, Bill Kendrick <nb...@so...> wrote:
>
>I haven't touched the Tux Paint code since Sunday, except to re-run
>"indent" to clean up any code formatting inconsistencies that were
>introduced in recent months. [*]
>
>I'm curious whether anyone out here has had time to try out the new
>Magic tool size options yet?
>
>On the other hand, if folks here would prefer that I just get
>real-life beta testers in the wild to try things out, then I'd be
>happy to just roll a release candidate tarball.
>
>First, though, at the very least, it'd be good to know it all still
>compiles, and that it doesn't crash on any platform.
>
>Sorry for being impatient...  I'm excited for the new feature, and a
>lot of our fans on Twitter are too.  :-D
>
>Thanks as always,
>
>-bill!
>
>[*] I also added shell scripts to both Tux Paint & Tux Paint Config.
>    (in both cases, "src/indent.sh") to do the job in the future,
>    so I don't have to go back and dig up the precise options every time.
>
>
>_______________________________________________
>Tuxpaint-maintainers mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-maintainers

Re: [Tuxpaint-devel] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

I haven't touched the Tux Paint code since Sunday, except to re-run
"indent" to clean up any code formatting inconsistencies that were
introduced in recent months. [*]

I'm curious whether anyone out here has had time to try out the new
Magic tool size options yet?

On the other hand, if folks here would prefer that I just get
real-life beta testers in the wild to try things out, then I'd be
happy to just roll a release candidate tarball.

First, though, at the very least, it'd be good to know it all still
compiles, and that it doesn't crash on any platform.

Sorry for being impatient...  I'm excited for the new feature, and a
lot of our fans on Twitter are too.  :-D

Thanks as always,

-bill!

[*] I also added shell scripts to both Tux Paint & Tux Paint Config.
    (in both cases, "src/indent.sh") to do the job in the future,
    so I don't have to go back and dig up the precise options every time.

[Tuxpaint-devel] Tux Paint 0.9.30 Magic size feature -- please test git master!

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

I've spent the past two weeks slowly working through every single
Magic tool plugin (".c source file") to update them all to work with
the Magic tool API that I've extended slightly in what will become
version 0.9.30.

For about 50 of the Magic tools, I've added support for various sizing
options. [1]  (For example, different sized flowers, thicker toothpaste,
chunkier blocks, bigger pixelart pixels, more Googly eye sizes, etc.)

The new Magic size feature can be disabled using the "nomagicsizes"
option (e.g., "--nomagicsizes" on the command line, or
"nomagicsizes=yes" in the config file).

It would be very helpful if people could test Tux Paint in _both_ the
standard mode -- where many of the tools offer sizes -- as well as the
simplified mode -- where the tools should all revert back to acting,
more or less, like they did in Tux Paint 0.9.29 and earlier. [2]

I'm thinking of releasing a new version of Tux Paint relatively
soon (compared to the 10 months between the last two versions,
or sometimes many _years_ between other versions), therefore...

As with 0.9.29, before I bother rolling the first release candidate
("0.9.30-rc1") to have beta testers out in the wild try out, I'd like
to ask folks here on the team to help me alpha test it!

So please "git pull" from master, build it, and try it out!  Let me
know if you come across any bugs or have any suggestions! [3]

Thanks in advance!!!

-bill!

[1] The full list of Magic tools that gained 'size' support is:
    + Blocks, Chalk, Drip
    + Bloom
    + Blur
    + Bricks
    + Cartoon
    + Clone
    + Confetti
    + Darken, Lighten
    + Distortion
    + Emboss
    + Fisheye
    + Flower
    + Foam
    + Googly Eyes
    + Kaleidoscope, Symmetric L/R & U/D, Pattern, Tiles
    + Light
    + Metal Paint
    + Mosaic
    + Negative & Opposite
    + Noise
    + Pixels
    + Puzzle
    + Rain
    + Rainbow & Smooth Rainbow
    + Remove Color, Keep Color
    + Ripples
    + Rosette, Picasso
    + Saturate, Desaturate
    + Sharpen, Edges, Silhouette
    + Smudge, Wet Paint
    + Tint, Color & White
    + Toothpaste
    + TV
    + Xor Colors

[2] I also did update a few of the Magic tools to improve their
    behavior (e.g., Foam would often show oval bubbles, which was
    never my intention!  String tools benefitted from XOR previews.
    And so on...)

[3] Moments after I thought I was finally all done, I discovered an
    `update_rect` bug with Pixels that I had to correct. :)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Magic size option

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

On Thu, Apr 13, 2023 at 10:18:56AM -0700, Bill Kendrick wrote:
> 
> I've extended Tux Paint's Magic "API", and added a UI element to the
> Magic tool, to allow magic tools to support sizes.

Whew!  This has been tedious, and some of the older Magic tools that I
don't fully understand the operation of (fancy math, etc.) have taken
(or will take) a bit of work to retrofit... but I've so far gone through
a lot of the plugins already, and either:

(a) added support for sizes (e.g., Toothpaste can come out different
thicknesses, the Bricks tool collapses down to one item in the
toolbar, with two size options -- unless "--nomagicsizes" is
specified, in which case it splits into two separate tools again, to
avoid removing any pre-existing functionality),

or (b) had them respond correctly to the updated API, so they load
again (e.g., Stretch, Perspective, Checkerboard, etc. do not offer
sizing options, as it wouldn't make sense).


For those interested in what has been involved, generally it's:

In all cases:

1. add the "Uint32 disabled_features" argument to _init()
2. create a new "Uint8 _accepted_sizes()" function
3. create a new "Uint8 _default_size()" function
4. create a new "void _set_size()" function
5. update/add function prototypes to correspond to all those


And, in the case of (a), adding sizing support:

1. Change a global "const int" or "#define" value into a regular
   global "int", or add a new global "int" if none existed
   (or sometimes it was a "float")

2. Have "_accepted_sizes()" return some value > 1

3. Have "_default_size()" return a value that will end up matching
   the tool's size (e.g., the radius of a painted brush or applied
   effect) as it has been all along (in 0.9.29 & earlier).

   This way, "out of the box" (that is, without the user having
   to make adjustments to the size setting), it will work like it
   always has, prior to 0.9.30.  And, importantly, if the
   "--nomagicsizes" option is set, and the sizing controls are
   therefore not available, it will simply work like it always has.

4. Have "_set_size()" accept the size setting (which will be
   a value between '1' and the maximum -- what we returned in
   "_accepted_sizes()") and place it into the global variable.

   Some calculation may take place here. i.e., if the default size
   was 16, I might choose to offer 6 size settings, with the default
   being "4", and then multiply the size by 4 to get the radius
   in pixels.  (Therefore the tool would suppport 4px, 8px, 12px, 16px,
   20px, and 24px radii.)

   It's all a bit arbitrary, which is where alpha & beta testing
   might come in handy.  "Did the numbers Bill selected late at
   night after a long day's work _actually make sense?_" ;)

5. If the radius was hard-coded, or perhaps some other calculations
   were hard-coded, update them as necessary to use the new global
   variable.

   (For example, "confetti.c" used "CONFETTI_BRUSH_SIZE", but _also_ had
   some hard-coded numbers related to how the effect should be spread
   out, which I updated to be based on a multiple of CONFETTI_BRUSH_SIZE,
   so that it also scaled up/down properly.)

6. Watch out for other unintended consequences related to size
   changes!

   (For example, "toothpaste.c" had "toothpaste_RADIUS = 10", which
   I was able to utilize, but then I noticed the effect didn't work
   properly at sizes larger than the original.  It turns out there was
   a kind of cached 'intensity' matrix, "toothpaste_weights",
   which was allocated & filled during _init().  The solution was to
   free(), re-malloc(), and re-fill it every time the size was changed
   via "_set_size()")

7. Always remember to mention new features ("tool X now supports sizes")
   in the changelog!  (docs/CHANGES.txt)  ;-)


For some plugins, it's a little more complicated.  Many plugins offer
multiple tools, and/or run in different modes...

 * Size options may only make sense with some of the plugin's tools.
   Or, the sizes you want to make available may differ for each tool.

   Consult the "which" variable sent to each function, especially in
   "_accepted_sizes()".

 * For tools that offer both "painting" (brush) and "entire picture"
   (full canvas) application of an effect -- such as the "Blur" tool,
   and where the size option is being used to set the radius of the
   applied effect when "painting" it -- the size option doesn't make
   sense in the "entire picture" mode.

   Check the "mode" variable against "MODE_FULLSCREEN" in your
   "_accepted_sizes()", and return 0 or 1 (both mean the same),
   in that case.

   Note: This isn't a hard and fast rule.  As long as it's not
   confusing to users, it might actually make sense for the
   "sizing" options to have different meanings in the two different
   modes.

   While I'm generally using for the literal size (radius) of an
   effect, the sizing option could also be used to indicate "intensity".
   And, for example, the "Bricks" tools use size to dictate the size of
   the brick shapes, not a specific "radius".

Finally, in the case of (b), making plugins work again (without
supporting size options), simply extend the plugin so it contains
all of the functions that the updated API requires.  This was handled
in the "in all cases" steps above, but to wrap that up, you need to:

1. Have "_accepted_sizes()" return a 0 (or a 1), which means
   "I only offer one size; do not make the sizing controls available".

2. Have "_default_size()" return anything (0 makes sense).

3. "_set_size()" can be an empty function.


Unfortunately, I'm not sure how to get Tux Paint to detect whether
a function knows to accept certain arguments or not, but it does
complain (& avoid trying to load any Magic tools from a plugin) if
functions are completely missing.

So when you run Tux Paint, you will see complaints like:

  Error: plugin /usr/local/lib/tuxpaint/plugins/clone.so is missing accepted_sizes
  Error: plugin /usr/local/lib/tuxpaint/plugins/clone.so is missing default_size
  Error: plugin /usr/local/lib/tuxpaint/plugins/clone.so is missing set_size

(Despite this, I'm also also being sure to update every plugin's "init()"
function, to accept the new "Uint32 disabled_features" argument.)


For examples of where plugins detect "--nomagicsizes" being set
("_init()" receives the bit "MAGIC_FEATURE_SIZE" in "disabled_features"),
and then behave differently, see "googlyeyes.c" and "bricks.c".

Those plugins historically provided two different tools (large & small).
Now, they can just provide one tool which offers two (or more) sizes via
the new sizing feature.

However, if the sizing feature is disabled, they revert back to providing
two separate tools, as they did in 0.9.29 & prior.

Whew!  I hope this all makes sense; typing it up over a long period
while doing other things. :-)

-bill!

[Tuxpaint-devel] Magic size option

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

I've extended Tux Paint's Magic "API", and added a UI element to the
Magic tool, to allow magic tools to support sizes.

For example, for 20 years now, tools like "Darken" have been locked at
a particular size -- e.g., a 16px diameter circle -- making it
difficult to make finer adjustments.

Now, it will be possible for such tools to tell Tux Paint, for example,
"I accept 4 different sizes, and my default is '2'".  The Magic tool
will then show a little 4-step sizing selector (similar to the options
for stamp sizes, brush spacing, and slideshow playback speed).

Almost none of the Magic tools support the updated API yet (I need to
go in and edit every single pluin source!), so if you `git pull` right
now, don't be surprised when you see almost all of the Magic tools
missing. ;-)

I've so far worked on three plugins:

 * Kaleidoscope, Symmetry, Tile, Pattern -- offer different thickness
   levels for the lines you paint.

 * Blur -- offer different radiuses for the blur effect.

   Since the Blur tool offers both 'paint'/freehand mode, and
   'fullscreen'/affect-the-whole-canvas-at-once mode, I had to
   make sure the sizing option was not just tool-specific,
   but also mode-specific.

 * Googly Eyes -- offer four different sizes of googly eyes.

   But wait!  Tux Paint already has two different googly eye
   tools -- large & small!  Well, it won't any more.
   That is, unless Tux Paint is invoked with "--nomagicsizes",
   which disables this new feature altogether, thus simplifying
   the UI for younger kids.

It isn't a requirement that size option needs to affect the
radius of an applied effect (like darken, blur, etc.), or the thickness
of a painted effect (like toothpaste or fur); it's entirely up
to the Magic tool to decide how to interpret the user's choice.
(Of course, we need to avoid too many 'surprises'.)

For example, the new Kaleido-X tools could be collapsed into a
single tool (when this new sizing UI hasn't been disabled), and
offer the different variations (-4, -6, and -8 -- and perhaps more!)
via the 'sizing' interface.  Some tools may end up using the setting
more as an 'intensity' option.  (I've actually thought of providing
TWO sliders, but... I need to not go overboard, here, I think!)

Why did I do this?  It's by popular demand.  Obviously, folks I hear
from on Twitter are not the youngest users of Tux Paint, and are
skewed more in the teen-to-twenties age range, but of course that's
why I always try to make it possible to turn off new "advanced"
features for the younger users.  (The option to disable this
is already in tuxpaint-config git master. :) )

Long story short, basically there are a lot of places where we
(mostly me) picked an arbitrary hard-coded value that gets used
by Magic tools, but now it's possible to let the user pick
from a variety of sizes :)


-  for (yy = -8; yy < 8; yy++)
-  {
-    for (xx = -8; xx < 8; xx++)

+  for (yy = -kalidescope_sz; yy < kalidescope_sz; yy++)
+  {
+    for (xx = -kalidescope_sz; xx < kalidescope_sz; xx++)


-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Word-wrapping button labels; scaling button icons

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

In an attempt to make Tux Paint's buttons _slightly_ more usable, last
night I updated the label generation to apply a word-wrap to the label
text.  It looks for a space character around the middle-ish of the
string, and turning it into a "\n" newline; h/t Jozef for pointing out
that this 'just works', if entering them manually in the "msgstr" in
the PO files!)

When the text gets word-wrapped, it is allowed to take up about 1.5 times
the height as a single-line string.  If the text + icon end up overlapping,
the icon will be scaled (vertically only; so it gets squished a little,
which I feel is acceptable).

This helps a bit, even improving some of the longer English strings.
In some cases, the strings are still VERY long (especially with the
default buttonsize of '48' pixels), and when there's nowhere to split
(no space character), it doesn't help at all.  Greek is still quite
unsatisfactory, but overall I think it's an improvement.

Some screenshots can be seen in the very old bug about this (2009! ;-( )
https://sourceforge.net/p/tuxpaint/bugs/131/

Please take a look, check that things are working okay for you, and if
anyone else has any ideas for improvements, let me know!

Sadly, Tux Paint's UI is all homegrown, and handled individually
within each 'part' of the app.  A long time ago, there were very few
'places', but there are a few more now (the various color pickers,
slideshow, ...).  So I feel like before we could overhaul things in
a big way, we'd need to generalize/modularize a bit more.

Alas, it's just a hobby and doesn't pay the bills or give me health
insurance, so I can only pick away at things slowly over many
decades. ;-)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Xor of stamps too fine in high resolution screens

[Albert C. <aca...@gm...>]

>> I went with simply making the outline thicker, and I totally
>> cheated, but I think it looks fine and will hopefully be
>> helpful on devices with high dot pitch (like my phone).
>
> Before/after screenshots:
> https://twitter.com/TuxPaintTweets/status/1638427499649712128

You may remember the RAM sizes that we used to use
and the number of CPUs that we used to have when Tux Paint
was started. The OLPC XO-1 B2 prototype had 64 MB of RAM.
You might have started with 8 MB, which was enough for X.

I have upgraded well beyond that, but not enough to view Twitter
without locking up my system. I have 8 GB RAM, 4 cores, and
an SSD. Granted, I have other tabs open, but still...

So a non-Twitter screenshot would be very helpful.

>From the description, I think there is an asymmetry, which feels
really wrong. Could you go both directions evenly? Also it just
isn't very much when DPI has gone up by a factor of 6.

I can vaguely remember how the "8" came about. I wasn't going
to use strings originally, and the original stiple pattern was 4x4.
I had hex numbers. I replicated the patterns to fill something larger.
Eventually I noticed that the stiple pattern appeared in the hex,
so I just used that. Any digit would work, so I picked the 8.

I don't think the pattern should change, except getting larger.
It was well tested against the stamps. The stop sign is a notable
source of trouble for other patterns. It would tend to align with
the edges, making the dots disappear.

You can't see it now, but at low resolution the stiple pattern
actually looks really good. It's not just a grey blur.

Re: [Tuxpaint-devel] Xor of stamps too fine in high resolution screens

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

On Tue, Mar 21, 2023 at 11:26:37PM -0700, Bill Kendrick wrote:
<snip>
> I went with simply making the outline thicker, and I totally
> cheated, but I think it looks fine and will hopefully be
> helpful on devices with high dot pitch (like my phone).

Before/after screenshots:
https://twitter.com/TuxPaintTweets/status/1638427499649712128

-bill!