Tuesday, April 23, 2019

Bundle Up, It's Time To Discover Some Apps

The Short Of The Long

(or tl;dr)

Would you like to try out Discover's AppImageHub integration? Sure you do! You'll need Discover from git master, and you'll want to install the storekdeapps.knsrc file (which you for now can get by installing the bits found in this scratch repository). Then all you need to do is start up your shiny, new Discover and navigate through Applications to the KDE Store Apps category. Early days, but there you go!

The Long of the Short

(or gimme all that juicy stuff)

And now the long version with me writing about history and stuff, accompanied by a bunch of screenshots and old videos and doodads and whatnot!

2009: The Gluon Years

Once, in the long ago times, before i had finished attending university, i and a few others got together to describe what we then called Gaming Freedom (thanks archive.org for providing us with a functioning link, there, as we've shut down the original site). Some of you reading this will remember a project called Gluon, which was designed as a (primarily) 2D game engine, which would use QML as both the UI language and the internal scripting system, and envisioned as a way to easily create, distribute, play and interact with games, as both creators and players of games. Have a video of me talking about this idea for a while:


2010: The Age of Bretzn

Later on, straight out of university, i was hired by then opendesktop.org front person Frank Karlitschek to work with him and a few others on Project Bretzn, which was envisioned as being a way to close the loop and provide a fix for the questionmark on the number two step in the following three-step process:
  1. Build app using some IDE
  2. ?
  3. have users download app from e.g. opendesktop.org's software categories
You might notice a similarity between this and the concepts we described in Gluon's vision. In this project, however, we did indeed achieve the goal, at least for some Linux distributions, by using the then newly renamed Open Build Service to do the heavy lifting of actually building packages. We did this through creating a plugin for Qt Creator which created a set of basic OBS instructions, upload sources, and then once OBS had created packages, distribute those automatically using the Open Collaboration Services API, for which we created an extension supposed to interact with OBS directly. You might be forgiven for not having heard too much about this effort; while it did in fact work, it was perhaps a little more like a proof of concept than an actual, finished product, and after six months of work, we ran out of funds and i had to find somewhere else to pay my rent.


2016: Splitting Frameworks

Since then, i have been working on Open Collaboration Services and KNewStuff on and off, and in the autumn of 2016 i fronted a project to split KNewStuff's UI logic from the logic of its core. Initially this was aimed at allowing the use of KNewStuff entirely without having to link to QWidgets and the like, but it also resulted in a much more sleek engine, which reduced the requirements of the KNewStuffCore to a strict minimum (that is to say, while the KNewStuff Framework is Tier 3, if you only require KNewStuffCore, you can consider it effectively a Tier 2 Framework).

As a result of this work, in addition to being able to build store support into the Peruse comic book reader, it meant that the shiny new software manager Discover was able to finally start allowing users a central location to manage the Plasma extensions and addons which were previously managed in all sorts of varied locations throughout the Plasma Desktop UI. It further, and very rapidly, ended up also showing literally all Application extensions provided by any KNewStuff configuration file found on the system, again in one central location.

2017-2018: Folksonomic Adaptations

One thing which has, arguably, been missing from the Open Collaboration Services API is the ability to filter on types of information which are highly tied to the specific type of content found in some category. The reason this feature has been missing is that OCS itself is designed very explicitly to be content type agnostic. What that means is that if some piece of information is not generally applicable to the vast majority of content, then it isn't exposed through the API.

A couple of examples describe fairly simply how this might be less than great: Say you have a category which is supposed to contain electronic books. This might cause problems for clients consuming this content, as while that might be interpreted to mean anything like epub, mobi, cbz, cbr, dejavue, pdf or indeed any other number of assorted formats used to distribute electronic book content, not all clients are going to be able to actually consume that content. So, being able to filter out bits that you don't support would be very handy.

Since the end of 2018, both the KDE Store, and the Attica and KNewStuffCore frameworks support filtering by a variety of bits of information which are defined per category, rather than directly in the API. See also this maniphest task for the proposed OCS extension (and if anybody reading can help me get my fdo account credentials back so we can get it ratified, do get in touch ;) ).

2019: Bundles of Discoveries

With the ability to filter things based on any arbitrary number of things, it was finally time to get all of this tied together and put a nice bow on top. We had always had the ability to show the applications in Discover, ever since the KNewStuffCore split, but they would invariably show up in a huge bunch listed simply under the name of the configuration file representing them, and underneath the Application Addons category rather than Applications, and you would also get shown literally everything in the categories as well, rather than only the applications you'd be able to actually download and run on your particular device, as well as a few other little annoyances (like the Launch button saying Use instead).

As of now, while things are not rosy and there is certainly more work to be done, we are a very great deal of the way there, and i think it's time i did that thing where i ask people to try it out and tell me which bits are absolutely totally wrong and where i can then see who is wrong (likely me) and how to fix it (hopefully easily).

Thank you to the one or two people who've read until now, and i hope you've enjoyed reading about my personal journey through software distribution :D

