In Calamares there is a debug window; it shows some panes of information and one of them is a tree view of some internal data in the application. The data itself isn’t stored as a model though, it is stored in one big QVariantMap. So to display that map as a tree, the code needs to provide a Qt model so that then the regular Qt views can do their thing.

Each key in the map is a node in the tree to be shown; if the value is a map or a list, then sub-nodes are created for the items in the map or the list, and otherwise it’s a leaf that displays the string associated with the key. In the screenshot you can see the branding key which is a map, and that map contains a bunch of string values.

Historically, the way this map was presented as a model was as follows:

• A JSON document representing the contents of the map is made,
• The JSON document is rendered to text,
• A model is created from the JSON text using dridk’s QJsonModel,
• That model is displayed.

This struck me as a long-way-around. Even if there’s only a few dozen items overall in the tree, it looks like a lot of copying and buffer management going on. The code where all this happens, though, is only a few lines – it looks harmless enough.

I decided that I wanted to re-do this bit of code – dropping the third-party code in the process, and so simplifying Calamares a little – by using the data from the QVariant directly, with only a “light weight” amount of extra data. If I was smart, I would consult more closely with Marek Krajewski’s Hands-On High Performance Programming with Qt 5, but .. this was a case of “I feel this is more efficient” more than doing the smart thing.

I give you VariantModel.

This is strongly oriented towards the key-value display of a QVariantMap as a tree, but it could possibly be massaged into another form. It also is pushy in smashing everything into string form. It could probably use data from the map more directly (e.g. pixmaps) and be even more fancy that way.

Most of my software development is pretty “plain”. It is straightforward code. This was one of the rare occasions that I took out pencil and paper and sketched a data structure before coding (or more accurate: I did a bunch of hacking, got nowhere, and realised I’d have to do some thinking before I’d get anywhere – cue tea and chocolate).

What I ended up with was a QVector of quintptrs (since a QModelIndex can use that quintptr as intenal data). The length of the vector is equal to the number of nodes in the tree, each node is assigned an index in the tree (I used depth-first traversal along whatever arbitrary yet consistent order Qt gives me the keys, enumerating each node as it is encountered). In the vector, I store the parent index of each node, at the index of the node itself. The root is index 0, and has a special parent.

The image shows how a tree with nine nodes can be enumerated into a vector, and then how the vector is populated with parents. The root gets index 0, with a special parent. The first child of the root gets index 1, parent 0. The first child of that node gets index 2, parent 1; since it is a leaf node, its sibling gets index 3, parent 1 .. the whole list of nine parents looks like this:

-1, 0, 1, 1, 0, 0, 5, 5, 5

For QModelIndex purposes, this vector of numbers lets us do two things:

• the number of children of node n is the number of entries in this vector with n as parent (e.g. a simple QVector::count()).
• given a node n, we can find out its parent node (it’s at index n in the vector) but also which row it occupies (in QModelIndex terms), by counting how many other nodes have the same parent that occur before it.

In order to get the data from the QVariant, we have to walk the tree, which requires a bunch of parent lookups and recursively descending though the tree once the parents are all found.

Changing the underlying map isn’t immediately fatal, but changing the number of nodes (expecially in intermediate levels) will do very strange things. There is a reload() method to re-build the list and parents indexes if the underlying data changes – in that sense it’s not a very robust model. It might make sense to memoize the data as well while walking the tree – again, I need to read more of Marek’s work.

I’m kinda pleased with the way it turned out; the consumers of the model have become slightly simpler, even if the actual model code (from QJsonModel to VariantModel) isn’t much smaller. There’s a couple of places in Calamares that might benefit from this model besides the debug window, so it is likely to get some revisions as I use it more.

So, we had a Krita sprint last week, a gathering of contributors of Krita. I’ve been at all sprints since 2015, which was roughly the year I became a Krita contributor. This is in part because I don’t have to go abroad, but also because I tend to do a lot of administrative side things.

This sprint was interesting in that it was an attempt to have more if not as much artists as developers there. The idea being that the previous sprint was very much focused on bugfixing and getting new contributors familiar with the code base(we fixed 40 bugs back then), this sprint would be more about investigating workflow issues, figuring out future goals, and general non-technical things like how to help people, how to engage people, how to make people feel part of the community.

Unfortunately, it seems I am not really built for sprints. I was already somewhat tired when I arrived, and was eventually only able to do half days most of the time because there were just too many people …

So, what did I do this sprint?

Investigate LibSai (Tuesday)

So, PaintTool Sai is a 2d painting program with a simple interface that was the hottest thing around 2006 or so, because at the time, you had PaintShop Pro(a good image editing program, but otherwise…), Photoshop CS2(You could paint with this but it was rather clunky), GIMP, OpenCanvas(very weird interface) and a bunch of natural media simulating programs (Corel, very buggy, and some others I don’t remember). Paint Tool Sai was special in that it had a stablizer, and mirroring/rotating the viewport, and a color-mixing brush, and variable width vector curves, and a couple of cool dockers. Mind you it only had like, 3 filters, but all those other things were HUGE back then. So everyone and their grandmother pirated it until the author actually made an English version, at which point like 90% of people still pirated it. Then the author proceeded to not update it for like… 8 years?, with Paint Tool Sai 2 being in beta for a small ever.

The lowdown is that nowadays many people(mostly teens, so I don’t really want to judge them too much) are still using Paint Tool Sai 1, pirated, and it’s so old it won’t work on windows 10 computers anymore. One of the things that always had bothered me is that there was no program outside of Sai that could handle opening the Sai file format. It was such a popular program, yet noone had seemed to have tried?

So, it seems someone has tried, made a library out of it even. If you look at the readme, the reason noone besides Wunkolo has tried to support it is because sai files aren’t just encoded, no, they’re encrypted. This would be fine if it were video game saves, but a painting program is not a video game, and I was slightly horrified, as it is a technological mechanism put in place to avoid people getting to their artwork that they made rather than just the most efficient way to store it on the computer. So I now feel more compelled to have Krita be able to open these files, so people can actually access them. So I sat down with Boudewijn to figure out how much needs to be done to add it to Krita, and we got some build errors, so we’re delaying this for a bit. Made a phabricator task instead:

T11330 – Implement LibSai for importing PaintTool Sai files

Pressure Calibration Widget (Tuesday)

This was a slightly selfish thing. I had been having trouble with my pen deciding it had a different pressure curve every so often, and adjusting the global tablet curve was, while perfectly possible, getting a bit annoying. I had seen Pressure Calibration widgets in some android programs, and I figured that the way how I tried to figure out my pressure curve(messing with the tablet tester and checking the values) is a little bit too technical for people, so I decided to gather up all my focus and program a little widget that would help with that.

Right now, it asks for a soft stroke, a medium one and a heavy one and then calculates the the desired pressure from that. It’s a bit fiddly though, and I want to make it less fiddly but still friendly in how it guides you to provide the values it needs.

MR 104 – Initial Prototype Pressure Callibration Widget

HDR master class (Tuesday)

(Not really)

So, the sprint was also the first time to test Krita on exciting new hardware. One of these was Krita on an Android device(more on that later), the other was the big HDR setup provided by Intel. I had already played with it back in January, and have since the beginning of Krita’s LUT docker support played with making HDR/Scene Linear images in Krita. Thus when Raghu started painting, I ended up pointing at things to use and explaining some peculiarities(HDR is not just bright, but also wide gamut, and linear, so you are really painting with white).

Then Stefan joined in, and started asking questions, and I had to start my talk again. Then later that day Dmitry bothered David till he tried it out, and I explained everything again!

Generally, you don’t need an HDR setup to paint HDR images, but it does require a good idea of how to use the color management systems and wrapping your head around it. It seems that the latter was a really big hurdle, because artists who had come across as scared of it over IRC were, now that they could see the wide gamut colors, a lot more positive about it.

Animation cycles were shown off as well, but I had run out of juice too much to really appreciate it.

Later that evening we went to the Italian Restaurant on the corner, who miraculously made ordering á la carte work for a group of 25 people. I ended up translating the whole menu for Tusooaa and Tiar, who ended up repaying me by making fun of my habit of pulling apart the nougat candy I got with the coffee. *shakes fist in a not terribly serious way* There were later during the walk also discussions had about burning out and mental health, a rather relevant topic for freelancers.

Open Lucht Museum Arnhem (Wednesday)

I did make a windmill, but… I really should’ve stayed in Deventer and catch up on sleep. Being Dutch, this was my 5th or 7th time I had seen this particular open air museum(there’s another one(Bokrijk) in Belgium where I have been just as many times), but I had wanted to see how other people would react to it. In part because it shows all this old Dutch architecture, and in part because these are actual houses from those periods, they get carefully disassembled and then carefully rebuild brick by brick, beam by beam on the museum terrain, which in itself is quite special.

But all I could think when there was ‘oh man, I want to sleep’. Next time I just need to stay in Deventer, I guess.

I did get to take a peek at other people’s sketchbooks and see, to my satisfaction, I am not the only person to just write notes and todo lists in the sketchbook as well.

At dinner, we mostly talked about the weather, and confusion over the lack of spicyness in the other wise spicy cuisine of Indonesia(which was later revealed to be caused by the waiters not understanding we had wanted a mix of spicy and non-spicy things). And also that box-beds are really weird.

Taking Notes (Thursday Afternoon)

Given the bad decision I had made yesterday to go to the museum, I decided to be less dumb and tell everyone I’d sleep during the morning.

And then when I joined everyone, it turned there had been half a meeting during the morning. And Hellozee was kind of hinting that I should definitely take the notes for the afternoon(looking at his notes and his own description of that day, taking notes had been a bit too intense for him). And later he ranted at me about the text tool, and I told him that ‘Don’t worry, we know it is clunky as hell. Identifying that isn’t what is necessary to fix it’. (We have several problems, the first being the actual font stack itself, so we can have shaping for scripts like those for Arabic and Hindi, then there’s the laying out, so we can have wordwrap and vertical layout for CJK scripts, and only after those are solved we can even start thinking of improving the UI).

Anyhow, the second part of the meeting was about instagram, marketing, and just having a bit of fun with getting people to show off their art they made with Krita. The thing is of course that if you want it to be a little bit of fun, you need to be very thorough in how you handle it. Like, competition could lead to it feeling like a dog-eat-dog style competition, and we also need to make it really clear how to deal with the usual ethics around artists and ‘working for exposure’. Sara Tepes was the one who wants to start up the Krita account for Instagram, which I am really thankful of. She also began with the discussion on this, and I feel a little bad because I pointed out the ethical aspect by making fun of ‘working for exposure’, and I later realized that she was new to the sprint, and maybe that had been a bit too forward.

And then I didn’t get the chance to talk to her afterwards, so I couldn’t apologize. I did get some comments from others that they were glad I brought it up, but still it could’ve been nicer. orz

In the end we came to a compromise that people seemed comfortable with: A cycle of several images, selected from things people explicitly tag to be included on social media, for a short period, and a general page that explains how the whole process works so that there’s no confusion on what and why and how, and that it can just be a fun thing for people to do.

Android Testing (Friday)

I had poked at the android version, but last time it had not yet have graphics acceleration support, so it was really slow. This time I could really sit down and test it. It’s definitely gotten a lot better, and I can see myself or other artists having this as an alternative to a sketchbook to sit down and doodle on while the computer is for the bigger intensive work.

It was also a little funny, when I showed to someone it was pressure sensitive, all the other artists present one-by-one walked over to me to try poke the screen with a stylus. I guess we generally have so much trouble to get pressure to work on desktop devices it’s a little unbelievable it would just work on the mobile device.

T11355 – General feedback Android version.

That evening discussions were mostly about language, and photoshop’s magnetic lasso tool crashing, and that Europeans talk about language a lot.

Saturday

On Saturday I read an academic book of 300~ pages, something which I had really needed after all this. I felt a lot more clear headed after wards. I had attempted to help Boudewijn with bugtriaging, which is something we usually do on a sprint, but I just couldn’t concentrate.

We were all too tired to talk much on Saturday. I can only remember eating.

Sunday

On Sunday I spent some time with Boudewijn going through the meeting notes and turning it into the sprint report. Boudewijn then spend 5 times trying to explain the current release schedule to me, and now I have my automated mails setup so people get warned about backporting their fixes and about the upcoming monthly release schedule.

In the evening I read through the Animator’s Survival Kit. We have a bit of an issue where it seems Krita’s animation tools are so intuitive that when it comes to the unintuitive things that are inherent to big projects themselves (ram usage, planning, pipeline), people get utterly confused.

We’ve already been doing a lot of things in that area: making it more obvious when you are running out of ram, making the render dialog a bit better, making onion skins a bit more guiding. But now I am also rewriting the animation page and trying to convey to aspiring animators that they cannot do a one hour 60 fps film in a single krita file, and that they will need to do things like planning. The Animator’s Survival Kit is a book that’s largely about planning, which very little talked about, so hence why it is suggested to aspiring animators a lot, and I was reading it through to make sure I wasn’t about to suggest nonsense.

We had, after all the Indians had left, gone to an Indian restaurant. Discussions were about spicy food, language and Europe.

Monday

On Monday I stuck around for the irc meeting and afterwards went home.

It was lovely to meet everyone individually, and each singular conversation I had, had been lovely, but this is really one of those situations where I really need to learn to take more breaks and not be too angry at myself for that. I hope to meet everyone in the future again in a less crowded setting so I can actually have all the fun of meeting fellow contributors and none of the exhausting parts. The todo list we’ve accumulated is a bit daunting, but hopefully we’ll get through it together.

As a conclusion, it was very nice to be at the sprint and to be able to talk to real painters! Face to face meetings are really important for getting such detailed lists of new features we need to implement. If we did this discussion through Phabricator we would spend weeks on it :)

I’ve updated the kde.org/applications site so KDE now has web pages and lists the applications we produce.

In the update this week it’s gained Console apps and Addons.

Some exciting console apps we have include Clazy, kdesrc-build, KDebug Settings (a GUI app but has no menu entry) and KDialog (another GUI app but called from the command line).

This KDialog example takes on a whole new meaning after watching the Chernobyl telly drama.

And for addon projects we have stuff like File Stash, Latte Dock and KDevelop’s addons for PHP and Python.

At KDE we want to be a great place to be a home for your project and this is an important part of that.

KDevelop 5.4.1 released

Last week I finished writing all the new examples for the ROCS, together with a little description of each commented in the beginning of the code. The following examples were implemented:

• Breadth First Search;
• Depth First Search;
• Topological Sorting Algorithm;
• Kruskal Algorithm;
• Prim Algorithm;
• Dijkstra Algorithm;
• Bellman-Ford Algorithm;
• Floyd-Warshall Algorithm;
• Hopcroft-Karp Bipartite Matching Algorithm.

It is good to note that while Prim algorithm and BFS were already in rocs, they were broken and could not be run. The following image is an example of a simple description of an algorithm:

About the step-by-step execution, I am considering our possibilities. My first idea was to take a look into the debugger for the QScriptEngine class, which is the QScriptEngineDebugger class. An instance of this class can be attached to our script engine, and it provides the programmer with a interface with all the necessary tools.

Although useful, I personally think our rocs don’t need all this tools. (but they can be provided separately) There are 3 ways to stop the code execution using this debugger:

• By an not treated Exception inside the javascript code;
• By a call to the debugger instruction, that automatically invokes the debugger interface;
• By a breakpoint, that can be put in any line of the javascript code.

The first one is not really useful for us, as it halts the code execution. The second and the third can be really useful couple with an Continue command. But the second invokes the full debugger interface, which we don’t really want.

So, by using the third one, we can stop the execution in any line of the javascript code and create a step button with the Continue command to continue executing the code. The only problem is how to add the breakpoints, as there is no direct function to add them, and usually the programmer has to use the ConsoleWidget interface or the BreakpointsWidget to do this. The following image shows the Continue button, which is already working:

But the challenge of adding the breakpoints still remains. One of my ideas is to modify the code editor to accept an click on the line number bar, which triggers an signal to add/remove an breakpoint to that line. This is an clean alternative for me. But for that I have to check if the KTextEditor have this type of signal and create a way to add breakpoints in the code by function.

Some considerable time ago I wrote up instructions on how to set up a FreeBSD machine with the latest KDE Plasma Desktop. Those instructions, while fairly short (set up X, install the KDE meta-port, .. and that’s it) are a bit fiddly.

So – prompted slightly by a Twitter exchange recently – I’ve started a mini-sub-project to script the installation of a desktop environment and the bits needed to support it. To give it at least a modicum of UI, dialog(1) is used to ask for an environment to install and a display manager.

The tricky bits – pointed out to me after I started – are hardware support, although a best-effort is better than having nothing, I think.

In any case, in a VBox host it’s now down to running a single script and picking Plasma and SDDM to get a usable system for me. Other combinations have not been tested, nor has system-hardware-setup. I’ll probably maintain it for a while and if I have time and energy it’ll be tried with nVidia (those work quite well on FreeBSD) and AMD (not so much, in my experience) graphics cards when I shuffle some machines around.

Here is the script in my GitHub repository with notes-for-myself.

Installing FreeBSD is not like installing a Linux distribution. A Linux distro hands you something that will provide an operating system and more, generally with a selection of pre-installed packages and configurations. Take a look at ArcoLinux, which offers 14(?) different distribution ISOs depending on your preference for installed software.

FreeBSD doesn’t give you that – you end up with a text-mode prompt (there’s FreeBSD distributions, though, that do some extra bits, but those are outside my normal field-of-view). So it’s not really expected that you have a complete desktop experience, post-installation (nor, for that matter, a complete GitLab-server, or postfix-mail-relay, or any of the other specialised purposes for which you can use FreeBSD).

I could vaguely imagine bunging this into bsdinstall as a post-installation option, but that’s certainly not my call. Not to mention, I think there’s an effort ongoing to update the FreeBSD installer anyway, led by Devin Teske.

So to sum up: to install a FreeBSD machine with KDE Plasma, download script and run it; other desktop environments might work as well.

There is one week left of the call for papers for the foss-north IoT and Security Day. The conference takes place on October 21 at WTC in Stockholm.

We’ve already confirmed three awesome speakers and will fill the day with more contents in the weeks following the closing of the CfP, so make sure to get your submission in.

Patricia Aas

The first confirmed speaker is Patricia Aas who will speak about election security – how to ensure transparency and reliability into the election system so that it can be trusted by all – including a less technologically versed public.

Also, this is the first stage in our test of the new foss-north conference administration infrastructure, and it seems to have worked this far :-). Big thanks goes to Magnus for helping out.

This week in KDE’s Usability & Productivity initiative is massive, and I want to start by announcing a big feature: GTK3 apps with client-side decorations and headerbars using the Breeze GTK theme now respect the active KDE color scheme!

Pretty cool, huh!? This feature was written by Carson Black, our new Breeze GTK theme maintainer, and will be available in Plasma 5.17. Thanks Carson!

As you can see, the Gedit window still doesn’t display shadows–at least not on X11. shadows are displayed on Wayland, but on X11 it’s a tricky problem to solve. However I will say that that anything’s possible!

Beyond that, it’s also been a humongously enormous week for a plethora of other things too:

New Features

