LibAlkimia is a base library that contains support for financial applications based on the Qt C++ framework. One of its main features is the encapsulation of The GNU Multiple Precision Arithmetic Library (GMP) and so providing a simple object to be used  representing monetary values in the form of rational numbers. All the mathematical details are …

Continue reading "LibAlkimia 7.0 released"

After a very long time, the KMyMoney development team is about to start the release cycle for the first release of its personal finance manager application based on KF5/Qt5. Various reports show us that people are already using the master branch in their production environment, as several team members have also done for at least …

Continue reading "Rome wasn’t built in a day"

Community Goals Over the second half of 2017, KDE has been going through the ambitious effort of having its community propose and choose goals for the next 3-4 years. These goals have been set now, and I was thrilled to learn that my proposal on Streamlined onboarding of new contributors was chosen and many other KDE contributors believed this was a goal worth pursuing in the near future and voted for it.

First of all: Happy New Year! Second, I think that I need to update you on Atelier and AtCore. There are about two months now that AtCore reached its beta stage and we release it with the test client.  On my Docker Hub account, the image of AtCore(Master and Beta) was pulled more than 30... Continue Reading →

After a beta version in September and a release candidate in October, there is finally a release of KBibTeX 0.7.
A tag has been set and tar balls have been published.

The only changes compared to the release candidate are attempts to fix online search issues with Google Scholar and IEEE Xplore.

KDE’s Visual Design Group recently put some thought into shadows in Breeze. Right now, the default shadows are rather small, and can be almost entirely invisible on the left edge:

We decided to make them larger and deeper by default, and center them horizontally so that there’s a shadow on the left edges of windows and menus as well. I was honored to produce the patch, and I’m happy to report that it’s been accepted and merged! Starting in Plasma 5.12, here’s how shadows will look:

These are just default settings of course; if you don’t like big shadows, you can tweak to your heart’s content (System Settings > Application Style > Window Decorations > [click on the little menu button in the corner of the Breeze entry] > Shadows). But this new default setting provides a much greater sense of depth that I think most users will find quite welcome.

FreeBSD is getting more serious about license metadata in the packages produced by the project — that is, the binary distribution of software produced from licensed source code. A lot of software in FreeBSD “proper” is (naturally) BSD-licensed, and a lot of Free Software packaged by FreeBSD is (also naturally) GPL licensed. But the different licenses carry different obligations, so it’s good to keep track of the exact licensing applied to each bit of software.

To this end, there’s the LICENSE= line in each port’s Makefile. Its meaning is “this software has such-and-such a license”. For conciseness, SPDX identifiers are used, so that you can write

LICENSE=LGPL21

and we know what you mean. Because licenses can carry textual obligations (e.g. the GPL expects you to receive a copy, and the BSD licenses generally require you to include the copyright notice with distributions), there’s
an additional setting to include the actual text, called LICENSE_FILES:

LICENSE_FILES=COPYING.LIB

There’s a third source of license information, and that is the headers of the sources themselves. Usually you put a copyright-and-license header at the top of each file; some licenses such as the MPL even require some administration in there. The reuse.software site (by the FSFE) provides good guidance and best-practices information for providing licensing metadata in software packages.

Anyway, for KDE Frameworks 5 I was going through the ports Makefiles and adding LICENSE information. The KDE Licensing Policy tells me that frameworks should be licensed LGPL21+, with a few variants allowed; an interesting one is (at your option) “LGPL21 or LGPL3 or any later version approved by KDE e.V.” Right now, in 2017, this choice is the same as LGPL21+ because no later versions exist, but it is not always-in-the-future-same, so I hesitate to write

LICENSE=LGPL21+

for KDE Frameworks until I’ve checked the files. The license text is usually included, but it’s not quite consistently named, so I need to look into the tarballs anyway. And as a double-check, I read a couple of source headers to see if the license named in the code, matches the license text elsewhere (e.g. some files say LGPL 2.1 only).

