Replies: 5 comments 6 replies
-
|
Hi, question is - is there the actual interest in this? Maybe it is, looking at downloads numbers it seems that on Linux "nowebengine" version is actually MORE used than webengine one. On other operating systems the exact opposite is correct. Linux is specific in that its users are more security-aware and tend to use more secure apps. Given that. It might actually be sensible to produce yet another variant of RSS Guard. There is one more thinking behind this: AppImage build of RSS Guard with Qt 6.3 has some "upstream" bugs and will have for some time to come and I am not happy with that. If flatpak build of RSS Guard works (particularly audio support etc.) I will be glad if you prepared that yaml/repo for it. I guess that would mean I would have to prepare extra "com.github.rssguard.appdata.xml" appstream file in RSS Guard repository, right? As for new "id", I would maybe suggest using "com.github.rssguardlite". |
Beta Was this translation helpful? Give feedback.
-
Good question, but I'm afraid I can't answer it. 😅 I guess my idea is just about having different choices... For instance, I've been exclusively using the WebEngine build since it was first introduced on Flatpak, but the reality is that I don't use it at its full potential: Most of the times, I just double click the entries to read them on my external web browser... :/ But your point about most Linux users preferring the non-webengine build is very telling! And while I agree that the AppImage situation with GStreamer is really unfortunate, if you're thinking about removing it, I'd ask you to really evaluate this decision. Because based on the number of installations for the RSS Guard Flatpak that happened on 2022-10-10, we can stipulate that the number of active users of the Flatpak build it's in the hundreds. I obviously don't have the download numbers for the official AppImage, but you can use this information to determine if removing the AppImage build is a good idea. Don't get me wrong, I'm a very big fan of Flatpak, but a lot of its criticism come from AppImage users, in which they claim "Flatpak apps are bloated". Which is not strictly false, but I think the pros of using Flatpak highly outweighs the cons, and if the cost for that is some extra disk space usage, count me in. 😄 Anyway... I don't have anything prepared right now, and it's quite late in my timezone, so I'll try to work on a new manifest tomorrow.
Good catch! For now, I suppose I can manually modify the app id and add 'Lite' to the existing For example, changing the window title/app name to "RSS Guard (Lite)" to make it obvious for users they're running a stripped-down build of RSS Guard. |
Beta Was this translation helpful? Give feedback.
-
These figures are bit higher than AppImage download stats I have.
Yes, I will "install" proper AppStream XML file depending on "USE_WEBENGINE" flag. I believe that the actual "desktop" file might be the same contents, no? Only with perhaps different name? I will try to make the needed changes today so that you can potentially test with flatpak. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I did some changes. No, different appdata.xml file is deployed but is named the same (I believe I do not have to remove). I tweaked "autostarting" feature to account for "lite" in nonwebengine builds for flatpak. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry for the delay! I finally got to the Flatpak build to a working state, but only after a lot of changes:
All these changes (and a couple of others) are in this quite long patch which, believe or not, I think simplifies some things as well. I didn't send a pull request, because it introduces a breaking change (the autostart feature on Linux will break because now we use a different name for the I created a testing repo here just so I could generate some build artifacts to easily test the build before (maybe) submitting it to Flathub. Speaking of Flathub, this brings us to an important topic: Although the build is passing and the app works, right now it's actually failing to validate the manifest with 4 errors (step "Validate manifest"), and I believe until we fix those, we can't actually submit the app to Flathub. :( My personal opinion on the validation errors:
If you want to test the build I'm working, you can grab the latest artifacts from here: https://github.com/guihkx/flatpak-app-rssguard-lite/actions And then install it with Anyway, that's all I could remember. Let me know if you're still interested in the whole idea or if maybe we should ditch it. 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
Well, this is quite scary. 🗡️ First to mention is that also, we have AppImage build, so that must be taken into account as it needs that fckin appdata XML file too. Maybe, maybe - it would be best to somehow go from "com.github" thing to "io.github" thing? How can we rename the ID for the flat{pak,hub}? Maybe if we decide to fix those validation errors and side things first, then the actual "split" into one extra "lite" app will be more streamforward. Probably better than doing all those steps in a single release? So:
Once we have here, we will have nice/modern Flathub RSS Guard release, then we can go from there and create RSS Guard (lite). This seems best idea because at this point, nobody really complained/asked about the need of extra "lite" RSS Guard, but I understand that having the actual "lite" variant (less libraries deployed, smaller size, arguably smaller memory footprint, increased security) is better for some people than using "-w" CLI switch to disable WebEngine. Maybe you could point me if it is possible to somehow "change" app ID for flathub? I do not really blend into Linux world lately as my life is very hectic (3 kids, demanding wife) and I am so-so able to keep RSS Guard somewhat relevant and bug free. |
Beta Was this translation helpful? Give feedback.
-
I'm pretty sure this change in particular won't break neither the AppImage, nor any Linux distributions that correctly package RSS Guard. I basically just renamed it from
Yeah, I like this idea. We just have to mention in the release notes about the potential breakage of the
That's a good question. I know this can be done, because I've had other Flatpak apps showing me a deprecation warning and pointing me to the newer app. I'm not sure how it's supposed to be done, though. I'd try asking the Flathub people on their Matrix channel, they usually answer me quite fast on non-weekends. If for some reason you can't, just let me know and I'll ask them. And let me know if you have any other questions so I can forward to them.
Sounds like a plan! Since we're doing the split, we could also investigate the possibility of installing This would allow Linux users (and maybe users from other OSes as well?), to have both variants installed simultaneously, for whatever reason... 😄 For example, on Arch Linux, the
It shouldn't be too complicated for you, I think. I did try implementing it, but since my C++ knowledge matches my Dbus knowledge, I didn't go too far...
LOL. Yeah, I can only imagine... Not that my opinion matters or something, but RSS Guard has genuinely been one of my favorite apps in the last couple of years. It's so hard to find a good/lightweight/easy RSS reader these days, so when I found RSS Guard it felt like a blessing. 😄 And knowing that you managed to create/maintain it in your free time, while also taking care of your family, is absolutely amazing! 👌 |
Beta Was this translation helpful? Give feedback.
-
|
OK, I added myself to the matrix. Also, RSS Guard has discord channel (readme) feel free to stay around for faster comm. I would start with that renaming/validations stuff. Then we can move on from there. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Just to be safe, let's wait for a response from the Flathub people about the possibility of renaming |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I just learned it's really easy to deprecate an app on Flathub. We just have to create a file called https://github.com/search?q=org%3Aflathub+%22end-of-life%22&type=code But let's only do it once everything is put together and working. |
Beta Was this translation helpful? Give feedback.
-
|
In an attempt to tackle the autostart issue first, I was investigating how other apps implemented the "RequestBackground" D-Bus permission. I found Crow Translate's implementation (it's licensed under GPL3 as well, so feel free to take a look): https://github.com/crow-translate/crow-translate/blob/d55dac9c8d74cfd34037db88169c2fdd5178dc7c/src/settings/autostartmanager/portalautostartmanager.cpp They handle it pretty nicely: Video_2022-10-29_19-23-49.mp4However, I noticed that there is no way to query the current autostart status of an app, so I'm not sure how you wanna deal with that... |
Beta Was this translation helpful? Give feedback.
-
I was wondering if you'd be interested in having another build of RSS Guard on Flathub, but this one would be built with no QtWebEngine support, and also no bundled NodeJS/npm.
I asked the Flatpak people on their Matrix server regarding the possibility of having two different builds of the same app, and apparently the only way for that to happen, is by submitting a new app, but under a different app id.
Even though it shouldn't be too difficult to maintain another Flatpak build of RSS Guard, I didn't want to impose a maintenance burden on you, so that's why I'm asking if you think that's a good idea or not.
If you think this is a good idea, I can write the new Flatpak manifest for you to submit (or I can submit it myself, if you'd like), which should be very similar to the current one we have anyway. I'd just need ideias for the new app id...
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions