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: , ,

Friday, November 21, 2014

Only Tangentially Related To The Stars


It's a scary moment, that time when you reach the conclusion of something which has taken up a considerable chunk of your life for months. Not a bad kind of scary, really, more a sort of exciting, i-wonder-what-others-think kind of scary. For me, this is a moment i've reached now that Calligra Gemini has been merged into the master branch of Calligra, and is scheduled to be shipped with Calligra 2.9. Another reason it's scary is that, given this is sort of my baby, and have found it's something i use actively pretty much every day now, i am now also the official maintainer of that application, which is kind of a new thing for me. If you're wondering what this whole thing is about, there's a rundown of the news over on the Dot.

At the beginning of this project it was a fairly straight forward thing for me, very similar to the Krita Gemini project in which i was sort of a code monkey, with some marketing thrown in for good measure (i produced the videos used to show off Krita Gemini for the Steam Greenlight campaign, which culminated in Krita Gemini being, to our knowledge, the first piece of free/libre software launched on the platform). I had a manager, who did the majority of the liaising with our customer, Intel, and i provided technical commentary and timelining for the features which were suggested for the application.

As the project progressed, however, the manager in charge of the project ended up taking long term ill (the background story for which is all long and sad and not really relevant here), which essentially landed me with his responsibilities as well. This is not to say it was a bad thing, really - the illness obviously was, but me ending up with those responsibilities wasn't. It meant that i became the client liaison, and the person responsible for packaging Calligra Gemini for Windows, using the same WiX based system created by Stuart Dickson and used for Krita Gemini, and for generally just keeping the project running. In short, everything to do with it bar billing the customer for the work. This was also the time during which i decided we needed to tell more people about the project, and so came the idea to OBS our way to that, and produce some packages for openSuse at least - since, well, that is what i've packaged for in the past, and OBS is just so pleasant to work with that it'd be silly not to.

And now, we stand at the point of concluding the project itself. Not completing, not finishing by a long way, this really is just the start of the journey for Calligra Gemini, and but a small step on the journey of the whole Gemini thing. Really, what Gemini is is just an interpretation of the responsive design concept, which describes how your application should fit the device you're on. What we're doing here is implementing, in the real world, applications which don't simply look and feel right, but which will adapt at runtime to changing device conditions.

Where do we go from here?

This is what my interpretation of responsive design is. Not something which looks sort of ok everywhere, but something which adapts the entire experience to give you the options which make sense where you are. For Calligra Gemini that means the three-tiered approach of Create (desktop and laptops), Edit (all touch) and View (minimally interactive devices like televisions and other infotainment style devices), or indeed any of these when the user specifically requests it.

As the world fills with all sorts of strange device form factors, we have to be able to work well on them. Laptops and desktops, phones, tablets, televisions, cars, airplanes, even fridges and all sorts of other places. Another piece of software created by KDE which takes this head on is Plasma. The people behind it have, since some time now, been working on creating a variety of frontends for it which scale to various form factors, and a chat with one developer there a short while ago made me think that well, it would be brilliant to see that adaptability happen at runtime, the way Krita and Calligra Gemini do it.

What he could tell me was that, technically speaking, it was possible to do it, but that the code path had been untested and such. This is something nobody else has done. Other shells have tried to create one thing which fits everything (calling it convergence), where KDE has realised, as a community, that the way forward is to adapt to each, not to work with the assumption that a single size fits everybody.

So, what stars is it this is tangentially related to? Easy, the ones we're shooting for ;)

The word of the day is: writing
(as in, in bed, the way i do the majority of it ;) )

Labels: , ,

Sunday, October 19, 2014

Calligra Gemini - now also for Linux :)


Some people may remember earlier this year when Krita Gemini became (to my knowledge) the first open source software to become greenlit on Steam. For those who don't, yeah, that really happened ;) Krita Gemini was a project created in cooperation between the KDE community's Calligra team, the little software consultancy KO GmbH, and a large semiconductor manufacturer named Intel, who had some devices they needed to be able to show off. Krita Gemini is available on the Steam store, though not yet for Linux (as it turns out, Steam packaging for Linux is even more awkward than building stand-alone installers for Windows, an odd sort of situation for us used to sensible package managers)


Earlier this year (late April 2014) the team from KO and Calligra which built Krita Gemini had a teleconference with the Intel team, and we agreed that other applications would be well suited to a similar attention, and we came up with the idea of building Calligra Gemini, an application which would encapsulate Words and Stage, Calligra's word processor and presentation tool respectively, in the same way that Krita Gemini encapsulates Krita, with automatic switching between the existing desktop UX and a new touch friendly UX created for the purpose. Over the last little while, i've been posting builds on the project minisite (along with release notes and screenshots and such).


So now, with the initial work on that project reaching its conclusion, i decided that it was time to expose a few more people to it than what's been the case so far. So, over the course of this weekend, between making some tasty bread, cleaning and cooking dinner, i have been working on some packages for people who don't run Windows. Specifically, i have made a set of packages for openSUSE (just 13.1, in various guises, for now - others will follow), and they're available right here (and also shown on the project's minisite linked above)


Finally, i also released a short story i've been writing over the last couple of weeks (while waiting on the editors to get back to me on the novel i've also been working on). This is relevant here because i have been dogfooding; it was written entirely using Calligra Gemini, and the pdf and ePub versions were produced using the Calligra features as well. Finally, the work is stored in a git repository, which is also controlled by Calligra Gemini's support for using Git as cloud storage. The story is available as pdf and ePub on my deviantArt page :)

The word of the day is: Geiko

Labels: , ,

Thursday, December 20, 2012

Krita Sketch is: Colourful


