tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Stamps rotation

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

Hi Bill, thanks for the comments,

El dv. 02 de 09 de 2022 a les 01:53 -0700, en/na Bill Kendrick va escriure:
> Wow, this was a pleasant surprise!  I checked it out
> briefly; my main issue has to do with speed, but
> I'm not sure the best way to deal with it.
> 
> (In other words, the response of the XOR outline
> preview can 'lag' a bit with very large stamps.)

Indeed, I've tried caching the 360 degrees XORs and things 
speed up a lot after the cache has been created, but the first
moments before the cache is created XOR still lags.
We could also restrict the rotation steps to 5 or 10 degrees each, 
so things go smoother, and combine restrictions with cache.

At the moment I don't have any code ready to show.

Another idea is to discard XORs/events so there is no need to draw 
XORs for old positions when the mouse has moved meters.
Do the SDL events have a timestamp so we can check against it?


I've tried also to rotate the stamp before the scaling up step 
in update_stamp_xor() but I did not measure any notizable improvement

> 
> There's also a problem of the rotation being very
> easily tilted sideways quickly.  Since the mouse
> remains at the center of the stamp, you need to
> carefully move to the right (zero degrees angle)
> before moving the mouse around much.
> 
> With the stamps, since the mouse currently remains
> at the center of the shape, if you move slightly...
> 
>  * up -- the shape tilts counter clockwise 90 degrees
>  * down -- the shape titles clockwise 90 degrees
>  * left -- the shape rotates 180 degrees
> 
> I think the mouse should be warped to the far right
> side of the vertical-center of the stamp, like the
> "Shapes" tool does.  (It will warp to the left of
> a shape if you 'drag' the shape out to the left.
> That's not an interaction we do with stamps, though.)
> 
> 
> Also, I just noticed (how long has this happend! 8^o)
> that the "flip" control button is not showing any icon.
> (The "mirror" one shows me the "sphere + mirror" icon,
> as expected.)
> 
> I'll see if I can address both of these.
> 
> 
> Thanks so much for this Pere!  I bet we have a ticket
> in SourceForge that we can close, once we're happy
> with the feature.  If we can get it working well,

Just from 2006 ;) https://sourceforge.net/p/tuxpaint/feature-requests/62/

> I'd be fine with making it a default setting, with an
> option to deactivate it.

I did not make it default because it changes the current 
workflow and possibly people do not expect the workflow to change.
Anyway I am fine with both, default and not default.

> 
> FYI, we'll need to remember to document it everywhere.
> 
>  * The feature itself
>    + README docs
>    + Features page of website
> 
>  * Option to disable
>    + OPTIONS docs
>    + manpage
>    + bash shell tab completion file

I saw you did it, thanks :)

Pere

> 
> -bill!
> 
> 
> On Fri, Sep 02, 2022 at 02:24:24AM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > I've just commited some work to add rotation to stamps,
> > It is not enabled by default, you must add --stamp-rotation to 
> > the command line to activate it.
> > 
> > The rotation is just a call to rotozoom, instead the hard work 
> > has been to deal with the xor interface, and it is still not 
> > finished, the key combos like CTRL Z and others are messing 
> > with the xor interface, but the use with a mouse should be correct.
> > 
> > Please test,
> > 
> > Thanks
> > Pere
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

[Tuxpaint-devel] Prompt drop-shadows in SDL2

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

I'm noticing in the SDL 2 branch, especially with the color palette
pop-ups (which have no border, like the generic dialog does;
e.g. "Quit: are you sure?"), that the drop-shadows are not appearing.

The code is running, but the way we're doing it in SDL2 doesn't
work.

SDL1.2:
  SDL_SetAlpha(alpha_surf, SDL_SRCALPHA, 64);

SDL2:
  SDL_SetSurfaceAlphaMod(alpha_surf, 64);

