Open beankylla opened 5 months ago
Hi @beankylla, Thanks a lot for opening this issue. Yes, we are aware that using Flatpak would be a lot more convenient for the Linux users and this have been in our backlog for quiet some time now. Unfortunatly, we never had time so far to do it. PS: all PR are welcome ;)
I join the call for the packaging of kDrive as flatpak... also directly as a direct replacement for the appimage
I’m going to go against the grain, but I think it would be better to opt-out from those packagers and just provide a « classic » binary build. If anyone then wants to package the app as a Flatpack, a Snap or an AppImage, that’s up to them.
I attempted this a while ago: https://github.com/eylenburg/kdrive-flatpak
However, I failed to get the tray icon to show up on KDE Plasma and while the tray icon appeared on Ubuntu Desktop you can't click on it.
I’m going to go against the grain, but I think it would be better to opt-out from those packagers and just provide a « classic » binary build. If anyone then wants to package the app as a Flatpack, a Snap or an AppImage, that’s up to them.
in terms of portability it's not really interesting is it?
in terms of portability it's not really interesting is it?
Indeed, building a plain binary isn’t very portable.
But since you already can build the binary, there isn’t much hassle to turn it into a flatpak as an additional step for those out there who want that. And you still allow users who just want a binary to enjoy the application. My point is: don’t force users to use one packaging format over another, be flexible.
At least that’s my opinion. But I might be biased since I like to « build the world » (read: build everything from sources)…
I attempted this a while ago: https://github.com/eylenburg/kdrive-flatpak
However, I failed to get the tray icon to show up on KDE Plasma and while the tray icon appeared on Ubuntu Desktop you can't click on it.
@ClementKunz could you possibly use this ? :-)
or @eylenburg could you pr this to the kdrive repo? i mean if the version is working and there are slight issues with the icon this is acceptable territory for me ;)
I attempted this a while ago: https://github.com/eylenburg/kdrive-flatpak However, I failed to get the tray icon to show up on KDE Plasma and while the tray icon appeared on Ubuntu Desktop you can't click on it.
@ClementKunz could you possibly use this ? :-)
or @eylenburg could you pr this to the kdrive repo? i mean if the version is working and there are slight issues with the icon this is acceptable territory for me ;)
It's unusable without the icon though because I don't think there's any other way to access the UI?
Hi @eylenburg, Thank you for the time you put into your kdrive-flatpak repo!
It's unusable without the icon though because I don't think there's any other way to access the UI?
This might not be very practical for daily usage, but as a tip, if you start kDrive with --synthesis
(while kDrive is already running), it will act as if you clicked the kDrive icon.
However, I agree with you that it is almost unusable, therefore can't be merged into kDrive as it stands.
PS:
been in our backlog for quite some time now. Unfortunately, we never had time so far to do it.
Unfortunately, we still haven't had time so far to plan it.
+1 Flatpak available on Flathub would be so great
Note: Please write your issue only in english
Is your feature request related to a problem? Please describe. The golden standard of packaged application in linux is Flatpak. All new distros use flatpak. Flatpak is also integrated into distro "app stores". This would enable update to be done automatically vs the current manual updates needed with the appimages (beneficial also for devs they would see way quicker updates ;))
Having kdrive available on flathub is also a source of visibility and will potentially lead to new customers that are FOSS fans.
Describe the solution you'd like to implement Kdrive should be available as a flatpak, optimally on flathub
Describe alternatives you've considered I'm running the appimage now, because i don't have a choice :)
Additional context fully available to test if needed