This Blog has Moved
Please, dear followers and reader, consider: I have moved my blog to the new site https://dragotin.codeberg.page (RSS)
This blog here will close be left unmaintained from now on, and new posts will only go to the new site.
For long time I was happy to be here. But the page got advertisements at some points that were not acceptable for my needs, so I was forced to pay for a non-advertisement plan on WordPress.com. That does not scale forever, so I decided to move away. And .. hugo is obviously more cool anyway 😉
Thank you all for your interest in my blog here, I hope you will follow me to the new platform.
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.
Kraft Version 0.98
We are happy to announce the new Kraft version 0.98 that is available for download.
Kraft is software for the Linux desktop to handle quotes and invoices in the small business.
This is a version packed with bugfixes and also new features. The most important fixes were in the area of the catalog handling: Based on bug reports from the community the catalog window was completely reworked. Drag and drop of items in the catalog, the sorting and reordering of items are now working properly and as planned.
Another big addition is the support of 
. XRechnung is an E-invoicing format more and more mandatory in the governmental area in Germany. We are very proud that Kraft is the first open source office tool that supports that standard in a user friendly way. All invoices can now also exported in the XRechnung-XML format.
Beside these two big improvements, there are lots of others. For example, the user manual was further improved and is available also in Dutch. A lot of other smaller but non the less important improvements and fixes make version 0.98 a valueable release.
We wish a lot of fun with this new improved version of Kraft!
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.
Screensharing with MS Teams and KDE: Black Screen
In the day job we use Microsoft Teams. The good news is that it is running on the Linux Desktop, and specifically KDE. So far, so good, however, there was a problem with screensharing for me.
Whenever I tried to share my KDE screen, the screen became black, surrounded with a red rectangle as indicator for the shared area. The people who I shared with also just saw the black area, and also the mouse pointer as me.
The problem is described in a bugreport and there are two ways of solving it:
- Enable compositing: The red indicator rectangle requires that the window manager supports compositing. KWin can of course do that, and with that enabled, sharing works fine including the red rectangle.
- If compositing can or should not be used there is another workaround: As the bug report shows, renaming the file
/usr/share/teams/resources/app.asar.unpacked/node_modules/slimcore/bin/rect-overlayso that it is not used by teams fixes it as well. Obviously you wont have the red rectangle with this solution.
That said, it is of course preferable to use an open source alternative to Teams to help these evolve.
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.
Open Search Foundation
recently I learned about the Open Search Foundation in the public broadcast radio (Bayern 2 Radio Article). That surprised me: I had not heard about OSF before, even though I am active in the field of free software and culture. But this new foundation made it into the mainstream broadcast already. Reason enough to take a closer look.
It is a very good sign to have the topic of internet search in the news. It is a fact that one company has a gigantic market share in searching which is indeed a threat to the freedom of internet users. The key to be found in the web is the key to success with whatever message or service a web site might come up with, and all that is controlled by one enterprise driven by commercial interests. That should be realized by a broad audience.
The Open Search Foundation has the clear vision to build up an publicly owned search index as an alternative for Europe.
Geographical and Political Focus
The whitepaper talks about working on the search machine specifically for Europe. It mentions that there are search indexes in the US, China and Russia, but none rooted in Europe. While this is a geographical statement in the first place, it is of course also a political, because some of the existing services are probably politically controlled.
It is good to start with a focus on Europe, but the idea of a free and publicly controlled project should not be limited to Europes borders. In fact, it will not stop there if it is attractive because it might offer a way to escape from potentially controlled systems.
On the other hand, Europe (in opposite to any single European country alone) seems like a good base to start with this huge effort as it is able to come up with the needed resources.
Organization
The founding members of the Open Search Foundation are not very well known members of the wider open source community. That is good, as it shows that the topics around the free internet do not only concern nerds in the typical communities, but also people who work for an open and future proof society in other areas like academia, research and medicine.
On the other hand, an organization like for example the Wikimedia e.V. might have been a more obvious candidate to address this topic. Neither on the web site nor in the whitepaper I found mentions of any of the “usual suspects” or other organizations and companies who have already tried to set up alternative indices. I wonder if there have been discussions, cooperations or plans to work together?
I am very curious to see how the collaboration between the more “traditional” open data/open source community and the Open Search Foundation will be, as I think it is a crucial part to combine all players in this area without falling into the “endless discussion trap” while not achieving countable results. It is the question of building an efficient community.
Pillars of Success
Does the idea of the OSF have a realistic chance to succeed? The following four pillars might play an important role for the success of the idea to build the free search index of the internet:
1. Licenses and Governance
The legal framework has to be well defined and thought through, so that it will be resilient longer term. As we talk about a huge commercial potential to control this index, parties might wanna try to get into control of it.
Only a strong governance and legal framework can ensure that the idea lasts.
The OSF mentions in the whitepaper that it is one of the first steps to set this up.
2. Ressources
A search index requires big amounts of computing power in the wider sense, including storage, networking, redundancy and so on. Additionally there need to be people who take care on that. For that, there needs to be financial support for staffing, marketing, legal support and all that.
The whitepaper mentions ideas to collect the computing power from academia or from company donations.
For the financial backing the OSF will have to find sources like EC money, from governments and academia, and maybe private fund raising. Organizations like Wikimedia would already have experience with that.
If that will not be enough, the idea of selling better search results for money or offering SEO help for development will quickly come up. This will be interesting discussions that require the strong governance.
3. Technical Excellence
Who will use a search index that does not come up with reasonable search results?
To be able to compete with the existing solutions that even made it into our daily communication habits already, the service needs to be just great in terms of search results and user experience.
Many already existing approaches that use the Google index as a backend have already show that even with that it is not easy to provide a comparable result.
It is a fact that users of the commercial competition trade their personal data against optimal search results, even if they dont do that consciously. It is more difficult for a privacy oriented service, so this is another handicap.
The whitepaper mentions ideas on how to work on this huge task and also accepts that it will be challenging. But that is no reason to not try it. We all know plenty of examples where these kind of tasks were successful even though nobody believed that in the beginning.
4. Community
To achieve all the points a strong community is key factor.
There need to be people who do technical work like administering the data centers, developers who code, technical writers for documentation, translators and much more. But that is only the technical part.
For the financial-, marketing- and legal support there are other people needed, not speaking about political lobby and such.
All these parts have to be built up, managed and kept intact long term.
The Linux kernel, which was mentioned as a model in the whitepaper, is different. Not even the technical work is comparable between the free search index and the Linux kernel.
The long term stable development of the Linux kernel is based on people who work full time on the kernel while being employed by certain companies who are actually competitors. But on the kernel, they collaborate.
This way, the companies share cost for inevitable base development work. There differentiators in the market are not depending on there work on the kernel, but in the levels above the kernel.
How is that for OSF? I am failing to see how enough sustainable business can be based on an open, privacy respecting search index so that companies will be happy to fund engineers working on it.
Apart from that, the kernel has the benefit that it had strong companies like RedHat, SUSE and IBM who pushed Linux in the early times, so no special marketing budgets etc. were needed for the kernel specifically. Also that is different for OSF, as quite some marketing- and community management money will be required to start.
Conclusion
Building a lasting, productive and well established community will be the vital question for the whole project in my opinion. Offering a great idea, which this initiative is without question, will not be enough to motivate people to participate long term.
There has to be an interesting offer for potential contributors at all levels, starting from individuals and companies for contributions, to universities for donating hardware or the governments and the European Community for money. There needs to be some kind of benefit they will gain for their engagement on the project. It is interesting if the OSF can come up with a model that will get that kickstarted.
I very much hope that this gets traction as it would be an important step towards a more free internet again. And I also hope that there will be collaboration on this topic with the traditional free culture communities and the foundations there.
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!
Kraft Version 0.90
This blog is to inform that Kraft, the Qt and KDE based desktop software to manage documents like invoices and quotes in your small company was released in version 0.90 recently.
Followup Documents
A great new feature is the completely reworked handling of so called follow-up documents. Kraft has this feature to help dealing with docs that follow on a certain kind of predecessor doc in the business flow, such as an invoice follows on an offer once the work has been finished.
To achieve that and to have all the items of the offer again referenced in the invoice, the Kraft user justs clicks on the menu item “Create Followup Document” on the selected offer, and the new doc is created with all the items of the offer prepared. It is ready to be adjusted to the final invoice details.
Now with version 0.90 this has even improved. Often, the flow is a bit different because a partial invoice is sent while the job is still in progress, for example to cover cost for material. A partial invoice usually has only one item, which is the progress payment the customer should pay.
Kraft users can handle that now very easy: The new UI does not only allow to choose from which predecessor document the final invoice should copy the items (which usually is the offer in the beginning) but it also realises that a partial invoice was sent before, so this amount of payment has to be substracted from the final invoice. Kraft adds an item to the final doc automatically here.
This helps to create high quality documents for your customers even faster, which is exactly the mission of Kraft.
Other Improvements
In addition to that, as usual a lot of other visible and invisible changes have gone into this release. For example, the UI has been simplified again by a clean up of the menu for example. The About Kraft dialog was removed and integrated into the Kraft information page.
Under the hood, we finally added unit tests, which is just a start so far, and ntroduced a new, XML based system to manage the available document types which makes igrations way easier. Last but not least the python based pdf conversion script was ported to python 3 to be ready for the end of python 2.
Community
Last but not least, Kraft got new contributions from the community: A new document type was initiated by a community member, which is a offer like document without showing the price information. Also, the complete app was translated to Dutch by a volunteer, and the translation is now shipped with Kraft by default. Also, other smaller bugfixes went in.
Thank you all for your help to improve Kraft.
Dragotin's Blog (archived) 