You promised me screenshots!

I absolutely did, and here you go! The culmination of ten years of scheming and plotting has come to fruition, and we finally have a way to deliver software in a more social fashion. Now, I realise you are going to scream at us all and say distributions are great at this. They totally are, and that's not the point here, and i would like if we could aim that discussion elsewhere (you will notice how Discover still very much has all the distribution packages up front and centre, particularly in the last screenshot).

That's a whole lot of applications there, in a whole lot of nicely nested categories, you might say, and you'd be right, thank you so much for noticing that!
Oh look, SuperTux, i know that game! Nice screenshots there, think I might just click install on that one.

Oh hey, now that it's installed, guess I'll just click launch...


Nice, let's do this thing, time to do a bit of running and jumping with our favourite, lovable chubby penguin mascot!

Hey, look, it's right there alongside all the other bits of software I've installed, how handy!




The word of the day is: Sunshine. Because we seem to have it now, yay! :)


Labels: ,

Friday, October 19, 2018

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)

Labels: ,

Thursday, August 17, 2017

Services Collaborating Openly at Akademy 2017

At the recently concluded Akademy 2017 in the incredibly hot but lovely Almería, yours truly went and did something a little silly: Submitted both a talk (which got accepted) and hosted a BoF, both about Open Collaboration Services, and the software stack which KDE builds to support that API in the software we produce. The whole thing was amazing. A great deal of work, very tiring, but all 'round amazing. I even managed to find time to hack a little bit on Calligra Gemini, which was really nice.

This blog entry collects the results from the presentation and the BoF. I realise this is quite long, but i hope that you stick with it. In the BoF rundown, i have highlighted the specific results, so hopefully you'll be able to skim-and-detail-read your specific interest areas ;)

First, A Thank You In Big Letters

Before we get to that, though, i thought i'd quickly touch on something which i've seen brought up about what the social media presence of the attendees looks like during the event: If you didn't know better, you might imagine we did nothing but eat, party and go on tours. My personal take on that is, we post those pictures to say thank you to the amazing people who provide us with the possibility to get together and talk endlessly about all those things we do. We post those pictures, at least in part, because a hundred shots of a group of people in an auditorium get a bit samey, and while the discussions are amazing, and the talks are great, they don't often make for exciting still photography. Video, however, certainly does that, and those, i hear, are under way for the presentations, and the bof wrapups are here right now :)

Nothing will stop our hackers. And this is before registration and the first presentation!

Presenting Presentations

Firstly, it felt like the presentation went reasonably well, and while i am not able to show you the video, i'll give you a quick run-down of the main topic covered in it. Our very hard working media team is working on the videos at the moment, though, so keep your eyes on the KDE Community YouTube channel to catch those when they're released.

The intention of the presentation was to introduce the idea that just because we are making Free software, that does not mean we can survive without money. Consequently, we need some way to feed funds back to the wildly creative members of our community who produce the content you can find on the KDE Store. To help work out a way of doing this in a fashion that fits in with our ideals, described by the KDE Vision, i laid out what we want to attempt to achieve in five bullet points, tongue-in-cheek called Principia pene Premium, or the principles of almost accidental reward:
  • Financial support for creators
  • Not pay-for-content
  • Easy
  • Predictable
  • Almost (but not quite) accidental
The initial point is the problem itself, that we want the creators of the content on the store to be financially rewarded somehow. The rest are limiting factors on that:

Not pay-for-content alludes to the fact that we don't want to encourage paywalls. The same way we make our software available under Free licenses of various types, we want to encourage the creators of the content used in it to release their work in similarly free ways.

Easy means easy for our creators, as well as the consumers of the content they produce. We don't want either them to have to jump through hoops to receive the funds, or to send it.

Predictable means that we want it to be reasonably predictable for those who give funds out to the creators. If we can ensure that there are stable outgoings for them, say some set amount each month or year, then it makes it easier to budget, and not have to worry. Similarly, we want to try and make it reasonably predictable for our creators, and this is where the suggestion about Liberapay made by several audience members comes in, and i will return to this in the next section.

Finally, perhaps the most core concept here is that we want to make it possible to almost (but not quite) accidentally send one of the creators funds. Almost, because of course we don't want to actually do so accidentally. If that were the case, the point of being predictable would fly right out the window. We do, however, want to make it so easy that it is practically automatically done.

All of this put together brings us to the current state of the KDE Store's financial support system: Plings. These are an automatic repayment system, which the store handles for every creator who has added PayPal account information to their profile. It is paid out monthly, and the amount is based on the Pling Factor, which is (at the time of writing) a count of how many downloads the creator has accumulated over all content items over course of the month, and each of those is counted as $0.01 USD.

Space-age looking crazy things at the Almería Solar Platform. Amazing place. Wow. So science.

Birds of a Feather Discuss Together

