-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add artifacts to TRavis for us to download #246
Comments
Hello! |
Do you know of any alternative way to package / distribute a Qt application for Linux? |
Strange, Geary has an AppImage version and works well with plugins. Maybe @b4n, @ecmu, @elextr, @Enrix835, @fusion809 and @codebrainz can explain how. Principally @ecmu built successfully an AppImage-built Geany working with plugins, maybe he/she know better than others and can explain.
Flatpak and Snapcraft. Both are OS-agnostic, build an embed or packaged QT-built application, isolating any non-KDE/non-QT OS, for working on any non-KDE/QT-based OS. @brunob, who built a Snapcraft package for Geany, can explain how to make an Snapcraft-built app working with plugins. |
@gusbemacbe i haven't done it for Geany, just posted some comments about it, but i'm doing it for Timeline here : https://github.com/thetimelineproj/timeline_snap |
A great answer, thank you, I'll look into and hopefully will come up with some distributable package. |
Do you know some Snapcraft yaml which builds a embed or packaged QT-based application with plugins? |
To clarify: plugins in File Commander are .so libraries that are enumerated and loaded dynamically at runtime. |
Inkscape has Flatpak and Snacraft versions, ships with Python plugins. GIMP has also has Flatpak and Snapcraft and ships with DLL, SO and Python plugins. https://snapcraft.io/inkscape https://www.flathub.org/apps/details/org.inkscape.Inkscape As for SO and DLL files, Notepad++ has a Flatpak version and is totally Windows-based and works on any Linux OS. You can check; https://github.com/winepak/applications. |
Interesting, but since I can provide a native Linux application using native APIs, I don't think there's any reason for me to go that way? |
It is up to you. If your application for Linux is still in development, ship your Windows-built application for Flatpak with Winepak until you release a working version for Flatpak and Snapcraft. |
I found the article about the Snacraft KDE/QT-based apps: https://apachelog.wordpress.com/2016/12/02/snapping-kde-applications/ But is old. Check the link at the end.
@bashfulrobot used to build a Krita for Snapcraft, but discontinued. Let me see if he has still an old Krita's yaml file. If you want to build quickly your application for Snapcraft since it is QT-based, check @galgalesh's small tutorial which is the most recent: https://forum.snapcraft.io/t/qt5-and-kde-frameworks-applications/13753 |
It seems that there is a ready built app via AUR: https://aur.archlinux.org/packages/file-commander-git It opens marvelously here on Arch Linux with KDE. But there is an issue, for example, see the comment. I backed a |
Probably a bug of the application itself, need a way to reproduce it. I used to have a virtual machine for Linux development but it doesn't work right now due to my Windows Hyper-V settings. I'll give it a few hours this evening, will see if I can get back to Linux development. I know there's one serious outstanding bug that often makes File Commander unusable on Linux (complains about exhausting file handles). |
I understood what happened. I could not click the folder
If you do not want to install natively Linux on your only drive, you can run Arch Linux or Ubuntu with KDE on WSL. Check two @Biswa96's tutorials: If you have 32 or 64GB USB drive stick, you can install natively Arch Linux or ArcoLinux, KaOS or Kubuntu on it.
It happened with me hours ago. I was compiling, running and building your application with QT Creator, and it froze the whole OS. |
I'm the current maintainer for the Krita snap. We're in the process of switching to the You can find the latest version of the Krita snap manifest here: https://invent.kde.org/merlijnsebrechts/krita/blob/neon-extension/packaging/linux/snap/snapcraft.yaml This will be merged into Krita master when snapcraft 3.9 releases. I recommend using the extension, since it greatly improves startup time, snap size and desktop integration. Plus, it's a lot simpler for the developers of the snap. Let me know if you have any issues, I'm happy to help. |
As written there, can you point me to the build script, build log, and AppImage for test? |
@galgalesh, thanks for the guidance! I'll look into it shortly. |
@VioletGiraffe I am trying to do it from scratch, it may be easier. However, it seems like this requires a compiler newer than the compiler in the oldest still-supported LTS release of Ubuntu. This complicates things. |
@probonopd: does the compiler version itself matter? A newer compiler doesn't automatically require that you use newer glibc, I would think, or am I wrong? |
Flatpak and Snapcraft are ideal for packaging an isolated application with something newer for working on any older versions of Linux distributions dated to 2014 or 2015. For an AppImage to work on any distribution dated to 2014, you have to use any old files. Create and separate two AppImages, one with something older and another with something newer. The AppImage inventor will take one older, but as you are independent, you can release both them in your repository release. |
But nobody will use any distribution which reached the end of life. It is not a good idea that somebody still uses Ubuntu 14.04 whose end of life happened on April 2019 because it will no longer receive security updates. |
Hello @gusbemacbe ! The Krita snap was not discontinued, just moved upstream. 👍 https://snapcraft.io/krita |
A newer C++ compiler usually draws in a newer libstdc++. |
The oldest still-supported LTS release at the moment is 16.04 (xenial), which is only a bit over three years old, and is in wide use (including by myself). |
Even when using c++-7, getting errors: Do you know why? |
Did you git-pull-upstream his repo before? He has just updated. |
Argh, no, getting dreaded merge conflicts... https://github.com/probonopd/file-commander/compare/patch-1...VioletGiraffe:master?expand=1 |
@probonopd : Sorry, I didn't realize my push will mess with your work. As long as you weren't editing the source code itself, your changes should be easy to rebase on top of the new revision, I hope? Either way, I don't think that particular error is solved in the latest revision. It looks like the compiler doesn't support "Template argument deduction for class templates", but GCC 7 supports at least some revision of it: https://gcc.gnu.org/projects/cxx-status.html |
Remove your branches, and create a new branch from the git-pull-upstreamed branch. |
OK, made a new branch, but still getting compile errors: |
@probonopd : I see |
Not sure where it's coming from. This is what I am doing: |
You're using an older Qt version that doesn't understand |
"Older"? 5.10.1 is pretty recent. Which version of Qt is the first that can handle this without fiddling around? (How do I pass in |
I have now upgraded the script to use bleeding edge Qt 5.12.3. |
@probonopd: I think your commit should work. According to StackOverflow, CONFIG += c++17 can be used with Qt 5.12. |
I am giving up. I can't even get this software to compile, so not even an AppImage related issue. Due to too many bleeding edge dependencies. This software seems not to be developed with backward compatibility in mind. |
I'm sorry, don't know why it didn't work with Qt 5.12. No, you shouldn't need both, Qt 5.12 recognizes |
It is why Flatpak and Snapcraft are ideal for packaging an application with something newer and isolating it from the older OSes. |
They do not use the libraries that come with the system. They are working around the problem by adding bloat. The real solution is to develop on the oldest system that you still want to support.
You should consider doing this. Firefox, LibreOffice and other large projects develop for and build on something like CentOS 5, because they care about backward compatibility. If they build on older systems, then it will work on newer systems, but not the other way around. Developing for and building on the newest systems is just a recipe for trouble. Just my 2 cents. Of course you are free to think otherwise, but that is my perspective. If I was developing a Windows app, I would think the same way - never develop for the latest version, but for the oldest still-supported version. |
@probonopd: except on Windows you don't need to actually build on an old version to support this old version. |
Hello @VioletGiraffe !
We would like you add artifacts to Travis for us to download. I refer: https://docs.travis-ci.com/user/uploading-artifacts/
I am a Linux user and want to try @probonopd's AppImage's a canary/nightly version.
The text was updated successfully, but these errors were encountered: