-
Notifications
You must be signed in to change notification settings - Fork 37
Please provide a flatpak through flathub #24
Comments
I've never used Flatpak (or Snap or any of the others) but if people use it then it sounds sensible. For now, though, I'm going to concentrate on the main app and building native packages on OBS. If someone wants to build a Flatpak in the meantime then I'll support where I can. |
This would be a very good step :) |
Thanks to @p1u3o, we've got the starts of a PR to add this. I guess I need to work out how to submit to Flathub. |
Hey @IBBoard Submitting to Flathub is pretty easy. My PR should be good to merge after a few changes which I'll do in a moment. If you're happy with it, I don't mind submitting it to Flathub and getting you added as a mantainer. One thing that would be handy is if the icon name could be the same as the app-id. This means the manifest file doesn't have to rename it and is the practice upstream GNOME apps have adopted. |
Ah, yes, the new "org.gnome.App" approach to icon naming. I hadn't thought about that. Feel free to fix it in your PR as part of the Flatpak changes. I guess you'll need to rename the SVG, the PNGs under hicolor, and the render-icons.sh script. Or I can do it after the merge. |
@IBBoard is there any reason why you're generating pngs instead of just using the svg? |
Because Baedert did it that way, and he was involved in Gnome/GTK? But no, not really. I'm used to PNGs (and despite some artist blogs I've seen saying otherwise, I prefer the Tango icons that were crafted to each size) but if SVG is all we need then we could go pure SVG. |
I don't think the pngs are needed and the svg can dropped into hicolor/scalable but I will leave that and renaming the icon to the app-id up to you. The manifest itself should be good to merge. |
Nothing wrong with generating PNGs, they are faster to load and its not like the space savings matter. |
The convention is now Java package-like "reverse DNS" notation
The convention is now Java package-like "reverse DNS" notation Standardise on capitalisation of existing files
I've updated the app ID and icons. As far as I can tell, that Flatpak config is for building locally, but Flathub wants a tag-based "stable" config? What's the normal practice there - keep this as the Dev one and submit a Production version to Flathub? |
You'll want to make a manifest just for Flathub that lives over there that pulls from a release tag rather than from disk. For each release, you then update the Flathub repository that contains this manifest. I'm out at the moment, but when I get home I'll put something together as well as removing the un-needed gstreamer plugins, unless someone beats me to the punch. |
The latest PR has been merged. I still need to make the official release package, once I work out how it works and what needs to change in the config. |
is there any pre-release we can try out in the meantime? |
There's a config in the repo now. It'll build Git Master, but that's currently stable. I guess that's effectively always a pre-release. Unless Flatpak has some other concept of "pre-release"? |
A Flatpak has been submitted and approved on Flathub. Sorry about the wait. |
Thanks for building and submitting that! I guess I need to work out what needs maintaining now 😄 |
The Flatpak is pretty easy to maintain. For each new release you just need to update the manifest file on the Flathub repository (https://github.com/flathub/uk.co.ibboard.cawbird) to point to that release. Flathub automatically pulls all the app information and update notes from the appdata file. |
https://flathub.org/apps/details/uk.co.ibboard.cawbird is live so you can probably go ahead and close this issue. A lot of GNOME apps have this in their README, if you want to use it. |
Please provide a flatpak through flathub.
CoreBird used to be available this way.
See the archived project https://github.com/flathub/org.baedert.corebird
The text was updated successfully, but these errors were encountered: