tuxpaint-devel — General discussion list for Tux Paint developers

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

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

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.

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

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

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

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] pencil, arrow and rotating_dash don't draw at single click, they need drag

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

Hi all,

Was updating the Catalan translation and in the tests I've found 
that some brushes need drag to draw, the ones that have "rotate"
in their .dat file

HTH
Pere

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

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

El dl. 08 de 04 de 2024 a les 21:06 -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 :)
> > 
> > Just found a minor problem:
> 
> "Minor" X-D

Well, polyfill is WIP, I don't consider bugs critical if we are not near a release :)

> 
> 
> > Start Tux Paint, select the Polygon Fill tool.
> > select another tool and draw something.
> > Return to the Polygon Fill tool, see how everything you had drawn is lost.
> > 
> > The problem is polyfill_snapshot being kept and later blit into the canvas via
> > set_color() -> draw_preview() before switchin()
> > 
> > We could clean up polyfill_snapshot at switchout() and recreate it at each swcithin() or
> > we could set some marker, mark it at switchout, clean it up at switchin() and only blit polyfill_snapshot
> > if the marker allows it, that would allow to reuse polyfill_snapshot and not destroy/recreate it
> > at each switchout()/switchin() cycle.
> 
> For now, I've set a variable to tell whether switchin() has been
> called yet.  To me, it seems strange that I'm calling a Magic tool's
> set_color() BEFORE its switchin() has been called.  But rather than
> change that (and potentially break lots of other tools), I've opened a
> ticket. :-)
> 
>   https://sourceforge.net/p/tuxpaint/bugs/286/
> 
> I also addressed an issue I already knew about, where the in-progress
> polygon preview (the lines and big red & green boxes) would remain on
> the canvas when switching to a different tool.


Oh, I thouth it was on purpose, to let children with something painted 
on the screen, in fact the Undo tool still recovers them.


> 
> I believe I solved that by simply blitting the tool's own snapshot
> back to the canvas on switchout().  (And since it makes a fresh
> snapshot after every polygon has been completed, this works.)
> 
> Adjustments like this may help some of the other Magic tools that
> "act weird" when you're in the middle of using them, but then
> switch away.
> 
> I've also thought it might be nice to provide a way for Magic
> tools to say "I can handle the 'Undo' command myself", e.g.
> for Filled Polygon tool, it would remove the most-recently
> added point.  Then, if there's no more work for them to do,
> they can tell Tux Paint that it should do it's normal Undo
> process.
> 
> Prior to that, I also thought it might be interesting to provide a
> way for Magic tools to provide an 'overlay' SDL_Surface which
> Tux Paint would draw on top everything else, rather than having
> to abuse the main `canvas` surface to draw previews, crosshairs,
> grids, etc.
> 
> Things are getting tricky. :)
> 
> -bill!


Currently magic tools that need multiple clicks to do their work 
are tricky, especially when faced to the Undo tool.

Pere


> 

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

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

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 :)
> 
> Just found a minor problem:

"Minor" X-D


> Start Tux Paint, select the Polygon Fill tool.
> select another tool and draw something.
> Return to the Polygon Fill tool, see how everything you had drawn is lost.
> 
> The problem is polyfill_snapshot being kept and later blit into the canvas via
> set_color() -> draw_preview() before switchin()
> 
> We could clean up polyfill_snapshot at switchout() and recreate it at each swcithin() or
> we could set some marker, mark it at switchout, clean it up at switchin() and only blit polyfill_snapshot
> if the marker allows it, that would allow to reuse polyfill_snapshot and not destroy/recreate it
> at each switchout()/switchin() cycle.

For now, I've set a variable to tell whether switchin() has been
called yet.  To me, it seems strange that I'm calling a Magic tool's
set_color() BEFORE its switchin() has been called.  But rather than
change that (and potentially break lots of other tools), I've opened a
ticket. :-)

  https://sourceforge.net/p/tuxpaint/bugs/286/

I also addressed an issue I already knew about, where the in-progress
polygon preview (the lines and big red & green boxes) would remain on
the canvas when switching to a different tool.

