There haven't been any changes in linuxdeployqt in between the two builds you named that could explain the difference in behavior. I suspect that there were some changes in the KDE binary factory build scripts. Where's that code located so we could have a look?
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 31 2019
Jan 29 2019
You can use a system Google test installation by setting -DUSE_SYSTEM_GTEST=ON, IIRC. But it's easier to simply git submodule --init --recursive.
Jan 27 2019
In D18450#400865, @astippich wrote:I am having troubles getting it to build (Kubuntu 18.10). Unfortunately, I could not find pre-build packages for libappimage. I have overcome two small issues in building libappimage, but now I can't get it to work in KFileMetaData because cmake complains that LIBAPPIMAGE_BINARIES is not set. Is that me doing something stupid? Anyway, I cannot test
Nov 27 2018
Yep, it's really nice, thanks @kossebau!
Nov 26 2018
Quoting myself:
AFAIK vnd.appimage resolves to type 2, whereas x-[iso9660-]appimage resolves to type 1. At least that's the MIME data I've been working with all the time so far.
The new logos look great!
Nov 22 2018
@bcooksley sure, as said, a WIP project on my side. I hope people will see the advantages of using linuxdeploy.
@bcooksley it would be nice if you could provide the more modern linuxdeploy, which supersedes linuxdeployqt. It's plugin based (https://github.com/linuxdeploy/awesome-linuxdeploy), providing an extensive framework for plugin developers.
There will be packages for libappimage (hopefully) soon, which provide a .pc file. This provides an alternative to using these generated CMake config files, which can be used through CMake's pkg-config module (find_package(PkgConfig)).
AppImages are, after all, only ELF executables. They're not archives. Using a zipper implies this, though. I really like the initial version that mimics the "normal executable" icon better. The dark blue is quite nice, but I thought perhaps a color from the official AppImage logo might fit better.
Nov 13 2018
@scarlettclark is your (old?) code available somewhere so I could look a bit into it? I'd like to see how much work it'd be to maintain.
@scarlettclark since I'm a passionate Pythoneer, but have no clue about Ruby (I can read most of it, but like with PHP, I try to avoid it as good as I can), I guess we could team up to port your stuff to Python?
@scarlettclark I can provide assistance of course, just let us know what we can help you with. I'd offer to collaborate on developing the scripts for craft or whatever system you use, they might come in handy for non-KDE projects as well. Also, it's always good to see how people use our tools, as we then get an impression how we can improve them.
Sep 17 2018
The AppImage project doesn't do any versioning right now. We've recently extracted libappimage into a separate project to be able to start versioning of it, as projects like KDE expect and somehow need that. We're discussing a suitable versioning scheme right now. Please feel free to participate in the discussion in https://github.com/AppImage/AppImageKit/issues/849, and add your point of view.
Sep 11 2018
Aug 27 2018
@michaeltunnell that's a great idea to generally improve the UX with AppImages or, even better, all ELF files. Then, one of the issues https://github.com/TheAssassin/AppImageLauncher tries to solve is already solved upstream, at least for KDE.
Aug 22 2018
Looks good to me. I'm not a KDE expert and can't tell much about that, but the AppImage part is perfectly fine. At some point, the temporary file should be replaced by some in-memory file buffer. See https://github.com/AppImage/libappimage/issues/1 for reference.
Aug 16 2018
About the only tricky problem we might have is getting newer versions of dependencies like Qt in an older distribution like CentOS 6 or Ubuntu 14.04 but if those end up being an issue we can always compile those ourselves as part of the image build process if a PPA or equivalent is not available.