Your Hot New Stuff Here

KNewStuff, our Framework designed to make it as easy as possible for people to Get Hot New Stuff for whatever app they're running, and for the people who make those apps to add that same functionality to the apps, has for some time suggested that the KDE Store has the ability to accept uploading of content directly from the application. Unfortunately, due to the way this was originally built (which was essentially built around the idea that People Are Nice) turned out to be a fairly effective vector for spam and malicious content.

The result of this is that for several years, while KNewStuff has had an implementation of the OCS Content Create functionality, there is no serverside implementation which supports it as it stands. Which is a shame, especially when, while we may not be able to do it through the API because people are, apparently, sometimes Not Nice, what we can do instead is make it easier for people who are nice to learn how to add their own stuff to those listings.

Quickly Now!

How about that discoverability, eh?

 

Enter NewStuff.UploadPage and a few little hooks scattered through the rest of the Framework, such as a context action in NewStuff.Page which pushes an UploadPage to the page stack, and a reimplemented KNS3::UploadDialog which wraps up the QtQuick based UploadPage in a dialog, so those who use the existing dialog don't end up without functionality. This was added from the merge request right over here, if you would like to see what the process looked like.

How about using a Dialog? Even More Discoverable-er!

Some Side Effects

While working on this innocent seeming bit of stuff, i ran into few little things that needed to be done first. Of course, i could have hacked this and just Made It Work, but also that is not what we do in KDE.

The first, probably smallest thing is that this inherently shows up in our mobile apps, because it's now a part of both Page and Dialog now. Not that there's a problem with people finding their way to the store and uploading things there, but if we catch just a couple of people who would have otherwise not uploaded their stuff for the rest of the world to see, well, i'll chalk that down as a win :D

As for more technical things, the way in which one would get a list of the providers known to a KNewStuffCore::Engine was previously all manner of awkward, and really does not fit into how a modern Qt application works (that is, you'd call one function to get some string IDs, then you'd call another function to get each provider, and there was no good way to keep track of what might happen if another got added late, and so on). So, we now have a little model, KNSCore::ProvidersModel, which handles this, and just gives you a list of all the Providers known to an Engine, with a bunch of roles that lets you read all the information you need.

Did you know KNewStuff supports multiple providers?

Another long standing issue in KNewStuffCore::Engine, as non-critical as it was, is that it never properly understood what to do with a relative path for a knsrc file. In daily operation this isn't an issue at all, since you just pass it the filename of an installed one, or the full path if you manage your own, and that works just fine. For testing, though, being able to pass in a relative path to for example the multi-provider test knsrc shown in the upload page screenshot above is just kind of handy.

KNewStuff is supposed to be able to handle multiple languages. This turns out to never have worked right for the StaticXML provider, which would simply run through all the title entries, and assign all of them to the provider's title string, which would invariably end up with the last one. Now, though, it will pick the correct one, depending on the current system locale.

Thoughts?

The intention (of course) for NewStuff.UploadPage and the functionality its name suggests is to be expanded in the future. We are looking into ways for how to add the upload functionality back in, in a way that does not also turn into a spam vector. One method we have considered here is to, basically, retain the functionality in OCS as it exists right now, but have a vetting process for users (which then will need some way to essentially "knock" to be allowed API upload privileges). Another idea we have floated is to not allow new content to be added, but for it to be possible to change existing content. I am not really sure precisely what to do, and i also see the two previous ideas could potentially work simultaneously. But, for the time being, while we work this out, we now have a way to at least guide people through to how to actually add their own content to the store (and, indeed, any other source that KNewStuff handles).

---

The word of the day is: Incremental. Because this obviously isn't the end product here, there will be website-less uploads again, sometime, somehow!