A quick recap of the main topic: My employer, KO GmbH, has been working on a touch version of Krita, called Krita Sketch, over the last few months, and has finally made the first release! So, i'm doing a bit of writing, talking about some of the work i've been doing as a part of this project. (you should also read the dot article, because it's good and has shiny ;) )


In the previous instalment i wrote about rounded corners, and mentioned there was something else in Krita Sketch which was round. Those who use Krita will have already encountered the colour wheel that's used to select colours in the application, and this is a very popular feature with the target audience, so of course we need it in Krita Sketch as well. This entry discusses the implementation of that element

An important point to be made here is that this will not be possible in Qt 5 (which is now finally out of the door, putting to shame all the snarky predictions of postponings  great work people!), and as such this point will need to be revisited once that comes around. However, as with all such things, there was a deadline so some shortcuts had to be made. This was one of those places where we felt it was more prudent to get it working right away, and then make it "correctly" later on. If you run into a similar situation, this will show you how. If you want to do it "the right way", there's comments on the topic here (you can still use the QQuickPaintedItem, but it is not recommended due to its inherent speed penalties - but if you have time constraints on your project, it's a straight forward way to reuse your existing work).

So, what we are talking about here is, of course, the colour selector item that you see a screenshot of above as it looks inside Krita Sketch. Under here you can see what it looks like inside Krita Desktop.


What you can see here is that there is, for all practical intentes and purposes, no difference between the two. The way this was done was, quite simply, to reuse the painting code from the widget without change.

Inside the declarative item there are a couple of bits of code which were unfortunately copied over from the widget version, but the code is reasonably small, so it's not all that much of an issue, to be fair. The code is based around the idea that you have two colour selection parts, the main part, and the sub part. For now we have only got a triangle with a circle around it, but we will be introducing the same modes as found in the desktop version at a later point in time (the code is already there, it simply is not exposed in the user interface yet). This means the paint method is really quite simple: Since the sub-parts already know how to paint themselves using QPainter, we can simply tell them to be painted in the area we have available.

Mouse events are handled very simply and similarly as well (just continue scrolling in that code there ;) ). First, on mouse down, we check whether we're handling foreground or background colours (left or right mouse button), and then we ask the main and sub components which of the two, if any, wants the input. When you then move the mouse, that component is passed the data, and that means you don't accidentally get something picked up elsewhere. As you drag the mouse around on the component, the colour is set, and Calligra's resource system is asked to handle this.

So, very simple approach as you can tell, but one which really does work, and provided some decidedly pleasant and rapid development.

To recap, if you are developing something from new, use the scene graph based drawing methods in Qt Quick 2, but if you have some existing code, you can use this method to produce a nice level of code reuse.


The word of the day is: Reusable

Labels: , ,

Tuesday, November 27, 2012

Krita Sketch is: Rounded

A quick recap of the main topic: My employer, KO GmbH, has been working on a touch version of Krita, called Krita Sketch, over the last few months, and is gearing up towards a first release. So, i'm doing a bit of writing, talking about some of the work i've been doing as a part of this project.


There are two things in Krita Sketch which are rounded, and i will be covering the first of these in this entry. The first is the simple rounded corners in various places around the application, which are done in three ways (that i will get back to in a moment), and the other is the colour selector, which is an entirely different matter. That one will be covered in the next entry.

So, rounded corners in QML, how do you do that? Well, in reality it really is quite simple, but i thought i would spend a little while talking about it anyway. In addition to just using a set of Images manually, lining them op as appropriate (which we did in a lot of places), you have two options when making them, depending on precisely what you are trying to do.

Pure QML painting

The first option is to use the radius option on a Rectangle item. A very simple approach, which does however come with one caveat, which is not the radius itself, but rather a problem of how borders work in Qt in general (it will also be known to people who work with WebKit, which behaves in the same way). Shortly, borders are painted on the centre of the element's edge, rather than on either side of it. If you are aware of this, it is easy enough to work with, but you must be aware of the behaviour for it all to make sense.

Using the radius property means that all four corners on the element will be rounded a number of pixels equal to that radius. Easy to work with. Except in the case where you only want some of your corners to be rounded. We have not used this trick in Krita Sketch, but it's a useful trick to know: Use the Item item's clipping property, fill it with your rounded-cornered Rectangle, and make that Rectangle larger than the Item by way of adding negative margins in the appropriate places. For example, the following code will give you a blue rectangle with the two top corners rounded:

BlueRectangle.qml:


import QtQuick 1.0
Item {
    Item {
        width: 50;
        height: 50;
        anchors.centerIn: parent;
        clip: true;
        Rectangle {
            anchors {
                fill: parent;
                bottomMargin: -radius;
            }
            radius: 10;
            color: "blue";
        }
    }
}


A total hack? Yes, absolutely. But it works a treat :)

The BorderImage Compoment

The solution we should have used in Krita Sketch in the majority of cases was the BorderImage component. A very simple but extremely powerful component, which shortly takes an image, cuts it into nine slices according to what's set in your border property, and arranges those slices according to your desire (scaling and tiling according to the settings you choose). The documentation for this component is extensive and well written, so i won't talk about this other than saying it is very powerful.

An important thing, however, is to make sure that you know it exists. It is a non-obvious thing to have available, and if you do not know it's there you'll find yourself reinventing a lot of things and doing a lot of manual cutting which, on mobile devices in particular, means that you are using more texture space than you should. In our case this is not any serious cost (we have a LOT of images in memory already, and not using this component does not seriously impact on this), but if you are targeting mobile devices, in particular the smaller variety (smartphones), make sure you're not reinventing the wheel here.


The word of the day is: Squircle

Labels: , ,