tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

"x" works great on the Mac.

Fixed the quick eraser continuing to quick erase while the mouse is moving
-- 
https://sourceforge.net/p/tuxpaint/tuxpaint/ci/371d9cdbd855939e340e9758efa3d6d586244760/

Thanks,
Mark

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

Hi!

On Thu, 29 Sep 2022 08:17:32 +0200, Pere Pujal i Carabantes wrote:
>> > 2. The erase operation doesn't stop if the mouse is moving quickly even
>> > after both the delete key and the primary mouse button are both released.
>> > This can go on indefinitely as far as I can tell as long as the mouse
>> > continues to move quickly.
>> 
>> Hrm, it should exit on SDL_MOUSEBUTTONUP, but perhaps if you move very
>> quickly some of the events get lost.  I'm unable to replicate this,
>> though.  (And I was REALLY going nuts with my mouse :) )
>
>I've reproduced by slowing tuxpaint with valgrind
>valgrind ./tuxpaint --1800x1000
>
>I found this that seems a different issue, click, hold X, slowly drag and start erasing, 
>then release X but continue slowly dragging, it still erases.

It reproduce also on windows build regardless of the mouse speed.

FYI

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

El dc. 28 de 09 de 2022 a les 21:59 -0700, en/na Bill Kendrick va escriure:
> On Wed, Sep 28, 2022 at 09:24:02PM -0400, Mark K. Kim wrote:
> > Hi Bill,
> > 
> > On Wed, Sep 28, 2022 at 5:13 AM Bill Kendrick <nb...@so...> wrote:
> > 
> > > 
> 
> 
> > 2. The erase operation doesn't stop if the mouse is moving quickly even
> > after both the delete key and the primary mouse button are both released.
> > This can go on indefinitely as far as I can tell as long as the mouse
> > continues to move quickly.
> 
> Hrm, it should exit on SDL_MOUSEBUTTONUP, but perhaps if you move very
> quickly some of the events get lost.  I'm unable to replicate this,
> though.  (And I was REALLY going nuts with my mouse :) )

I've reproduced by slowing tuxpaint with valgrind
valgrind ./tuxpaint --1800x1000

I found this that seems a different issue, click, hold X, slowly drag and start erasing, 
then release X but continue slowly dragging, it still erases.

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

On Wed, Sep 28, 2022 at 09:24:02PM -0400, Mark K. Kim wrote:
> Hi Bill,
> 
> On Wed, Sep 28, 2022 at 5:13 AM Bill Kendrick <nb...@so...> wrote:
> 
> > So, if you notice any glitches,
> > please let me know ASAP so I can try to address them.
> >
> 
> 1. The erase operation doesn't start until the delete key and the primary
> mouse button are both pressed.  My instinct is to expect the mouse cursor
> to change the moment the delete key is pressed to signal that the function
> of the primary button on the mouse has changed from "draw" to "erase".

I don't disagree.  I'm just a little fearful of tacking too much more
on in here.  :-)  It would also need to be done for the [Ctrl]+click
for the pipette tool, for consistency, IMO.


> 2. The erase operation doesn't stop if the mouse is moving quickly even
> after both the delete key and the primary mouse button are both released.
> This can go on indefinitely as far as I can tell as long as the mouse
> continues to move quickly.

Hrm, it should exit on SDL_MOUSEBUTTONUP, but perhaps if you move very
quickly some of the events get lost.  I'm unable to replicate this,
though.  (And I was REALLY going nuts with my mouse :) )

Also, the function will also exit when you press [Esc]
(SDL_KEYDOWN with SDLK_ESCAPE).


> 3. Using the "delete" key to erase on the Mac will be confusing and
> difficult.  Confusing because the key labeled "delete" on the Mac keyboard
> is actually where the backspace key is on the PC keyboard and works like
> the backspace key.  And difficult because triggering the scancode
> equivalent to PC's delete on the Mac keyboard, which lacks the extended
> keys on the default out-of-the-box keyboard, involves pressing and holding
> down simultaneously the Fn key on the bottom-left of the keyboard and
> pressing the delete key on the top-right of the keyboard, which is a two
> handed operation for most people.  Therefore holding down the "delete key"
> and using the mouse simultaneously is a three-handed operation on the Mac!
> :D