I believe I solved that by simply blitting the tool's own snapshot
back to the canvas on switchout().  (And since it makes a fresh
snapshot after every polygon has been completed, this works.)

Adjustments like this may help some of the other Magic tools that
"act weird" when you're in the middle of using them, but then
switch away.

I've also thought it might be nice to provide a way for Magic
tools to say "I can handle the 'Undo' command myself", e.g.
for Filled Polygon tool, it would remove the most-recently
added point.  Then, if there's no more work for them to do,
they can tell Tux Paint that it should do it's normal Undo
process.

Prior to that, I also thought it might be interesting to provide a
way for Magic tools to provide an 'overlay' SDL_Surface which
Tux Paint would draw on top everything else, rather than having
to abuse the main `canvas` surface to draw previews, crosshairs,
grids, etc.

Things are getting tricky. :)

-bill!

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

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

Hi all,

Tested the new polyfill stuff, it is nice :)

Just found a minor problem:
Start Tux Paint, select the Polygon Fill tool.
select another tool and draw something.
Return to the Polygon Fill tool, see how everything you had drawn is lost.

The problem is polyfill_snapshot being kept and later blit into the canvas via
set_color() -> draw_preview() before switchin()

We could clean up polyfill_snapshot at switchout() and recreate it at each swcithin() or
we could set some marker, mark it at switchout, clean it up at switchin() and only blit polyfill_snapshot
if the marker allows it, that would allow to reuse polyfill_snapshot and not destroy/recreate it
at each switchout()/switchin() cycle.

HTH
Pere

Re: [Tuxpaint-devel] 2-points selection freezes when joining the 2 points

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

On Sun, Jan 21, 2024 at 12:52:45AM +0100, Pere Pujal i Carabantes wrote:
<snip>
> I've played a little with it and really enjoyed it :)
> The right point escaping the left one is amazing :)
> Is this the first easter egg in Tux Paint?

Hahah.  No, it's just a suboptimal and lazy solution to
the problem.  But I suppose it is kind of fun.  Just waiting
for a user to report it as a bug, 5 or 10 years from now. ;)

-bill!

Re: [Tuxpaint-devel] 2-points selection freezes when joining the 2 points

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

El ds. 20 de 01 de 2024 a les 15:07 -0800, en/na Bill Kendrick va escriure:
> On Sat, Jan 20, 2024 at 09:29:35PM +0100, Pere Pujal i Carabantes wrote:
> > Just found this: magic 2-point selection, if you let one of the points in place 
> > and drag the other next/over to it, Tux Paint freezes.
> 
> Mended, thanks!  I glanced over the rest of the code for
> slope calculations to see if any other spot might crash
> due to a divide-by-zero, and didn't see any.
> (Usually there's a safety check, or it's impossible for
> the points to be in the same X position; this was done
> for 2-Pt Persp's vanishing points, but only on _release_,
> not drag!)

I've played a little with it and really enjoyed it :)
The right point escaping the left one is amazing :)
Is this the first easter egg in Tux Paint?

Best
Pere

Re: [Tuxpaint-devel] magic di/tri metric some strings may be changed from click to click and drag?

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

Ooops, forgot to call _drag() from _click() for these tools.
I think that got it.

-bill!

On Sat, Jan 20, 2024 at 11:18:24PM +0100, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> Dimetric selection:
> Click in your drawing to adjust the angle used by the dimetric projection
> Just clicking works sometimes, click and drag works always.
> 
> Same for Oblique selection.
> 
> Trimetric selection:
> Click in your drawing to adjust the angles used by the trimetric projection painting tool.
> Only click works very few times, click-pointing the lines and drag them works always.
> 
> HTH
> Pere
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] 2-points selection freezes when joining the 2 points

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

On Sat, Jan 20, 2024 at 09:29:35PM +0100, Pere Pujal i Carabantes wrote:
> Just found this: magic 2-point selection, if you let one of the points in place 
> and drag the other next/over to it, Tux Paint freezes.