Any clues, Pere (or others who are more familiar with SDL2's quirks)?
Thanks in advance!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Stamps rotation

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

On Fri, Sep 02, 2022 at 01:53:24AM -0700, Bill Kendrick wrote:
<snip> 
> There's also a problem of the rotation being very
> easily tilted sideways quickly.

I added a mouse warp, which helps!


<snip>
> Also, I just noticed (how long has this happend! 8^o)
> that the "flip" control button is not showing any icon.

The image is very simple, graphically, so when I did
some image compression (`pngout`) recently, I guess it
dropped to "indexed" mode, and it seems that the SDL
alpha blending trickery I use to plop icons onto buttons
was failing in that situation.

I'm finding others in the same situation.  I'll work to
mend those, too.


kendrick@gambit:~/tuxpaint/tuxpaint$ find . -name "*.png" -exec file {} \; | grep "1-bit colormap"
./starters/grid_20x20.png: PNG image data, 601 x 305, 1-bit colormap, non-interlaced
./starters/chicken.png: PNG image data, 448 x 376, 1-bit colormap, non-interlaced
./starters/jigsaw_5x5.png: PNG image data, 800 x 614, 1-bit colormap, non-interlaced
./starters/grid_10x10.png: PNG image data, 602 x 306, 1-bit colormap, non-interlaced
./starters/jetplane.png: PNG image data, 448 x 376, 1-bit colormap, non-interlaced
./starters/jigsaw_3x3.png: PNG image data, 800 x 614, 1-bit colormap, non-interlaced
./flip.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/realrainbow-roygbiv.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/flip.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/silhouette.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/fisheye.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/mosaic.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/tv.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/picasso.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./magic/icons/stretch.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./data/brushes/tiny.png: PNG image data, 1 x 1, 1-bit colormap, non-interlaced
./data/brushes/square_seethru.png: PNG image data, 20 x 20, 1-bit colormap, non-interlaced
./data/brushes/rotating_dash.png: PNG image data, 5 x 10, 1-bit colormap, non-interlaced
./data/brushes/aa_round_03.png: PNG image data, 3 x 3, 1-bit colormap, non-interlaced
./data/brushes/square_24.png: PNG image data, 24 x 24, 1-bit colormap, non-interlaced
./data/brushes/square_36.png: PNG image data, 36 x 36, 1-bit colormap, non-interlaced
./data/brushes/square_12.png: PNG image data, 12 x 12, 1-bit colormap, non-interlaced
./data/brushes/square_06.png: PNG image data, 6 x 6, 1-bit colormap, non-interlaced
./data/images/shapes/square.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./data/images/shapes/rectangle.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./data/images/shapes/rectangle_f.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced
./data/images/shapes/square_f.png: PNG image data, 40 x 30, 1-bit colormap, non-interlaced



-bill!

Re: [Tuxpaint-devel] Stamps rotation

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

Wow, this was a pleasant surprise!  I checked it out
briefly; my main issue has to do with speed, but
I'm not sure the best way to deal with it.

(In other words, the response of the XOR outline
preview can 'lag' a bit with very large stamps.)

There's also a problem of the rotation being very
easily tilted sideways quickly.  Since the mouse
remains at the center of the stamp, you need to
carefully move to the right (zero degrees angle)
before moving the mouse around much.

With the stamps, since the mouse currently remains
at the center of the shape, if you move slightly...

 * up -- the shape tilts counter clockwise 90 degrees
 * down -- the shape titles clockwise 90 degrees
 * left -- the shape rotates 180 degrees

I think the mouse should be warped to the far right
side of the vertical-center of the stamp, like the
"Shapes" tool does.  (It will warp to the left of
a shape if you 'drag' the shape out to the left.
That's not an interaction we do with stamps, though.)


Also, I just noticed (how long has this happend! 8^o)
that the "flip" control button is not showing any icon.
(The "mirror" one shows me the "sphere + mirror" icon,
as expected.)

I'll see if I can address both of these.


Thanks so much for this Pere!  I bet we have a ticket
in SourceForge that we can close, once we're happy
with the feature.  If we can get it working well,
I'd be fine with making it a default setting, with an
option to deactivate it.

FYI, we'll need to remember to document it everywhere.

 * The feature itself
   + README docs
   + Features page of website

 * Option to disable
   + OPTIONS docs
   + manpage
   + bash shell tab completion file

-bill!


On Fri, Sep 02, 2022 at 02:24:24AM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> I've just commited some work to add rotation to stamps,
> It is not enabled by default, you must add --stamp-rotation to 
> the command line to activate it.
> 
> The rotation is just a call to rotozoom, instead the hard work 
> has been to deal with the xor interface, and it is still not 
> finished, the key combos like CTRL Z and others are messing 
> with the xor interface, but the use with a mouse should be correct.
> 
> Please test,
> 
> Thanks
> Pere
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Stamps rotation

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

Hi all,

I've just commited some work to add rotation to stamps,
It is not enabled by default, you must add --stamp-rotation to 
the command line to activate it.

The rotation is just a call to rotozoom, instead the hard work 
has been to deal with the xor interface, and it is still not 
finished, the key combos like CTRL Z and others are messing 
with the xor interface, but the use with a mouse should be correct.

Please test,

Thanks
Pere

Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

Pere Pujal i Carabantes skreiv 07.07.2022 00:06:
> Are those brushes?
>
> rgrep rotate data/brushes/
> data/brushes/arrow.dat:rotate
> data/brushes/rotating_dash.dat:rotate

Yes.


> I remember having to use plain SDL_BlitSurface in the sdl2.0 branch when
> rotational brushes were added,
> was the 6891266eeebd0aa1268dd6ef4c699e3d80e10958 commit
> It was for other reasons, no SDL(2)_gfxBlitRGBA() available for the SDL2 lib,
> but as you say the sdl2.0 performs right here, the only difference between
> master and sdl2.0 in this area coming to my mind is this one
>
> maybe you could try if it is worth too to use SDL_BlitSurface() insteadSDL_gfxBlitRGBA()
> in the master branch.

I tried cherry-picking the commit, but it didn’t have an effect. But 
that’s not so strange, as it turns out that this code path is not used 
for these two brushes, only for multi-frame brushes. In other words, 
it’s used for the (working!) arrow_triangles.png brush.

I have also tried changing the colour space (RGB vs. greyscale vs. 
indexed) in the PNG images, as different PNG images have different 
colour spaces, but that didn’t have an effect.

I have narrowed the problem down to this line:

     rotated_brush = rotozoomSurface(img_cur_brush, rotation, 1.0, 
SMOOTHING_ON);

If I instead write

     rotated_brush = img_cur_brush;

then the two brushes are drawn even if I use the black colour – and then 
Tux Paint immediately crashes … So there’s something in 
rotozoomSurface() which doesn’t work properly when the brush colour is 
black?


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

Hi,

El dc. 06 de 07 de 2022 a les 20:36 +0200, en/na Karl Ove Hufthammer va escriure:
> 
> BTW, it would be interesting to know what the root cause of the bug is. 
> Is it a bug in sdl12-compat, SDL2 (since this is what sdl12-compat uses 
> behind the scenes) or Tux Paint? If it’s a bug in sdl12-compat or SDL2, 
> it is likely that other parts of the code could trigger it. It’s such a 
> strange bug, in that only two brushes trigger it, and only if the 
> selected colour is pure black.
> 
> 

Are those brushes?

rgrep rotate data/brushes/
data/brushes/arrow.dat:rotate
data/brushes/rotating_dash.dat:rotate

I remember having to use plain SDL_BlitSurface in the sdl2.0 branch when 
rotational brushes were added, 
was the 6891266eeebd0aa1268dd6ef4c699e3d80e10958 commit
It was for other reasons, no SDL(2)_gfxBlitRGBA() available for the SDL2 lib,
but as you say the sdl2.0 performs right here, the only difference between 
master and sdl2.0 in this area coming to my mind is this one

maybe you could try if it is worth too to use SDL_BlitSurface() insteadSDL_gfxBlitRGBA() 
in the master branch.

HTH
Pere

Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

Bill Kendrick skreiv 06.07.2022 06:17:
> WELL! :^D I wondered how mine could have been_so_  many revisions
> (35!?) out-of-date, considering my distro is only 2 years out-of-date,
> and SDL2 has been around forever.:-D
>
> I supposed, based on this, that we could simply call this a
> known-issue, but I don't really think it's worth trying to address it.
> In other words: recommend people_not_  use the SDL1.2 version of Tux
> Paint with an SDL12-compat, and instead just use the SDL2.0 versions
> of Tux Paint directly.

I guess most users use Tux Paint packaged by their distro. And if the 
last official version SDL 1.2 was released 10 years ago, there are bound 
to be (security) issues. So distros would be wise to replace it with 
sdl12-compat. In other words, if they haven’t already replaced SDL 1.2 
with sdl12-compat, they probably will do so. So more and more people 
will encounter the bugs.

What’s the status of the SDL2 branch? Can it be made the default? (I 
have done some testing, and it seems to work fine. The only difference I 
can see, is that a different font is used in the UI.)

BTW, it would be interesting to know what the root cause of the bug is. 
Is it a bug in sdl12-compat, SDL2 (since this is what sdl12-compat uses 
behind the scenes) or Tux Paint? If it’s a bug in sdl12-compat or SDL2, 
it is likely that other parts of the code could trigger it. It’s such a 
strange bug, in that only two brushes trigger it, and only if the 
selected colour is pure black.


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

On Mon, Jul 04, 2022 at 10:25:37PM +0200, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 04.07.2022 22:19:
> >Karl posted these two bugs over on SourceForge:
> >
> >  * Two directional brushes don't work when using black colour
> >    https://sourceforge.net/p/tuxpaint/bugs/253/
> >
> >  * Tux Paint window don��t refresh when alt-tabbed into
> >    https://sourceforge.net/p/tuxpaint/bugs/254/
> >
> >I am unable to reproduce either bug on my Ubuntu 20.04.4 LTS
> >system running Tux Paint 'master' branch with SDL 1.2.15, or
> >'sdl2.0' branch with SDL 2.0.10, under X-Window X.Org 1.20.13.
> >
> >Karl reports that the Alt+Tab issue happens with X11 and SDL 1.2.50,
> >but not under Wayland, nor under SDL 2.0.
> 
> Turns out that the latest version of SDL 1.2 is version 1.2.15,
> released in 2012 (!), and that what I’m actually using is
> https://github.com/libsdl-org/sdl12-compat. This is a compatibility
> layer, which *pretends* to be SDL 1.2.x (in this case 1.2.50), but
> which uses SDL 2.0 under the hood.
> 
> The original SDL 1.2 is not packaged in my distro (openSUSE Tumbleweed).

WELL! :^D I wondered how mine could have been _so_ many revisions
(35!?) out-of-date, considering my distro is only 2 years out-of-date,
and SDL2 has been around forever. :-D

I supposed, based on this, that we could simply call this a
known-issue, but I don't really think it's worth trying to address it.
In other words: recommend people _not_ use the SDL1.2 version of Tux
Paint with an SDL12-compat, and instead just use the SDL2.0 versions
of Tux Paint directly.

Any objections?  If not, I can close those two tickets, and put
a not somewhere on the website (to at least keep track of it,
I'm thinking https://tuxpaint.org/requirements/ ... rather than
the actual "known issues" page, https://tuxpaint.org/docs/known_issues/,
because we'd need to keep it around 'forever', and I'd rather not
clutter it up too much...)

Thanks!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

Bill Kendrick skreiv 04.07.2022 22:19:
> Karl posted these two bugs over on SourceForge:
>
>   * Two directional brushes don't work when using black colour
>     https://sourceforge.net/p/tuxpaint/bugs/253/
>
>   * Tux Paint window don��t refresh when alt-tabbed into
>     https://sourceforge.net/p/tuxpaint/bugs/254/
>
> I am unable to reproduce either bug on my Ubuntu 20.04.4 LTS
> system running Tux Paint 'master' branch with SDL 1.2.15, or
> 'sdl2.0' branch with SDL 2.0.10, under X-Window X.Org 1.20.13.
>
> Karl reports that the Alt+Tab issue happens with X11 and SDL 1.2.50,
> but not under Wayland, nor under SDL 2.0.

Turns out that the latest version of SDL 1.2 is version 1.2.15, released 
in 2012 (!), and that what I’m actually using is 
https://github.com/libsdl-org/sdl12-compat. This is a compatibility 
layer, which *pretends* to be SDL 1.2.x (in this case 1.2.50), but which 
uses SDL 2.0 under the hood.

The original SDL 1.2 is not packaged in my distro (openSUSE Tumbleweed).


-- 
Karl Ove Hufthammer

[Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

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

Karl posted these two bugs over on SourceForge:

 * Two directional brushes don't work when using black colour
   https://sourceforge.net/p/tuxpaint/bugs/253/

 * Tux Paint window don��t refresh when alt-tabbed into
   https://sourceforge.net/p/tuxpaint/bugs/254/

I am unable to reproduce either bug on my Ubuntu 20.04.4 LTS
system running Tux Paint 'master' branch with SDL 1.2.15, or
'sdl2.0' branch with SDL 2.0.10, under X-Window X.Org 1.20.13.

Karl reports that the Alt+Tab issue happens with X11 and SDL 1.2.50,
but not under Wayland, nor under SDL 2.0.


The SDL 2.0 version of Tux Paint does not exhibit the brush-drawing
issue Karl reported.

The brushes in question are rotating ones, so I thought perhaps it
was an issue of the brush not wanting to draw anything on a simple
click+release, at least under larger brush spacing, as the brushes
want to know what direction to "face", based on mouse motion.
However, Karl confirms the issue happens all the time, and even
with the Lines tool (not just the Paint [brush] tool).

Since they are rotating, they use some SDL and SDL_gfx routines
to manage rotation (rotozoom).


Based on my inability to reproduce under either SDL 1.2.15 or
SDL 2.0.10 under X11, and Karl only reproducing the issues under
SDL 1.2.50 (and one of the confirmed to happen only under X),
my _hunch_ is there may be some bug in some versions of SDL 1.2,
and/or Tux Paint is doing something naively that causes the
problems to occur (especially with regards to the brush issue).

Can others here please let us know if you come across either
issue, and report back what version(s) of Tux Paint & SDL you're
using.  You can run "tuxpaint --verbose-version" for that.

And let us know whether you're seeing the issues on X-Window and/or
Wayland, and what version(s) of those you're using.

(I've admittedly not used Wayland yet; for X-Window, I run
"xdpyinfo | grep version" to get its version info.)

Thanks in advance!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Appstream metainfo file added, removed intltool dependency

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

Thank you – I've opened
https://sourceforge.net/p/tuxpaint/tuxpaint/merge-requests/13/ to rename
this file.

– Will


On Wed, 29 Jun 2022 at 00:30, Shin-ichi TOYAMA <dol...@wm...>
wrote:

> Thanks Will,
>
> I confirmed
>
>  * copying .metainfo.xml to .appdata.xml
>  * replacing string 'metainfo' with 'appdata' in Makefile
>
> will fix it on RHEL 7 and 8.
> I will apply these to the packages for the next release if it is is
> reasonable.
>
> Thanks!
>
>
>
> On Tue, 28 Jun 2022 16:15:52 +0100, Will Thompson wrote:
> >Hi,
> >
> >What version of RHEL are you using? Which version of gettext do you have?
> I
> >believed that this change would require gettext 0.19.7, which was released
> >in Dec 2015.
> >
> >Ah, actually I have a hunch... It looks like the RHEL 7 version of gettext
> >may be 0.19.8.1. In that version, only the old name for these files,
> ending
> >appdata.xml, is supported, not the newer name, metainfo.xml. So I think at
> >present the effective minimum gettext version is 0.20. If you can confirm
> >my hunch with the questions above, and the project desires to support this
> >platform & gettext version, then I can take a look at reducing the minimum
> >version required.
> >
> >– Will
> >
> >
> >On Tue, 28 Jun 2022 at 15:27, Shin-ichi TOYAMA <
> dol...@wm...>
> >wrote:
> >
> >> Hi!
> >>
> >> I noticed that 'make' currently stops on RHELs showing error as follows.
> >>
> >> msgfmt --xml -d src/po --template src/
> >> org.tuxpaint.Tuxpaint.metainfo.xml.in -o
> >> src/org.tuxpaint.Tuxpaint.metainfo.xml
> >> msgfmt: cannot locate ITS rules for src/
> >> org.tuxpaint.Tuxpaint.metainfo.xml.in
> >> make: *** [Makefile:539: src/org.tuxpaint.Tuxpaint.metainfo.xml] Error 1
> >>
> >> How shoud I do for thie?
> >>
> >>
> >>
> >> On Tue, 14 Jun 2022 01:30:21 -0700, Bill Kendrick wrote:
> >> >
> >> >This evening I merged a number of commits from Will Thompson,
> >> >who has been maintaining the Flathub (Flatpak) version of
> >> >Tux Paint.
> >> >
> >> >  https://sourceforge.net/p/tuxpaint/tuxpaint/merge-requests/12/
> >> >
> >> >Some of these concern localization, and POT/PO files were
> >> >regenerated this evenign as well:
> >> >
> >> > * Add appstream metainfo file
> >> >
> >> >   This is used by software centres such as GNOME Software to display
> >> >   information about the app, both before and after it is installed.
> >> >
> >> >   ...
> >> >
> >> >   Many fields in this file are translatable.
> >> >
> >> >   ...
> >> >
> >> >   The release notes are taken from the press releases on the Tuxpaint
> >> >   website. They will be extracted for translation.
> >> >
> >> >
> >> > * Remove intltool dependency
> >> >
> >> >   Since gettext 0.19, gettext itself has been able to extract strings
> >> >   from and merge translations to .desktop files. As a result, there is
> >> >   no need to use intltool. More details are available on
> >> >   https://wiki.gnome.org/MigratingFromIntltoolToGettext, though that
> >> >   page assumes a project using Autotools, which this project does not.
> >> >
> >> >   One advantage of using xgettext rather than intltool is that there
> is
> >> no
> >> >   need to prefix translatable keys in the .desktop.in file with _.
> This
> >> >   patch adjusts tuxpaint.desktop.in accordingly, which makes the
> input
> >> >   file itself a valid desktop file.
> >> >
> >> >   ...
> >> >
> >> >   POTFILES.in.in must be updated to remove the intltool-specific file
> >> >   encoding annotation; instead this is passed to xgettext.
> >> >
> >> >   Finally, update-po.sh is rewritten to invoke xgettext and msgfmt
> rather
> >> >   than intltool commands.
> >> >
> >> >   The mangling of POTFILES.in.in to prefix all filenames with '../'
> is
> >> >   only necessary to minimize the churn when updating the .pot and .po
> >> >   files, to simplify review of this change. The alternative is to pass
> >> >   --directory=.. to xgettext. This would cause all .po files to be
> >> updated
> >> >   as follows when regenerated:
> >> >
> >> >     #. Response to Black (0, 0, 0) color selected
> >> >     -#: ../colors.h:86
> >> >     +#: colors.h:86
> >> >     msgid "Black!"
> >> >     msgstr "Noir !"
> >> >
> >> >I'm a bit exhausted at this point, but I _think_ this all looks good,
> >> >and wanted to give a heads-up to translators.
> >> >
> >> >Gnite! :)
> >> >
> >>
> >>
> >> --
> >> Shin-ichi TOYAMA <dol...@wm...>
> >>
> >>
> >> _______________________________________________
> >> Tuxpaint-devel mailing list
> >> Tux...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >>
>
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>

Re: [Tuxpaint-devel] Appstream metainfo file added, removed intltool dependency

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

Thanks Will,

I confirmed

 * copying .metainfo.xml to .appdata.xml
 * replacing string 'metainfo' with 'appdata' in Makefile

will fix it on RHEL 7 and 8.
I will apply these to the packages for the next release if it is is reasonable.

Thanks!



On Tue, 28 Jun 2022 16:15:52 +0100, Will Thompson wrote:
>Hi,
>
>What version of RHEL are you using? Which version of gettext do you have? I
>believed that this change would require gettext 0.19.7, which was released
>in Dec 2015.
>
>Ah, actually I have a hunch... It looks like the RHEL 7 version of gettext
>may be 0.19.8.1. In that version, only the old name for these files, ending
>appdata.xml, is supported, not the newer name, metainfo.xml. So I think at
>present the effective minimum gettext version is 0.20. If you can confirm
>my hunch with the questions above, and the project desires to support this
>platform & gettext version, then I can take a look at reducing the minimum
>version required.
>
>– Will
>
>
>On Tue, 28 Jun 2022 at 15:27, Shin-ichi TOYAMA <dol...@wm...>
>wrote:
>
>> Hi!
>>
>> I noticed that 'make' currently stops on RHELs showing error as follows.
>>
>> msgfmt --xml -d src/po --template src/
>> org.tuxpaint.Tuxpaint.metainfo.xml.in -o
>> src/org.tuxpaint.Tuxpaint.metainfo.xml
>> msgfmt: cannot locate ITS rules for src/
>> org.tuxpaint.Tuxpaint.metainfo.xml.in
>> make: *** [Makefile:539: src/org.tuxpaint.Tuxpaint.metainfo.xml] Error 1
>>
>> How shoud I do for thie?
>>
>>
>>
>> On Tue, 14 Jun 2022 01:30:21 -0700, Bill Kendrick wrote:
>> >
>> >This evening I merged a number of commits from Will Thompson,
>> >who has been maintaining the Flathub (Flatpak) version of
>> >Tux Paint.
>> >
>> >  https://sourceforge.net/p/tuxpaint/tuxpaint/merge-requests/12/
>> >
>> >Some of these concern localization, and POT/PO files were
>> >regenerated this evenign as well:
>> >
>> > * Add appstream metainfo file
>> >
>> >   This is used by software centres such as GNOME Software to display
>> >   information about the app, both before and after it is installed.
>> >
>> >   ...
>> >
>> >   Many fields in this file are translatable.
>> >
>> >   ...
>> >
>> >   The release notes are taken from the press releases on the Tuxpaint
>> >   website. They will be extracted for translation.
>> >
>> >
>> > * Remove intltool dependency
>> >
>> >   Since gettext 0.19, gettext itself has been able to extract strings
>> >   from and merge translations to .desktop files. As a result, there is
>> >   no need to use intltool. More details are available on
>> >   https://wiki.gnome.org/MigratingFromIntltoolToGettext, though that
>> >   page assumes a project using Autotools, which this project does not.
>> >
>> >   One advantage of using xgettext rather than intltool is that there is
>> no
>> >   need to prefix translatable keys in the .desktop.in file with _. This
>> >   patch adjusts tuxpaint.desktop.in accordingly, which makes the input
>> >   file itself a valid desktop file.
>> >
>> >   ...
>> >
>> >   POTFILES.in.in must be updated to remove the intltool-specific file
>> >   encoding annotation; instead this is passed to xgettext.
>> >
>> >   Finally, update-po.sh is rewritten to invoke xgettext and msgfmt rather
>> >   than intltool commands.
>> >
>> >   The mangling of POTFILES.in.in to prefix all filenames with '../' is
>> >   only necessary to minimize the churn when updating the .pot and .po
>> >   files, to simplify review of this change. The alternative is to pass
>> >   --directory=.. to xgettext. This would cause all .po files to be
>> updated
>> >   as follows when regenerated:
>> >
>> >     #. Response to Black (0, 0, 0) color selected
>> >     -#: ../colors.h:86
>> >     +#: colors.h:86
>> >     msgid "Black!"
>> >     msgstr "Noir !"
>> >
>> >I'm a bit exhausted at this point, but I _think_ this all looks good,
>> >and wanted to give a heads-up to translators.
>> >
>> >Gnite! :)
>> >
>>
>>
>> --
>> Shin-ichi TOYAMA <dol...@wm...>
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>


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

Re: [Tuxpaint-devel] Appstream metainfo file added, removed intltool dependency

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

Hi,

What version of RHEL are you using? Which version of gettext do you have? I
believed that this change would require gettext 0.19.7, which was released
in Dec 2015.

Ah, actually I have a hunch... It looks like the RHEL 7 version of gettext
may be 0.19.8.1. In that version, only the old name for these files, ending
appdata.xml, is supported, not the newer name, metainfo.xml. So I think at
present the effective minimum gettext version is 0.20. If you can confirm
my hunch with the questions above, and the project desires to support this
platform & gettext version, then I can take a look at reducing the minimum
version required.

– Will


On Tue, 28 Jun 2022 at 15:27, Shin-ichi TOYAMA <dol...@wm...>
wrote:

> Hi!
>
> I noticed that 'make' currently stops on RHELs showing error as follows.
>
> msgfmt --xml -d src/po --template src/
> org.tuxpaint.Tuxpaint.metainfo.xml.in -o
> src/org.tuxpaint.Tuxpaint.metainfo.xml
> msgfmt: cannot locate ITS rules for src/
> org.tuxpaint.Tuxpaint.metainfo.xml.in
> make: *** [Makefile:539: src/org.tuxpaint.Tuxpaint.metainfo.xml] Error 1
>
> How shoud I do for thie?
>
>
>
> On Tue, 14 Jun 2022 01:30:21 -0700, Bill Kendrick wrote:
> >
> >This evening I merged a number of commits from Will Thompson,
> >who has been maintaining the Flathub (Flatpak) version of
> >Tux Paint.
> >
> >  https://sourceforge.net/p/tuxpaint/tuxpaint/merge-requests/12/
> >
> >Some of these concern localization, and POT/PO files were
> >regenerated this evenign as well:
> >
> > * Add appstream metainfo file
> >
> >   This is used by software centres such as GNOME Software to display
> >   information about the app, both before and after it is installed.
> >
> >   ...
> >
> >   Many fields in this file are translatable.
> >
> >   ...
> >
> >   The release notes are taken from the press releases on the Tuxpaint
> >   website. They will be extracted for translation.
> >
> >
> > * Remove intltool dependency
> >
> >   Since gettext 0.19, gettext itself has been able to extract strings
> >   from and merge translations to .desktop files. As a result, there is
> >   no need to use intltool. More details are available on
> >   https://wiki.gnome.org/MigratingFromIntltoolToGettext, though that
> >   page assumes a project using Autotools, which this project does not.
> >
> >   One advantage of using xgettext rather than intltool is that there is
> no
> >   need to prefix translatable keys in the .desktop.in file with _. This
> >   patch adjusts tuxpaint.desktop.in accordingly, which makes the input
> >   file itself a valid desktop file.
> >
> >   ...
> >
> >   POTFILES.in.in must be updated to remove the intltool-specific file
> >   encoding annotation; instead this is passed to xgettext.
> >
> >   Finally, update-po.sh is rewritten to invoke xgettext and msgfmt rather
> >   than intltool commands.
> >
> >   The mangling of POTFILES.in.in to prefix all filenames with '../' is
> >   only necessary to minimize the churn when updating the .pot and .po
> >   files, to simplify review of this change. The alternative is to pass
> >   --directory=.. to xgettext. This would cause all .po files to be
> updated
> >   as follows when regenerated:
> >
> >     #. Response to Black (0, 0, 0) color selected
> >     -#: ../colors.h:86
> >     +#: colors.h:86
> >     msgid "Black!"
> >     msgstr "Noir !"
> >
> >I'm a bit exhausted at this point, but I _think_ this all looks good,
> >and wanted to give a heads-up to translators.
> >
> >Gnite! :)
> >
>
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Appstream metainfo file added, removed intltool dependency

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

Hi!

I noticed that 'make' currently stops on RHELs showing error as follows.

msgfmt --xml -d src/po --template src/org.tuxpaint.Tuxpaint.metainfo.xml.in -o src/org.tuxpaint.Tuxpaint.metainfo.xml
msgfmt: cannot locate ITS rules for src/org.tuxpaint.Tuxpaint.metainfo.xml.in
make: *** [Makefile:539: src/org.tuxpaint.Tuxpaint.metainfo.xml] Error 1

How shoud I do for thie?



On Tue, 14 Jun 2022 01:30:21 -0700, Bill Kendrick wrote:
>
>This evening I merged a number of commits from Will Thompson,
>who has been maintaining the Flathub (Flatpak) version of
>Tux Paint.
>
>  https://sourceforge.net/p/tuxpaint/tuxpaint/merge-requests/12/
>
>Some of these concern localization, and POT/PO files were
>regenerated this evenign as well:
>
> * Add appstream metainfo file
>
>   This is used by software centres such as GNOME Software to display
>   information about the app, both before and after it is installed.
>
>   ...
>
>   Many fields in this file are translatable.
>
>   ...
>
>   The release notes are taken from the press releases on the Tuxpaint
>   website. They will be extracted for translation.
>
>
> * Remove intltool dependency
>
>   Since gettext 0.19, gettext itself has been able to extract strings
>   from and merge translations to .desktop files. As a result, there is
>   no need to use intltool. More details are available on
>   https://wiki.gnome.org/MigratingFromIntltoolToGettext, though that
>   page assumes a project using Autotools, which this project does not.
>
>   One advantage of using xgettext rather than intltool is that there is no
>   need to prefix translatable keys in the .desktop.in file with _. This
>   patch adjusts tuxpaint.desktop.in accordingly, which makes the input
>   file itself a valid desktop file.
>
>   ...
>
>   POTFILES.in.in must be updated to remove the intltool-specific file
>   encoding annotation; instead this is passed to xgettext.
>
>   Finally, update-po.sh is rewritten to invoke xgettext and msgfmt rather
>   than intltool commands.
>
>   The mangling of POTFILES.in.in to prefix all filenames with '../' is
>   only necessary to minimize the churn when updating the .pot and .po
>   files, to simplify review of this change. The alternative is to pass
>   --directory=.. to xgettext. This would cause all .po files to be updated
>   as follows when regenerated:
>
>     #. Response to Black (0, 0, 0) color selected
>     -#: ../colors.h:86
>     +#: colors.h:86
>     msgid "Black!"
>     msgstr "Noir !"
>
>I'm a bit exhausted at this point, but I _think_ this all looks good,
>and wanted to give a heads-up to translators.
>
>Gnite! :)
>


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

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

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

Hi,

I think your fix was much better, because it runs fine both on linux and windows without using #ifdef stuff.

Thanks!


On 2022年5月25日 9:14:54 JST, Bill Kendrick <nb...@so...> wrote:
>On Fri, May 20, 2022 at 04:29:52PM +0900, Shin-ichi TOYAMA wrote:
>> Ah!!
>> 
>> It looks like that my commit for Windows was wrong.
>> 
>> See the commit "4749214383bf7d881e85cb82fea2d751c9b292da"
>> 
>> I thiks following patch will fix it.
>
>Ah well shoot; if you think it's safe to unravel what _I_ did
>(in my attempt to fix things), would you be so kind as to do so? :)
>
>Thanks!
>
>-bill!
>
>> 
>> --- onscreen_keyboard.c.org	2022-05-20 16:21:47.219690242 +0900
>> +++ onscreen_keyboard.c	2022-05-20 16:22:49.095034241 +0900
>> @@ -1865,10 +1865,12 @@
>>              wcstombs(event.text.text, keyboard->composed, 16);
>>            //          event.text.text = *keyboard->composed;
>>            else{
>> -            //snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
>> +#ifdef WIN32
>>  	    int iwc = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
>>  	    wcstombs(event.text.text, (wchar_t *) &iwc, 16);
>> -          //event.text.text = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
>> +#else
>> +            snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
>> +#endif
>>  	  }
>>  
>>            clear_dead_sticks(keyboard);
>> 
>> 
>> I think following patch winn
>> On Thu, 19 May 2022 23:36:39 -0700, Bill Kendrick wrote:
>> >On Thu, Nov 18, 2021 at 11:57:02PM +0900, TOYAMA Shin-ichi wrote:
>> >> Hi Bill,
>> >> 
>> >> Bill Kendrick wrote in <202...@sh...>
>> >> >My plan, however, is to release the NEXT version of Tux Paint,
>> >> >which includes a lot of new features (new Magic tools, and the
>> >> >Magic tool grouping functionality) using the SDL1.2 branch.
>> >> >This will be 0.9.27.
>> >> >
>> >> >Then, more-or-less immediately, we can try releasing an SDL2.0
>> >> >version, that adds no new features to Tux Paint itself.
>> >> >This will be 0.9.28.
>> >> 
>> >> Are you still on this track?
>> >
>> >BTW, obviously I was not on this track. X^D  Sorry!
>> >(It's too tempting to add new features, I had some stress
>> >that made "adding new features to Tux Paint" a stress reliever,
>> >as weird as that probably sounds.)
>> >
>> >
>> >> I tried to build current sdl2.0 blanch on windows.
>> >> 
>> >> It looks almost fine but I found that onscreen-keyboard does not 
>> >> work correctly with compose function.
>> >
>> >Uh oh, hrm, using the sdl2.0 branch here on Kubuntu Linux,
>> >I am also getting some weird behavior.
>> >
>> >When I type [h], [e], [l], [l], [o] with the OSK, I get
>> >"hello▯" on the canvas, and in the printf()'d output
>> >from im.c, I noticed:
>> >
>> >  im->s o羻, event.text.text o羻
>> >
>> >I was _not_ using the compose button.
>> >
>> >In fact, playing with it more, as I click the buttons
>> >to spell "hello" again, I'm getting the "unknown character"
>> >rectangle a bunch of times.  Just now typing
>> >"helloooooooo", I see:
>> >
>> >  he▯ll▯ooo▯oo▯o▯oo
>> >
>> >Oh and interestingly, if I try to type any characters
>> >that would normally compose, e.g. ~, ', or ", they do not
>> >appear unless I type them a second time.
>> >
>> >So yes, something is definitely broken in the IM stuff
>> >with the OSK in the sdl2.0 branch!  Sorry I forgot about
>> >this, but I guess I'm glad I left this email in my mailbox. :-D
>> >
>> >Thanks!
>> >
>> >-bill!
>> >
>> >
>> >_______________________________________________
>> >Tuxpaint-devel mailing list
>> >Tux...@li...
>> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>> 
>> 
>> -- 
>> Shin-ichi TOYAMA <dol...@wm...>
>> 
>> 
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
>-- 
>-bill!
>Sent from my computer
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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

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

On Fri, May 20, 2022 at 04:29:52PM +0900, Shin-ichi TOYAMA wrote:
> Ah!!
> 
> It looks like that my commit for Windows was wrong.
> 
> See the commit "4749214383bf7d881e85cb82fea2d751c9b292da"
> 
> I thiks following patch will fix it.

Ah well shoot; if you think it's safe to unravel what _I_ did
(in my attempt to fix things), would you be so kind as to do so? :)

Thanks!

-bill!

> 
> --- onscreen_keyboard.c.org	2022-05-20 16:21:47.219690242 +0900
> +++ onscreen_keyboard.c	2022-05-20 16:22:49.095034241 +0900
> @@ -1865,10 +1865,12 @@
>              wcstombs(event.text.text, keyboard->composed, 16);
>            //          event.text.text = *keyboard->composed;
>            else{
> -            //snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
> +#ifdef WIN32
>  	    int iwc = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
>  	    wcstombs(event.text.text, (wchar_t *) &iwc, 16);
> -          //event.text.text = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
> +#else
> +            snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
> +#endif
>  	  }
>  
>            clear_dead_sticks(keyboard);
> 
> 
> I think following patch winn
> On Thu, 19 May 2022 23:36:39 -0700, Bill Kendrick wrote:
> >On Thu, Nov 18, 2021 at 11:57:02PM +0900, TOYAMA Shin-ichi wrote:
> >> Hi Bill,
> >> 
> >> Bill Kendrick wrote in <202...@sh...>
> >> >My plan, however, is to release the NEXT version of Tux Paint,
> >> >which includes a lot of new features (new Magic tools, and the
> >> >Magic tool grouping functionality) using the SDL1.2 branch.
> >> >This will be 0.9.27.
> >> >
> >> >Then, more-or-less immediately, we can try releasing an SDL2.0
> >> >version, that adds no new features to Tux Paint itself.
> >> >This will be 0.9.28.
> >> 
> >> Are you still on this track?
> >
> >BTW, obviously I was not on this track. X^D  Sorry!
> >(It's too tempting to add new features, I had some stress
> >that made "adding new features to Tux Paint" a stress reliever,
> >as weird as that probably sounds.)
> >
> >
> >> I tried to build current sdl2.0 blanch on windows.
> >> 
> >> It looks almost fine but I found that onscreen-keyboard does not 
> >> work correctly with compose function.
> >
> >Uh oh, hrm, using the sdl2.0 branch here on Kubuntu Linux,
> >I am also getting some weird behavior.
> >
> >When I type [h], [e], [l], [l], [o] with the OSK, I get
> >"hello▯" on the canvas, and in the printf()'d output
> >from im.c, I noticed:
> >
> >  im->s o羻, event.text.text o羻
> >
> >I was _not_ using the compose button.
> >
> >In fact, playing with it more, as I click the buttons
> >to spell "hello" again, I'm getting the "unknown character"
> >rectangle a bunch of times.  Just now typing
> >"helloooooooo", I see:
> >
> >  he▯ll▯ooo▯oo▯o▯oo
> >
> >Oh and interestingly, if I try to type any characters
> >that would normally compose, e.g. ~, ', or ", they do not
> >appear unless I type them a second time.
> >
> >So yes, something is definitely broken in the IM stuff
> >with the OSK in the sdl2.0 branch!  Sorry I forgot about
> >this, but I guess I'm glad I left this email in my mailbox. :-D
> >
> >Thanks!
> >
> >-bill!
> >
> >
> >_______________________________________________
> >Tuxpaint-devel mailing list
> >Tux...@li...
> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> 
> -- 
> Shin-ichi TOYAMA <dol...@wm...>
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Some videos made using Tux Paint

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