Hah!  Whoops, rookie mistake!  Sorry!

Okay, so I'm going to restrict this feature such that it does not work
_at all_ while using the Text or Label tool, and am using the [X] key,
instead of [Del].

QWERTY, QWERTZ, and AZERTY all have "X".  However, ÄWERTY, and sometimes
ĄŽERTY, do not have "X".  It's a bit of a rabbit hole.

Any problems with this plan, does anyone think?


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

Hi Bill,

On Wed, Sep 28, 2022 at 5:13 AM Bill Kendrick <nb...@so...> wrote:

> So, if you notice any glitches,
> please let me know ASAP so I can try to address them.
>

1. The erase operation doesn't start until the delete key and the primary
mouse button are both pressed.  My instinct is to expect the mouse cursor
to change the moment the delete key is pressed to signal that the function
of the primary button on the mouse has changed from "draw" to "erase".

2. The erase operation doesn't stop if the mouse is moving quickly even
after both the delete key and the primary mouse button are both released.
This can go on indefinitely as far as I can tell as long as the mouse
continues to move quickly.

3. Using the "delete" key to erase on the Mac will be confusing and
difficult.  Confusing because the key labeled "delete" on the Mac keyboard
is actually where the backspace key is on the PC keyboard and works like
the backspace key.  And difficult because triggering the scancode
equivalent to PC's delete on the Mac keyboard, which lacks the extended
keys on the default out-of-the-box keyboard, involves pressing and holding
down simultaneously the Fn key on the bottom-left of the keyboard and
pressing the delete key on the top-right of the keyboard, which is a two
handed operation for most people.  Therefore holding down the "delete key"
and using the mouse simultaneously is a three-handed operation on the Mac!
:D

Mark

[Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

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

Tonight I thought that, since Tux Paint is now focused on SDL2, I
could finally look into adding drawing tablet (e.g., Wacom) support to
Tux Paint.

Right now, it works, but acts as a mouse: no pressure, no recognition
of which stylus tip (pen vs. eraser) is being usded, etc.

Unfortunately, even after so many years, SDL isn't quite ready! :-D
(See https://github.com/libsdl-org/SDL/issues/2217)

However, I realized the process would end up being very similar
to what I did for the color picker "pipette" shortcut ([Ctrl] key)
in 0.9.28, and decided I could add a similar feature that would
give users quick access to an eraser via a shortcut key.

Once SDL could actually tell us when a stylus' eraser tip is
being used, we could simply do the same thing as when the
shortcut key is being held!

So, I've added code in what will become Tux Paint 0.9.29 that lets you
hold the [Del] ("delete"; not to be confused with "backspace") key,
at _almost_ any time, to get quick access to a small, round eraser.


Without checking for the state of things, I discovered that this
feature would interfer with the rotation steps of both the Shapes
and Stamps tools.  So I specifically avoid invoking this new code
in those two situations.

Other parts of Tux Paint -- like the Fill tool's linear gradient and
brush modes, interactive Magic tools, etc. -- appear to inherently
avoid interference from this feature, since you're in the process of
click+dragging.  It's impossible to get another click in there;
pressing [Del] on its own doesn't invoke this code, it's the
combination of an otherwise-uncaught click, plus the [Del] key
already being held.

However, as usual, it's late at night, I should have gone to bed
2 hours ago, and mistakes happen.  So, if you notice any glitches,
please let me know ASAP so I can try to address them.


So far, I think I need to tackle:

 * interferrence with onscreen keyboard (Text & Label tools)

 * "--mouse-accessibility" mode
   (other features, like the [Ctrl] quick access color picker,
   probably need to better support this option!)

 * "--keyboard" mode
   (ditto)



-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Merging sdl2.0 branch into master -- help wanted

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

Since the last release of Tux Paint, we've been focusing on the SDL2.0
version of the codebase (in the "sdl2.0" branch), and finally diverged
significantly from the classic SDL1.2 version of the codebase
(the "master" branch).

Specifically, a major new feature -- Stamp rotation -- exists only in
the "sdl2.0" branch.

This departure is fine, as we recently decided to stop supporting
SDL1.2. [*]  Previously, we (mostly me) had been continuing development
in "master" and Pere would merge & port the changes to SDL2.0 in the
"sdl2.0" branch.  (Thank you!)  This made the Android port possible.

The last version of Tux Paint was released as source (and in some
cases, e.g. for some versions Red Hat Enterprise Linux (RHEL), it
was built as binaries) twice -- once using the SDL1.2 "master" branch,
]and again using the SDL2.0 branch.  Moving forward, I'd like to stop
this.

And a minor problem right now is that some people are still on
"master" and making changes (e.g., translation updates in "src/po/")
in that branch, which require syncing up the files in "sdl2.0".


Therefore, I'd like to merge all the "sdl2.0" codebase into "master",
or maybe swap the branches somehow ("master" becomes "sdl1.2" and
"sdl2.0" becomes the new "master"), if there's any good reason to do
it that way instead.

Searching around Google I find a million questions, and just as many
answers; and most of them seeming to not be quite relevant to our
particular problem here.  (Also, many are GitHub-specific, and may
not apply to SourceForge, due to differences in their web UIs...?)


The following appears like the most appropriate way of just pulling
all of the "sdl2.0" code into "master", but I'm far from a Git expert,
and dare not attempt it before asking.

  git checkout sdl2.0
  git merge -s ours --no-commit master
  git commit
  git checkout master
  git merge sdl2.0

Does anyone out here have experience doing something like this?

I'd really like to avoid causing a huge mess, if possible.  And of
course, require as little work from the rest of the team as possible
(i.e., not do something that requires everyone _else_ do anything
beyond just switching [back to] "master" branch and "git pull"-ing
before making any further changes).

If no one speaks up, I'll start asking around the wider community
(e.g., my Twitter followers, maybe even folks at my Day Job(tm)).

Thanks in advance, and thanks again to Pere for doing such a good
job of keeping "sdl2.0" sync'd with "master" all these years,
and handling the Android builds!

-- 
-bill!
Sent from my computer

[*] SDL2.0 has been around since 2013, and I've recently been cluing
into the fact that SDL1.2 apps on various Linux platforms use a
compatibility later between the 1.2-based app and the 2.0 libraries,
which has caused some issues with Tux Paint which are not seen when
using 100% SDL1.2 or 100% SDL2.0.)

[Tuxpaint-devel] Preview of Rush does not match with results

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

Hi all,
I noticed this some time ago but later forgot about it, sorry

Start Tux Paint, put a stamp there and go to Magic Rush
Click at the bottom of the image and drag up to enlarge the stamp
See how the final rushed image is smaller that the one in the preview.

HTH
Pere

Re: [Tuxpaint-devel] Can't recover original behavior of half-transparent brushes

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

On Sun, Sep 18, 2022 at 08:16:09PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> I was updating the Catalan translation when I noticed this:
> 
> Start Tux Paint, select a brush that is not fully opaque, like the sixth or seventh ones and paint a line,
> change the brush spacing to something bigger, then change it again to the smallest and paint another line
> 
> See the differences between both lines, I've not been able to get the original behavior again unless restarting Tux Paint.

Ah, I see what you mean!  My hunch is that the initial
spacing of the brush is _not_ something you can subsequently
re-select using the UI.

I'll try to investigate how we can address this.

Thanks for reporting!

-bill!

[Tuxpaint-devel] Can't recover original behavior of half-transparent brushes

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

Hi all,

I was updating the Catalan translation when I noticed this:

Start Tux Paint, select a brush that is not fully opaque, like the sixth or seventh ones and paint a line,
change the brush spacing to something bigger, then change it again to the smallest and paint another line

See the differences between both lines, I've not been able to get the original behavior again unless restarting Tux Paint.


HTH
Pere

Re: [Tuxpaint-devel] Pipette tool begins drawing right away (ctrl+click quick access)

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

On Thu, Sep 15, 2022 at 12:42:08AM +0200, Pere Pujal i Carabantes wrote:
> El dt. 13 de 09 de 2022 a les 02:39 -0700, en/na Bill Kendrick va escriure:
> > Note to self (or anyone else who wants to investigate)...
> > 
> > Under the sdl2.0 branch, something seems to be causing the
> > quick-access to the pipette (pick color from the canvas)
> > tool -- that is, holding [Ctrl] & clicking in the canvas -- to mak
> > Tux Paint's active active tool (e.g., Paint, Lines) think that
> > the mouse button is being held down.
> > 
> > Needs to be corrected before the next release!
> > 
> 
> Tracked down to the 0f7054d118ae6e930948909bbdaab986303fc12a commit
> Looks I did not curate correctly the previous cherry-pick 3b4d2fc8f2457ad4c96dde2bec2141b1281959a1

That was easy. I think it was just that "button_down = 1" was
happening outside the click-and-draw block, and hence _also_
being set (when it should not have) during the ctrl-click-for-pipette
action.

https://sourceforge.net/p/tuxpaint/tuxpaint/ci/09f332367fcae9a660534b55ff0706d4ab042f31/

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Pipette tool begins drawing right away (ctrl+click quick access)

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

El dt. 13 de 09 de 2022 a les 02:39 -0700, en/na Bill Kendrick va escriure:
> Note to self (or anyone else who wants to investigate)...
> 
> Under the sdl2.0 branch, something seems to be causing the
> quick-access to the pipette (pick color from the canvas)
> tool -- that is, holding [Ctrl] & clicking in the canvas -- to mak
> Tux Paint's active active tool (e.g., Paint, Lines) think that
> the mouse button is being held down.
> 
> Needs to be corrected before the next release!
> 

Tracked down to the 0f7054d118ae6e930948909bbdaab986303fc12a commit
Looks I did not curate correctly the previous cherry-pick 3b4d2fc8f2457ad4c96dde2bec2141b1281959a1

If somebody wants to put an eye there...

Thanks
Pere

[Tuxpaint-devel] Tux Paint quickstart guide - draft

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

Tonight I walked myself through all of Tux Paint's main features and
tried to briefly explain them in a simple text file, which I ended up
saving out as Markdown.

It's attached, and I'd love any feedback on it!  I'm thinking I could
PHP + gettext()-ify it, and place it in tuxpaint-docs, and then
generate it like we generate the HTML version of the docs, to allow
translation.

As it's plaintext / markdown, it has no screenshots or images of
any kind, but I did use some Unicode (including some newer emojis)
to try and convey some of the UI (e.g., thumbs-up and -down whenever
I mention the Redo & Undo buttons, respectively).

When I open up this version in Okular on KDE, it looks pretty nice,
and seems to come out to about 5 pages.

For comparison, the English version of the README, as plain text,
opened in Kate and previewed for printing, would come out to about
19 pages (~4x larger).

And the English version of the README in HTML (which admittedly does
include some hints to invoke pagebreaks at each section, and avoid
some widows/orphans), opened in Google Chrome browser and printed,
would come out to 33 page (~6-7x larger).

(All of this printing talk is on a system set up for US Letter,
8.5" x 11", FWIW.)

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Pipette tool begins drawing right away (ctrl+click quick access)

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

Note to self (or anyone else who wants to investigate)...