Mended, thanks!  I glanced over the rest of the code for
slope calculations to see if any other spot might crash
due to a divide-by-zero, and didn't see any.
(Usually there's a safety check, or it's impossible for
the points to be in the same X position; this was done
for 2-Pt Persp's vanishing points, but only on _release_,
not drag!)


> I've not been able to reproduce with 3-points selection.

Thanks!

-bill!

[Tuxpaint-devel] magic di/tri metric some strings may be changed from click to click and drag?

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

Hi all,

Dimetric selection:
Click in your drawing to adjust the angle used by the dimetric projection
Just clicking works sometimes, click and drag works always.

Same for Oblique selection.

Trimetric selection:
Click in your drawing to adjust the angles used by the trimetric projection painting tool.
Only click works very few times, click-pointing the lines and drag them works always.

HTH
Pere

[Tuxpaint-devel] 2-points selection freezes when joining the 2 points

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

Just found this: magic 2-point selection, if you let one of the points in place 
and drag the other next/over to it, Tux Paint freezes.

I've not been able to reproduce with 3-points selection.

HTH
Pere

[Tuxpaint-devel] Magic tools now report an "order" integer

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

Magic tools are now queried for an 'order' value (an integer),
which is used as the sorting method for organizing the various
tools within each group.

I've just assigned some values to every single Magic tool
in every plugin (.c) file.  Whew!

This allows us to place related Magic tools next to each
other, rather than having them organized somewhat arbitrarily
by their name (which of course differs for each language!)

I've been thinking about doing this, especially after adding
numerous related tools which make sense to list in a certain
order (Isometric, Dimetric, Trimetric, Oblique), rather
than alphabetically (in English, they appeared in the order:
Dimetric, Isometric, Oblique, Trimetric).  Thanks to Shin-ichi
for mentioning this, which was the nudge I needed to actually
get it done. ;)

Note that the numbers are relative to other tools within the
same group, and remember that a particular plugin source file
may place tools in different groups than each other.
(For exmaple, "swirls.c" has both the "Circles" and "Rays"
distortion effects, and the "Fur" painting tool.)

I thought about creating a 'global' header file for
the entire set of Magic tools that ship with Tux Paint,
but since it was already an overwhelming task to modify
62 source files, AND think about how to organize the
approx. ten dozen tools, I figured this was good enough
for now.  Time for bed. :-)

Please try it out and let me know if you notice any
issues, or have suggestions on how to improve the
ordering of things.

(This WILL have a "who moved my cheese!?" effect on users,
but frankly so does adding new Magic tools, which get
inserted in the groups... and so did adding groups to
begin with!)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] New perspective drawing tools & complexity setting

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

On Tue, 2 Jan 2024 22:44:52 -0800, Bill Kendrick wrote:
>I _believe_ I've corrected it. Please `git pull` and rebuild, and
>tell me if you can still replicate it :)

Confirmed it is fixed.

>> In addition, I observed crash on windows when switching magic tool categories.
>> Unfortunately I have not found the step to reproduce it so far.
>
>Hrm, I cannot replicate in Linux.  I tried all three of the new
>complexity levels.
>
>Oh, question -- did you rebuild all of the Magic tools from scratch?
>(Hrm, I suppose you must have, for them to load at all, since they
>need to match the Magic API version.)  Hmm... please tell me what
>you discover.

At first, Tuxpaint crashed every time when "ARTISTIC" group was selected.
After that I once removed tuxpaint.cfg (I should have keep it's copy....) seeing
above strange value for complexity. Then, I've lost the way to reproduce the crash.

Sorry for the vague information.

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

Re: [Tuxpaint-devel] New perspective drawing tools & complexity setting

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

On Tue, Jan 02, 2024 at 12:59:28PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I noticed that complexity is incorrectly set to "qwerty.layout" in personal config file.
> 
> This happens with following steps.
> 
>  1) start tuxpaint-config
>  2) set complexity to "(no override).
>  3) apply and quit.
>  4) start tuxpaint-config
>  5) change any setting other than complexity.
>  6) apply and quit

Hrm I was able to replicate it by leaving the setting
blank (which should NOT have been an option -- I forgot to
add the new widget to the appropriate routine in `defaults.cxx`),
then change something else so I could click "Apply" to save.