On Wednesday, a little while before lunch, it was time for me to attend my final BoF session of the week (as i would be leaving early Thursday). This one was slightly different, of course, because i was the host. The topic was listed as Open Collaboration Service 1.7 Preparation, but ended up being more of a discussion of what people wanted to be able to achieve with the store integration points we have available.

Most of the items which were identified were points about KNewStuff, our framework designed for easy integration of remote content using either OCS, or static sources (used by e.g. KStars for their star catalogues).

Content from alternate locations was the first item to be mentioned, which suggests a slight misunderstanding about the framework's abilities. The discussion revealed that what was needed was less a question of being able to replace existing sources in various applications, so much as needing the ability to control the access to KNewStuff more granularly. Specifically, being able to enable/disable specific sources was highlighted, perhaps through using Kiosk. It might still make sense to be able to overlay sources - one example given was the ability to overlay the wallpapers source (used in Plasma's Get New Wallpapers) with something pointing to a static archive of wallpapers (so users might be able to get a set of corporate-vetted backgrounds, rather than just one). This exact use case should already be possible, simply by providing a static XML source, and then replacing the wallpapers.knsrc file normally shipped by Plasma with another, pointing to that source.

A more complete set of Qt Quick components was requested, and certainly this would be very useful. As it stands, the components are very minimal and really only provide a way to list available items, and install/update/remove them. In particular two things were pointed out: There is no current equivalent of KNS3::Button in the components, and further no Kiosk support, both of which were mentioned as highly desired by the Limux project.

Signing and Security was highlighted as an issue. Currently, KNSCore::Security exists as a class, however it is marked as "Do not use, non-functional, internal and deprecated." However, it has no replacement that i am myself aware of, and needs attention by someone who, well, frankly knows anything of actual value about signing. OCS itself has the information and KNS does consume this and make it available, it simply seems to not be used by the framework. So, if you feel strongly about signing and security issues, and feel like getting into KNewStuff, this is a pretty good place to jump in.

Individual download item install/uninstall was mentioned as well, as something which would be distinctly useful for many things (as a simple example, you might want more than one variant of a wallpaper installed). Right now, Entries are marked as installed when one download item is installed, and uninstalling implicitly uninstalls that download item. There is a task on the KNewStuff workboard which has collected information about how to adapt the framework to support this.

But KNewStuff wasn't the only bit to get some attention. Our server-side software stack had a few comments along the way as well.

One was support for Liberapay which is a way to distribute monetary wealth between people pretty much automatically, which fits very nicely into the vision of creator support put forward in my presentation. In short, what it allows us to do

One topic which comes up regularly is adding support for the upload part of the OCS API to our server-side stack. Now, the reason for this lack is not that simply adding that is difficult at all, because it certainly isn't - quite the contrary, the functionality practically exists already. The problem here is much more a case of vetting: How do we ensure that this will not end up abused by spammers? The store already has spam entries to be handled every day, and we really want to avoid opening up a shiny, new vector for those (insert your own choice of colloquialism here) spammers to send us things we want to not have on the store. Really this deserves a write-up of its own, on account of the sheer scope of what might be done to alleviate the issues, but what we spoke about essentially came down the following:

  • Tight control of who can upload, so people have to manually be accepted by an administration/editors team as uploaders before they are given the right to do so through the API. In essence, this would be possible through establishing a network of trust, and through people using the web interface first. As we also want people to approach without necessarily knowing people who know people, a method for putting yourself up for API upload permission approval will also be needed. This might possibly be done through setting a requirement for people who have not yet contributed in other ways to do so (that is, upload some content through the web first, and then request api upload access). Finally, since we already have a process in place for KDE contributors, matching accounts with KDE commit access might also be another way to achieve a short-cut (you already have access to KDE's repositories, ability to publish things on the store would likely not be too far a stretch).
  • Quality control of the content itself. This is something which has been commented on before. Essentially, it has been discussed that having linting tools that people can use locally before uploading things would be useful (for example, to ensure that a kpackage for a Plasma applet is correct, or that a wallpaper is correctly packaged, or that there is correct data in a Krita brush resource bundle, or that an AppImage or Flatpak or Snap is what it says it is, just to mention a few). These tools might then also be used on the server-side, to ensure that uploaded content is correctly packaged. In the case of the API, what might be done is to return the result of such a process in the error message field of a potentially failed OCS content/add or content/edit call, which then in turn would be something useful to present to the user (in place of a basic "sorry, upload failed" message). 

For OCS itself, adding mimetype as an explicit way to search and filter entries and downloaditems was suggested. As it stands, it could arguably be implemented by clients and servers, however having it explicitly stated in the API would seem to make good sense.

The proposal to add tagging support to OCS currently awaiting responses on the OCS Webserver phabricator was brought up. In short, while there are review requests open for adding support for the proposal to Attica and KNewStuff respectively, the web server needs the support added as well, and further the proposal itself needs review by someone who is not me. No-one who attended the BoF felt safe in being able to review this in any sensible way, and so: If you feel like you are able to help with this, please do take part and make comments if you think something is wrong.

Finally, both at the BoF and outside of it, one idea that has been kicked around for a while and got some attention was the idea of being able to easily port and share settings between installations of our software. To be able to store some central settings remotely, such as wallpaper, Plasma theme and so on, and then apply those to a new installation of our software. OCS would be able to do this (using its key/value store), and what is needed here is integration into Plasma. However, as with many such things, this is less a technical issue (we have most of the technology in place already), and more a question of design and messaging. Those of you who have ever moved from one Windows 10 installation to another using a Microsoft account will recognise the slightly chilling feeling of the sudden, seemingly magical appearance of all your previous settings on the machine. As much as the functionality is very nifty, that feeling is certainly not.

Solar powered sun-shade platform outside the university building. With fancy steps. And KDE people on top ;)

