Felix Ernst

F10 for the Main Menu!

We now have a new KStandardShortcut. With https://commits.kde.org/kconfig/782e43f8076e5f4a10111a6b4d2cc6b1741c9798 the F10 key is now assigned to “Open Main Menu”. This is in my opinion a big win for accessibility because up until now for blind people there was no consistent way in our software to open the main menu.

You can see the problem for yourself if you try to get to the menu bar in your favourite KDE application. Notice how you can't get there using the Tab key? You actually need to hold down the Alt key and then use mnemonics i.e. the underlined letter to jump right there. Now blind people obviously can't see those underlined letters or there might not even be a menu bar in the first place so there actually was no reliable way for them to explore all the actions our software had to offer.

So now we decided (or rather I suggested and everyone seems to agree) to have F10 as the key to open the main menu. Why F10 you ask? Well, mostly because everyone else is already using it: Gnome, Microsoft, Chrome/ium, and Firefox (but Alt also works here). We don't want users to have to care which toolkit they use when they just want to open the main menu, so F10 was the logical choice.

However, only deciding on a standard shortcut obviously isn't enough. The opening of the main menu also needs to be implemented. My goal was to implement this for many applications for free. The other goal was to not disrupt those applications too much by taking away their F10 key. Unfortunately, a little bit of disruption is still necessary and this blog is here to announce this.

So considering that we have applications that use the menu bar as their main menu and others that use a hamburger menu and others that might have neither of those or some custom main menu, the best I did for now is to implement F10 to open a main menu in KHamburgerMenu. This is handled as a normal keyboard shortcut that is assigned to KHamburgerMenu by default and which will open either the menu bar or the hamburger menu depending on what the application currently uses. Even if the application currently has both the main menu and a hamburger menu button completely hidden my implementation makes sure that a menu still opens so no blind person ever has to wonder why nothing happened.

All of this means that after upgrading to KF6, pressing F10 in your KHamburgerMenu-using application might have a keyboard shortcut conflict. This won't/shouldn't lead to a crash or anything, just to an annoying popup. This can be avoided by assigning one of the conflicting actions to something else either in application code or by the user.

If an application does not use KHamburgerMenu, there will be no change at all. I would however encourage everyone to make F10 open the main menu for every application. That's typically very easy to implement. QMenuBar for example has a method for this. But honestly, if we are talking about an application that could be using KHamburgerMenu, it might be about as much work to implement a very minimal KHamburgerMenu. In kdenlive they only had to add 20 lines for this: https://invent.kde.org/multimedia/kdenlive/-/commit/cb38d57691cfba311c0e59fd748d88a5b8690ba8 This implementation will allow users to re-assign the keyboard shortcut.

I haven't really checked how to best do this in Kirigami-based applications.

Anyways, with F10 by itself partially dealt with, there is one more F10 related accessibility feature I need to talk about:

Shift+F10 to Open Context Menus!

You see, people who can't use a mouse pointer or other pointing device rely on the keyboard to open context menus. However, many keyboards these days do not have a Menu key. Therefore there is no way to open context menus by only using a keyboard! Well, at least not in KDE applications. Actually, this is again a situation where everyone else has already decided that context menus should be triggered by Shift+F10. This is already recommended by the Web Accessibility Initiative, Microsoft, and implemented in Chrome/ium and Firefox. We are, however, behind on this.

So on to the implementation. Skip to the end of this section if you only want to know what I will be doing and how this might affect your application.

How can I make every application also listen for Shift+F10? It would be really nice if, from one day to the other, all of our software would open context menus on Shift+F10. This can be accomplished by binding Shift+F10 to the Menu key which is surprisingly easy to do even as an end user. If you want to have this functionality today, do the following (not sure if it works on Wayland):

1. Create an .Xmodmap file in your home directory (https://linux.die.net/man/1/xmodmap):

   cd 
   xmodmap -pke > .Xmodmap 
   

   This file will be used to re-assign keys or keyboard shortcuts.

2. Open that file and change the line that looks somewhat like this

   keycode 76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10
   

   to this

   keycode 76 = F10 Menu F10 F10 F10 F10 XF86Switch_VT_10
   

   Replacing this second occurrence of F10 in this line with Menu will tell the software Xmodmap that from now on, pressing the key with the keycode 76 simultaneously with Shift should be translated to a Menu key press.

Delete this file later if you don't want key re-assignment anymore.

Now obviously this means that no software anywhere will be able to use Shift+F10 for anything. Or rather: It will always be interpreted as a Menu key, so the Menu key and Shift+F10 would always do the same.

Honestly, it might be a bit rude to take away Shift+F10 from all software, but I am not sure if this would even be a problem. I kind of doubt that there are many applications that have any crucial functionality on Shift+F10 and do not allow to re-assign this. If this was the only downside to this approach, I might have tried to convince the wider KDE community that this or something similar was the best way forward. However, the thing is that this only solves the problem in situations in which we/Plasma have control over the system. This won't fix any of our software when it is used in a system in which one can't interpret Shift+F10 as Menu.

A different idea I had, which is a bit more targeted, would have been to instead implement the above as part of the KDE platform. Qt software adapts itself to the platform it runs on, so we have some control there which we can force upon software by implementing a platform plugin (see https://doc.qt.io/qt-6/qpa.html or https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbkeyboard.cpp#n903). This would then only affect Qt software instead of affecting the whole system, but once again: This only works as long as our software runs on a platform that we control.

So this needs to be implemented on a non-system layer. Frameworks perhaps? What about interpreting Shift+F10 as Menu through an EventFilter on top of the QApplication?

This works and is portable but I would still take away softwares' autonomy to use Shift+F10 as they please (or at least require them to opt out). It is also not nice for performance reasons because such an EventFilter will slightly slow down every user interaction with the application.

Okay, let's try to be even more cautious and choose a different implementation. Let's simply override QMainWindow::keyPressEvent(). Unfortunately this means that only key press events on children of QMainWindow can be handled. Key presses on secondary windows the application might have won't be within our grasp. However, on the plus side, key presses will only arrive at this method if they hadn't be handled by the application already. So we wouldn't be taking away Shift+F10 from the application! Good news!

So this is what I am going to do: I will override the QMainWindow::keyPressEvent() in the KXmlGui framework so that we post our own context menu events whenever a Shift+F10 key press comes in. This works pretty well so far from my testing. It doesn't always work unfortunately because the context menu opening was, in some cases, implemented in a way that expects either right-clicks or Menu key presses in a hard-coded way. They don't react to QContextMenuEvents as they should. So in those cases I might adapt some widgets so they behave nicely.

This will result in applications using the KXmlGui framework reacting to Shift+F10 by opening context menus if the applications don't already handle or use Shift+F10 themselves. If applications really absolutely do not want anything to happen when Shift+F10 is pressed, they can filter these events out beforehand.

Shout-out and Thanks

This work is being supported by the NLnet foundation and the European Commission! The project I am being funded for isn't really specifically about accessibility, but the people at NLnet are so nice and forward-thinking that I am allowed to do a good amount of work on improving accessibility in Dolphin as part of my grant. As is the nature of open source, in this case many KDE applications will benefit from this work.

I also want to mention Fushan Wen here even though he had nothing to do with any of the work mentioned in this blog post simply because he has been doing outstanding work for accessibility in KDE for many month now.

Contributing to KDE sometimes leads to a flood of negative or even insulting feedback. To not get disheartened by this it is important to correctly assess the significance of these comments. One possible stance to take towards these reports can be taken from punk culture.

I hope this video with hand-crafted subtitles will be a valuable resource for people stumbling into this situation in the future. Enjoy the skateboarding clips!

Man, I wish politics were boring, but that is never going to happen. The only way a party can improve their popularity is by being seen as different and in some way better, so we will always have parties saying exactly that: That the others are wrong and that they are better.

However, in many cases there is actually a right and a wrong way to engage with a problem, so what will happen if one side wants to become popular with the worse solution? Well, lies, propaganda and disinformation of course!

But all of that shouldn't matter. If you have any opinion at all about what policies are good or bad, you can look up for yourself if a specific party worked for or against you in the past. But who wants to figure that out in their free time, really? I certainly don't, but I did it anyway because various elections in Germany are coming up and some parties have been actively working against what the KDE community stands for:

https://wordsmith.social/felixernst/deutscher-wahlkampf-aus-einer-kde-perspektive (German)

Yes, that article is only in German. I don't really want to translate it because I would need to provide a lot of local background knowledge as context. I am also already annoyed enough by Germany's political landscape that I wouldn't want to spend the time figuring out how to explain it to an international readership with varying backgrounds and severity of disinformation.

In any case, I wish all of you will be able to elect the party that is the least corrupt and whose actions (or lack thereof) are the least likely to kill innocent people. Happy voting!

(German version of this post: https://wordsmith.social/felixernst/akademy-2023)

37 °C were the average daily temperature heights during the Akademy week in Thessaloniki. When you walk outside at these temperatures, your first thought is that you would rather go back inside. This used to be a temperature that one would hardly ever see there. 38 °C has not been exceeded in Thessaloniki in the 5 year span 1980 to 1984. But actually we were lucky, because the real heat wave only came around when we already left with around 44 °C in Thessaloniki and forest fires everywhere. It is a shame that with the current global political landscape none of this seems likely to become any better (to put it mildly) within our lifetimes. The nature in Greece is very nice aside from that.

But I think I have already exceeded my doom quota for this report, so back to brighter topics like the KDE community!

Meeting Everyone

I usually throw myself into these events, talking to everyone I haven't met yet and doing my part in making sure everyone feels welcome. It was especially interesting to talk to the local Greek students attending the event. One of them is already making attempts at contributing to Dolphin. I don't want to praise and pressure him here by saying his name already, but if you see a new Greek name on “This Week in KDE” in the next few weeks/month, you will know.

Some of the Greeks were part of the key note presentation “Libre Space Foundation – Empowering Open-Source Space Technologies”. Their passion for bringing their open source software to space was contagious.

I, on the other hand, am still stuck on this planet that gets hotter by the day. Did I mention the heat already? Oh right, back to topic…

Since becoming a maintainer of the Dolphin file manager about a year ago, I try to look out for the long-term health of the project. In that regard, I had an idea about how everything could go horribly wrong at this years Akademy:

Meeting the Other Dolphin Maintainer

I had never actually met the Frenchman Méven Car, who I share maintainership of Dolphin with. We hardly sent any direct messages to each other ever and none of them before April this year. All of this might seem strange considering that we have worked on Dophin together for a while now, but it also shows that one doesn't need to work behind closed doors to bring software forward. The most important aspect is having an atmosphere in which the technical and UX merits of work can be discussed honestly and without fear.

So one possible way our first meeting could go was, that we loathe each other. The next logical step would then be that we don't trust each other to be good stewards of the Dolphin project. One of us then creates a competing fork, which follows a different but similar vision, and in the end Dolphin would be stuck in an unpleasant atmosphere of hostile accussations and bad stability, eventually leading to its demise into irrelevance. 😱

In actuality, this didn't happen though. Phew!
But the above paragraph was the first story I told him.

We actually get along very well and had much time to talk about matters pertaining to Dolphin. It doesn't really seem like we have different ideas about what work needs to be done for further world domination.

Speaking of which:

Dolphin's Strategic Position

At last year's Dolphin meeting I had already tried to figure out the biggest areas of improvement by making this the headline of the meeting. Read all about it over here.

By this time, it seems like we are aware of most aspects that are still lacking in some regard. I am not really encountering a lot of fundamental criticisms anymore that I am not already aware of or which we don't know a way forward with. Most of the time we are lacking the work force to fix the more long-standing issues soon™.

Some of these were discussed at the Dolphin meeting at Akademy.

Especially Dolphin's search functionality was a big topic. It is kind of sad that people can't always rely on the Dolphin search to quickly find their files. This is partially for technical reasons, but also for user interface design reasons. You can read all about it here: https://invent.kde.org/system/dolphin/-/issues/46 Currently we are looking for a clear direction when it comes to the Dolphin search UI. You can find a mockup I made when you follow the link, but as long as nobody else is commenting on it or bringing their own design, there is no consensus. There are a lot of more technical background topics that need work as well though.

I was also wondering what Dolphin can gain from trying to break out of the Linux/Unix eco-system. Projects like Krita and Kdenlive were successfull in finding a user base outside of Linux. Dolphin is already one of (or even) the most popular file manager(s) on Linux. How much room for growth might there be if Dolphin's Windows version were more polished and visible for Windows users? Currently we don't seem to have people who want to fix bugs for this proprietary platform in their free time. Similar things could be said about a Mac or potential mobile version of Dolphin.

In line with KDE's current goals we also talked about improving testing using Selenium and AT-SPI. There is already some progress on this. Next there is the accessibility goal, for which I can point to a merge request I started creating while in Greece: https://invent.kde.org/system/dolphin/-/merge_requests/577 There is however still a lot of room for improvement when it comes to accessibility in Dolphin. Most annoyingly the “Back” and “Forward” buttons can currently not be focused using the Tab key. More contributions are always welcome in that regard. After attending all the talks about accessiblity I could find at this year's Akademy I feel a lot more confident about being able to review such contributions.

Méven has covered some more Dolphin topics in his article, so I will refer you to it: https://www.bivouak.fr/dolphin-at-akademy-2023/

Aside from Dolphin

…there is a lot more to talk about. So much more actually that it is becoming very apparent to me that I should probably cut it short now. Many of the talks are available on Peertube.

One more talk I want to highlight is “Make it talk: Adding speech to your application” by Jeremy Whiting. That one was about using speech more often in applications. I liked that talk not necessarily because I think there was a good way to add more speech to Dolphin in particular, but because it encourages improvements to tried and old basics of application design. If there was a “Speak” button next to this text you are currently reading, you would be able to transform this reading exercise into a podcast-like experience and a five-year-old kid could have listened along (and be bored about the tech-speak). I think a similar talk could be made about using animations for improved clarity when the state of an application or some data changes.

Thanks to the people who made this possible

Akademy would have been a very lonesome experience if we didn't have donors, sponsors and volunteers allowing everyone to come together. I am not sure if an international community like us could function long-term without such meetings. It gives me hope when people from eight different nations can sit at one table, talk about politics and still have a good time.

After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.

Dolphin 22.12 is going to be released in a few days so it is high time that I report on its big new feature which I have implemented: the selection mode. In this light-hearted video I will present it next to problems, whose solutions have not been implemented yet.

The video has English subtitles.

At the end of the video I am mentioning that supporting KDE through a donation is definitely a good idea. Wait … There is actually a KDE fundraiser going on right now? Here is the link: https://kde.org/fundraisers/yearend2022/

(German version: https://wordsmith.social/felixernst/dolphin-treffen-bei-barcelona)

Among my contributions towards KDE I am probably best known for becoming a dolphin maintainer recently. “Maintainers” are the people most responsible for something, and I share this responsibility with Méven Car these days.

The plan was to have a dolphin meeting at Barcelona, so I set off.

I think the most important topic for a self-organising and -acting international group like us, that swims in all seven seas, is that we meet from time to time at a coast to talk about common goals. Otherwise, everyone surfs and browses wherever the streams pulls them. Everyone has an idea about what is currently the most important thing to get to and then simply swims there as directly as they can. However sometimes it makes sense to discuss what really is the most important area to focus on. And that is exactly the topic I have chosen for our dolphin meeting.

It was new to me to act in a leading organisational role within KDE. Not only concerning Dolphin but also more generally within the ecosystem of penguin fans.

Okay, I think I have to drop the Doublespeak here because technical terms become necessary. To avoid any further confusion, I'll clarify now: Dolphin is an application. To be more precise: It is the default file manager of KDE. Méven Car and I share the responsibility of maintaining it. The text above wasn't really about animals at all!

We did meet in Barcelona and tried to figure out where the biggest areas of improvement for Dolphin might be.

Time Travel for Files and Folders?

Neal Grompa, who brings KDE's software to Fedora and other distributions, had the idea that Dolphin should have a feature that allows users to restore older states of files and folders. The practical application of this would for example be that a user — after ruining a report or article — could simply bring back an older version of that file. Or that someone — after accidentally deleting a file — could restore an older version of the folder containing that file and therefore restore the file itself.

Does that sound like magic to you? Is it even possible? Wouldn't it be necessary to have some sort of backup for this to work?

The answer to all these questions is “Yes”. You might not yet be aware that some modern file systems, which you might already be using while you are reading this, are already keeping old data around. They do this so that you can bring your computer back into a working condition if your system ever becomes dysfunctional. Popular file systems which have this as an integrated feature are BTRFS and ZFS.

While exploring the sights of Barcelona with Luca Weiss and Arjen Hiemstra, we discussed how such a time travel feature could be implemented in Dolphin, and I also researched the topic a bit on my own later: The problem I am currently seeing is that it is difficult to pinpoint where in the file system the older versions of files and folders are located. It turns out that at least for BTRFS there is no mandatory folder structure. While it is normally reasonably easy for users to find the old versions (e.g. in openSuse in “/.snapshot/SNAPSHOTNUMBER/snapshot”) the names could be anything, the age of the backup is not necessarily stored in an easily accessible manner either, and figuring out which files belong together isn't trivial either. What do we do if the file that should be restored has been moved to a different folder in the meantime?

Maybe I am missing something, but I am having difficulty inventing a reliable approach even if I ignore all the technical details for the moment. That doesn't mean that the project is impossible to implement. Not at all! Worst case one could simply search the full disk. However, I have to admit that this is too big of a project to programme on the side. If you are interested or capable to implement this nicely you would be the hero of some users who would otherwise not know how to recover the data. I am certain of that.

One would probably implement it as a KAbstractFileItemActionPlugin which opens a window in which the user could choose the version of the file or folder they want to restore.

Dolphin could be better at dealing with slow storage

In a way the most important thing for a file manager is that it quickly displays the data on storage media. We don't want the name Dolphin to only be for show: A dolphin is fast (fastest mammal in water at 64 km/h). Nothing blocks it in the oceans.

Disks, on the other hand, can be blocking which can be a problem for the other Dolphin. It might take a while for them to retrieve data especially when they are accessed over the internet or another “slow” network. But the access being slow isn't really a good excuse for Dolphin to stutter as well. Loading of data can obviously take some time but Dolphin should stay responsive and quick regardless of that.

More details on this topic can be found in our meeting notes: https://invent.kde.org/system/dolphin/-/issues/35#note_535555

Copying files and folders is wrongfully reported as completed

With some regularity users complain about data loss because they removed a storage device after the data transfer has been reported as completed.

In KDE we report a file transfer as complete when the Linux-kernel reports to us that the transfer is complete. Unfortunately, that isn't the full truth because the Linux kernel is a bit hasty in that regard. It considers a transfer as complete as soon as the data is “accessible from the new location.” However, that is a while before the data has actually been physically transferred.

I see three solutions to this: 1. Linux gains a new option so the reported transfer progress is based on physical data transfer progress. 2. We make sure ourselves that the transfer is complete before we report that it is. 3. (In the words of Kai Uwe Broulik:) “We show a very very angry message to the user when they unplug a device that is still mounted, so they will learn not to do that!”

Dolphin should allow users to manage root-owned files and folders

As you might know, the Linux security model can deal with multiple user accounts that act on the same data. Depending on the specific file or folder, different users can have different permissions when it comes to accessing, changing or executing the data.

The account that has full access to all data on the computer is typically called “root”. It is the administrator account on pretty much every computer.

If a user tries to run Dolphin with all the permissions of an administrator by using the programme “sudo”, which would allow them to edit any data on the file system, Dolphin denies this. The reason for this is that this action could potentially allow a hacker to seize full control over the computer. This blockade was put in place before I was part of KDE but users are still annoyed by it because it makes certain tasks more difficult for them. How can we improve this situation without introducing new security hazards for companies and users alike?

Harald Sitter created an alternative, more secure method (https://apachelog.wordpress.com/2022/08/04/kio-admin/) which allows users to manipulate all data. We might integrate it better into Dolphin eventually.

I also recently discussed a different more immediate solution with Nate Graham: We know that in the past years various methods have emerged to bypass the blockade. These methods, that reduce security, are quite popular. The blockade in Dolphin doesn't really stop users who want to do an insecure thing. So instead of trying to hinder users more effectively, we should take the chance and inform them about the dangers of what they are trying to do. If they still want to continue after that, we can't and shouldn't stop them. It could be a good idea to transform the block into more of a lock with an easy way to open it legitimately.

---

So much for what was discussed at the Dolphin Meeting. The rest of this article is about other topics that are relevant to me.

Dolphin for Phones?

In Barcelona I talked a lot with the young developers who strive to make an adapted version of KDE Plasma a success on mobile phones. I hope this software will soon become a viable alternative to Google's Android for the average user. There is some interest to have the file manager that people know and love from their computer also available on their phone.

They didn't know — and neither do you probably — that Dolphin is already so flexible and touch-friendly that not too much work should be necessary to bring Dolphin in a state that is nice to use on phones:

We would probably need a separate configuration for phones, so users can easily install Dolphin in such a fitted state. Are you interested in making Dolphin shine in the mobile space? Contributions are always welcome!

Dolphin and the “Blue Angel”

I talked with Joseph P. De Veaugh-Geiss, who supports the eco-friendly “Blauer Engel For FOSS” project, about the possibility of also certifying Dolphin with the “Blauer Engel”. Question is: What are the direct benefits we expect from such a move? Eventually, it could push governmental institutions towards using Dolphin but Joseph explained that they probably wouldn't switch to Linux for this alone. To his surprise — and maybe yours too — Dolphin already works on Microsoft Windows and to my knowledge even on macOS. It has some rough edges on Windows and nobody really takes care of those at the moment. Would that be worthwhile? If we were to popularise the Windows version, would that lead to a lot more free and eco-friendly computing? I am not sure if we shouldn't rather use our limited resources on other things.

You might notice by now that there is way more meaningful work to do in Dolphin alone than we can realistically undertake with our small group of volunteer developers. It would be great if even more friendly contributors would join the project all of a sudden. :)

Documentation in the Application

Another topic that is dear to my heart is that our software should also be usable by computer-illiterate users. We accomplish this with guides and help texts among other things. Some of my efforts to have more help available were successful. One example are the little help buttons which have made their way to various parts of KDE by now after I introduced them on the “Fonts” settings page only two years ago (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/51). In a similar vein I added a feature to many applications that allows users to invoke exhaustive help directly from an application's user interface. You might have noticed the little “Press Shift for more.”-notes which for example show up when you hover your mouse cursor over a button in Dolphin. In my opinion every KDE application should provide more help this way.

I was in the meeting about writing guides and documentation for the web page https://userbase.kde.org/Welcome_to_KDE_UserBase and tried to promote the idea there that it might make more sense in many cases to have help available directly where it is needed: in the application. Unfortunately, I didn't get the impression that I was able to convince the attendees of that. So instead, I'll repeat here that every step we put between the user and the available help leads to less users actually using that help. When a user wants to know what a button does, the help should be available right there either next to the button or invokable directly from the button.

On a positive note I noticed that some KDE contributors have already figured out the benefits of this feature. Kai is a fan for example. I hope it is only a matter of time until this new way of providing help is used as naturally as the two-year-old little help buttons are by now in system settings.

So much about my endeavours. If you read with interest until now, you might also be interested in my videos about KDE development: https://tube.tchncs.de/c/felix_ernst/videos

Thanks to KDE e.V. and Its Donors

Meeting the unique group that traveled to Akademy 2022 in Barcelona this year held many benefits for our future collaborations and therefore ultimately for our software. The text above is already way too long even though I nearly exclusively talked about Dolphin. So many other topics would be worth mentioning. Above all else how great it was for me to meet all these friendly KDE contributors in person for the first time.

I would like to thank KDE e.V. and the many donors to that organisation for paying the majority of my travel expenses. After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.

KDE Dev-Vlog 4: Too Much Spectacle!

Sometimes it is the smallest thing that makes the biggest difference for our users. This video shows the cause and the thoughts behind such a small change on a small application. Such a change would normally never be sensationalised but then this video came along!

KDE Dev-Vlog 3: The Final of the Gwenview Trilogy

For several weeks we have been working on the user interface of KDE's standard image viewer Gwenview and now the date for the release is just around the corner. In this video five remaining problems are pointed out. We were able to implement solutions to most of them in time for the Gwenview 21.08 release.

KDE Dev-Vlog 2: The Eye of the Beholder

This video continues right where the prior one left off: Improving the user interface of Gwenview, the default image viewer of KDE.

Different than the first video, this one is slightly thrilling at times. It also has more of a focus on showing the work processes instead of mostly presenting the results and thoughts behind it.

Have fun!

This is a German video with hand-crafted English subtitles.

KDE Dev-Vlog 1: Gwenview becomes more pretty

Hello! I've been contributing to KDE software for a while but this is the first blog post I am writing.

Over the last couple of weeks we have been improving the user interface of the default KDE image viewer Gwenview. Instead of just writing a text about the steps of turning a mockup into reality I made a video. I think it is way easier to show the evolution this way and it is also more fun for me personally. I think the video turned out great overall so please enjoy!

I went through the effort of writing English subtitles for this German video so I hope you won't mind reading them.

Strangely enough this is the first time the KDE community can see moving pictures of me even though I've been contributing for over two years now: I didn't have a webcam until recently and in-person events weren't possible because of Covid.