#296 Window & cursor issues with 0.9.34 flatpak on Linux on ChromeOS

[William Kendrick]

(The following was reported via email, and I was given permission to post it as a SF bug report.)

---

Hi! Thank you so much for your amazing drawing program. Your work is an incredible service to the world.

I've been having some issues with Tuxpaint 9.34 and figured that it might help other users if I made a bug report.

I use the Linux development environment on my Chromebook so I can use apps that need Linux to work well.

Some information about the Linux I'm using:

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
Virtualization: lxc
Chassis: container ☐
Architecture: x86-64

Some information about the version of ChromeOS I'm using:

Version 132.0.6834.190 (Official Build) (64-bit)

I downloaded Tuxpaint version 9.34 via flatpak.

Previously I tried to use sudo apt install to acquire Tuxpaint, but that yielded an older version, 0.9.28. Version 0.9.28 works exactly the way it should, exporting correctly, proper cursor behavior, listens to the system-wide configuration file, etc, but I wanted the new brushes and "magic tools", so I got rid of it and set out using flatpak to get the newest version.

I just re-downloaded 0.9.28 via sudo apt install tuxpaint AGAIN, just to check that the version number was correct in this email, and I noticed that it's applying the settings I changed in the system-wide configuration file. 0.9.28 can read the file but 9.34 cannot do that, strangely enough. That is why my settings only apply themselves only to 0.9.28. Does each version of Tuxpaint get its own system-wide configuration file? I am beginning to suspect that 9.34 does not have one/did not make one for itself because of some issue with its permissions,and the one I have been editing in an attempt to fix its problems belongs to 0.9.28.

Version 9.34, when I attempt to run it like this: "flatpak run org.tuxpaint.Tuxpaint" gets me these messages in my terminal. See file "no arguments.png". [...] The blacked-out text in the screenshot is just my username. [...]

Here is what the window looks like when I try to open it this way:
See "broken window.png". I am able to drag this guy around with my cursor, and hovering over it makes it so I can see some buttons. The cursor gets bigger when it is over this window. The minimize button works, the close button does not. This is because it wants me to click either the "quit" or "no! keep drawing" buttons to confirm if I really want to close Tuxpaint. But I can't see them or touch them, so this window is basically unclosable except with force quit. Tux starts talking when I press the little X, and I can imagine the screen that is supposed to be shown to me- with the red and green choice buttons- but the window is too teeny to show it. See "9.34 window behavior.webm"

This same thing happens with the window when I try to open 9.34 by simply clicking the app icon.

This window has no name when I click on the penguin-shaped icon to view which tabs are open + using Linux. It shows up as a blank space. If I open multiple tuxpaint 9.34 tabs, telling the computer to ignore the lock file, or waiting between each open, they all show up as blank, but the computer is able to count how many there are and show an accurate number of blank spaces.

I tried to meddle with the config file to fix this, to no avail. The only thing that messing with the config file changes is Tuxpaint 0.9.28's settings. It went Fullscreen because I uncommented that option and saved the file.

There are a few ways to run 9.34 so it opens in a usable window-running it like this "flatpak run org.tuxpaint.Tuxpaint --fullscreen=no" yields this result: see "tuxpaint --fullscreen=no.png" This is usable, except the cursor behaves in a very odd way. We get a new message when doing this, too! "Warning: Asking for native screensize in a window. Ignoring.
Warning: Could not query any display modes!?"
When I click on the penguin icon to check which tabs are open + using Linux, this window is named "Tuxpaint" !! A step in the right direction.

I'm pretty sure 9.34 cannot read the config file at all. It can't seem to find ".tuxpaint/saved" either, even though I know its real (I can find it myself by scrounging around in my files) It doesn't seem like it was able to create Pictures/Tuxpaint in my home directory, nor can it find the one that I made myself for it to have , with the same names and location as what it's looking for. Seems like a permissions problem. Tuxpaint 9.34 seems like it is not allowed to read write or execute most things. which I could probably fix easily, if I was not such a newbie when it comes to Linux.

Here's what it does when I try to export a doodle from version 9.34 See "terminal export message.png" and "tuxpaint export message.png"

For comparison, this is what happens when I try to export a doodle from version 0.9.28. (Remember that both versions are living on the same computer at the same time. Could that be causing some of my issues???) See "old tuxpaint export message.png". And there it is. Right where it should be. See "there it is.png"

Now, the weird cursor behavior.

Because 0.9.28 is the version I have used for the longest amount of time, I have come to accept that behavior as "normal". Here's what it looks like. The "paint" or rather, the line that i'm drawing,
--directly-- follows the "paintbrush"/cursor. When I erase, the plus sign is fully within the circle, making the plus sign the center of my "eraser" as I drag it around. It all seems pretty intuitive, making me assume that was an intentional choice on the part of you and other developers to make the paint follow close behind the cursor in that way. No matter what I make the spacing, the way the paint follows the cursor is always consistent.

The cursor behavior in 9.34 is vastly different, and pretty inconvenient! I didn't think any coder would ever make something inconvenient on purpose, so I assumed my computer was just being bad, or more specifically maybe a recent update to the OS had changed my devices compatibility with new apps. Unfortunately my computer is still mainly a Google machine and Google likes to do that a lot.

Here's what it looks like. With the erasers, the plus sign is now positioned down and to the right within the circle. With the brushes, where the paint comes from is now quite offset from the end of the cursor.

I am not able to attach any more files to this email, but I can send you the videos I took of cursor behavior in another video if you like.

Thank you so much for spending your valuable time reading this. It means a lot.

[William Kendrick]

Regarding Tux Paint's configuration files and save location under Flatpak, keep in mind that Flatpak typically runs applications within their own 'sandbox', meaning they cannot access other files. This is likely why Tux Paint 0.9.28 is using the config file, and saving where you expect, while 0.9.34 does not seem to.

Our Flatpak download page includes a few tips I've collected along the way (https://tuxpaint.org/download/linux-flatpak/), specifically:

Sending command-line arguments to Tux Paint
Invoke Tux Paint from a shell, script, or launcher via flatpak run org.tuxpaint.Tuxpaint, with arguments to Tux Paint at the end (e.g., flatpak run org.tuxpaint.Tuxpaint --fullscreen=no).

Access my ~/.tuxpaintrc personal configuration file and ~/.tuxpaint/ personal directory
flatpak --filesystem=~/.tuxpaintrc --filesystem=~/.tuxpaint run org.tuxpaint.Tuxpaint --nosysconfig

Tux Paint 0.9.28 was the first version that was built natively against SDL2 (vs. the much older SDL1.2; modern systems would run Tux Paint using a compatibility layer, "sdl1.2-compat"). We still produced some SDL1.2 builds ourselves, but it seems Debian (& hence Ubuntu) provide the SDL2 flavor of 0.9.28. (These days, we no longer support SDL1.2.)

To wit:

$ ldd /usr/bin/tuxpaint|grep -i SDL
        libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007c8315389000)
        libSDL2_image-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0 (0x00007c8315369000)
        libSDL2_ttf-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0 (0x00007c8315354000)
        libSDL2_gfx-1.0.so.0 => /lib/x86_64-linux-gnu/libSDL2_gfx-1.0.so.0 (0x00007c8315342000)
        libSDL2_mixer-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0 (0x00007c83152c1000)

$ /usr/bin/tuxpaint --verbose-version

Tux Paint
  Version 0.9.28 (2024-03-31)

Built with these options:
  SDL version 2.30.0
  Built for POSIX
  Using software surface  (no USE_HWSURFACE)
  Using 32bpp video  (VIDEO_BPP=32)
  Prints as PostScript  (PRINTMETHOD_PS)
  Threaded font loader enabled  (FORKED_FONTS)
  Data directory (DATA_PREFIX) = /usr/share/tuxpaint/
  Plugin directory (MAGIC_PREFIX) = /usr/lib/tuxpaint/plugins/
  Doc directory (DOC_PREFIX) = /usr/share/doc/tuxpaint-0.9.28/
  Locale directory (LOCALEDIR) = /usr/share/locale/
  Input Method directory (IMDIR) = /usr/share/tuxpaint/im/
  System config directory (CONFDIR) = /etc/tuxpaint/

[William Kendrick]

I opened a small ticket (https://github.com/flathub/org.tuxpaint.Tuxpaint/issues/59) that points to this SF.net bug report.