On Sat, Apr 30, 2022 at 01:02:47PM -0700, Bill Kendrick wrote:
> 
> Some kids in South Africa have been using Tux Paint (sometimes
> together with Blender, and other tools) to create some rather silly
> cartoons and videos, including a music video (coming soon).

GabeTYJ (https://twitter.com/GabeTYJ) has completed the music video
for the song "All Out of Riddles"!  You can watch it here on YouTube!

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


PS - Also check out some more fantastic landscape artwork by Miyagi Andel
(https://twitter.com/Miyagi_Andel):

 * https://tuxpaint.org/gallery/image.php?i=untitled-bob-ross-evenings-glow-by-miyagi_andel.jpg
 * https://tuxpaint.org/gallery/image.php?i=untitled-pond-by-miyagi_andel.jpg

...and some fantastic fanart by "baji" (https://twitter.com/koyo8899):

 * https://tuxpaint.org/gallery/image.php?i=in-my-court-discoduo-from-dream-smp-by-baji-koyo8899.jpg
 * https://tuxpaint.org/gallery/image.php?i=dapduo-from-dream-smp-by-baji-koyo8899.jpg
 * https://tuxpaint.org/gallery/image.php?i=tntduo-from-dream-smp-by-baji-koyo8899.jpg
 * https://tuxpaint.org/gallery/image.php?i=tntduo-from-dsmp-2-by-baji-koyo8899.jpg
 * https://tuxpaint.org/gallery/image.php?i=crimeboys-fanart-by-baji-koyo8899.jpg

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

Thanks to everybody for looking into the sdl2.0 branch, 
obviously it needed more power brain than what I could supply :)

Best
Pere

El dj. 19 de 05 de 2022 a les 23:26 -0700, en/na Bill Kendrick va escriure:
> On Thu, May 19, 2022 at 09:52:02PM +0900, Shin-ichi TOYAMA wrote:
> > On Thu, 19 May 2022 01:59:17 -0700, Bill Kendrick wrote:
> > > One problem for me is that I can't get SDL2_Pango working.
> > 
> <snip>
> > I confirmed my SDL2_Pango.spec which I used to create rpm package for SDL_Pango.
> > I think it was tweaked based on the spec file for SDL_Pango.
> > 
> > Seeing the spec file, I could build SDL2_Pango on my ubuntu on VMware as follows.
> > 
> > $ tar zxvf SDL2_Pango-0.1.2.tar.gz 
> > $ cd SDL2_Pango-0.1.2/
> > $ autoreconf -i 
> > $ libtoolize --copy --force
> > $ automake --add-missing
> > $ ./configure --disable-static
> > $ make
> > 
> > good luck!!
> 
> I was able to build it, and Tux Paint's Makefile found it!
> (I had to run "sudo ldconfig", which my brain dug up from the
> depths.)
> 
>   kendrick@gambit:~/tuxpaint/tuxpaint$ ldd `which tuxpaint` | grep -i pango
>           libSDL2_Pango.so.1 => /usr/local/lib/libSDL2_Pango.so.1 (0x00007f22b54ae000)
>           libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f22b3c1b000)
>           libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f22b3bcc000)
>           libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f22b3660000)
> 
> (Before running "ldconfig", the above showed a "not found"
> error for "libSDL2_Pango.so.1 => ...", and "tuxpaint"
> wouldn't run due to a missing library.)
> 
> Thanks!
> 
> (And thanks to Mark, too; though I didn't use your solution.)
> 

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

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

On Fri, May 20, 2022 at 3:32 AM Bill Kendrick <nb...@so...> wrote:

> So right now, if I type: ['] [a], I get "�", rather than "'a",
>
even without first clicking the [Cmp] (compose) button.
> This is not the correct behavior.
>
> (And, of course, typing ['] at first appears to do nothing.
> If I type it again, I finally get a "'" on the screen.)
>
> Again, this is all with the On-screen Keyboard feature
> (tuxpaint --onscreen-keyboard).  Typing on my physical keyboard
> seems fine.  (i.e., it's a problem at the OSK level, not the
> IM level, like I mistakenly stated before.)
>

It looks like the onscreen keyboard mapping files are setup such a way that
apostrophe, backtick, and tilde are treated as accents unless AltGr is
pressed first.

As far as I know this may be an intentional behavior to accommodate users
of certain European languages.

In any case, submitted the change
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/d167907e194b4cff4c8ae75f6e628aba7ae1c461>
to both master and sdl2.0 branches to swap the behavior of these three keys
between plain and AltGr.  Feel free to revert the check to recover the
previous behavior.

Mark

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

On Fri, 20 May 2022 23:50:18 +0900, Shin-ichi TOYAMA wrote:

>>However, I noticed that SDL2 build often crash when starting it on Windows7
>>despite that it looks quite stable on Windows 10 and 11. 
>>(By the way I do not have test environment for 8 and Vista)
>>
>>Seeing the panic message when it crash:
>>
>> "Panic: VERIFY d:\build\ob\bora-14943755\bora-vmsoft\build\release\svga\wddm\src\usermode\wddmcmdbuf.cpp:763"
>
>I tested sdl2 build on Windows 10 running on VMware, and came across the
>same crash.
>Considering that there is no problem on my windows 11 laptop, this might be 
>due to the specific problem on VMware.
>
>Therefore, if current sdl2 build has no problem on 'physical' windows 10,
>it might be O.K. also on windows 7 and other version of relatively modern
>windows systems.
>
>So, I expect positive feedbacks from beta testors crossing my fingers.

After that, I upgraded the VMware player version from 15 to 16, and also
adjusted the video-related settings of the virtual machines.

Then sdl2 builds ran with no crash on either Windows 7 or Windows 10.

Therefore, if we had no crash report in the beta test, it might be O.K.
to release only 4 (not 8!) veriations (64bit/32bit * exe/zip) of SDL2
build for the next release.

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

Re: [Tuxpaint-devel] SDL2 for the next release for windows?

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

Hi!

On Wed, 18 May 2022 22:34:30 +0900, Shin-ichi TOYAMA wrote:
>Hi!
>
>Recently, I am thinking about that the windows build for the next version
>could be based on the SDL2 branch.
>
>Its good point is that the known issue regarding scaling problem on modern
>windows system will be fixed. 
>
>  See: https://sourceforge.net/p/tuxpaint/bugs/218/
>
>However, I noticed that SDL2 build often crash when starting it on Windows7
>despite that it looks quite stable on Windows 10 and 11. 
>(By the way I do not have test environment for 8 and Vista)
>
>Seeing the panic message when it crash:
>
> "Panic: VERIFY d:\build\ob\bora-14943755\bora-vmsoft\build\release\svga\wddm\src\usermode\wddmcmdbuf.cpp:763"

I tested sdl2 build on Windows 10 running on VMware, and came across the
same crash.
Considering that there is no problem on my windows 11 laptop, this might be 
due to the specific problem on VMware.

Therefore, if current sdl2 build has no problem on 'physical' windows 10,
it might be O.K. also on windows 7 and other version of relatively modern
windows systems.

So, I expect positive feedbacks from beta testors crossing my fingers.

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

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

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

On Thu, May 19, 2022 at 11:36:39PM -0700, Bill Kendrick wrote:
<snip>
> > I tried to build current sdl2.0 blanch on windows.
> > 
> > It looks almost fine but I found that onscreen-keyboard does not 
> > work correctly with compose function.
> 
> Uh oh, hrm, using the sdl2.0 branch here on Kubuntu Linux,
> I am also getting some weird behavior.

Okay, I believe I fixed the following, by making sure strings
were being treated as strings (adding NUL '\0' at the end,
which was missing sometimes!)


> When I type [h], [e], [l], [l], [o] with the OSK, I get
> "hello▯" on the canvas, and in the printf()'d output
> from im.c, I noticed:
> 
>   im->s o羻, event.text.text o羻
> 
> I was _not_ using the compose button.
> 
> In fact, playing with it more, as I click the buttons
> to spell "hello" again, I'm getting the "unknown character"
> rectangle a bunch of times.  Just now typing
> "helloooooooo", I see:
> 
>   he▯ll▯ooo▯oo▯o▯oo


However, the compose problem still seems to be in effect.


> Oh and interestingly, if I try to type any characters
> that would normally compose, e.g. ~, ', or ", they do not
> appear unless I type them a second time.

So right now, if I type: ['] [a], I get "�", rather than "'a",
even without first clicking the [Cmp] (compose) button.
This is not the correct behavior.

(And, of course, typing ['] at first appears to do nothing.
If I type it again, I finally get a "'" on the screen.)

Again, this is all with the On-screen Keyboard feature
(tuxpaint --onscreen-keyboard).  Typing on my physical keyboard
seems fine.  (i.e., it's a problem at the OSK level, not the
IM level, like I mistakenly stated before.)


So...  OSK experts (Pere? maybe Mark?), what do you think?
I've tried doing a diff between 'master' and 'sdl2.0' branches'
versions of "onscreen_keyboard.c" and am not finding anything
obvious. :-(

Thanks in advance!

-bill!

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

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

Ah!!

It looks like that my commit for Windows was wrong.

See the commit "4749214383bf7d881e85cb82fea2d751c9b292da"

I thiks following patch will fix it.

--- onscreen_keyboard.c.org	2022-05-20 16:21:47.219690242 +0900
+++ onscreen_keyboard.c	2022-05-20 16:22:49.095034241 +0900
@@ -1865,10 +1865,12 @@
             wcstombs(event.text.text, keyboard->composed, 16);
           //          event.text.text = *keyboard->composed;
           else{
-            //snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
+#ifdef WIN32
 	    int iwc = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
 	    wcstombs(event.text.text, (wchar_t *) &iwc, 16);
-          //event.text.text = keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard);
+#else
+            snprintf(event.text.text, 16, "%lc", keysym2unicode(mnemo2keysym(mnemo, keyboard), keyboard));
+#endif
 	  }
 
           clear_dead_sticks(keyboard);


I think following patch winn
On Thu, 19 May 2022 23:36:39 -0700, Bill Kendrick wrote:
>On Thu, Nov 18, 2021 at 11:57:02PM +0900, TOYAMA Shin-ichi wrote:
>> Hi Bill,
>> 
>> Bill Kendrick wrote in <202...@sh...>
>> >My plan, however, is to release the NEXT version of Tux Paint,
>> >which includes a lot of new features (new Magic tools, and the
>> >Magic tool grouping functionality) using the SDL1.2 branch.
>> >This will be 0.9.27.
>> >
>> >Then, more-or-less immediately, we can try releasing an SDL2.0
>> >version, that adds no new features to Tux Paint itself.
>> >This will be 0.9.28.
>> 
>> Are you still on this track?
>
>BTW, obviously I was not on this track. X^D  Sorry!
>(It's too tempting to add new features, I had some stress
>that made "adding new features to Tux Paint" a stress reliever,
>as weird as that probably sounds.)
>
>
>> I tried to build current sdl2.0 blanch on windows.
>> 
>> It looks almost fine but I found that onscreen-keyboard does not 
>> work correctly with compose function.
>
>Uh oh, hrm, using the sdl2.0 branch here on Kubuntu Linux,
>I am also getting some weird behavior.
>
>When I type [h], [e], [l], [l], [o] with the OSK, I get
>"hello▯" on the canvas, and in the printf()'d output
>from im.c, I noticed:
>
>  im->s o羻, event.text.text o羻
>
>I was _not_ using the compose button.
>
>In fact, playing with it more, as I click the buttons
>to spell "hello" again, I'm getting the "unknown character"
>rectangle a bunch of times.  Just now typing
>"helloooooooo", I see:
>
>  he▯ll▯ooo▯oo▯o▯oo
>
>Oh and interestingly, if I try to type any characters
>that would normally compose, e.g. ~, ', or ", they do not
>appear unless I type them a second time.
>
>So yes, something is definitely broken in the IM stuff
>with the OSK in the sdl2.0 branch!  Sorry I forgot about
>this, but I guess I'm glad I left this email in my mailbox. :-D
>
>Thanks!
>
>-bill!
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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

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

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

On Thu, Nov 18, 2021 at 11:57:02PM +0900, TOYAMA Shin-ichi wrote:
> Hi Bill,
> 
> Bill Kendrick wrote in <202...@sh...>
> >My plan, however, is to release the NEXT version of Tux Paint,
> >which includes a lot of new features (new Magic tools, and the
> >Magic tool grouping functionality) using the SDL1.2 branch.
> >This will be 0.9.27.
> >
> >Then, more-or-less immediately, we can try releasing an SDL2.0
> >version, that adds no new features to Tux Paint itself.
> >This will be 0.9.28.
> 
> Are you still on this track?

BTW, obviously I was not on this track. X^D  Sorry!
(It's too tempting to add new features, I had some stress
that made "adding new features to Tux Paint" a stress reliever,
as weird as that probably sounds.)


> I tried to build current sdl2.0 blanch on windows.
> 
> It looks almost fine but I found that onscreen-keyboard does not 
> work correctly with compose function.

Uh oh, hrm, using the sdl2.0 branch here on Kubuntu Linux,
I am also getting some weird behavior.

When I type [h], [e], [l], [l], [o] with the OSK, I get
"hello▯" on the canvas, and in the printf()'d output
from im.c, I noticed:

  im->s o羻, event.text.text o羻

I was _not_ using the compose button.

In fact, playing with it more, as I click the buttons
to spell "hello" again, I'm getting the "unknown character"
rectangle a bunch of times.  Just now typing
"helloooooooo", I see:

  he▯ll▯ooo▯oo▯o▯oo

Oh and interestingly, if I try to type any characters
that would normally compose, e.g. ~, ', or ", they do not
appear unless I type them a second time.

So yes, something is definitely broken in the IM stuff
with the OSK in the sdl2.0 branch!  Sorry I forgot about
this, but I guess I'm glad I left this email in my mailbox. :-D

Thanks!

-bill!