Add artifacts to TRavis for us to download

[gusbemacbe]

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.

[VioletGiraffe]

Hello!
I was very excited about linuxdeployqt when I found out about it, and gave it a thorough try. It works for the main executable, but there was no way to bundle the plugins as well. See #187, that issue refers to two linuxdeployqt issues - both still open. I didn't see it fit to provide a half-working artifact, Linux user experience is sufficiently full of misery already.

[VioletGiraffe]

Do you know of any alternative way to package / distribute a Qt application for Linux?

[gusbemacbe]

and gave it a thorough try. It works for the main executable, but there was no way to bundle the plugins as well.

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.

Do you know of any alternative way to package / distribute a Qt application for Linux?

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.

[brunob]

@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

[VioletGiraffe]

A great answer, thank you, I'll look into and hopefully will come up with some distributable package.

[gusbemacbe]

@brunob

Do you know some Snapcraft yaml which builds a embed or packaged QT-based application with plugins?

[VioletGiraffe]

To clarify: plugins in File Commander are .so libraries that are enumerated and loaded dynamically at runtime.

[gusbemacbe]

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://snapcraft.io/gimp

https://www.flathub.org/apps/details/org.inkscape.Inkscape
https://www.flathub.org/apps/details/org.gimp.GIMP

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.

[VioletGiraffe]

As for SO and DLL files, Notepad++ has a Flatpak version and is totally Windows-based and works on any Linux OS

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?

[gusbemacbe]

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.

[gusbemacbe]

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.

• Kate, which comes with plugins: https://snapcraft.io/kate
• Krita, which comes with plugins: https://snapcraft.io/krita

@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

[gusbemacbe]

@VioletGiraffe

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 .tar.gz up and uninstalled your applications. I extracted to Applications/Sources. It worked marvelously. But it does not recognise other drives. At sometimes, there is a bug – I can not click twice the directory and am stuck in the root directory.

[VioletGiraffe]

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).

[gusbemacbe]

Probably a bug of the application itself, need a way to reproduce it.

I understood what happened.

I could not click the folder /home/my_username, because this folder is mounted by another drive not recognised by your application. And I could click twice any of root directories, except the folder home and opt which are mounted by drives. It also does not recognise my Windows partitions of an SSD m.2 228 with USB enclosure.

I used to have a virtual machine for Linux development but it doesn't work right now due to my Windows settings.

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:

1. Arch Linux on WSL
2. Installing KDE

If you have 32 or 64GB USB drive stick, you can install natively Arch Linux or ArcoLinux, KaOS or Kubuntu on it.

I know there's one serious outstanding bug that often makes File Commander unusable on Linux (complains about exhausting file handles).

It happened with me hours ago. I was compiling, running and building your application with QT Creator, and it froze the whole OS.

[merlijn-sebrechts]

I'm the current maintainer for the Krita snap. We're in the process of switching to the kde-neon snapcraft extension, which I expect to be released this or next week.

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.

[probonopd]

I was very excited about linuxdeployqt when I found out about it, and gave it a thorough try. It works for the main executable, but there was no way to bundle the plugins as well. See #187,

As written there, can you point me to the build script, build log, and AppImage for test?

[VioletGiraffe]

@galgalesh, thanks for the guidance! I'll look into it shortly.
@probonopd : I did that already, you asked me to mail a faulty Appimage to you and I have done so. I no longer have the build script or the appimage file, I'd need to start from scratch. Also, this issue discusses the same problem/question I have but no solution on how to actually achieve the desired result was given (as far as I could see, at least).

[probonopd]

@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.

[VioletGiraffe]

@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?
Looks like GCC 7 is the oldest one that would work, GCC 5 and 6 are missing a couple important C++17 features.

[gusbemacbe]

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.

[gusbemacbe]

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.

[bashfulrobot]

Hello @gusbemacbe ! The Krita snap was not discontinued, just moved upstream. 👍 https://snapcraft.io/krita

[probonopd]

@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?

A newer C++ compiler usually draws in a newer libstdc++.

[probonopd]

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

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).

[probonopd]

Even when using c++-7, getting errors:
https://travis-ci.com/probonopd/file-commander/builds/135835131

Do you know why?

[gusbemacbe]

Even when using c++-7, getting errors:
travis-ci.com/probonopd/file-commander/builds/135835131

Do you know why?

Did you git-pull-upstream his repo before? He has just updated.

[probonopd]

Argh, no, getting dreaded merge conflicts... https://github.com/probonopd/file-commander/compare/patch-1...VioletGiraffe:master?expand=1

[VioletGiraffe]

@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
What are you supplying for -std? I have -std=c++17 specified in the .pro files, but GCC 7 may not yet support c++17. Try -std=c++1z and -std=gnu++1z.

[gusbemacbe]

Argh, no, getting dreaded merge conflicts... https://github.com/probonopd/file-commander/compare/patch-1...VioletGiraffe:master?expand=1

git clone https://github.com/yourusername/file-commander
git checkout master
git remote add upstream https://github.com/VioletGiraffe/file-commander
git pull upstream master 
git push

Remove your branches, and create a new branch from the git-pull-upstreamed branch.

[probonopd]

OK, made a new branch, but still getting compile errors:
https://travis-ci.com/probonopd/file-commander/builds/135838648

[VioletGiraffe]

@probonopd : I see -std=c++11 in the compiler flags, that's definitely not right. The feature it needs in order to compile is from C++ 17.

[probonopd]

Not sure where it's coming from. This is what I am doing:
https://github.com/probonopd/file-commander/blob/patch-2/.travis.yml

[VioletGiraffe]

You're using an older Qt version that doesn't understand CONFIG += c++17. You need to manually specify in each .pro file: QMAKE_CXXFLAGS += -std=c++1z

[probonopd]

"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 QMAKE_CXXFLAGS without touching any files but .travis.yml?)

[probonopd]

I have now upgraded the script to use bleeding edge Qt 5.12.3.

[VioletGiraffe]

@probonopd: I think your commit should work. According to StackOverflow, CONFIG += c++17 can be used with Qt 5.12.
Qt is very slow to add out-of-the-box support for new C++ standards.

[probonopd]

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.
Does not work with "QMAKE_CXXFLAGS += -std=c++1z", also does not work with Qt 5.12.3.
or are you saying that I need to use both?

This software seems not to be developed with backward compatibility in mind.

[VioletGiraffe]

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 CONFIG+=c++17 which is what is already specified in the .pro files. I constantly watch that my projects can be built from repository with a single click, but no, I'm definitely not consciously targeting outdated libraries and compilers.

[gusbemacbe]

I constantly watch that my projects can be built from repository with a single click, but no, I'm definitely not consciously targeting outdated libraries and compilers.

It is why Flatpak and Snapcraft are ideal for packaging an application with something newer and isolating it from the older OSes.

[probonopd]

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.

I'm definitely not consciously targeting outdated libraries and compilers.

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.

[VioletGiraffe]

@probonopd: except on Windows you don't need to actually build on an old version to support this old version.
As for the issue at hand: I installed gcc-7 and g++-7, which resulted in 7.4.0, and successfully used it built file-commander from repository with no edits (with Qt 5.15.5). I don't understand why it didn't work for you. Perhaps, your GCC 7 is older than 7.4.0? 7.3 would also work, I think.