It’s a bit of a slow process — one which upstream (that is, the source code) could support a little better with consistent naming. It’s also a process that needs to be monitored continually, to ensure that the whole body of software remains properly and consistently licensed — hopefully following best practices, too.

Anyway, as of today only ten of the KDE Frameworks 5 ports in the official FreeBSD ports repository  have all their licensing information set, to the best of my ability to check their accuracy. As an ongoing project in keeping-license-info up-to-date it’s not very high-priority but something that gets done in-between other things.

Good evening fellas,

Happy New Year to all! The year 2017 has been a rollercoaster, to be honest. Well, it was rich and prosperous year regarding in technical terms. It was a beautiful year of great learning, splendid travel and got to network with some fantastic folks all around the globe.

The best reason for making this 2017 incredible for me is KDE. One of the exciting community I have ever seen! It all started at the end of 2016, I got intrigued by the Tagline of KDE, “Experience freedom”. I started contributing to various projects inside KDE. My initial start was with Konsole, system settings, KIO and various educational suite programs. Moving on, I came across a student program organized by KDE named KDE-SoK and I was selected for it, yay!!!

The project was with KStars(KDE’s amateur astronomy software which provides real-time and an accurate graphical simulation of the night sky, from any location on Earth.) to collect a new set of images from NASA/ESO catalogs along with orientation and pixel scale (arcsecs/pixel) from the whole set of Messier Catalog (which is a collection of 110 astronomy objects in the night sky). Images were processed for overlay in KStars using OpenCV, so to have transparency and to modulate according to the software.

After the successful completion of the project, I was invited as a speaker to give a talk on “Object-Tracking Using OpenCV and Qt” at KDE India Conference held at IIT Guwahati in March 2017. Again, yay!! :P. There I met a lot of enthusiastic KDE people out there.

Later on, I was selected as a Google Summer of Code (2017 edition) intern funded by Google. I contributed to  Krita(Krita is a professional and open source painting program) of KDE. The project was to Integrate share.krita.org. 

Share.krita.org is a place where users can share Krita scripts, images, brush packs and more. This project has two parts: integrate with the KNSCore part of the KNewStuff framework (or reimplement the protocol) and create a GUI for sharing. The second part is improving the support for creating and editing bundles. Bundles can contain brushes, patterns, gradients and so on. Also, Krita needed basic support for creating and editing bundles.

Thus said, the entire journey with KDE last year was splendid!! The community as such is a group of awesome and enthusiastic people from all around the globe. To do more than I could last year — I hope to be a part of this great venture in 2018.

Here’s to a productive year, and looking forward to the same in 2018. You can see more of what happened in KDE in 2017 on the KDE year-end fundraiser page. Please do show some of your support to the community and its developers through the fundraiser to built your favorite software

Some of my blog post regarding my work last year:

• KDE SoK 2016-2017
• Introduction for GSoC 2017 with KDE, Krita
• Awesome::KDE Community
• GSoC ’17 – Week #1
• GSoC ’17 – Week #2
• GSoC ’17 – Week #3
• GSoC ’17 – Week #4
• GSoC ’17 – Week #5
• GSoC’17 – Week #6
• GSoC’17: From 1 Line of Code to 4828

To the awesome year coming right your way,

Cheers.

At the beginning of 2017, I was a programmer (mostly Python, and a little bit of C++) and spent most of my day at my desk, with an IDE open and a cup of coffee at hand. At the end of 2017, I’m a programmer (mostly C++, and a little bit of Python) and spend most of my day at my desk, with an IDE open and a cup of espresso at hand.

At some level of abstraction, not much has changed this year.

Of course, now I spend my entire day working on Free Software, in three different but partly-overlapping communities: KDE, FreeBSD, and Calamares. Basically you can track everything I do each day by looking in the relevant repositories on GitHub (read-only mirrors in the case of FreeBSD and KDE). Inspired by Michael, Krita, Matthieu Gallien (with the this-week-in-Elisa series) and Dominik Haumann, I’ve collected a list of things I did this year, in no particular order:

• Released two versions of the proprietary application I worked on previously, and quit my job. Started working for BlueSystems and other organizations as a free-lance yet full-time programmer.
• Updated Nethack in FreeBSD, and discovered I no longer have the Nethack chops to ascend half of the games I start. Updated Unnethack on FreeBSD, and fixed a clang-related bug upstream. Yay for roguelikes.
• Released a dozen Calamares versions with regular bugfixes and small features. Worked together with the KDE VDG, Jens in particular, to figure out some of the UI choices — thanks for plying me with ideas.
• Updated CMake a couple of times in FreeBSD and chased lots of weird CMakeLists code in unrelated applications.
• Massaged KDE on FreeBSD under the expert guidance of Tobias and Raphael.
• Attended three weeks of KDE-related sprints or meetings and a week of Akademy.

Here’s to a productive year, and looking forward to the same in 2018. You can see more of what happened in KDE in 2017 on the KDE year-end fundraiser page.

A central place to track KDE development is the kde-commits@kde.org mailing list. To this mailing list, all code changes are sent, containing the log message as well as the diff that quickly shows what really changed. In the early days of KDE development, the changes were maintained by the CVS version control system. Later, this was changed to subversion. Nowadays, KDE mostly uses git, but some svn modules are still around.

Since KDE is developed by many contributors, the  kde-commits@kde.org mailing list obviously has high traffic, ranging from ~100 mails up to 400 mails a day (see marc.info for statistics).

Many developers are subscribed to this mailing list. However, due to high traffic and possibly many changes that are unrelated to your pet project, a commit filter was invented, which was available on https://commitfilter.kde.org for a long time. Essentially, this commit filter allowed to easily setup filters in terms of regular expressions, such that you’d only get mails for changes you are interested in. While this was convenient, the commit filter also had its drawbacks: Instead of getting all KDE changes, you missed a lot possibly interesting conversations: Since post-code reviews are often done by others through email conversation directly on the code changes.

Nowadays, the commit filter is not available anymore, mostly for security reasons since it was unmaintained for a long time.

What does that mean? I’m subscribed to kde-commits@kde.org again, getting all changes. In fact, I am enjoying skimming quickly through the changes, even doing a code review here and there.

I recommend every KDE contributor to subscribe to this mailing list, since it is very interesting to see which projects are actively developed and who really contributes to KDE in person. Even better, sometimes there are discussions on this list, helping you to learn things you didn’t know. Of course, nowadays we also have many code reviews on phabricator, but still the commit mailing list is a nice addon to track KDE development.

The year is about to end and so is Cutelyst v1 series, I wasn’t planning for another release this year but Matthias added some nice new features that I decided to roll 1.12 in 2017 branching 1.x.x series and master is now officially Cutelyst 2 with no stable API/ABI until 2.0.0 is tagged.

HTTP/2 support will hopefully be part of Cutelyst 2.0.0, there aren’t any drastic changes in v2, most important thing is fixing MSVC builds and removing deprecated API.

Back to this release it includes a new CSRF protection plugin, with a Grantlee tag similar to what Django has. Add to this many fixes and the epoll event loop dispatcher is now even faster and got many fixes, performance wise it’s great advantage is when dealing with many simultaneous connections, it can lead to 2-3 times faster than default glib one.

https://github.com/cutelyst/cutelyst/archive/v1.12.0.tar.gz

Happy new hacking year!

Playing with emojis

At some point, I needed to copy paste emojis, but couldn’t find a good way to do it. So what does a good hacker do?
Scratch an own itch. As I wrote about in the past, all these projects should be shared with the rest of the world.
So here it is: https://cgit.kde.org/scratch/sune/aubergine.git/

It looks like this with the symbola font for emojis:

It basically lets you search for emojis by their description, and by clicking on a emoji, it gets inserted into the clipboard.

As such, I’m not sure the application is really interesting, but there might be two interesting bits in the source code:

• A parser for the unicode data text files in /usr/share/unicode/NamesList.txt is placed in lib/parser.{h,cpp}
• A class that tries to expose QClipboard as QML objects placed in app/clipboard.{h,cpp}. I’m not yet sure if this is the right approach for that, but it is the one that currently makes most sense in my mind. If I’m receiving proper feedback, I might be able to extend/finish it and submit it to Qt.

And of course, now it is simple to describe fancy cooking:

(aubergine) (hocho) (fire)

I ❣ emoji

Not goodbye, but hello to a new music player on my desktop. It is already packaged for FreeBSD and has a long development history.

Music players stand or fall per individual user whether they satisfy the user’s needs — no duh there, but it means I should note what my use cases are before enthusing about some music player in particular. I would be fine with playing music from the command-line, most of the time: mpg123 --shuffle /mnt/music/*/*/* is just about right (except it fails with an argument list too long error in the shell). This is for music-while-I-hack, so I don’t listen too closely, it’s not hi-fi at all, basically I want “play in a genre until I switch it off“. Tagging is largely done when ripping my CDs (I still buy physical media!) and I don’t care for album art (I can look in the jewel case if I want that, and they’re all stacked in boxes upstairs). So play, pause, stop .. and if it can avoid mixing Mahler with Morrissey and Mötorhead, that’s a bonus.

Off to the left here is Sayonara, which describes itself as:

“Sayonara is a small, clear and fast audio player for Linux written in C++, supported by the Qt framework. It uses GStreamer as audio backend. Sayonara is open source and uses the GPLv3 license. One of Sayonara’s goals is intuitive and easy usablility. Currently, it is only available for Linux.“

Clearly that’s not true, because it’s available for FreeBSD as well . I forget how I configured it; there’s a File > Open Directory entry and I probably filled in /mnt/music and it went and found everything that gstreamer will sensibly play. The screenshot is of the minimal playlist-only view. It can be broadened to include a library view which is a bit chaotic, but which searches reasonably well (e.g. for Mudhoney). Sayonara is actually where I discovered the luxury of stay-on-genre autoplay: when I started on some Dutch punk and it kept pretty close to that, wandering off to de Kift occasionally — but no Drs.P.

I contributed a few small fixes to get Sayonara building on FreeBSD, cleaning up the CMakeLists for newer CMake, that kind of thing. Now that it runs on my Plasma desktop all day, I can spot some more  minor issues — the system tray media player control doesn’t interact with Sayonara at all, for instance. For my use-case, that’s not so important, since the fire-and-forget genre play does it for me until I hit pause in the main UI.

I’m looking forward to KDE music players Elisa and Babe, for comparison purposes: maybe they tick my requirements-boxes just as well, or better. Certainly Elisa seems to be fairly playing-music-focused. I’ve even got a FreeBSD port for Elisa ready, just waiting for Qt 5.9 to show up on my doorstep (I can get it to compile against 5.7, but it won’t run due to QML runtime thingies).

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

I enjoy working on the elisa music player. I hope some people enjoy using it. All of this would not have been possible without the KDE community. There is an ongoing fundraising campaign. Please support it.

https://www.kde.org/fundraisers/yearend2017/

Not much have been done due to Christmas and end of year holidays.

The following things have been integrated in Elisa git repository:

• Disable shadows when no artist image is present by Diego Gangl ;
• Unify track delegate handling by Alexander Stippich ;
• Fix missing assignment of music listener for MediaArtistAlbumView by Alexander Stippich ;

There are also some pending diff request in phabricator.

We have also some ongoing work to organize work with KDE VDG. Some future changes following their feedback is planned.

I am also driving an effort to more clearly communicate what elisa is about (inspired by the work on KDE goals and plasma vision). I hope to be able to also have a vision for elisa and to derive some goals aligned with those of the KDE community.