Another Thank You, and a Wish

Akademy is not the only event KDE hosts, and very soon there is going to be another one, in Randa in the Swiss alps, this year about accessibility. I will not delve into why this topic is so important, and can only suggest you read the article describing it. It has been my enormous privilege to be a part of that several years, and while i won't be there this year, i hope you will join in and add your support.


The word of the day is: Aircon. Because the first night at the Residencia Civitas the air conditioning unit in the room i shared with Scarlett Clark did not work, making us very, very happy when it was fixed for the second night ;)

Labels: , ,

Wednesday, December 28, 2016

Peruse 1.2 "The Winter Wonderland Release"

My sister, with a cup of gløgg and some
æbleskiver, reading Wasteland Mutants in Peruse.
Today marks a very interesting day: Near enough to six months after its initial release, this will be the final release (minus any potential minor revision work) of the 1.x series of the comic book reader Peruse.

Why is it the final release, you say? Well, easy - there will be a 2.x series, which will be based upon Kirigami 2, and further have a bunch of new features and behavioural changes which all together makes it sensible to make a big version number change. So, no, this is not the final release of Peruse itself, only the 1.x series - rest assured that there is a very bright future indeed for your favourite comic book reader built by and powered by the KDE community!

Where can I get it?!

Don't want to wait? Well, certainly, don't let me stop you! Hop right over to the Peruse website and grab yourself a copy of whichever version best matches your needs.

What's in this?

While you wait for your download, let's have a look at what you can find in this shiny, new version of Peruse. The same features you found in 1.1 are still there, of course: CBZ, PDF and ePub support, alongside a few other less common ones. A handy continue-where-you-left-off feature with support for multiple books. A collection system with filtering options based on author, title, folder structure and so on. Full screen mode, with both touch and keyboard controls. All that stuff you already know.

As for new things, however, we have done some major overhauling of the PDF and ePub support, which is now considerably more solid, with less glitchy rendering and a more usable view. Still based on Okular, but using a more Peruse-like navigation system, which makes the whole thing feel more at home.

A whole bunch of little annoyances have been ironed out as well, and using Peruse is now more pleasant as a result. Things like using a more natural title for title-less comic book archives, and supporting basic ACBF information will come in handy when browsing your collection, and when reading.

What about shinies?

This version is not all just cleaning and polishing, you also have a preview of things to come: There is now a (very basic) shop, which you can find in the sidebar with the title "Get Hot New Books", which is by no means the final name, and is more alluding to the name of the technology underneath. Clicking on this entry will let you download and read comics from the share.krita.org comic section, which is currently quite low on content - something which the second thing being previewed in this version might help with.

Peruse Creator is a partner application to Peruse Reader, designed to allow the many creative people out there to easily produce comic book archives, for use not only with Peruse, but with any other comic book readers out there. The version shipped with this release is an initial, basic version, a sort of proof of concept. Even then, it already has support for creating comic book archives with ACBF information embedded, including not only titles and other basic information like that, but also genres and the like. Important to note is that comic book archives made using Peruse Creator will, even though they have ACBF information embedded, work just fine with applications which do not support this: They will simply not have the information available, and really just work like any other cbz file you might come across.

What's next?

Bear with me as I go slightly fluffy for a moment: The next step for Peruse is to close the cycle between creation and consumption. We want to make it as easy for the readers and the makers to achieve their goals, which here is, of course, to let the readers read the things the makers make. This is not simply a case of creating a store that people can put things on and get things from, it is about creating the tools which allow the readers to read the content they want to read, in the most comfortable manner possible, and for the makers to make the content they want to make, in the most comfortable manner possible. That all sounds nice and logical, right? But, what, more precisely, does it mean?

For the readers, it means creating a place where they can get that content, the store which is previewed in this version. The version in Peruse now is extremely simple, and really, it would be great to hear what you all want out of it. We have ideas of our own, like showing you what's next in a series where you have downloaded and completed reading a book, and there are more books available on the store. And to show various categories and the like in the store, to let you find things you want to read. Most of all, though, we want to hear what you want to be able to do.

For the makers, it means letting you create comics not only comfortably, but efficiently as well. The creation tool is currently simplistic, but we want to support all the features that ACBF allows for, to allow our makers to make comics which can do things they could not do on paper alone, such as frame based navigation instead of simply page-by-page navigation. Again, we want to hear from you what you want to be able to do.

We in this case are myself and the KDE Visual Design Group, and we would absolutely welcome input from everybody out there, because you are the people we want to be able to make happy. So please, get in touch and we will greatly enjoy listening to your amazing ideas, so we can create the best Peruse possible.

The word of the day is: Boiler. Because we are having a new one installed right now. Have been without heating for over a week now, so getting that sorted is nice ;)

Labels: ,

Tuesday, September 06, 2016

The Past and the Immediate of the Future, For Your Perusal

Why hello there! Gather round, and i shall spin you a tale of sadness and joy and the hard work of many, many proud and capable people.

Once upon a time there was a small community of people who wrote computer code. They had many great pieces of software, and lots of people were excited about them and wanted to make new stuff for them, like icons and templates and extension scripts. They despaired, however, when they realised it was really hard to get these new things to other people. They tried to staple them to trees, or to send floppy disks to people in the mail, but this was just not good enough.

Finally, one decided that this was just not right, and created the website kde-look.org. All who saw it were astonished and decided it was really great. The one who made it did not agree, and decided it was not good enough. Together with others, they created the GetHotNewStuff library, which was able to get those hot new things on kde-look.org directly from inside applications, and finally they were satisfied as well.

Many years passed since them, and eventually things grew and became much more than it once was. Many other sites joined the first, and the library expanded into a framework, and the babbling conversation between the website and library turned into a real language, the Open Collaboration Services standard.

The one who built this large amount of lovely stuff then became distracted with vast, new plans of malevolent world domination, trying to help people take back control of their own data, and ended up leaving his previous baby to simply exist on its own. Without the close attention of earlier years, it continued to work but did not grow or change to fit the changing world around it.

This was known by many, and many were sad but unable to do much about it. Attempts were made to at least reproduce functionality, if not content, but even those were not quite the right fit for what was needed. Then, suddenly, not long ago, another found themselves in the right place at the right time, and spoke with the first. Finally, things were moving again, and store.kde.org was born!

Comics For All By All

Why am i talking about this on a blog which is normally more about a comic book reader? Well, this is where you might want to watch the video below, of me on stage at QtCon 2016, talking endlessly and way too fast about the work i am currently doing to be able to get comic books into Peruse.


The gist of that presentation, which expands on the hints dropped in my previous blog about how Peruse Creator is becoming a thing, is that we now, with the new KDE Store site, have an actively developed digital content store again, and that this means the client libraries also need some work again.

Over the last couple of months, ideas were hatched and plans were laid, and finally code was produced, which means we now, in addition to the existing KNewStuff functionality people know as the Get Hot New Stuff star buttons in the wallpaper dialogue and many other places, have the beginnings of a set of Qt Quick components, named KNewStuffQuick, and a core library containing the majority of the non-ui dependent functionality named, cleverly, KNewStuffCore, if neither of the two ui options fit your needs.

In Peruse, what that means is that we are able to show the comic books available on the KDE Store very easily, with very few lines of code. When reading comics that you have downloaded from there, we are also able able to show those comics which are related and in the same series as that comic book, so that when you get to the last page and think you would like to read more of that comic, and there is more of it available, we can show that to you in the list, and let you download it directly from there without having to go into the store and break from your reading, alongside the rating and reviewing options available in the same place.

All in all, this is all (i think) terribly exciting stuff, and we are fast approaching the point at which we need to ask some of those makers of amazing works to help us out, so we can help them more. Nothing like a positive feedback loop to make people happy, when the positivity is both the topic and the function of the loop :)

KDE Store
Peruse ReaderPeruse Creator



The word of the day is: Laptop (because i left mine in England, which was silly when going to a place to do much hacky type stuffs)

Labels: ,

Tuesday, August 16, 2016

Peruse 1.1 "The Cuppa Release"

Slightly later than the 21st of June this year, the inaugural release of the Peruse comic book reader was made, and received with while not wide spread excitement, then certainly with mostly positive comments (and some very good suggestions). If you are a software developer yourself, you will know exactly how much this means to me. If you are not: This is what sustains us, what encourages us to continue working on the things we do. Thank you all very much!

Today marks the day at which some of those suggestions have been turned into reality. Obviously by no means all of them, some will take longer to surface than others, but even then, today marks the official release of Peruse 1.1, entitled The Cuppa Release, because hey, who doesn't like a nice cuppa, with their comics, eh? ;)


Get Peruse Now

What happened?

During the last month or so, a fair few little bits changed in Peruse, but perhaps the biggest change was not Peruse itself, but rather the Kirigami framework on which the user interface in Peruse is based. This has now also had its inaugural release, and the 1.0 release announcement included mentions of Peruse (and a quote from yours truly). Not only that, but Heise.de decided to use Peruse as the pull-in, and had a screenshot of that as their image. So, you know, that's pretty neat.

