Jump to content

jonri

Member
  • Posts

    146
  • Joined

  • Last visited

  • Days Won

    14

jonri last won the day on September 15

jonri had the most liked content!

Reputation

206 Excellent

Profile Information

  • Gender
    Male
  • Location
    Charlotte, NC

Recent Profile Visitors

1138 profile views
  1. Looks like it's happening for me with 3.3.0 and 3.2.0.
  2. @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.
  3. The Flathub package has been updated, it should be available once their system finishes building it.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. I think I've got this in good shape: Upgraded to the new DarkRadiant release 3.2.0 Icon is now installed correctly Tested wxgtk 3.2.0, it works better than it did before but still found issues (bug report to come tomorrow) so I will keep the flatpak on wxgtk 3.0 for now. Tested on wayland wxgtk-3.0 does not work in native wayland mode, but seems to be ok in xwayland wxgtk-3.2 will likely work natively on wayland once remaining issues are fixed In either case, a user on wayland won't have to worry about it, the flatpak manifest is configured to do the right thing I'll submit this to flathub for review tomorrow.
  12. Thanks for taking a look! I think this is to be expected, flatpak should keep configuration files within the app's sandbox. I think figured out the difference - I normally run in SplitPane layout and this doesn't happen there. I was able to reproduce it in the default layout. It's been surprisingly harder to fix than expected. The directive in the build script that's supposed to do it can't find the original icon. At worst I'll just make a copy of the icon and a new .desktop file to go with it. I should also be able to give it a test on a KDE wayland session.
  13. If anyone is inclined to try out the flatpak by building it locally, here are the steps: Install flatpak and flatpak-builder using your normal package manager. Create a new directory and place the attached com.thedarkmod.DarkRadiant.yml inside of it. In the directory, run `git clone https://github.com/flathub/shared-modules.git`. Run `flatpak install org.freedesktop.Platform//21.08 org.freedesktop.Sdk//21.08`. Run `flatpak-builder --user --install --force-clean build-dir com.thedarkmod.DarkRadiant.yml`. Grab a coffee while you wait for DR and all its dependencies to compile. Launch DarkRadiant from your UI, or run `flatpak run com.thedarkmod.DarkRadiant`. Specifically, I'm interested in: Build issues: this should work pretty universally since it builds against a common SDK, but if the steps above don't work let me know. Runtime issues: this should also run universally, if it doesn't launch then something went wrong. If it runs but you come across a specific feature that doesn't work, let me know and I'll see if we can work around it. If anyone runs Wayland, please let me know either way whether it is working. If not, there are some permissions I should add. Known issues: The flatpak currently can't find the icon. It should just be a matter of getting the build file to copy it to the right place, so I can resolve that easily. This doesn't use flatpak's portals for file access. One of flatpak's advantages is its sandboxing features, but I currently have this app's permissions set to allow the whole filesystem (even so, technically there are some things flatpak still sandboxes away). It would take a some development to use portals for file dialog boxes, the big unknown to me is how to deal with accessing the game directory which could be anywhere. This doesn't prevent us from releasing, but it might be nice to look at in the future. If everything looks good, I'm planning to get this up on flathub this weekend. com.thedarkmod.DarkRadiant.yml
  14. Yes, that was the big one and I responded with more details. There were some other new asserts as well. I updated my flatpak build script with the new DR release this week and re-tested. I'll post the build script and some instructions soon for others to test. From what I can tell, the standard practice is to commit the build script to Flathub instead of the project repo. Once we agree everything looks good I can submit the PR at flathub unless@greebo would prefer to do it.
×
×
  • Create New...