• The KWin window manager now supports the zwp_linux_dmabuf_v1 interface on Wayland, which, for supported hardware and drivers, should result in lower memory usage and better performance (Roman Gilg, KDE Plasma 5.17.0)
• Okular can now open and read .cb7 comic book files, and Dolphin now shows previews for them (Natsumi Higa and Kai Uwe Broulik, KDE Applications 19.12.0/Okular 1.9.0)

Bugfixes & Performance Improvements

• Fixed a bug that could cause KRunner to display duplicate search results for unit conversions with a partially-written second unit (Ismael Asensio, KDE Plasma 5.16.5)
• When music is playing and the screen locks, the media art preview on the lock screen is no longer awkwardly stretched when it’s not a perfect square (Filip Fila, KDE Plasma 5.16.5):
  
• The volume slider now provides audio feedback only when you’re done dragging it, so it doesn’t make a bunch of weird noises while being dragged (Kezi Olio, KDE Plasma 5.17.0)
• Fixed a layout problem with the Kickoff Application Launcher that could cause its tab bar to take up the entire view the first time its parent horizontal panel was changed to be vertical or vice versa (Konstantin Lisin, KDE Plasma 5.17.0)
• Fixed a security vulnerability that could have caused maliciously-crafted .desktop or .directory files to execute arbitrary code (David Faure and Kai Uwe Broulik, KDE Frameworks 5.61, and should show up as a hotpatch update for all distros soon)
• When the Kickoff Application launcher is located on a vertical panel, its tab layout is no longer messed up until it’s used every time you log in or restart Plasma (Konstantin Lisin KDE Frameworks 5.62)
• Discover now shows proper icons for Snap apps in search lists, browse lists, and app pages, as well as after they’re installed (Aleix Pol Gonzalez, KDE Frameworks 5.62):
  
• In System Settings, when you click the preview button for an inactive global theme or splash screen and then navigate to another page, you’re no longer prompted to save or discard changes, because nothing has gotten changed (me: Nate Graham, KDE Frameworks 5.62)
• Icons in .flatpakref and .directory files are now shown even when text file previews are on (me: Nate Graham, KDE Applications 19.08.0):
  

User Interface Improvements

• The notifications indicator now looks like a bell, the way it does everywhere else (Noah Davis, KDE Frameworks 5.62 with Plasma 5.16.5 or later):
  
• The notifications indicator no longer shows the number of unread notifications in the system tray so a high number doesn’t stress you out; instead, a “ringing bell” icon is shown instead. The exact number of unread notifications is available in the tooltip if you really want to see it (Noah Davis, KDE Plasma 5.17.0):
  
• The bell-style notifications indicator in the system tray now wiggles a bit when the first unread notification comes in! (Kai Uwe Broulik, KDE Plasma 5.17.0):
  
• List headers throughout System Settings have now been standardized in appearance (Björn Feber, David Redondo, me: Nate Graham, and the rest of the KDE VDG team, KDE Plasma 5.17.0):
  
  
  (This is still a work-in-progress, both in implementation and visual style)
• The presentation of System Settings’ Appearance category has been polished and re-organized (me: Nate Graham and the rest of the KDE VDG team):
  
• The System Settings Screen Locking page now has an updated and polished user interface (Björn Feber, KDE Plasma 5.17.0):
  
• The System Settings Screen Edges and Touch Screen pages now have updated and polished user interfaces (Björn Feber, KDE Plasma 5.17.0):
  
• When navigating the Kickoff Application Launcher’s Applications tab using the keyboard, the parent category is now pre-selected when going backwards (Andrey Kozlovskiy, KDE Plasma 5.17.0)
• When creating a new user’s password or changing an existing one, more descriptive messages are now shown for bad passwords (Harald Sitter, KDE Plasma 5.17.0):
  
• The sorting menu in the file open/save dialogs now also uses human-readable sort ordering descriptions, just like Dolphin (Méven Car, KDE Frameworks 5.62):
  
• When one of Dolphin’s extended tooltips is being shown, pressing a key now instantly hides it (Piotr Dabrowski, Dolphin 19.12.0)
• When drawing on a presentation using a stylus in Okular, the cursor now turns into a crosshair as the stylus approaches the screen (Oliver Sander, Okular 1.9.0)

If you’re getting the sense that KDE’s momentum is accelerating, you’re right. More and more new people are appearing all the time, and I am constantly blown away by their passion and technical abilities. We are truly blessed by… you! This couldn’t happen without the KDE community–both our contributors for making this warp factor 9 level of progress possible, and our users for providing feedback, encouragement, and being the very reason for the project to exist. And of course, the overlap between the two allows for good channels of communication to make sure we’re on the right track.

Many of those users will go on to become contributors, just like I did once. In fact, next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

As part of migrating this blog from a defunct hosting company and a Wordpress installation, to a non-defunct hosting company and Jekyll, I’m re-visiting a lot of old posts. Assuming the RSS generator is ok, that won’t bother the feed aggregators (the KDE planet in particular). The archives are slowly being filled in, and one entry from 2004 struck me:

Ok, my new machine is installed (an amd64 running FreeBSD -CURRENT, which puts me firmly at the forefront of things-unstable).

Not much has changed in 15 years, except maybe the “unstable” part. Oh, and I tend to run -STABLE now, because that’s more convenient for packaging.

Something else I spotted: in 2004 I was working on KPilot as a hobby project (alongside my PhD and whatever else was paying the bills then), so there’s lots of links to the old site.

Problem is, I let the domain registration expire long ago when Palm, Inc., the Palm Pilot, and KDE 4 ceased to be a going concern. So, that domain has been hijacked, or squatted, or whatever, with techno bla-bla-bla and recognizable scraps of text from the ancient website. Presumably downloading anything from there that pretends to be KPilot will saddle you with plenty of malware.

In any case it’s a reminder that links from (very) old blog posts are not to be trusted, particularly. Since the archives are being updated (from old Wordpress backups, and from the Internet Archive) I’ll try to fix links or point them somewhere harmless if I spot something, but no guarantess.

The sprint has officially ended yesterday and most of the participants have already left, except me, Ivan, Wolthera and Jouni. Well I would have also left as planned but I read my flight timings wrong and it would leave after 3 hours of what I thought the departure time was.

The default configuration for the Kate LSP client does now support more stuff than just C/C++ and Python out of the box.

In addition to the recently added Rust support we now support Go and LaTeX/BibTeX, too.

Configuration

The default supported server are configured via some JSON settings file we embed in our plugin resources.

Currently this looks like:

{
"servers": {
"bibtex": {
"use": "latex"
},
"c": {
"command": ["clangd", "-log=error", "--background-index"],
"commandDebug": ["clangd", "-log=verbose", "--background-index"],
"url": "https://clang.llvm.org/extra/clangd/"
},
"cpp": {
"use": "c"
},
"latex": {
"command": ["texlab"],
"url": "https://texlab.netlify.com/"
},
"go": {
"command": ["go-langserver"],
"commandDebug": ["go-langserver", "-trace"],
"url": "https://github.com/sourcegraph/go-langserver"
},
"python": {
"command": ["python3", "-m", "pyls", "--check-parent-process"],
"url": "https://github.com/palantir/python-language-server"
},
"rust": {
"command": ["rls"],
"rootIndicationFileNames": ["Cargo.lock", "Cargo.toml"],
"url": "https://github.com/rust-lang/rls"
}
}
}

The file is located at kate.git/addons/lspclient/settings.json. Merge requests to add additional languages are welcome.

I assume we need still to improve what we allow to specify in the configuration.

Currently supported configuration keys

At the moment, the following keys inside the per-language object are supported:

use

Tell the LSP client to use the LSP server for the given language for this one, too. Useful to dispatch stuff to a server supporting multiple languages, like clangd for C and C++.

command

Command line to start the LSP server.

commandDebug

Command line to start the LSP server in debug mode. This is used by Kate if the LSPCLIENT_DEBUG environment var is set to 1. If this variable is set, the LSP client itself will output debug information on stdout/stderr and the commandDebug command line should try to trigger the same for the LSP server, like e.g. using -log=verbose for clangd.

rootIndicationFileNames

For the Rust rls LSP server we added the possibility to specify a list of file names that will indicate which folder is the root for the language server. Our client will search upwards for the given file names based on the file path of the document you edit. For Rust that means we first try to locate some Cargo.lock, if that failed, we do the same for Cargo.toml.

url

URL of the home page of the LSP server implementation. At the moment not used internally, later should be shown in the UI to give people hints where to find further documentation for the matching LSP server (and how to install it).

Current State

For C/C++ with clangd the experience is already good enough for day-to-day working. What is possible can be seen in one of my previous posts, video included. I and some colleagues use the master version of Kate at work for daily coding. Sometimes Kate confuses clangd during saving of files but otherwise, no larger hiccups occur.

For Rust with rls many things work, too. We now discover the root directory for it more easily thanks to hints to look for the Cargo files. We adapted the client to support the Hover message type rls emits, too.

For the other languages: Beside some initial experiments that the servers start and you get some completion/…, not much work went into that. Help is welcome to improve their configuration and our client code to get a better experience.

Just give Kate from the master branch a test drive, here is our build it how-to. We are open for feedback on kwrite-devel@kde.org or directly via patches on invent.kde.org.

Btw., if you think our how-to or other stuff on this website is lacking, patches are welcome for that, too! The complete page is available via our GitHub instance, to try changes locally, see our README.md.

If you want an Akademy 2019 t-shirt you have until Monday 12th Aug at 1100CEST (i.e. in 2 days and a bit) to order it.

Head over to https://akademy.kde.org/2019/akademy-2019-t-shirt and get yourself one of the exclusive t-shirts with Jen's awesome design :)

