Cleaning up the KDE Store

In August of last year, i wrote a blog entry about my experience at Akademy 2017 in the amazing Almería, and in that blog entry, amongst many other things, i wrote about an effort which had been slowly brewing, conceptually, for about a year by then: Tagging support in the Open Collaboration Services API. Now, what does that have to do with the KDE Store, you might say? Well, that is the API used by the KNewStuff framework to interface with the store, and that in turn is what is used in the many various places in our software which show shiny, new content for downloading (or to put it in a different way: used by our software to let users Get Hot New Stuff).

For Your Immediate Consumption

I am proud to announce that as of KDE Frameworks 5.51.0, a major patch for KNewStuff was merged, which expands substantially on some basic tag data handling functionality previously added to the Attica framework. One thing it includes, amongst others, is a test tool. Have a screenshot, because those are shiny and make people look at blog entries ;)

A usable test tool for KNewStuff would make testing KNewStuff easier, you say? Well, in that case, have a usable test tool for KNewStuff.

Some of you brave people running Frameworks from Neon's nightly packages saw an explosion when using Discover a few weeks ago, and i'd just like to also extend an apology to you, as that was my fault for temporarily introducing a binary incompatibility in the first merged version of that patch. Thank you, also, for actually running this, as without you we might have not found this bug before releasing, at which point it would have been too late to fix. So, thank you for your invaluable testing and reporting work! This double merge of the patch is also why you might notice two entries of that patch being mentioned in the changelog.

Immediate Culminations

So, apart from shiny new test tools, what sort of shiny things can you, as a user or developer of KDE software, expect when running it on top of KF5.51? Well, one important thing you will notice (or, rather, hopefully not notice too much) is that the content offered to you in for example Plasma's Get New Wallpapers dialogue or KDEnlive's templates are going to be both installable and usable. This does require intervention by the KDE Store's moderators, who are the ones that can mark content as something KNewStuff should hide by default, and is why a call went out for assistance there a couple of months ago, so we could prepare for the arrival of this patch. Incidentally, if you find anything off on the store, please do tell us about it and we'll get right on it!

One very important point i feel i need to make before continuing: The basic filtering functionality I'm about to describe is entirely backward compatible, with no side effects other than the filtering just not happening if an application using it is run on top of an older version of KNewStuff. This means if you want to add this to your software, you won't need to wait for your favourite distros to get all up to date with Frameworks.

As an example of something slightly more involved than just hiding those bits explicitly marked as unwanted on the server, have a couple of screenshots of a bit more of the functionality in this patch. On the left we have the test category Comics on share.krita.org, with one comic (supplied as an ePub file in this case), one non-downloadable comic (still technically a comic, but it's a link to a website - technically fine for this category, but not downloadable), and one spam entry (fairly sure this stuff isn't a comic book of any kind...). On the right, the same data is shown in Peruse,  but with the two non-usable entries filtered out for having either no comic to download, or for being spam and explicitly excluded by a moderator.

No modifications were done in Peruse's code itself either, only the knsrc configuration file, which had the following line added to it:

DownloadTagFilter=data##mimetype==application/x-cbz,data##mimetype==application/x-cbr,data##mimetype==application/x-cb7,data##mimetype==application/x-cbt,data##mimetype==application/x-cba,data##mimetype==application/vnd.comicbook+zip,data##mimetype==application/vnd.comicbook+rar,data##mimetype==application/vnd.ms-htmlhelp,data##mimetype==image/vnd.djvu,data##mimetype==image/x-djvu,data##mimetype==application/epub+zip,data##mimetype==application/pdf

This somewhat unsightly chunk means, fairly simply, that there should be a filter on the content item's download items, which should accept only entries in which at least one of those download items had one of the listed entries for the data##mimetype tag. The documentation for the filtering of content items can be found right over here and here for download item tags, alongside KNewStuff's other API documentation.

If you want to do something more involved than what is possible using a static list of tags like that, you can absolutely add the filters manually through code. Do this by calling the KNSCore::Engine::addTagFilter and addDownloadTagFilter functions, using the formats listed in TagsFilterChecker's documentation.

Future Prospects

What does the future hold? Well, for KNewStuff itself, the functionality as it stands now is pretty powerful already, but if you have ideas for enhancements, please do get in touch, either directly to me (i'm not difficult to find, to the best of my knowledge i'm the only leinir around), or on IRC (i'm leinir on many of KDE's various channels on Freenode and on our Telegram groups, on Twitter and so on), or even better, surprise us with a patch over on Phabricator.

What are all these AppImage being filtered by architecture? Well, then, that's certainly something we should perhaps be doing more of now that it's possible to do so... ;)

One future prospect which is very immediate is going to be enhancing the KDE Store support in Discover. Right now, Discover's support for content coming through KNewStuff is limited to, effectively, just showing the items offered by all the knsrc files on the system and managing their installation and removal. This is already lovely, but enhancing this functionality by adding such things as explicit, user specified filtering or browsing through tags supplied by the creators, or by computer architecture and the like for things which require running would be very handy (for example for supporting downloading and installing AppImages from the AppImage section on the store).

Thank You!

The future, then, is very much full of shiny possibilities, and while i am under no illusion that anybody is going to be quite as enthusiastic as someone who has been working (on and off) on this functionality for over two years, i do hope that some of my excitement might have rubbed off on you.

---

The word (/abbreviation) of the day is: SABA (because having supplied air breathing apparatus would be handy with the bitumen removal chemicals being used in our house at the moment)