Peruse itself, of course, has not sat still while waiting for that to happen. It would not be worthy of a 1.1 version if that were the case, then it would have simply been version 1 with updated libraries. What follows is a condensed list of the changes in Peruse itself, in no particular order (since people of course will consider different things more important):
  • More natural keyboard controls (f to enter full screen, escape to exit, book details closed with escape, and navigation through the book details screen now functions as expected as well with arrow keys changing the book and enter opening the book)
  • Settings page is now a top level page, same as the bookshelves and so on, making it feel much more natural
  • The sidebar now shows which page you are currently on
  • Make the context drawer able to host subitems, and use that for the first view option (Right To Left and Left To Right navigation, aka Manga Mode)
  • Fullscreen enter/exit is now more solid (and ensures the current page is restored when switching, as that would fail sometimes)
  • Fix the page-change animation (which was never stopped like it was supposed to, causing a certain amount of heaviness where none needed to exist)
  • Don't allow dragging the pagestack around when there aren't any controls (as that's simply jarring)

My sister Liv, reading a comic, with a nice cuppa, in mum and dad's garden.
Yup, i'm visiting the parents ;)

And finally, we have another couple of options for people who want to run the application:

Firstly, people asked about packages for Arch, and a it was within the abilities of the Open Build Service to create Arch binaries, we are happy to say that such packages now exist.

Secondly, and perhaps more interestingly for a larger number of people, and part of the reason it has taken so long to get 1.1 out the door: We now have an AppImage of Peruse, available right beside all the other options on the website. Don't want to install Peruse packages, or don't have them available for your distribution? Well, if it's modern enough, you should be able to run Peruse without needing to install anything. And the size? Well, with more space optimisation to be done, and considering the sheer amount of dependencies that Okular brings with it, at 86 MiB, i don't think that it's at all bad.

What happens now?

So, what is next for Peruse? Well, other than making it better, faster, smaller, stronger and all those lovely things that might be considered a bit fluffy, there are still plenty of items on the Work Board over on the project page. One item, however, which is missing from that board right now is a little tool which is slowly taking shape in the git repository, called Peruse Creator.

Having talked with people who make comics (both hobbyists and self published full timers), one thing they've mentioned is that while they would certainly like to make it easy for people to get their comics for use in something like Peruse, and while it is fairly straightforward to create cbz archives (literally just a zip file with pictures in it), the problem remains that it is still not quite point and click easy. So, enter Peruse Creator, a tool which initially just creates those cbz files with a sprinkling of useful metainfo, the format of which is hinted at in this task. Initially that work will not include the viewports - but if we don't build the foundations, castles in the sky tend to fall down rather hard. Since that is where we are headed, let's get that foundation nice and solid, and ready to hold up all our dreams.

So, what happens now? The future? The future is full of speech bubbles and beautiful vistas and tight closeups and, above all, amazing stories told by creators throughout the world. Watch this space (and drop by QtCon if you want to know something more).



The word of the day is: Green (because that's the colour of all the pretty things in my parents' garden i can see through the window i am sat next to ;) )

Labels: ,

Wednesday, June 22, 2016

Peruse 1.0 "The Birthday Release"

One day, about half a year or so ago, it came up in a discussion that while we in KDE have a lovely document viewer named Okular, we don't have something that is well suited to actually reading things, comic books in particular. So, a project was hatched to fix this. I've blogged about it before, and made a few tweets on the topic, but today is special. Today, 1.0 happens.
(Alright, so it technically happened yesterday. But it's still special. At least, i think it's kind of special - it's called the birthday release for a reason, donchaknow ;) )

Meet the Peruse comic book reader. This little application is based on KDE Frameworks 5, and is designed with the same principles as Plasma in mind: It should get out of your way and let you read your comics, comfortably. The user interface was designed and built using the Kirigami components, which the famous diving tool Subsurface also uses, and which is being developed by KDE's Plasma and VDG teams.

The welcome page, where you can pick up reading where you left off last time, or navigate your way through your library in a range of different ways. Or, just open a file the way you might do it in other applications, if you've not got the thing you want in the library locations.

The navigation sidebar you have available when reading your comic. In full screen (click the button in the middle), with the controls hidden (tap the comic view), you can show this by swiping in from the side, or with a hook gesture by swiping up from the bottom (because Windows eats the sideways swipes).

When you reach either end of the comic and tap to try and continue past the end (by tapping the sides of the view), this drawer shows up to let you switch to other books in the same series. Because you don't want to be stuck on that cliffhanger ending, right?

What Lies Ahead

So, what is next for Peruse? Well, apart from fixing bugs which have made their way into the release, and pushing various bits of code upstream that need to be upstream (such as the karchive rar support, which i discussed with the karchive maintainer last week; more on that in a different blog post), there are some big things that need doing (and some not so big things, obviously, as well).

The things which are already planned can all be seen on the Peruse work board, but i feel that i should highlight the task entitled "Get Comics Online". Right now, the way you get comics is that you open your web browser and point it at some website where you happen to know comics can be found, such as Archive.org's Comic Books and Graphic Novels site, and then download things from there, which you then open Peruse to read. Now, that's all well and good, and that, basically, works. However, it just isn't good enough. The experience is jarring, and it really is just a bit silly when there are ways of making that much more pleasant.

Enter KNewStuff, a library created back in the olden days when the K in KDE still stood for Kool, and KDE was a bunch of software rather than a bunch of people who make software. The library was built to make it possible to get new stuff, specifically Get Hot New Stuff, into your applications, and to do so in a semi-social manner. Fast forward some ten, fifteen years, and we have a framework which, while it certainly functions (every tried getting new wallpapers using that little button in your desktop settings?), has a design which doesn't quite fit with how software tends to be built today. So, the next couple of months is going to be spent turning the functional framework into a modern, modular one which will work for a wider range of use cases and workflows. The work has already begun, and a plan was hatched at the Randa Meetings 2016 for how to proceed.

What does KNewStuff have to do with Archive.org, though? Well, honestly not a great deal. However, the plan for Peruse is to have a system which will allow you to have both KNewStuff capable sources (such as opendesktop.org, which things like Parley and KStars use in various forms), and non-ocs based ones, which will require more intervention in code form by yours truly. Archive.org's archive as linked above gives us a nice target for that: Lots of content to get, with licenses that means we can actually suggest people use it (read: it's not illegal content), and it is well structured, but not ocs based. So, having Peruse able to use those two types of sources means we should cover a fairly nice amount ground.

