Darkradiant install with Flatpak? (Linux)

[datiswous]

20 hours ago, jonri said:

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?

Why is it not possible to give access to other places than home (mounted partitions)?

[jonri]

4 hours ago, datiswous said:

Why is it not possible to give access to other places than home (mounted partitions)?

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.

[Neko-san]

Flatpak has a default install location though, why would it even be necessary to give it access to the non-default location at all?

To my understanding, leaving the install paths where they are is part of the point with flatpak: it isn't meant to be tampered with or moved by users. That said, running the binaries directly by encouraging the old execution process (./example-executable or double-clicking) isn't how we want users to do this anyway because it could bypass the flatpak sandbox.

I think the solution here would be to just include a .desktop file with the game, but do correct me if I'm misunderstanding something Lol

[jonri]

5 hours ago, Neko-san said:

Flatpak has a default install location though, why would it even be necessary to give it access to the non-default location at all?

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.

 

[Neko-san]

Quote

but rather being able to access the TDM game files in whatever arbitrary location the user has installed them

Why would any of the game files be in an arbitrary location if all the files should be where you expect them?

They shouldn't be anywhere else; for that, why even bother making that a concern for supporting with Flatpak at all?

[jonri]

1 hour ago, Neko-san said:

Why would any of the game files be in an arbitrary location if all the files should be where you expect them?

They shouldn't be anywhere else; for that, why even bother making that a concern for supporting with Flatpak at all?

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.

[Neko-san]

Sorry, I misinterpreted the topic; I thought we were dicussing a TDM Flatpak and missed that this was actually a discussion about Darkradiant

[jonri]

On 9/9/2022 at 10:35 PM, jonri said:

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?

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.

Edited September 13, 2022 by jonri

[OrbWeaver]

If, hypothetically speaking, a future FlatPak containing the game itself were to be created, would this be an easier problem to solve? Or is linking between FlatPak directories just as hard as gaining access to an arbitrary directory?

[jonri]

40 minutes ago, OrbWeaver said:

If, hypothetically speaking, a future FlatPak containing the game itself were to be created, would this be an easier problem to solve? Or is linking between FlatPak directories just as hard as gaining access to an arbitrary directory?

I think it would actually make things harder...

[jonri]

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.

[datiswous]

I installed the Flatpak version via my disto (Manjaro) package manager without problem. I think it should state: 3D level editor for The Dark Mod and Doom 3, instead of the other way around.

Originally DR takes over the system theme that is selected. So in my case the dark theme, but with the Flatpak install, only the light theme is used. It doesn't take over the system theme. Is there a way to force the system theme? I guess using the light theme does have the benefit of good looking icons.

Edited September 21, 2022 by datiswous

[jonri]

22 minutes ago, datiswous said:

I think it should state: 3D level editor for The Dark Mod and Doom 3, instead of the other way around.

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.

24 minutes ago, datiswous said:

Is there a way to force the system theme?

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.

[datiswous]

Maybe it's early, but wouldn't it be good if this info is shown on https://www.darkradiant.net/ as an installation option? Otherwise we're the only ones using it.

[jonri]

On 9/28/2022 at 6:04 PM, datiswous said:

Maybe it's early, but wouldn't it be good if this info is shown on https://www.darkradiant.net/ as an installation option? Otherwise we're the only ones using it.

Done!

[Ludvig]

On 9/13/2022 at 4:16 PM, jonri said:

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.

Hey! Have you had a chance to try this with the flatpak manifest I'm working on? I'm curious if one flatpak app can access another's dir in ~/.var or if it's completely disabled. If it's the latter, we need to change the default installation path in the darkmod flatpak:

 

[jonri]

10 hours ago, Ludvig said:

Hey! Have you had a chance to try this with the flatpak manifest I'm working on? I'm curious if one flatpak app can access another's dir in ~/.var or if it's completely disabled. If it's the latter, we need to change the default installation path in the darkmod flatpak:

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.

[datiswous]

Every time I install the DR flatpack version it downloads an amount of different nvidia GL runtimes, but I already found out I only need one and the rest is just wasted storage. What is the reason for that?

Edited February 5, 2023 by datiswous

[jonri]

I doubt it's something on our end, as we just tell flatpak that we need OpenGL support and it's supposed to figure out the rest.  I'll see if I can read up on it a little though.  Flatpak has many advantages, but storage space efficiency is not one of them.

[Ludvig]

Yeah, that's something that flatpak does, and only for nvidia since the driver isn't fully open source. Basically flatpak checks what version of the driver your system is using and tries to install a corresponding version for the runtime. These need to match for hardware acceleration to work within flatpak.

You can see if you have any old nvidia runtimes that can be removed by running

flatpak remove --unused

 

[datiswous]

2 hours ago, Ludvig said:

You can see if you have any old nvidia runtimes that can be removed by running

flatpak remove --unused

This info should go in the topic post I think. Works really well.

[Ludvig]

9 hours ago, datiswous said:

This info should go in the topic post I think. Works really well.

Yeah that might be a good idea, but it's not something specific to this package.