Under the sdl2.0 branch, something seems to be causing the
quick-access to the pipette (pick color from the canvas)
tool -- that is, holding [Ctrl] & clicking in the canvas -- to mak
Tux Paint's active active tool (e.g., Paint, Lines) think that
the mouse button is being held down.

Needs to be corrected before the next release!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Stamps rotation

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

On Sun, Sep 11, 2022 at 12:01:15PM +0200, Pere Pujal i Carabantes wrote:
> > Another idea is to discard XORs/events so there is no need to draw 
> > XORs for old positions when the mouse has moved meters.
> 
> I've finally implemented this approach, toke me some time but seems to work fine, 
> and speeds up a lot the rendering of BIG scaled stamps.

Yes, it's very nice on my laptop in 800x600 mode, making very
large stams (e.g., of the frog, a bird, etc.)  It seems to follow
along for a few frames, and then 'snap' to catch up, once I stop
wiggling the mouse.

Specs: Lenovo Thinkpad T480s, Ubuntu 20.04.5 LTS.
KDE's System Info shows:

  ...
  Kernel Version: 5.4.0-124-generic
  OS Type: 64-bit
  Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
  Memory: 23.3 GiB of RAM

-bill!

Re: [Tuxpaint-devel] Stamps rotation

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

El ds. 03 de 09 de 2022 a les 01:51 +0200, en/na Pere Pujal i Carabantes va escriure:
> 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.

I've finally implemented this approach, toke me some time but seems to work fine, 
and speeds up a lot the rendering of BIG scaled stamps.

Please test

Thanks
Pere

Re: [Tuxpaint-devel] Stamps rotation

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

On Sat, Sep 03, 2022 at 01:51:37AM +0200, Pere Pujal i Carabantes wrote:
<snip>
> > 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/

Time flies.  :-Z

Closed it!


> > 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.

I've made it the 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 :)

Actually, I had not!  But I just did.  I also added the feature's
disabling option to Tux Paint Config.

-bill!

Re: [Tuxpaint-devel] Prompt drop-shadows in SDL2

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

On Sat, Sep 03, 2022 at 02:03:29AM +0200, Pere Pujal i Carabantes wrote:
<snip> 
> Sorry, I thouth you spoke about the increasing shadows(from the button to the dialog)
> Indeed I dont see the final shadow next to the dialog.

Now that my weekend-long headache has ended, I was able to sit
down and figure out how to fix it. :)

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/270f5353e09b8a8938e497b8f5667a044b622f10/

Basically, for each it looked like

-      SDL_FillRect(alpha_surf, NULL, SDL_MapRGB(alpha_surf->format, 0, 0, 0));
-      SDL_SetSurfaceAlphaMod(alpha_surf, 64);
-
+      SDL_FillRect(alpha_surf, NULL, SDL_MapRGBA(alpha_surf->format, 0, 0, 0, 64));


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Prompt drop-shadows in SDL2

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

El ds. 03 de 09 de 2022 a les 01:57 +0200, en/na Pere Pujal i Carabantes va escriure:
> El dv. 02 de 09 de 2022 a les 02:51 -0700, en/na Bill Kendrick va escriure:
> > 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!
> > 
> Strange, I see the shadows here
> Maybe they show/disappear too quick?
> Try to slowdown launching Tux Paint with valgrind
> 
> Or maybe your box has an older version of libsdl2?
> I currently have libsdl2-2.0-0 Version: 2.0.18+dfsg-2

Sorry, I thouth you spoke about the increasing shadows(from the button to the dialog)
Indeed I dont see the final shadow next to the dialog.

Re: [Tuxpaint-devel] Prompt drop-shadows in SDL2

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

El dv. 02 de 09 de 2022 a les 02:51 -0700, en/na Bill Kendrick va escriure:
> 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!
> 
Strange, I see the shadows here
Maybe they show/disappear too quick?
Try to slowdown launching Tux Paint with valgrind

Or maybe your box has an older version of libsdl2?
I currently have libsdl2-2.0-0 Version: 2.0.18+dfsg-2

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