Ideas and Bugs

What if you have more ideas than those on the work board? Well, i would love to hear from you in that case! No idea is too crazy or far out. No, really, they're not - they may just not happen immediately ;) Anything that isn't small should likely not go on the bugtracker, though, but rather directly to me. If you want to catch me, either comment here, or get a hold of me on any number of various platforms, such as freenode irc (where i'm leinir and hang in a fair few channels), or twitter or, or, or... Basically, if you run into someone called leinir out there, it's fairly likely it'll be me.

As with all such first releases, Peruse 1.0 is a bit rough around the edges and there are plenty of features that would be great to have in there - for example, there are no visual clues to suggest you can tap on the sides of the viewport to change pages when reading, and pdf and epub support feels very different to cbr support (and much less comfortable). If you come across any of those issues, please make sure to tell me about them - submit a ticket on the bugtracker for anything you run into that isn't right (though, please, and this goes for reporting on other products as well: check and make sure it hasn't been reported before. Help us help you :) )

Even More Awesomer!

On the note of helping us help you: The final sprint towards the release happened in part at the Randa Meetings 2016, and many other amazing things were achieved there. Not only that, but other sprints that KDE has through the year consistently yield both some heavy, intense coding sessions, and a lot of decisions which are just too difficult to make when you are not face to face with the people you need to talk with. So, if you want us to keep going and make more amazing stuff, click the banner below and donate what you can. If you can't donate, spread the word instead, help us raise enough to have the sprints we need to make KDE's software even better!


The word of the day is: solstice - because this is the longest day of the year and that's pretty neat :)

Labels: ,

Thursday, June 16, 2016

Perusing Progress at Randa Meetings 2016

Over the last couple of days, the 40 or so people here in Randa have been, amongst other things, been learning how to pronounce the name of the village correctly, treated to some lovely food and chocolate, and most importantly, been very, very busy learning from each other and producing great amounts of both code and plans, and as you can see from the picture below, smiles.



One of those who have been learning new things is Chris, aka Makenshi or chaz6, my better half, who has gained KDE developer access, and is now hard at work on adding GDAL support to Marble. As you can see below, it is coming along very nicely! Not only that, the initial version of the plugin has been submitted as a review request.


For my own part, i have been hard at work getting Peruse whipped into shape for release, which has meant the getting the series navigation done more pleasantly, and the addition of translation contexts to all strings in the application. As you can see below, the drawer with book information isn't that pretty, but it works, and it pops up when you try and move past either end of the book you are reading, just like you might recognise it from your ebook reader.


It has also meant building packages for a distribution i have very little experience with. While i may be a fairly proficient user of the open build service, which i have used a great deal for rpm packages over recent years, the creation of deb packages has always been something of a dark art to me. Over the last couple of days, however, that has become much more clear. A painful sort of clarity, certainly, but clarity none the less.

The end result is that i now have, on the Peruse website, a repository of deb packages for Peruse, and for Kirigami and the Okular frameworks branch both of which it depends on, all still built on obs, which means that updating the packages is very, very simple for me, and they're shipped to the users moments after they are built. In the words of Jazz Show host Louis Balfour: Nice.


The word of the day is: peruse - because i'm a silly person who likes that word, and thinks that perusing is the most sensible way of describing the experience of consuming comic books and graphic novels :)

Labels: ,

Monday, June 13, 2016

Randa Meetings 2016 is go!

After a nice, mostly uneventful trip to Randa, which involved picking up David on the way to the airport and then a long train trip on the very pleasant Swiss trains, we are now settled into the computer room and ready to get on with this year's meeting.