The CMake port on FreeBSD is in the hands of the KDE-FreeBSD folks (since KDE was an early adopter), and generally it falls to me to do the CMake update while Tobias is still wrestling with Plasma and Raphael massages Qt 5.9 into our way of building. 3.10 was released five weeks ago, and it took a while to update the port.

It doesn’t take long because of CMake — they’re great, the code builds flawlessly, and there has been a real effort on the part of the KitWare folks recently to absorb our downstream patches so that we have less work in future (During the delay packaging CMake 3.10.0 Kitware even put out 3.10.1, which re-started some processes). It doesn’t take long because of new FreeBSD-specific features in CMake — you can now use CPack to create native FreeBSD packages, just in case you don’t want to go through the ports system or poudriere.

Nope, the problem is the 2000-odd ports using CMake. These generally behave, but every CMake update brings with it some ports that suddenly don’t build. So I spent a day on things like openvsp and scalapack, which fall over with 3.10 (and didn’t with 3.9). The causes of these failures is diverse; sometimes bad local CMake modules that don’t add all the right linking flags, sometimes bad C++ code, sometime stuff that has nothing to do with CMake at all but just happens to be newly triggered, and therefore my problem.

CMake 3.10.1 landed in the official ports tree with r457041, just before Christmas.

Naturally, there are some cases that fall out after an update, that are not caught before the update is committed. I’m told that FreeBSD on PowerPC doesn’t have a C++11-capable compiler installed by default, so I’ll need to massage that a little. Boost 1.66 came out very shortly after CMake 3.10.1, and that leads to new kinds of breakage. I’ve spent a half day compiling and re-compiling ceph, a distributed filesystem, trying to get that to work. It’s amazing sometimes how shifting one brick can bring down a whole house, and how we ever built the house in the first place.

It’s time for the end of 2017 KDE fundraiser, and so this is good a time as any during the year to take a step back and publish a retrospective on the work we’ve individually done in 2017.

For those maintaining a module or two this isn’t too hard to figure out what you’ve done with some git magic. But if you’ve made contributions to more than a few modules it can be a bit unwieldy trying to figure out what work you’ve actually done.

While it’s probably not too difficult to craft a find(1) command to search recursively under a common directory for git modules, and then run git-log to look for commits with a given author, it can take a significant amount of time to go through that list if you have a set of checkouts like mine.

Instead, I used kdesrc-build to help, using the --query flag I blogged about a few days ago.  Using kdesrc-build to query for a source directory isn’t very helpful here compared to raw use of find(1).  Rather, it allowed me to allow use kdesrc-build’s own facilities for filtering through modules to build so that I could eliminate git modules I know I’ve had nothing to do with in a way that isn’t as easily expressible using find flags.

In my case, I used a command like this:

kdesrc-build --query source-dir --resume-from extra-cmake-modules | \
    cut -f 2 -d ':' | \
while read dir ; do \
    [ -d "$dir" ] && cd "$dir" && \
    git --no-pager log --since='2017-01-01' \
        --pretty="tformat:$(basename $dir): %s" \
        --author='mpyne@kde.org' --committer='mpyne@kde.org' ; \
    done

What this does is to run kdesrc-build and have it generate its module list as normal, using the --resume-from command to skip over a bunch of large modules I had nothing to do with, and output a line for each of those modules in the form “ki18n: /kdesrc/src/kf5/frameworks/ki18n”.

Each line is fed to cut(1), which prints just the part after the colon (sed(1) would work as well). This path is fed into the while loop, which extracts each input line into the $dir variable, and uses that variable to make sure the directory is actually checked-out and if so, runs git-log in that directory.

Git then actually does the search for any commits since the date given (2017-01-01) by the author(s) or committer(s) you pass.  I use the --no-pager flag before the git subcommand so that I don’t have to pipe to cat(1) to avoid the automatic interactive result display.

Finally, I use the --pretty flag to cause git to also include the basename of the directory when it is showing each commit.  This helps organize where you did your work in a form that’s easy to slice-and-dice later.

So, what did I do this year?  It was split up among these major categories:

• The kdesrc-build changes I already mentioned.
• KCoreAddons: Minor fixes, including to improve desktop entry specification parsing and legacy KDE service type handling. I then fixes a similar issue in KConfig.
• KI18N: Mark .h files generated by uic as ineligible for CMake’s AUTOMOC (fixes a warning of a new CMake policy)
• KF5: Make it compile with Alpine Linux (which uses musl).  This work was actually to support kdesrc-build in a Docker container, but I never got around to publishing that… :(.  This touched KIO, Solid, KInit, KSysGuard.
• KWallet: Coverity fixes (on that note, we need someone to start running Coverity builds again…)
• and finally… completed Kacper Kasper’s port of JuK to KF5!  This work was released with KDE Applications 17.12.  There are still things missing but in some important internal ways, the port is even more complete than the port of JuK from KDE3 to KDE4 was.  Unlike the KDE4 version which always used kde3support, JuK now doesn’t use any compatibility libraries, not even Kdelibs4Support, and should compile without warnings (deprecated uses or otherwise).

While it has been (and continues to be) difficult to find time to make a meaningful impact with a full-time job outside of software development and a growing family, I hope to be at least as productive in the year to come in 2018.

Happy New Year’s everyone and if you have some spare change lying around, please don’t hesitate to support the KDE fundraising drive!  Every bit goes to work on something important, and each contribution helps.

KMarkdownWebView 0.4.0 has been released.

Example: KMarkdownWebView KParts plugin used by Ark

The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies (native wrapper around a webpage with a JavaScript library which creates HTML from the plain text handed in).
The software contains

• a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format.
• a Markdown file KIO thumbnail generator plugin, which allows KIO-powered file managers & dialogs to show thumbnails and previews of files in Markdown format in the target format (currently only available when building against QtWebKit)

The KMarkdownWebView KParts plugin is also prepared for improved experience with the KTextEditor Document Preview plugin for KTextEditor-based applications like the editor Kate and IDE KDevelop.

KMarkdownWebView can be built both with QtWebEngine (preferred by the build system) and QtWebKit. Pass -DUSE_QTWEBKIT=TRUE to CMake to enforce the use of QtWebKit.

Changes since 0.3.0

• New feature in KParts plugin: show hovered link in status bar
• Fix: KParts plugin appstream metadata had wrong type
• Translations updated for some languages (cs, da, de, en_GB, fr, ko, pl, sr@ijekavian, sr@ijekavianlatin, sr@latin, sr, zh_CN)

Download sources

Download from: https://download.kde.org/stable/kmarkdownwebview/0.4.0/src/

sha256: 38b72ba6fa4b513002e7873d2b774e50d676fc878a38b18e6eb9636b53b4c29d kmarkdownwebview-0.4.0.tar.xz

Signed with my new PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau
kmarkdownwebview-0.4.0.tar.xz.sig

Bystander.

It seems such a passive word for a passive role.

Let's consider how it is instead a position of power.

First, as a bystander, I can observe what is happening which nobody else sees, because nobody else is standing exactly where I am. Nobody else has my mix of genes and history and all of what makes me who I am and so I see uniquely.

As bystanders each of us has power we often do not grasp. It is of the moment. We can plan, and prepare so that we are ready to act, intervene if necessary; build up potential energy. While remaining polite, I can step in to help, intervene, participate, engage. I can ACT.

Pro-tip: run this program (courtesy of the Linuxchix:

1. be polite
2. be helpful
3. iterate

Boom! You have a team.

Supporting free software is one of the things I do. Right now is a great time to help support KDE.

KDE Powers You - You Can Power KDE, Too! 

https://www.kde.org/fundraisers/yearend2017/