Archive
Learnings from Building an AppImage
For some time I am offering an AppImage of Kraft to make installations for users as easy as possible. Unfortunately real linux packages are big effort for the variety of distributions, and having one way to rule them all seems very appealing.
My first AppImage versions were pretty faulty when looking into details. So I spent some time to improve it recently, with the great help of the friendly people from AppImage community.
Here is my little report about what I have learned. If there is something I can do better, please let me know (unless it is use $OTHERTOOL).
How to build an AppImage?
At first, it makes sense to build the AppImage automatically via Github Actions. GH Actions are powerful, and well integrated. I also looked into using the openSUSE Buildserver for that, which works, but Github Actions seemed easier.
I got convinced by @TheAssasin to use AppImageCraft to build the image. That simplifies the process significantly by hiding a lot of auto generating things under the hood. While that leads to very clean and short config files for the AppImage build, it is harder to deal with issues that might come up because things are covered.
If I would not have had help from the dev that I know personally, I probably would not have survived the process. Yet, AppImageCraft is an awesome utility, yet a bit better documentation would help a lot.
Python Components
Kraft has a few Python components that are called from Kraft to do specialized tasks that I did not want to reimplement in C++. For example, it uses the awesome tool weasyprint to generate PDF from html.
While the AppImage can call a weasyprint installation that is installed on the host system that is not a good solution as there is no way to control if the required tool is really installed. So bundled Python is needed with all the dependencies for the external deps.
To achieve that, there is a very useful linuxdeploy-plugin called conda that uses conda to install Python. It installs the required python libs via pip and make them available in the bundle. Very convenient.
Pathes
To be a good citizen in the AppImage world, the app needs to be careful with pathes. When running in the AppImage, it is advisable to not use for example classes like QStandardPath directly or even worse hardcode paths that do any loading of files the app needs. Since the file tree of the AppImage is just mounted somewhere in the host system, the app needs to consider that it is not installed in standard locations.
A good rule of thumb when locating a file to load is to always check relative to the binary path first (ie. ../share/kraft/data/), and if that does not exist, continue to check the standard paths of the host system.
In Kraft there were already utility methods to adjust paths which I could simply extend to work fine in the AppImage. Still, that is kind of fiddly as there are more places to consider than one expects.
Locate translation files
Also a result of the challenge described before is that the app did not find the translation files to load in the filesystem of the AppImage. The translation system (KLocalizedString in Kraft) does obviously not check the correct path inside the AppImage mount.
Setting an additional relative path to look up translations at runtime fixes that problem.
Icons
Another issue that required quite some work were icons. Kraft used icons from the system theme quite a lot. As long these are installed, because the user has the same fitting desktop environment, that is not an issue, and icons are found.
However, if the icon theme is not installed, the app just lacks icons which make it bad looking or even hard to use.
That can be solved by using own icons as fallback in the app. For simplicity and consistency I switched to a complete set of own icons that are now coming with Kraft. They are bundled to the app with the Qt resource system now.
Dependencies to the Outside
Last but not least: When preparing an app for AppImage it needs to be checked if the app has binary dependencies that can (or should) not be packaged into the AppImage for efficiency reasons. Kraft for example uses Akonadi for contacts. With that users can use KAddressbook to manage addresses and Kraft uses the address lists via Akonadi. Life is too short for reinvention of an Addressbook.
Of course one could think of bundling the entire Akonadi and KAddressbook into the AppImage of Kraft. But that seems overkill, as that would mean bundling a lot of stuff, and would bring KDE users two instances of KAddressbook (the one from their desktop installation and the one from the AppImage). Seems not a good idea.
So this seems to be the only downside of the new Kraft AppImage now: It can not use the Akonadi based address management. To fix that, there needs to be a non binary dependant way. There could for example be a way to sync contacts to a local file system and let Kraft pick them up from there. That way, users could use the address management they want (also for example google) and Kraft could still pick addresses from there. That needs more thoughts.
The good news on this that Kraft is still fully functional as the Akonadi integration is great, but optional.
Summary
An AppImage seems to be a great way of distributing desktop applications, because there is only one build to run on all distributions. Well, fingers crossed…
However, building an AppImage that really works flawlessly is not a simple task, as this blog hopefully illustrates a bit.
One thing would have helped me: A simple option to understand when the app loads things from the host system, rather than from within the AppImage, for example as commnd line switch when running the AppImage. That would have eased the path adjustment development described above.
What is next in that area: User friendly updating of the AppImage and a solution to the address management problem.
All changes were merged in Kraft master today, the resulting AppImages can be found here.
PDF Quirk Version Update
The good thing about this quiet holidays is that there is time to work on projects. I had a few nice changes of PDF Quirk laying around, and now finalized them to a new version. Please welcome PDF Quirk version 0.95!
What is PDF Quirk?
PDF Quirk is a little desktop utility to create PDF files from images, targeted to non nerdy desktop users.
Sending PDFs is (still) often a requirement in offices where people are asked to transfer PDF files via email, or better by pushing them through their private ownCloud.
The source images can either be loaded from file, or directly scanned with an hardware scanner. For that, PDF Quirk utilizes the tool scanimage from the SANE Projekt, to avoid reinventing the wheel. Configured once, that works like a charm.
Having scanned or picked the source images, they can be deskewed, turned and rearranged, and finally converted to a good quality PDF file with reasonable file size.
New Version 0.95
The new version brings a few features and some fixes:
- Images can deskewed now
- Basic PDF options like margin, paper size and orientation can be set
- The UI got a little cleanup
- Translations were added, first new language is German
- Dependencies were reduced, new Qt based PDF generator was implemented
- Builds with Qt5 and Qt6
Interested?
Check out PDF Quirks Website for more information.
PDF Quirk is free software. Please contribute through the Github repository.
ownClouds Virtual Files on the Linux Desktop
it could already be read somewhere that 2021 will be the year of Linux on the desktop 😀
Fine with me. Just to support that, I did a little hackery over XMas to improve the support for ownClouds virtual file system on the Linux Desktop.
What are Virtual Files?
In professional usecases, users often have a huge amount of data stored in ownCloud. Syncing these completely to the desktop computer or laptop would be too much and costly in bandwidth and harddisk space. That is why most mature file sync solutions came up with the concept of virtual files. That means that users have the full structure with directories and files mirrored to their local machines, but have placeholder of the real files in the local file manager.
The files, however, are not on the disk. They get downloaded on demand.
That way, users see the full set of data virtually, but save time and space of files they never will need on the local system.
The ownCloud Experience
ownCloud has innovated on that topic a while ago, and meanwhile support virtual files mainly on Windows, because there is an elaborated system API to work with placeholder files. As we do not have this kind of API on Linux desktops yet, ownCloud desktop developers implemented the following solution for Linux: The virtual files are 1 byte sized files with the name of the original file, plus a suffix “.owncloud” to indicate that they are virtual.
That works, yet has one downside: Most file managers do not display these placeholder files nicely, because they loose the MIME type information. Also, downloading and also freeing up the space of downloaded files is not integrated. To summarize, there is a building block missing to make that useful on Linux.
Elokab-files-manager with ownCloud
I was wondering if it wasn’t possible to change an existing file manager to support the idea of virtual files. To start trying I found the Elokab-files-manager which is a very compact, yet feature rich file manager built on Qt. It is built with very few other dependencies. Perfect to start playing around with.
In my Github fork you can see the patches I came up with to make Elokab-fm understand ownCloud virtual files.
New Functionality
The screenshot shows the changes in the icon view of Elokab-fm.
To make that possible, Elokab-fm now pulls some information from the ownCloud Sync Client config file and connects to the sync client via local socket to share some information. That means, that the sync client needs to run to make that work.
Directories that are synced with ownCloud now show an cloud overlay in the center (1).
The placeholder files (2) which are not present on the local hard drive indicate that by showing a little cloud icon bottom right. However, other than before, they are displayed with their correct name and mime-type, which makes this already much more useful.
Files, which are on the local disk as the image (3) show their thumbnail as usual.
In the side panel (4) there are a few details added: The blue box on the bottom indicates that the file manager is connected to the sync client. For the selected virtual file (2), it shows an button that downloads the file if clicked which would turn it into a non virtual, local file. There is also an entry in the context menu to achieve that.
Status
This is just a proof of concept and a little XMas fun project. There are bugs, and the implementation is not complete. And maybe Jürgen‘s idea of a FUSE layer to improve that is the better approach, but anyway. It just shows what is possible with virtual files also on Linux.
If you like that idea, please let us know or send a little PR if you like. We do not wanna fail providing our share on the year of the Linux Desktop, right? 😉
Building it from my Github branch should be fairly easy, as it only depends on Qt.
For openSUSE users, I will provide some test packages in my home project on Open Build Service.
Kraft Version 0.95
The authors are happy to announce the new release 0.95 of Kraft. Kraft is free desktop software for managing office documents like quotes and invoices in the small enterprise for the Linux desktop.
With version 0.95 we do a big step forward in the way of generating documents: Until now (more than fifteen years!) Kraft uses the ReportLab python library to create high quality PDF documents.
While this has served us well, it has always been cumbersome to adopt the template for users needs. ReportLab uses a XML format as the template which has a bit of a steep learning curve and is not really easy with syntax.
This changes now: From version 0.95, Kraft supports the cool project WeasyPrint. The principle remains the same: The document is built of a text based template which defines the look of the output document. That gets filled with the document data and gets converted to a PDF document. But unlike ReportLab, Weasyprint is HTML based. Many people know a bit of HTML and thus will have an way easier time to adopt the template to personal needs.
Apart from the ease of use, it is much more simple to do modern report design with Weasyprint, as it supports the wide range of CSS styling.
That is a great improvement, as adopting Krafts output to personal needs is much more intuitive now. For now, Kraft supports both rendering engines, but ReportLab based reports are deprecated now and support will end in future releases of Kraft.
Along with integration of Weasyprint the text templating library Grantlee was added, as it is the standard in the KDE/Qt world, well maintained and widely available. The ctemplate library which was used for that so far will also be deprecated.
The other great improvement in this release is that Kraft now has a user manual embedded which will give new users a guiding help. It will open in the browser once the user clicks on the menu entry in the help menu, also without internet connection. It was started by a community member and it will grow and improve over time.
As usual this new version also ships an amount of bug fixes and small improvements which can be found in the Changelog.
We wish all users big fun with this remarkable new version of Kraft.
Welcome PDF Quirk
How often have you scanned a letter, a certificate or whatever and looked for the right way to call $UTILITY to convert it to a PDF that can be shared via internet?
For this very common use case I could not find a tool to make that really easy for the Linux desktop. Given my mission to help making the Linux desktop more common in the small business world (do you know Kraft?) I spent some time starting this little project.
Please welcome PDF Quirk, the desktop app to easily create PDFs out of images from storage or directly from the scanner!
It is just what this screenshot shows: A one page app to pick images from either the harddisk or from a scanner if configured, and save it right away to a multi page PDF file. The only option is to have either monochrome or color scan. No further scan chi-chi, just nice PDFs within seconds.
Of course I did not want to spend too much time and reinvent the wheel. PDF Quirk uses ImageMagicks convert utility and the command line scan client scanimage of the SANE Project in the background. Both are welknown standard commands on Linux, and serve well for this purpose.
Maybe you find PDF Quirk useful and wanna try it. You find it on Github, or packages on the openSUSE Buildservice.
Contributions and comments are very welcome. It is a fun little project!
Change in Professional Life
This November was very exciting for me so far, as I was starting a new job at a company called Heidolph. I left SUSE after working there for another two years. My role there that was pretty far away from interesting technical work, which I missed more and more, so I decided to grab the opportunity to join in a new adventure.
Heidolph is a mature German engineering company building premium laboratory equipment. It is based in Schwabach, Germany. For me it is the first time that I am working in company that doesn’t do only software. At Heidolph, software is just one building block besides mechanical and electronic parts and tons of special know how. That is a very different situation and a lot to learn for me, but in a small, co-located team of great engineers, I am able to catch up fast in this interesting area.
We build software for the next generation Heidolph devices based on Linux and C++/Qt. Both technologies are in the center of my interest, over the years it has become more than clear for me that I want to continue with that and deepen my knowledge even more.
Since the meaning of open source has changed a lot since I started to contribute to free software and KDE in particular, it was a noticeable but not difficult step for me to take and move away from a self-proclaimed open source company towards a company that is using open source technologies as one part of their tooling and is
interested in learning about the processes we do in open source to build great products. An exciting move for me where I will learn a lot but also benefit from my experience. This of course that does not mean that I will stop to contribute to open source projects.
We are still building up the team and look for a Software Quality Engineer. If you are interested in working with us in an exciting environment, you might wanna get in touch.
Kraft Version 0.80 Released
I am happy to announce the release of the stable Kraft version 0.80 (Changelog).
Kraft is desktop software to manage documents like quotes and invoices in the small business. It focuses on ease of use through an intuitive GUI, a well choosen feature set and ensures privacy by keeping data local.
After more than a dozen years of life time, Kraft is now reaching a new level: It is now completely ported to Qt5 / KDE Frameworks 5 and with that, it is compatible with all modern Linux distributions again.
KDE Frameworks 5 and Qt5 are the best base for modern desktop software and Kraft integrates seamlessly into all Linux desktops. Kraft makes use of the great KDE PIM infrastructure with KAddressbook and Akonadi.
In addition to the port that lasted unexpectedly over 12 months, Kraft v. 0.80 got a whole bunch of improvements, just to name some examples:
More Flexible Addressbook Integration
As Akonadi is optional now, Kraft can be built without it. Even if it was built with, but Akonadi for whatever reason is not working properly, Kraft still runs smoothly. In that case it only lacks the convenience of address book integration.
The Address book access was also nicely abstracted so that other Addressbook backends can be implemented more easily.
GUI Improvements
Even though the functionality and GUI of Kraft was not changed dramatically compared to the last stable KDE 4 version, there were a few interesting changes in the user interface.
- A new, bigger side bar simplifies navigation.
- In the timeline view, a click on years and month in the treeview show summaries of the selected time span, ie. the number of documents with financial summaries per month or year.
- A filter allows to limit the view on the current week or month.
Reduction of dependencies
Kraft makes broad use of the core Qt5 libraries. The required KDE dependencies were reduced to a bare minimum. Akonadi libraries, which enable KDE PIM integration are now optional. The former dependency on heavyweight web browser components were completely removed and replaced by the far more simple richtext component of Qt.
These changes make it not only easier and more transparent to build Kraft but allow make a port to other platforms like MacOSX more easy in the future.
Under the Hood
A countless number of bugfixes and small improvements went in. Also updates to the newer C++ concepts where applicable make the rather mature code base more modern and better maintainable.
The Reportlab based PDF document creation script was updated and merged with a later version for example.
Deployment
Installing Kraft is still a bit complicated for unexperienced users, and distributions sometimes haven’t made a good job in the past to provide the latest version of Kraft.
To make it easier to test, there is an AppImage of Kraft 0.80 available that should be runable on most modern distributions. Just download a single file that can be started right away after having added the executable permissions.
Linux packages are already built for openSUSE (various versions) or Gentoo.
Kraft’s website will contain a lot more information.
Kraft out of KDE
Following my last blog about Krafts upcoming release 0.80 I got a lot of positive reactions.
There was one reaction however, that puzzles me a bit and I want to share my thoughts here. It is about a comment about my announcement that I prefer to continue to develop Kraft on Github. The commenter reminded my friendly that there is still Kraft code on KDE infrastructure, and that switching to a different repository might waste peoples time when they work with the KDE repo.
That is a fair statement, of course I don’t want to waste peoples time. What sounds a bit strange to me is the second paragraph, that says that if I decide to stay with Github, I should let KDE people know that I wish Kraft to not be a KDE project anymore.
But … I never felt that Kraft should not be a KDE project any more.
A little History
Kraft has come a long way together with KDE. I started Kraft in (probably) 2004, gave a talk about Kraft at the Akademy Dublin 2006, maintained it with the best effort I could contribute until today. There is a small but loyal community around Kraft.
During all the time I got little substancial contribution to the code directly, with the exception of one cool developer who got interested for some time and made some very interesting contributions.
When I asked a for the subdomain http://kraft.kde.org long time ago I got the reply that it is not in the interest of KDE to give every little project a subdomain. As a result I reserved http://volle-kraft-voraus.de and run it since then, happily showing a “Part of the KDE family” logo on it.
Beside the indirect contributions to libraries that Kraft uses, I shipped Kraft with the translations made by the KDE i18n team, for which I always was very grateful. Otherwise I got no other services from KDE.
Why Github?
Githubs workflow serves me well in my day job, and since I have only little time for Kraft, I like to use the tools that I know best and give me the most efficiency.
I know that Github is not free software and I am sceptical about that. But Github also does not lock in, as we still are on git. We all know the arguments that usually come on the table at this point, so I am not elaborating here. One thing I want to mention though is that since I moved to Github publically I already got two little pull requests with code contributions. That is a lot compared to what came in the last twelfe years when living on KDE infrastructure only.
Summary
Kraft is a small project, driven by me alone. My development turnaround is good with Github as I am used to it. Even if no KDE developer would ever look at Github (which I know is not true) I have to say with heavy heart that Kraft would not take big harm by leaving KDEs infra, based on the experience of the last 12 years.
If the KDE translation teams do not want to work with Github, I am fine to accept that, and wonder if there could be a solution rather than switching to Transifex.
One point however I like to make very clear: I did not wish to leave KDE, nor aimed to move Kraft out.
I still have friends in the KDE community, I am still very interested in free software on desktop and elsewhere, and my opinion is still that KDE is the best around.
If the KDE community feels that Kraft must not be a KDE project any longer because it is on Github, ok. I asked KDE Sysadmins to remove Kraft from the KDE git, and it is already done.
Kraft Moving to KDE Frameworks: Beta Release!
Kraft is KDE/Qt based desktop software to manage documents like quotes and invoices in the small business. It focuses on ease of use through an intuitive GUI, a well chosen feature set and ensures privacy by keeping data local.
Kraft is around for more than twelve years, but it has been a little quiet recently. However, Kraft is alive and kicking!
I am very happy to announce the first public beta version of Kraft V. 0.80, the first Kraft version that is based on KDE Frameworks 5 and Qt 5.x.
It did not only go through the process of being ported to Qt5/KF5, but I also took the opportunity to refactor and tackle a lot of issues that Kraft was suffering from in the past.
Here are a few examples, a full changelog will follow:
- Akonadi dependency: Earlier Kraft versions had a hard dependency on Akonadi, because it uses the KDE Addressbook to manage customer addresses. Without having Akonadi up and running, Kraft was not functional. People who were testing Kraft without having Akonadi up were walking away with a bad impression of Kraft.
Because Akonadi and the KDE contacts integration is perfect for this use case, it still the way to go for Kraft, and I am delighted to build on such strong shoulders. But Kraft now also works without Akonadi. Users get a warning, that the full address book integration is not available, but can enter addresses manually and continue to create documents with Kraft. It remains fully functional.
Also, a better abstraction of the Akonadi-based functionality in Kraft eases porting to platforms where other system address books are available, such as MacOSX.
- AppImage: The new Kraft is available as AppImage.
There was a lot of feedback that people could not test Kraft, because it was hard to set up or compile, and dependency are missing. The major Linux distributions seem to be unable to keep up with current versions of leaf packages like Kraft, and I can not do that for the huge variety of distros. So AppImage as container format for GUI applications seems to be a perfect fit here.
- A lot more was done. Kraft got simplifications in both the code base and the
functionality, careful gui changes, and a decreased dependency stack. You should check it out!
Today (on FOSDEM weekend, which could be a better date?) the pre version 0.80 beta10 is announced to the public.
I would appreciate if people test and report bugs at Github: That is where the development is currently happening.
ownCloud 4 and ownCloud Client 1.0.2 released
It’s release day today: This morning, ownCloud 4 was released! With a very cool set of features it’s even more useful and again more fun to use.
Along with that I am happy to let you know that we also released the ownCloud Desktop Client in version 1.0.2.
It is a maintenance release with a couple of important bugfixes, such as the cross platform filename encoding problem I was already talking about. Apart from that big blocker a couple of smaller, but annoying problems were fixed. Also the GUI was polished, text changes here and there and a new icon set that looks more cool and more like ownCloud.
Version 1.0.2 is also the version that is released on all big desktop platforms the first time. Now we also offer a dmg for MacOSX as well as a Windows Installer and packages for the major Linux distributions. Have fun!
If you want to talk about ownCloud, file synchronization or such, we have a booth on Linuxtag in Berlin and I will be there. I am looking forward to meeting you.
Dragotin's Blog (archived) 