So, what will i be doing this year? Well, a few things, really:
  1. Hopefully we (that is myself and my better half Chris Hills, who has come with me this year) will succeed in getting him embedded in one of the teams, which is something we've wanted to do for ages, and this year it just seemed the time to get it under way for reals yo(tm). This is already well under way as i write these words, and that's pretty neat :) Thank you for being such a welcoming community! :D
  2. Get the first real release version done of the Peruse comic book reader app, which is based on KDE Frameworks 5 and the Kirigami Qt Quick 2 UX components
  3. Begin work on the content store support in Peruse.
  4. Hopefully get the Gemini microframework whipped into some semblance of usable shape (it would be nice to be able to use Calligra Gemini 3.0 for writing). This, however, is less critical than the others, for reasons which will become clear in the hopefully not too distant future. Very positive reasons. Keep your eyes peeled ;)
Points 3 and 4 above are... well, if you have followed me since i left university, and in part even during, you will know i've been involved with a fair few of the odd supporting fringe bits of the KDE community, and... it seems like i am going to be able to tie a few of those together into something coherent and functional. So, yes, watch this spot ;)

Now, do you like what we do at these sprints? Help us keep going! Sponsor it with any amount you can, or if you can't spare any funds, spread the word :)


The word of the day is: tea. Because that is totally a thing we can have here :)

Labels: , ,

Wednesday, August 26, 2015

Gemini at Randa 2015

Last year, I wrote a blog entry about the iminent release of Calligra 2.9 and the Calligra Gemini application which became a fully fletched member of the suite. In the latter half of that entry, I touched on what the future might potentially hold, and I mentioned the possibility of extending the concept from the application level to the complete system.

This future has, finally, arrived: We are now approaching the KDE Randa Meetings 2015, whose main topic this year is bringing touch to our software. In the spirit of KDE's software being something which integrates deeply between applications and with everywhere the applications run, the Gemini concept is in my personal, and of course biased, opinion a perfect match. In a world where our software runs on devices which, effectively, fit into three basic categories (that I will outline below), it would seem silly to not attempt this adaptation.


Create, Edit and View Presentations with Calligra Gemini
by Dan Leinir Turthra Jensen

The Gemini Device Categories

On the first, we find what we have become used to calling "the desktop", but which seems to be mostly laptops these days. These are devices where we have very detailed and fine grained interaction available, with a mouse and a keyboard, or some variation on those. In short, these are devices where we can perform intricate motions with a high level of precision; the sort of interaction required to create new content from scratch. These are devices in the Create category. In Plasma terms, this is the Plasma Desktop shell.

On the second, we have our various touch based devices. Recently there has been a great many attempts to create solutions to create content on these devices, but except for a very narrow range of situations, it turns out to be awkward and cumbersome. I am not talking about the attempts where you use a stylus to paint on a tablet screen, or a bluetooth keyboard to write text here. All that does is turn the previously simple-interaction device into a precise-interaction device as described above. What I mean here is a device with only a touch screen available, be it a tablet or a phone. These do not lend themselves well to creation of new content, but what they do lend themselves to is modification of existing content, which puts them very nicely into the Edit category. For Plasma, this would be Plasma Mobile, the shell created for phones, but which runs just fine on larger touch devices as well.

The final category are those devices which have extremely limited interaction available. There are a fair few of them out there, but without getting too deep here, let's say these are devices like an eBook reader (with the slow screen refresh and in some cases very limited input in the form of arrow keys and a select button), or TVs (where we can really only depend on input in the form of numbers and sometimes not even the arrow keys and select button that we might otherwise expect). Fairly obviously, these devices are not suitable for creation of new content, and really they are not well suited to even editing of it. They are, however, uniquely suited to consumption of content. This, in Gemini terms, puts them into the View category. This would be Plasma Media Center in the Plasma world.

What can you do to help?

In essence, as you can tell, we already have the bits available. Plasma is even able to switch its shell at runtime. Thought need to be put into getting the transitioning to work right. Not on a technical level, but on a human level. How can this be done without getting in the way? It is doable, but discussion must happen, and it is exactly the sort of thing which is done best face to face, and with prototypes made with pencils, paper and scissors, not with digital tools, simply because, well, once the code is written, people get attached: Paper is simple, and clearly not supposed to be final. This is why sprints and meetings like those held in Randa are so important.

As other blog entries on Planet KDE and elsewhere have suggested, the most immediately effective way to ensure that we can do this is to help with the fundraiser, which will allow the Randa Meetings and other sprints to happen in the best way possible. As i write these words, we have currently raised €10690 of our €38500 goal, so please, donate what you can, and spread the word far and wide. This year's hash tag is #KDEsprints, if you like that sort of thing - let's try and get this thing trending! I like aiming for the stars, won't you join me? :D


Donate to the KDE Sprints 2015 fundraising campaign

The word of the day is: Donations (because we need them!)

Labels: , ,