Oolite Bulletins

sharpenedblade wrote: ↑Fri May 30, 2025 3:58 am

So it looks for an AddOns dir next to the .app dir?

Yes.

Can pr#515 be merged soon, the last blocker for the flathub package is the appstream metadata. Once the metadata is upstream the pr can be tested according to the flathub merge process.

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

#515 looks mostly good to me.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR

#515 is just metadata for gui software apps, the actual build artifact is in #516.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

768 is what the flatpak docs say to use for desktop only apps. Flatpak doesn't strictly enforce the display length tag so desktops/laptops with smaller screens will still work. The tag actually means that it should not show up as a mobile app. https://docs.flathub.org/docs/for-app-a ... -only-apps

sharpenedblade wrote: ↑Tue Jun 17, 2025 7:20 pm

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR

#515 is just metadata for gui software apps, the actual build artifact is in #516.

Does the 'requires' section need 'display length', and if so, should the (presumably minimum) be as high as 768.

768 is what the flatpak docs say to use for desktop only apps. Flatpak doesn't strictly enforce the display length tag so desktops/laptops with smaller screens will still work. The tag actually means that it should not show up as a mobile app. https://docs.flathub.org/docs/for-app-a ... -only-apps

Thanks for the clarification.

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

The examples in the flathub docs add touch support for all mobile/tablet apps. Mobile flatpak can still install "desktop" apps, they just are not in the mobile section of flathub (edit: actually it will just give you a warning about compatibility, then install it like normal), so if someone does have a keyboard and wants to install the flatpak they still can.

sharpenedblade wrote: ↑Tue Jun 17, 2025 10:12 pm

Do mobile devices need excluding? Surely a mobile device/tablet with e.g. a Bluetooth keyboard would be fine.

The examples in the flathub docs add touch support for all mobile/tablet apps. Mobile flatpak can still install "desktop" apps, they just are not in the mobile section of flathub (edit: actually it will just give you a warning about compatibility, then install it like normal), so if someone does have a keyboard and wants to install the flatpak they still can.

Sweet!

another_commander wrote: ↑Tue Jun 17, 2025 7:32 am

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

Difficult to tell what it does. It adds another build job to the workflow that seems completely independend from everything that is in place already. So I'm wondering how the version calculation would be done, or how the up to date documentation goes in there.

Also there is no build artifact to be inspected.

hiran wrote: ↑Thu Jun 19, 2025 9:23 am

another_commander wrote: ↑Tue Jun 17, 2025 7:32 am

I haven't merged it because I have no say on the Linux builds nor way to confirm the functionality of the PR. Would appreciate one of the Linux guys with access to the project on github making the decision to press the merge button, provided they are good with the contents of the PR.

Difficult to tell what it does. It adds another build job to the workflow that seems completely independend from everything that is in place already. So I'm wondering how the version calculation would be done, or how the up to date documentation goes in there.

Also there is no build artifact to be inspected.

So I went to the source of the PR: https://github.com/sharpenedblade/oolite and checked the Actions tab.
The branch sharpenedblade:add-flatpak-ci has never finished successfully. That would explain why there is no build artifact to look at.

I would not go for a merge at this point.

I made the build job depend on the common-steps job now. The flatpak does not bundle docs because the only place they can go is the flatpak install dir, which is not meant to be accessed by users. I am still working on getting the version info to show up though.

The CI was failing because the git checkout failed because the .gitmodules file used relative URLs, I pushed a commit to temporarily fix that but it needs to be reverted before merging. The CI build-flatpak job passed and uploaded an artifact, but the windows build is failing for some reason. I didn't touch anything that could affect windows so I'm not sure whats happening.

It is a great shame that creating new versions of Oolite is such a pain in the unmentionables for both the AppleMac and Linux.

I know that other games have issues with the AppleMac. But is that also true for Linux?

And, why is Windows so easy?

It is a great shame that creating new versions of Oolite is such a pain in the unmentionables for both the AppleMac and Linux.

GNUstep is basically legacy technology now, and oolite doesn't even work with modern GNUstep and needs an older release to compile. Oolite also has some other legacy dependencies that are shipped as pre compiled object files which makes things weird.

I know that other games have issues with the AppleMac. But is that also true for Linux?

Most modern game engines/libraries are one click to compile for Linux. Packaging on linux is kind of a mess, but its not really a problem for games since they are usually shipped with something like steam that takes care of managing updates. By running in a flatpak (either directly or by being run by a flatpaked app store), host library versions don't even matter that much anymore. And even for games that don't compile on linux, wine is really good and runs almost every game that doesn't explicitly try to block it.