I _believe_ I've corrected it. Please `git pull` and rebuild, and
tell me if you can still replicate it :)


> In addition, I observed crash on windows when switching magic tool categories.
> Unfortunately I have not found the step to reproduce it so far.

Hrm, I cannot replicate in Linux.  I tried all three of the new
complexity levels.

Oh, question -- did you rebuild all of the Magic tools from scratch?
(Hrm, I suppose you must have, for them to load at all, since they
need to match the Magic API version.)  Hmm... please tell me what
you discover.

Luc, Mark, and Pere, when you have time can you also test the new
features on Haiku, macOS, and Android?

Thanks in advance!

-bill!

Re: [Tuxpaint-devel] New perspective drawing tools & complexity setting

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

Hi!

I noticed that complexity is incorrectly set to "qwerty.layout" in personal config file.

This happens with following steps.

 1) start tuxpaint-config
 2) set complexity to "(no override).
 3) apply and quit.
 4) start tuxpaint-config
 5) change any setting other than complexity.
 6) apply and quit

In addition, I observed crash on windows when switching magic tool categories.
Unfortunately I have not found the step to reproduce it so far.


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


On Sat, 30 Dec 2023 14:24:46 -0800, Bill Kendrick wrote:
>
>Hi all, and happy new year!
>
>Just a heads-up that some development for the next version of
>Tux Paint has been done, and I've added a set of new drawing
>tools for drawing in 1-Point, 2-Point, and 3-Point perspective,
>as well as adjusting/positioning vanishing points.
>
>Further to that, I've added a new "complexity" setting, that
>allows a user to specify their expertise level with Tux Paint
>(or art software, or computers in general), which allows some
>Magic tools to behave differently.
>
>For example, the perspective drawing tools mentioned above will
>normally (in the default "advanced" complexity mode) appear as
>six different magic tools: three for drawing, and three for
>adjusting their respective vanishing point(s).
>
>However, in "beginner" mode, only drawing tools will be made
>available; you're stuck with the default vanishing points.
>In fact, a fourth drawing tool, an alterlative version of the
>3-point perspective, will be made available in this case.
>(One for drawings "looking up from below", and the alternative
>for "looking down from above".)
>
>Lots of strings have been added (or in some cases changed) based
>on this work, and a bunch of other things I've done recently *,
>so if you've got the time & interest, please grab the latest
>PO files and send me (or commit back, if you have Git access)
>updates.
>
>Thanks as always, and take care!  Wishing you all the best for 2024,
>
>-bill!
>
>* All over the place: `tuxpaint`, `tuxpaint-docs`, `tuxpaint-website`,
>  `tuxpaint-config` repos.  See https://tuxpaint.org/help/po as always.
>
>
>_______________________________________________
>Tuxpaint-i18n mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-i18n


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

[Tuxpaint-devel] Complexity setting (was re: 1-, 2-, and 3-point perspective line drawing Magic tools)

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

Hi again and happy new year!

I've updated Tux Paint to offer a new "complexity" (aka "expertise level")
setting, which allows Magic tool plugins to respond differently based
on the user's setting: novice, beginner, or advanced (the default).

Tools can behave differently, or disappear completely, based on this.

The simplest example of this is an update I made to the "Clone"
(sheep) tool.  In 'novice' mode, it's not available at all.  I decided
that the method of using it, and what exactly it's doing to your
picture, are a little confusing -- compared to, for example, painting
a rainbow or smuding your picture, which are straightforward, and
their effects are obvious.

The motivation for this feature was my new 1-, 2-, and 3-point
perspective tools; see my previous post, a snippet of which is here:

On Mon, Dec 25, 2023 at 12:09:51PM -0800, Bill Kendrick wrote:
> 
> Happy holidays!  ICYMI, I've recently added three pairs of new
> Magic tools that allow you to draw diagrams using 1-, 2-, and
> 3-point perspective, and to adjust the vanishing point(s) for
> those three drawing tools.
<snip>

These three tools actually appear as pairs of tools: one to draw
(e.g., "2-Point Draw"), and one to adjust the vanishing point(s)
(e.g., "2-Point Select").

