jonri

Flatpak is updated and should show up on Flathub in a bit.

I created a bug tracker ticket for this issue: https://bugs.thedarkmod.com/view.php?id=6165 I made a build with debug symbols on my desktop, and oddly enough darkradiant exits entirely rather than crashing with a SIGTRAP when I try to debug it. I'll keep investigating...

I updated the flatpak earlier today and the new version is now available on Flathub. Unforunately the crash when opening certain dialogs is still present for me, but hopefully I'll have more time to look into that this week.

A bit of a guess here, but have you watched your memory usage while this happens? Those symptoms sound a bit like you're running out of RAM and swapping. Could be video RAM too, maybe...

I don't have enough symbol information to get the value of the variables, so I won't be able to help out there until I get a chance to make a debug build. I tried with G_MESSAGES_DEBUG=all and didn't get anything on the console either.

Launching a new 2D view, TexTool, or Light window all cause a crash for me as well in the Flatpak version (using Fedora and AMD). I'd guess junk rendering or the crash might both stem from the same underlying issue. Interestingly, the Light window actually displays and the area where you choose your material says "Loading Resources" before it stops. Running it in GDB yields a SIGTRAP. Here's the stack trace: Hopefully this helps somewhat; I won't get a chance to run it in a debugger until next week if needed.

I'm afraid to ask which kind of "coke" would be required for this...

I've updated the flatpak (and cherry-picked the above post-release Linux fix). It should show up online once Flathub's build scripts pick it up and do their thing.

I took a stab at it, here's what I did in case you want to try to improve it some more. In Gimp I used scaling with NoHalo interpolation, and then I adjusted the contrast to +30.

Did you file a bug report yet? I noticed that I can drag the layers, but dropping them doesn't do anything.

I like this approach, it seems like it would be easy to have some logic in DR that if the game path isn't set and that directory exists, then set it by default. This would keep it from affecting anyone that isn't using the flatpak version, and for anyone who just installs both flatpaks things will already be set up with the right paths. Locking down the filesystem for DR may be a minor inconvenience to anyone who keeps multiple TDM installs around (dev builds, etc), but in this case Flatseal provides an easy, one time solution to open up full access (I've already documented the reverse in the wiki). Your 128px icon looks fine to me, seems to be from the same original source as the 48px icon. Does it look ok if you derive a 64px icon from it too?

@Ludvig nice to see you're getting this ready for Flathub! Since I just went through this with DarkRadiant, I took a look at your manifest to see if there's anything that will trip up the process: Comments are fine, but they don't like commented out lines so you'll want to clean those up before submitting. They require a 64x64 and a 128x128 icon file, and the one you're providing is 48x48. You might need to go hunting in the assets or on the wiki, or see if someone here has a suitable icon lying around. I'm not sure about having --socket=wayland and --socket=x11 together. If we don't have explicit wayland support then --socket=x11 should be sufficient on its own; if we do, then I think you use --socket=wayland with --socket=x11-fallback. You have --talk-name=org.freedesktop.Notifications but I don't remember anything in TDM or the installer that would make use of it. If there is, feel free to correct me You'll need a flathub.json file that tells their build system which CPU architectures to support or skip. Without this, I think it will try to make an ARM package too. Once you've got an appstream file I'll gladly check it over for you too.

I haven't, but I'll certainly try it out! Ordinarily Flatpak packages can't get to each other's files, but if it can be installed to an agreed-upon location outside the sandbox we should be able to make this work.

Done!

Looks like it's happening for me with 3.3.0 and 3.2.0.

@datiswoustry upgrading your flatpak to the new 3.3.0 release. The 3.2.0 flatpak was indeed compiled against wx 3.0.5, but since a blocking bug got fixed the new one is using wx 3.2.1. I've got both flatpaks installed, and for me the old one has the scrollwheel issue and the new one does not.

The Flathub package has been updated, it should be available once their system finishes building it.

I just copied this information out of the .desktop file. It wouldn't hurt to clean some of those up though, the longer description was also there but might be a bit brief for a graphical package browser too. Not DarkRadiant specific, but I think you usually just have to install the Flatpak version of your system theme. For me (KDE / Breeze), I had to install https://github.com/flathub/org.gtk.Gtk3theme.Breeze and apply the workaround from the readme.

Good news everyone! Flathub accepted our package as-is! You can find it here: https://flathub.org/apps/details/net.darkradiant.DarkRadiant I started writing a wiki article for it yesterday, I'll change the wording to let people know how to opt in to the sandbox instead.

I think it would actually make things harder...

I think this is the only outstanding issue left. Instead of requiring TDM to be in /home, my alternative idea is to provide instructions for the user to modify the permissions after installation. This can either be done with a single command along the lines of flatpak override --user --filesystem=/path/to/tdm net.darkradiant.DarkRadian or by using Flatseal to so the same graphically. I propose putting these instructions in a wiki article that we link to in the package description, and possibly a little sentence on the Game Setup dialog in the next version of DR saying "Can't find your game path? Click here for instructions" that would show up in the flatpak version only. This process seems to be what various media players have settled on doing when they need persistent access to an arbitrary directory. As long as your TDM path doesn't change, this would be a one-time process.

Where should we expect the files to be? The darkradiant flatpak is separate from the game itself. Since TDM has its own installer, the files could be anywhere the user decides.

I'm not concerned about the DR flatpak install location, but rather being able to access the TDM game files in whatever arbitrary location the user has installed them. 1. We need to read the game files for the user to make use of any game assets in their map. 2. We need to write the map and its supporting files to this location for them to be loadable in-game.

One of flatpak's strengths and limitations is that it tries to sandbox off anything that is not required for the application to run. Since TDM can be installed anywhere, the only way to support that is to let the application have access to the whole filesystem, which essentially defeats the sandbox. There's a concept of "portals" that lets the user poke holes in the sandbox to load and save files, but I think DR does too much file access behind the scenes for this to work. I need to do more research here. If we can't find a good way forward, in the worst case we could provide instructions on how the user can use flatseal to change the flatpak's permissions and allow access to their chosen TDM install path after installation.

Got a small laundry list of things to fix up to pass validation: We need a content rating, I'm looking at how to generate that now. We need a 128x128 icon. I found this so I was wondering @greeboif you had any other icon source files lying around. If not I'll just upscale the 64x64 icon to meet the requirement. Screenshots of the application are also mandatory. I could make a wiki page to host them and it would probably be fine, but for maximum stability of the links could we put a Screenshots page on www.darkradiant.net without too much trouble? Allowing access to the whole filesystem is strongly discouraged, but hard to avoid if we want to support arbitrary TDM paths. Would it be reasonable to assume that most people install TDM in their /home directories, or would accept that limitation if they were using the flatpak DR? A couple other side notes: I realized that net.darkradiant.DarkRadiant would be a more accurate package name than com.thedarkmod.DarkRadiant, so anyone who built the test version will want to uninstall it once the flathub version comes out. I had to make an appstream metadata file, ultimately this can go in the main DR repo and will probably need to be updated with the new version number on each release.