Previously: 1st GSoC post 2nd GSoC post 3rd GSoC post 4th GSoC post In this GSoC entry I’ll mention two things implemented since the last blog post: syncing of scaling and NumLock settings. Aside from that, I’ll reflect on syncing of locally-installed files. Even thought I thought scaling would require changes on the SDDM side...... Continue Reading →

So far, most of my blog postings that appeared on Planet KDE were release announcements for KBibTeX. Still, I had always planned to write more about what happens on the development side of KBibTeX. Well, here comes my first try to shed light on KBibTeX&aposs internal working …

Active development of KBibTeX happens in its master branch. There are other branches created from time to time, mostly for bug fixing, i. e. allowing bug reporters to compile and test a bug fix before before the change is merged into master or a release branch. Speaking of release branches, those get forked from master every one to three years. At the time of writing, the most recent release branch is kbibtex/0.9. Actual releases, including alpha or beta releases, are tagged on those release branches.

KBibTeX is developed on Linux; personally I use the master branch on Gentoo Linux and Arch Linux. KBibTeX compiles and runs on Windows with the help of Craft (master better than kbibtex/0.9). It is on my mental TODO list to configure a free Windows-based continuous integration service to build binary packages and installers for Windows; suggestions and support are welcome. Craft supports macOS, too, to some extend as well, so I gave KBibTeX a shot on this operating system (I happen to have access to an old Mac from time to time). Running Craft and installing packages caused some trouble, as macOS is the least tested platform for Craft. Also, it seems to be more difficult to find documentation on how to solve compilation or linking problems on macOS than it is for Windows (let alone Linux). However, with the help of the residents in #kde-craft and related IRC channels, I was eventually able to start compiling KBibTeX on macOS (big thanks!).

The main issue that came up when crafting KBibTeX on macOS was the problem of linking against ICU (International Components for Unicode). This library is shipped on macOS as it is used in many other projects, but seemingly even if you install Xcode, you don't get any headers or other development files. Installing a different ICU version via Craft doesn't seem to work either. However, I am no macOS expert, so I may have gotten the details wrong …

Discussing in Craft&aposs IRC channel how to get KBibTeX installed on macOS despite its dependency on ICU, I got asked why KBibTeX needs to use ICU in the first place, given that Qt ships QTextCodec which covers most text encoding needs. My particular need is to transliterate a given Unicode text like ‘äåツ’ into a 7-bit ASCII representation. This is used among others to rewrite identifiers for BibTeX entries from whatever the user wrote or an imported BibTeX file contained to an as close as possible 7-bit ASCII representation (which is usually the lowest common denominator supported on all systems) in order to reduce issues if the file is fed into an ancient bibtex or shared with people using a different encoding or keyboard layout.

Such a transliteration is also useful in other scenarios such as if filenames are supposed to be based on a person&aposs name but still must be transcribed into ASCII to be accessible on any filesystem and for any user irrespective of keyboard layout. For example, if a filename needs to have some resemblance the Scandinavian name ‘Ångström’, the name&aposs transliteration could be ‘Angstrom’, thus a file could be named Angstrom.txt.