Similar to the "Clone" tool, I decided the vanishing point drawing
tools, as whole, are probably too complex for some users, so they
will not be available in "novice" mode.

In "advanced" mode, they appear as they were originally designed.
Six tools appear, three to draw, and three to adjust their
respective vanishing point(s).

In "beginner" mode, ONLY the drawing tools will appear.  The vanishing
points are fixed, and cannot be edited.

Beyond that, though, a fourth drawing tool is made available: another
3-point perspective, but with an alternative set of hard-coded
vanishing points.  The default vanishing points were set up for drawing
from the perspective of looking up from the below; the additional tool
has alternative vanishing points, for looking down from above.

(Think: looking up at the Eiffel Tower, versus looking down from on top
of it.)

The command-line and configuration option is called "complexity", and
accepts the argument "advanced" (default; useful to override if a
system-level config. has set something lower), "beginner", and "novice".

I currently cannot think of a reason to add further granularity.
I also haven't yet put much thought into other tools that may benefit
from offering different behavior in "beginner" or "novice" modes,
but I'm open to suggestions!

The man page, bash tab completion, OPTIONS docs, Tux Paint Config.
(and its own docs), and the various Magic tool doc pages for the
affected tools have all been updated to reflect these changes.

Thanks as always for everyone's help with the project, and here's
to a healthy and prosperous 2024!

-bill!

[Tuxpaint-devel] 1-, 2-, and 3-point perspective line drawing Magic tools

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

Happy holidays!  ICYMI, I've recently added three pairs of new
Magic tools that allow you to draw diagrams using 1-, 2-, and
3-point perspective, and to adjust the vanishing point(s) for
those three drawing tools.

They're a _little_ finnicky, but seem to work okay for now.
I'd be happy letting them loose into the world as-is, and
get feedback from "actual artists" (i.e., "not me") as to their
effectiveness.

In the meantime, you can see a demo of them here (note: I was
using a mouse, and my left button seemed to be dirty & acting up;
perfect timing :eyeroll:)

  https://www.youtube.com/watch?v=r3GyrmWDxcQ

This was inspired by some videos I saw of Krita, which has some
"guide" features which allow for the same kind of perspective
drawing technique.  My hope is that this can be used to help
educate kids learning art.  (A lot of things I've added to
Tux Paint are just "fun", or "in the style of {some artist or
art style}"... but things like this, and the Color Mixer tool,
are meant to be slightly more educational... hopefully ;-) )

Enjoy, and let me know what you think.  Code improvements
welcome.  As usual, I've often done this late at night
(in bed, even!), and I never took a Trigonometry class
(and I had, it would've been 30 years ago :-D ... my day job
does not involve this kind of math, hehehe)

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Anyone experienced with MSI (Microsoft Software Installer)?

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

Does anyone here on the team have experience making MSI
installers?  Thanks in advance,

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] "Having Problems?" page

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

We occassionally hear from users who have trouble starting Tux Paint,
or have other issues which might be solved by resetting their
configuration, removing corrupted or crash-causing drawings or other
files, and which we'd benefit from seeing their config & drawings, and
also log files (stdout/stderr output).

Shin-ichi had a very good set of questions he sent a user recently,
so I decided to formalize it so we can simply share a web page with
users, rather than having to copy/paste instructions, or rewrite them
each time. :)

Mark Kim provided some similar information for macOS.  Luc, if you
want to provide some info for Haiku, I can add it to the page too!

  https://tuxpaint.org/docs/having_problems/

If anyone has questions, suggestions, or other feedback, please let
me know and I can try and integrate it.  Thanks,

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] iOS port withdrawn

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

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

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

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

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

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

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

-- 
-bill!
Sent from my computer

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

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

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

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

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

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

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

  https://tuxpaint.org/interviews/


-- 
-bill!
Sent from my computer

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

-- 
-bill!
Sent from my computer

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

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

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

Oh wow!  Yikes, thanks for your efforts!

-- 
-bill!
Sent from my computer

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

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

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

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


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

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

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

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

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

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

Thanks!

-bill!