kdelibs4support/kfiledialog causes crashing
Hello all,
I found a bug in kdelibs4support/kio/kfiledialog but can't quite work
out where to file it in the bugtracker so I'll describe it here.
In short, some functions do not check whether d->native is non-null
before calling a method belonging to the file chooser widget d->w.
However, d->w is only set if d->native is null, so if this is not the
case then the application crashes. This issue manifested on a windows
build of kf5/okular by the application crashing in
KFileDialog::setMimeFilter. However, I see that there are another
half-dozen or so functions that have the same problem.
In any case I made the following patch and confirmed that with it okular
can open files without crashing:
--- a/src/kio/kfiledialog.cpp
+++ b/src/kio/kfiledialog.cpp
@@ -326,8 +326,6 @@ QString KFileDialog::currentFilter() const
void KFileDialog::setMimeFilter(const QStringList &mimeTypes,
const QString &defaultType)
{
-d->w->setMimeFilter(mimeTypes, defaultType);
-
if (d->native) {
QString allExtensions;
QStringList filters = mime2KdeFilter(mimeTypes, &allExtensions);
@@ -336,6 +334,8 @@ void KFileDialog::setMimeFilter(const QStringList
&mimeTypes,
}
d->native->filter = filters.join(QLatin1String("\n"));
}
+else
+d->w->setMimeFilter(mimeTypes, defaultType);
}
Presumably all the other functions that do not currently test d->native
should be made to do so.
Cheers,
Jonathan
Quick and dirty packaging
Hello all, I'm looking for some guidance or suggestions about some way to build a KDE application (more precisely a personal fork of okular) so that someone else with a reasonably similar system (x86_64 Linux) can use it without having to install extra packages, or otherwise mess with their installation. I've tried two ways so far but hit the wall in both cases: 1. Doing a static build (by including the line "cmake-options -DBUILD_SHARED_LIBS=FALSE") in my kdesrc-buildrc file. This builds a few packages but then produces a cmake error when building kconfigwidgets: CMake Error at src/CMakeLists.txt:21 (add_library): Target "KF5ConfigWidgets" links to target "Qt5::X11Extras" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? I've tried investigating but find cmake pretty hard to debug. Why does that add_library command work when building shared libraries but not static libraries - I guess it's something to do with intelligently choosing between shared and static libraries, but what to do next? 2. Doing a normal shared build and packaging all the required libraries with the executable. This hits the wall when I need to package a different version of libc.so.6, which then gets messed up with the native version of the same file and makes the shell segfault. I guess I could build in a docker container, but that would require my non-developer friend to install docker which might just be enough to make him lose interest... Any other suggestions would be most welcome! Cheers, Jonathan
Re: Quick and dirty packaging
Thank you for the help. I have confirmed that my static Qt5 build includes Qt5X11Extras, that is the file libQt5X11Extras.a is present in /lib But I still get the cmake error. I tried using strace to see what files cmake looks for, and rather surprisingly found: 1. no references to anything that looked like libQt5X11Extras.a and 2. looking for other Qt5 libraries in /usr/lib/x86_64-linux-gnu/ and not in the specified in by kdesrc-buildrc. I tried running cmake manually, adding -DQTDIR= and still nothing changed. So it seems that kdesrc-build and/or the cmake scripts are ignoring the value of qtdir. Is that possible? Or am I missing something? And is there a simple work-around? Jonathan On 24/01/18 11:41, Michael Pyne wrote: On Wed, Jan 24, 2018 at 10:18:32AM +0800, Jonathan Schultz wrote: Hello all, I'm looking for some guidance or suggestions about some way to build a KDE application (more precisely a personal fork of okular) so that someone else with a reasonably similar system (x86_64 Linux) can use it without having to install extra packages, or otherwise mess with their installation. I've tried two ways so far but hit the wall in both cases: 1. Doing a static build (by including the line "cmake-options -DBUILD_SHARED_LIBS=FALSE") in my kdesrc-buildrc file. This builds a few packages but then produces a cmake error when building kconfigwidgets: CMake Error at src/CMakeLists.txt:21 (add_library): Target "KF5ConfigWidgets" links to target "Qt5::X11Extras" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? I've tried investigating but find cmake pretty hard to debug. Why does that add_library command work when building shared libraries but not static libraries - I guess it's something to do with intelligently choosing between shared and static libraries, but what to do next? I think this is just a problem with a missing static-compiled version of Qt5X11Extras. If you don't have a static Qt then I would think you would have run into error messages earlier though. If you compiled your own Qt to make a static version of it then you may have missed that Qt5X11Extras is part of a separate module, it's not part of the qtbase repository. non-developer friend to install docker which might just be enough to make him lose interest... Any other suggestions would be most welcome! There are various technologies out there to try to solve distribution of application binaries on Linux without a full-blown container infrastructure like Docker, including FlatPak, Snappy, and AppImage. I've never used any of those however and so I'm not sure how easy it is to use, but something in that category seems like the best bet IMHO. Regards, - Michael Pyne
How to kdesrc-build a specific release?
Hello, Sorry for cross-posting, but 10 days after posting this on the 'KDE Frameworks & Development' forum I've had no response so trying again here: I have a quick question about kdesrc-build. Can I use it to build a specific KDE release/tag, or at least a consistent stable release? The branch-group stable-kf5-qt5 seems to use bleeding edge source code. The 'tag' option seems to need to be specified separately for each module. In fact the kdesrc-build manual states that you should use tarballs instead of 'tag', which would be fine if I could figure out how to make those tarballs work with kdesrc-build. Is there something I am missing here? Thanks
Troubles with icon themes
Hello KDE developers,
I wonder if someone can help me work out what is going on here.
I have build some KDE applications (konsole and okular) from source using
kdesrc-build, using QT5 version 5.11.3 also built from sources. The
applications build and run, but do not load the icons used in the UI. I have
the following lines in ~/.config/kdeglobals:
[Icons]
Theme=oxygen
and running strace on the application reveals that it is finding and crawling
the oxygen icon theme directories. However, if I rename the oxygen theme
directory to hicolor then the application does find the icons correctly.
I have written a trivial Qt test, using 'QIcon::setThemeName("oxygen")' to set
the theme and it works fine.
I also note that kiconfinder5 also finds the icons in the oxygen directory.
I've tried some reverse-engineering/debugging but succeeded only in getting
lost in the code.
One thing I suspect it that the problem might be related to my development
environment, which is a sandboxed Docker container with no display manager
installed. I understand that KDE tries to work out what icon theme is already
in use by an installed display manager, so perhaps this environment is somehow
triggering some unexpected (by me at least) behaviour.
Thanks as always.
Jonathan
Re: Troubles with icon themes
Your application is in docker, so it won't pick up your ~/.config/kdeglobals, that is outside docker how would it be picked up? Or you mean you ~/.config/kdeglobals is also inside your docker container? Yes, inside the docker container. I've confirmed with strace that the file is opened and read, and it also affects the fact that the app crawls the correct theme directories. Cheers, Jonathan
Re: Troubles with icon themes
By any chance, is the environment variable XDG_CURRENT_DESKTOP set when applications are launched within the Docker container? If not, it probably should be set to 'KDE' otherwise the appropriate QPA won't be loaded and you won't get any icons loaded (as the theme won't be known to the application) No it wasn't set (only using the generated kde-env-master.sh). But I tried setting XDG_CURRENT_DESKTOP manually to KDE and saw no difference. Moreover, I can confirm with strace that ~/.config/kdeglobals is read (whether or not XDG_CURRENT_DESKTOP is set), and its contents also affect which icon theme directories are crawled, ie 'oxygen' or 'breeze'.
Building KDE statically
Hello KDE developers, If anyone is interested, here is a brief report on something I have been working on in my spare time. TLDR: Here are some scripts to build KDE frameworks and okular statically using gcc/musl and cross-building for mingw: https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see the interesting stuff. I've been working on an application based largely on okular that I would like to be able to deploy as simply as possible for users with no technical expertise. For this purpose, and despite its well-known down-sides I thought that a static build would be helpful. So I started building KDE frameworks and other okular dependencies using kdesrc-build and working out what would need to change to make a static build. It turned out to be more painstaking but less complicated than I had imagined. It all happens inside Docker containers built on voidlinux, which I chose because it handles musl natively and has a build process simple enough for me to understand. No doubt there are good reasons to use a different Linux distro but so be it. Most of the patches are simply to make CMake handle static dependencies. A few deal with ad hoc issues that arose out of static building. The most complicated was linking okular's plugins statically, which involved a bit of build hacking, but nothing too dreadful (IMHO). I've made all the patches backwards-compatible, ie they have no effect on a conventional build using shared libraries. I took some shortcuts in working out which static libraries to include, ie basically all libraries are included on all link operations, and we count on the linker to leave out those that aren't required. I also put in some cross-building stuff. Since kdesrc-build seems not to do a good job with host applications required for the building process, I just pre-built those and put the executables in the repository. Not all of frameworks cross-builds, but enough to link okular does. What it produces: An static okular executable with the following generator plugins: poppler, kimgio, dvi, tiff, xps, ooo, fb, comicbook, fax, plucker, txt is about 88MB in size. I understand that this might be reduced, possibly by as much as 80%, by using Link-Time Optimisation (LTO). Even as it is, it starts and runs noticeably faster than a conventional build. Cross-building, a mingw32 okular.exe is around 58MB and a mingw64 73MB. Still some problems: it can't save files because (if I understand correctly) kio uses slave processes that are also based on plugins which would need to be linked statically. What's next: Cross-building for MacOS. Using craft instead of kdesrc-build. So feel free to hit me up with suggestions, interest or if anyone is interested in incorporating any of this into the mainline of KDE development. Cheers, Jonathan
Re: Building KDE statically
Thanks I will take your suggestion and post this to frameworks-devel. I'll also put a quick note on okular-devel since okular is my target application for doing all this. Cheers, Jonathan On 26/2/19 6:57 am, Albert Astals Cid wrote: El divendres, 22 de febrer de 2019, a les 4:57:42 CET, Jonathan Schultz va escriure: Hello KDE developers, If anyone is interested, here is a brief report on something I have been working on in my spare time. Since at least part of this involves frameworks, you may want to send this to the frameworks devel mailing list. Maybe you get some more answers/traction there. Cheers, Albert TLDR: Here are some scripts to build KDE frameworks and okular statically using gcc/musl and cross-building for mingw: https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see the interesting stuff. I've been working on an application based largely on okular that I would like to be able to deploy as simply as possible for users with no technical expertise. For this purpose, and despite its well-known down-sides I thought that a static build would be helpful. So I started building KDE frameworks and other okular dependencies using kdesrc-build and working out what would need to change to make a static build. It turned out to be more painstaking but less complicated than I had imagined. It all happens inside Docker containers built on voidlinux, which I chose because it handles musl natively and has a build process simple enough for me to understand. No doubt there are good reasons to use a different Linux distro but so be it. Most of the patches are simply to make CMake handle static dependencies. A few deal with ad hoc issues that arose out of static building. The most complicated was linking okular's plugins statically, which involved a bit of build hacking, but nothing too dreadful (IMHO). I've made all the patches backwards-compatible, ie they have no effect on a conventional build using shared libraries. I took some shortcuts in working out which static libraries to include, ie basically all libraries are included on all link operations, and we count on the linker to leave out those that aren't required. I also put in some cross-building stuff. Since kdesrc-build seems not to do a good job with host applications required for the building process, I just pre-built those and put the executables in the repository. Not all of frameworks cross-builds, but enough to link okular does. What it produces: An static okular executable with the following generator plugins: poppler, kimgio, dvi, tiff, xps, ooo, fb, comicbook, fax, plucker, txt is about 88MB in size. I understand that this might be reduced, possibly by as much as 80%, by using Link-Time Optimisation (LTO). Even as it is, it starts and runs noticeably faster than a conventional build. Cross-building, a mingw32 okular.exe is around 58MB and a mingw64 73MB. Still some problems: it can't save files because (if I understand correctly) kio uses slave processes that are also based on plugins which would need to be linked statically. What's next: Cross-building for MacOS. Using craft instead of kdesrc-build. So feel free to hit me up with suggestions, interest or if anyone is interested in incorporating any of this into the mainline of KDE development. Cheers, Jonathan