So, if ICU is not available, what are the alternatives? Before I adopted ICU for the transliteration task, I had used iconv. Now, my first plan to avoid hard-depending on ICU was to test for both ICU and iconv during the configuration phase (i. e. when cmake runs) and use ICU if available and fall back to iconv if no ICU was available. Depending on the chosen alternative, paths and defines (to enable or disable specific code via #ifdefs) were set.
See commit 2726f14ee9afd525c4b4998c2497ca34d30d4d9f for the implementation.

However, using iconv has some disadvantages which motivated my original move to ICU:

1. There are different iconv implementations out there and not all support transliteration.
2. The result of a transliteration may depend on the current locale. For example, ‘ä’ may get transliterated to either ‘a’ or ‘ae’.
3. Typical iconv implementations know less Unicode symbols than ICU. Results are acceptable for European or Latin-based scripts, but for everything else you far too often get ‘?’ back.

Is there a third option? Actually, yes. Qt&aposs Unicode code supports only the first 2¹⁶ symbols anyway, so it is technically feasible to maintain a mapping from Unicode character (essentially a number between 0 and 65535) to a short ASCII string like AE for ‘Æ’ (0x00C6). This mapping can be built offline with the help of a small program that does link against ICU, queries this library for a transliteration for every Unicode code point from 0 to 65535, and prints out a C/C++ source code fragment containing the mapping (almost like in the good old days with X PixMaps). This source code fragment can be included into KBibTeX to enable transliteration without requiring/depending on either ICU or iconv on the machines where KBibTeX is compiled or run. Disadvantages include the need to drag along this mapping as well as to updated it from time to time in order to keep up with updates in ICU&aposs own transliteration mappings.
See commit 82e15e3e2856317bde0471836143e6971ef260a9 where the mapping got introduced as the third option.

The solution I eventually settled with is to still test for ICU during the configuration phase and make use of it in KBibTeX as I did before. However, in case no ICU is available, the offline-generated mapping will be used to offer essentially the same functionality. Switching between both alternatives is a compile-time thing, both code paths are separated by #ifdefs.

Support for iconv has been dropped as it became the least complete solution (see commit 47485312293de32595146637c96784f83f01111e).

Now, how does this generated mapping look like? In order to minimize the data structure&aposs size I came up with the following approach: First, there is a string called const char *unidecode_text that contains any occurring plain ASCII representation once, for example only one single a that can be used for ‘a’, ‘ä’, ‘å’, etc. This string is about 28800 characters long for 65536 Unicode code points where a code point&aposs ASCII representation may be several characters long. So, quite efficient.

Second, there is an array const unsigned int unidecode_pos[] that holds a number for every of the 65536 Unicode code points. Each number contains both a position and a length telling which substring to extract from unidecode_text to get the ASCII representation. As the observed ASCII representations' lengths never exceed 31, the array&aposs unsigned ints contain the representations' lengths in their lower (least significant) five bits, the remaining more significant bits contain the positions. For example, to get the ASCII representation for ‘Ä’, use the following approach:

const char16_t unicode = 0x00C4; ///< 'A' with two dots above (diaeresis)
const int pos = unidecode_pos[unicode] >> 5;
const int len = unidecode_pos[unicode] & 31;
const char *ascii = strndup(unidecode_text + pos, len);

If you want to create a QString object, use this instead of the last line above:

const QString ascii = QString::fromLatin1(unidecode_text + pos, len);

If you would go through this code step-by-step with a debugger, you would see that unidecode_pos[unicode] has value 876481 (this value may change if the generated source code changes). Thus, pos becomes 27390 and len becomes 1. Indeed and not surprisingly, in unidecode_text at this position is the character A. BTW, value 876481 is not just used for ‘Ä’, but also for ‘À’ or ‘Â’, for example.

Above solution can be easily adjusted to work with plain C99 or modern C++. It is in no way specific to Qt or KDE, so it should be possible to use it as a potential solution to musl (a libc implementation) to implement a //TRANSLIT feature in their iconv implementation (I have not checked their code if that is possible at all).

This is a short description of a workflow I apply in git repositories that I “own”; it mostly gets applied to Calamares, the Linux installer framework, because I spend most of my development hours on that. But it also goes into ARPA2 projects and home experiments.

It’s a variation on “always summer in master”, and I call it the Git Alligator because when you draw the resulting tree in ASCII-art, horizontally (I realise that’s a pretty niche artform), you get something like this:

    /-o-o-\   /-o-o-o-\ /-o-\
o--o-------o-o---------o-----o--o

To me, that looks like the bumps on an alligator’s back. If I were a bigger fan of Antoine de Saint-Exupéry, I would probably see it as a python that has eaten multiple elephants.

Anyway, the idea is twofold:

• master is always in a good state
• I work on (roughly) one thing at a time

For each thing that I work on, I make a branch; if it’s attached to a Calamares issue, I’ll name it after the issue number. If it’s a different bit of work, I’ll name it more creatively. The branch is branched off of master (which is always in a good state). Then I go and work on the branch – commit early, commit often – until the issue is resolved or the feature implemented or whatever.

In a codebase where I’m the only contributor, or the gatekeeper for it so that I know that master remains unchanged, I know a merge can go in painlessly. In a codebase with more contributors, I might merge upstream master into my branch right at the end as a sanity check (right at the end because most of these branches are short-lived, a day or two at most for any given issue).

The alligator effect comes in when merging back to master: I always use --no-ff and I try to write an additional summary description of the branch in the merge commit.

Here’s a screenshot of Calamares history, from qgit, turned on its side like an alligator crawling to the right, (cropped a little so you don’t see where I don’t follow my own precepts and annotated with branch names).

Aside from the twofold ideas of “always summer in master” and “focus on one thing” I see a couple of other benefits:

• History if desired; this approach preserves history (all the little steps, although I do rebase and fixup and amend stuff as I go along, I don’t materially squash things).
• Conciseness when needed; having all the history is nice, but if you follow the “alligator’s tummy branch” (that is, master, along the bottom of the diagrams) you get only merge nodes with a completed bugfix or feature and a little summary: in other words, following that line of commits gives you a squashed view of what happened.
• Visual progress; each “bump” on the alligator’s back is a unit of progress. If I were to merge without --no-ff the whole thing would be smooth like a garter snake, and then it’s much harder to see the “things” that I’ve done. Instead I’d need to look at the log and untangle commit messages to see what I was working on. This has a “positivity” benefit: I can point and say “I did a thing!”

I won’t claim this approach works for everybody, or for larger teams, but it keeps me happy most days of the week, and as a side benefit I get to think about ol’ Albert the Alligator.

…and I’ve made a new wallpaper!

Yes, finally i’m back on my favourite application, Inkscape.

Hope this is a cool presentation

I called this wallpaper Mountain, because … well, there are mountains with a sun made with the KDE Neon logo. hope you like it

You can find it HERE

See you soon with other wallpapers …