Where in we talk more about the value of community design, talk about creating resources for developers, why it's cool checking out other designers work, show some details from the coming Plasma Theme (and a sneaky special gift to our fine readers ;) ) and then end with a short comment on politics.

From Marco Martins blog and Desktop. Plasma Next.

What a week, what a week... One of my favorite things is going in to the VDG forums at the KDE-forum and read and reply to posts. There are too many awesome things to talk about going on and ALL IN THE OPEN. Some would call it "design by committee" I call it "social design work"!

First off the Awesome Community Icon's need a mention. The idea came from a while back when a proposed set of monochrome icons to be used in applications and widgets based of the Awesome Font was talked about. It never really got further than that but now that work has started up again in earnest. The idea being to make a simple, lean and above all symbolic icon language to be used in Open Source projects and KDE projects especially. By being monochrome, it can also use the coming effect of changing to the color of the chosen text color in the color theme.
Right now a group of community members (me included) are sifting through the available icons and sorting them into the correct places, community member Davidwright will then work it into a git-thing and hopefully a member of the VDG will sort out a project page with all icons accessible and nice so anyone can use them. Hopefully we will also be able to describe all icon sets and what the name of the icon mean so further icon design work is made simpler.

We're also hoping to include monochrome versions of LegnaVI's Krita icons to create some kind of unification in this project, trying to make all KDE apps to use the same iconset.
If you feel like helping out KDE, join in the fun and help out - the beginning of the thread has links to the Google Spreadsheet we're using for work and the Awesome Font page we're using as base for all icons. Do it!

Then Leroux also finished his network icons that I posted about earlier and I suggest anyone who feels a passion for icons and themeing should check them out and perhaps use them in a theme (contact him so you guys can collaborate). Hopefully we will be able to use part of them in the AKI (yes "Awesome Kommunity Icons").
A wild debated has started about a new form of sidebar in the forums - a plethora of mockups and design idea's are being hammered out and I for one is right now lurking in the thread reading every little idea and notion with interest.
(Future Plasma Design leak: part of the design ideas are being used in the sketches for the next Plasma Kickoff Launcher... don't tell anyone, iiih exciting)
The Kmymoney project is also shaping up nicely - due to the brililant work of community member lucashappy, they now have a new application icon and thoughts are being worked on working the AKI icons into a future design for them.
Now there is also a large debate going on System Settings and the future of them in the forums. For now it will be a slow and bit-by-bit thing but when it takes off a large chunk of the work is done so far so if you want to get in on that, join the debate!
The System Settings also had a split today in how we handle Desktop Effects. Due to technical reasons it was split into Compositing and [Desktop Effects]. One being more technical and "please don't play too much with this" and the other the same collection of effects we as KDE and Plasma users have come to love and adore. That means naming should be talked about... and it is! In the forums!

Now all this is to say: if you have a problem with something, you have an idea how to solve it - we have a massive community, together we can fix things design-wise, we can come up with new ideas and amazing concepts in an air of togetherness, kindness and cooperation. So don't just say that you don't like something somewhere on a blog, write a proper suggestion for a solution (without smacktalking anyone, respect is key) in the forums instead. Join in the fun!

Also this week I have been installing different kinds of desktop environments to check them out and see how they solved their issues. The plan was to post that report yesterday (along with an illustration tutorial) but things got in the way so it'll be coming next week.
Safe to say, don't expect any "Unity/Gnome/Openbox/whatever sucks!" texts from me. I have nothing but admiration and respect for the work done by ALL Open Source and Linux designers. All. Even if I use Plasma by choice it doesn't mean I have to hate on them instead of seeing how they did different. So this is my shoutout to the designers of those desktop environments: "Great work boys and girls, you're an inspiration! <3"
Also I will start writing a column in Full Circle Magazine about Open Source and Design which will have its basis in my experiences with the KDE Community and the design work there. I think the first short one will be in the next issue.

From Marco Martins blog and desktop

But what about Plasma Next? Well the work is ticking on. The first screenshots from Plasma Next using our light theme are out on Marco Martins blog and everything is being worked on and tested right now to hopefully get into the Alpha of Plasma Next. We've soon to begin the work on a dark theme which hopefully will roll out the doors any second.

As a matter of fact... consider this a rare treat: We've bundled the preview we have that you can use in Plasma Current, it won't look exactly the same and it is massively a WORK IN PROGRESS - but we've added a color theme, an Aurorae theme for the window decoration and a Qtcurve theme for the widget - also a quick fix to make Chrome or Chromium look nice. So don't say we never did anything for you ;)

Now remember, this is massively a work in progress and hardly a final - the clock and logout and other bits need refining (and some lines etc). If you're on Plasma Next then it might be a bit more correct with the correct blurring effect on the panels - but anyway, enough talk you can download a tar of it here! Now it will say "no preview" but just press download and everything is ticketyboo.

All this is due to the massive work undertaken by Andrew Lake of the VDG - Andrew, what would we do without you?

Politics. Concerning the recent events in Malmö I just want to add a short #kämpashowan and that during the recent surge of right wing extremist violence and politics in Europe it is important to remember Edmund Burkes words: "the only thing necessary for the triumph for evil is for good men to do nothing", that is all for now and probably the last I will talk about politics in this blog.

Next week we will have some icon work to look at, some refinements to check out with the theme (maybe another sneak preview to our dedicated readers, hmm?) until then, take care!

10 Mar 2014 9:41pm GMT

As explained in my last blog post, Nepomuk has been replaced by Baloo, a new and simpler implementation of a desktop search engine built on the experience of Nepomuk. One consequence of this new project was that my query parser, that I developed during the GSoC 2013, was left in the Nepomuk world.

Several days ago, after university assignments and exams, I was finally able to find some time to dedicate to KDE. I used it to port the Nepomuk query parser to Baloo.

Baloo: Simple yet Powerful

The first thing that I needed to do before porting the query parser was to somewhat understand at least parts of the Baloo code base. I needed to find what was available, what was still compatible with Nepomuk-based code (Baloo keeps all the best ideas of Nepomuk), and where to put the parser.

I was quickly able to find my path in Baloo, as the code is much smaller than Nepomuk. The infrastructure is also simpler (in fact, the Nepomuk one was very complex, I remember having to wander in different levels of abstraction of the client side and on the server and finally in Soprano in order to find where a value was changed in a way that I did not like). In fact, everything in Baloo is clean and simple.

For instance, in Nepomuk, we had a Term class that represented "something" (a date-time, a comparison, a keyword, and also AND, OR and NOT operations). This class had many subclasses, one for each type of term. There was a LiteralTerm for simple values (a word, a number), a ComparisonTerm for comparisons (comparing a property with a literal term), and terms for logical operations. OrTerm and AndTerm both represented a logical operation, but were different subclasses with no common ancestor (except Term). My parser had to duplicate code in order to handle AND and OR comparisons, even though OrTerm and AndTerm behaved exactly the same way.

In Baloo, there is only one Term class that does everything. It may seem to be poor engineering, but it is actually very efficient and clean. A term is made of a property, a comparison operator, a value, a logical operator and subterms. AND and OR terms are simply terms whose logical operator is set to And or Or. No code duplication, I can simply use the subterms without having to worry about the logical operator. LiteralTerm is also gone and the API is far cleaner: gone are the Soprano::LiteralValues and complex property URIs. Properties are now simple strings, and values are QVariants.

Porting by Removing Code

The porting process began by copying the entire query parser into a new directory in Baloo Core. At first, I did not want to drop the entire history of the parser (Git has nice tools to merge code from somewhere into a new repository, without loosing any commit), but I finally thought that the history would only be noise, and that the parser would in fact never compile before the port is complete. I also sed'ed the files in order to change every occurence of Nepomuk to Baloo (in the comments and the license headers).

I started with the glue between the parser and Baloo. In Nepomuk, I needed a small utils.cpp file that performed repetitive tasks of wrapping and unwrapping terms from the Nepomuk world to the one of the parser. It contained several one-line and two-lines functions. I was very happy to remove most of these functions when porting to Baloo, as Baloo is clean and does not need repetitive boilerplate in order to use it.

When the utility functions were ported, I attacked the parsing passes. Each parsing pass is quite small and independent from the others. I was very surprised to see that the porting mostly consisted of removing code. I do not need anymore to pass LiteralTerms around and to build comparisons one small step at a time (first the operator, then the property, then only the value). A pass that consisted of 100 lines in Nepomuk is now reduced to approximately 60 lines.

Finally, I had to port the parser itself. I expected that to be a big task, as the parser consists of the pattern matcher (doing the proper recognition of "sent to X") and everything needed in order to parse date-times. Finally, it took only one day, and I was able to remove many lines of code. No big feature was lost and no big refactoring was done, as Baloo is still quite close to Nepomuk, but I was able to remove many duplicated lines and boilerplate. For instance, there were 40 lines just to recurse in the subterms of terms (using a different method for inversions, AND and OR). Now, a small 6-lines loop can simply iterate on Term::subterms and handles all cases (inversions, AND, OR or anything that could be invented in the future). The query parser weighted 2.132 SLOC in Nepomuk and is now consists of 1.892 SLOC.

Trying the Query Parser

The query parsed, ported to Baloo, lives in kde:baloo, branch queryparser. You can use it in your applications by including baloo/queryparser.h. The API is very simple and the parser does all the work. You can have a look at the unit tests in src/core/autotests/queryparsertest.cpp. Here is one unit tests, to show how simple to use the parser and Baloo are:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

void QueryParserTest::testReduction()
{
    QCOMPARE(
        QueryParser::parseQuery("size > 2K and size < 3K"),
        Query(
            Term("size", 2048, Term::Greater) &&
            Term("size", 3072, Term::Less)
        )
    );
}

The parser will not be released in KDE SC 4.13, but may be finished in time for KDE SC 4.14. I also still have to port the query builder widget, but it should not be too difficult as the widget is simple and depends on nothing except the query parser and Term.

The GSoC 2014

Before ending this blog post, I would like to say that I will apply for this year's Google Summer of Code. Working with KDE developers is a formidable experience and I would be very happy to be able to participate again this year. I have several ideas of projects, but if you think of something involving a parser, artificial intelligence, or low-level stuff (optimizing something or stuff that generally gives headaches), I would be glad to hear of it. Here are the ideas (found on the KDE Ideas page or "invented") that currently interest me the most:

• Working on Baloo, because I already know the library (and I like it). There are many small things to do everywhere (new file indexers, adding features, implementing more fine-grained date filters, etc), but I don't know if there is a big three-month project that could be done. I'm thinking about it :) . If you dream of something exciting that could be done using desktop search, I'm all ears.
• Giving love to the KDevelop QML/JS language plugin. The plugin is already in a fairly good shape, but its maintainer has ideas of many improvements that could span an entire summer. What could be very interesting is parsing the QML files shipped with Qt (and Plasma and any other QML "library") in order to offer auto-completion of the items they expose. An item gallery may also be quite useful.
• Add the ability to preview QML files in KDevelop. There is already one such thing in QtCreator but it seems that there are not many people liking it. I need to investigate and to see if a user-friendly previewer is possible. Plasmate for instance has a Plasmoid viewer that allows for easy testing of plasmoids.

10 Mar 2014 8:57pm GMT

We are currently approaching the release of the first alpha version of KWin 5. This is of course a significant milestone and we have put lots of work into the transition to ensure that it's already working quite fine. With such a big migration it is also important to not only work on new cool stuff, but also to do lots of house cleaning.

For example last week the build option for disabling scripting support got removed as we consider scripting as an important and integrated part of KWin. Thus during the house cleaning the build option got removed.

And of course there are areas where we wanted to remove some legacy code for quite some time but never really dared to do. Two years ago I already discussed the costs of supporting the legacy OpenGL 1 compositing backend. Now it was time to re-evaluate the situation.

KWin 5 is a strong user of QtQuick 2. In fact almost all user interface code is written with this new framework - be it the close button in Present Windows, the window switcher or (since today) the outline shown when using quick tiling/maximization. QtQuick 2 uses an OpenGL (ES) 2 powered scene graph thus KWin already has a runtime dependency on OpenGL 2. And in opposite to our Compositor this is a required dependency. While it has always been possible to disable the Compositor (and that won't change for X11), it is not (yet) possible to disable the OpenGL usage of QtQuick.

Thus we have to ask whether it's still worth keeping a code path for legacy hardware, if we require newer hardware. Combined with all the problems mentioned in the above linked blog post from two years ago it becomes really questionable to keep the code.

After some preparation to ensure that we have a clean cut I pushed today the changes to remove the legacy OpenGL 1 compositor in order to have this change in Alpha 1. We encourage all users who used to run the OpenGL 1 compositor to try with the OpenGL 2 compositor and also with the still supported XRender based compositor. If you run into any severe issues please report a bug (or check whether one has already been reported) and provide the support information. This will help us to iron out any issues, like ensuring that no effects get loaded which are not suited for your hardware. After all the base OpenGL 2 compositor should not be an issue for most hardware. But some effects are more demanding than the compositor itself and those can be disabled automatically. Also we try to keep the impact low. If our logic recommended OpenGL 1 compositing for a specific set of hardware, it doesn't enforce OpenGL 2 now, but uses the better suited XRender compositor.

10 Mar 2014 3:54pm GMT

Recently I have seen many comments by users in the style of "I'm looking forward to the first release of KDE5 because of Wayland". With every time there is such a comment the chances are that it spreads that the first release of "KDE5″ will support Wayland and will result in disappointment when the first release of something ends up on the users' systems. Thus I decided to write a blog post with clarifications.

As my readers probably know there won't be a combined release as the software compilation used to be. There are independent ongoing projects around the libraries (frameworks or KF5) the workspaces (Plasma Next) and the applications. These projects have independent release cycles and are not one product. I know, I know, many people will disagree and say that it's still one. But if we go for this strong simplification both "will support Wayland" and "will not support Wayland" are true.

And thus we enter the area where it is important to make the distinction between the various products and use the correct name. Otherwise people don't know what you are talking about and it results in confusion.

So let's look into the different areas. As I have already explained our libraries are getting prepared for Wayland and the first release of KF5 will have Wayland support not on par with X11 support but certainly on par with Microsoft Windows or OS X support.

This means for applications using our frameworks that they will support Wayland as long as they don't speak X11 directly.

For the workspaces it's more complex. Our aim for the first release of Plasma Next has never been to fully support Wayland or do the migration to Wayland. We obviously don't want to create too many construction sides and decided to concentrate on getting everything ported to Qt 5 first before going to Wayland. As we are entering the alpha release state shortly we can be quite certain that the Plasma desktop shell will not support Wayland. Other parts of Plasma Next have a little bit more integration, some systemsettings modules get hidden when running on Wayland, some modules got fixed to not crash, KInfoCenter got some improvements to support the OpenGL module on Wayland and got a new Wayland module. KWin is still in the experimental support stage not yet being a Wayland compositor. Here we might still have some improvements till the final release as Wayland specific code is excluded from the feature freeze. But overall we can quite certainly say that the first release of Plasma Next will not support Wayland.

10 Mar 2014 1:52pm GMT

After some time of really hard work we are happy to announce that our Krita Lime packages now support localization!

If you want to see Krita in your own language, just install a corresponding package...

apt-get install krita-testing-l10n-[your_language_id]

... and run Krita!

If you want to see Krita is a language that differs from your system one, type

KDE_LANG=[your_language_id] krita

Happy painting with Krita! :)

PS:
And for some languages the help of translators is really needed! Join our KDE translators team on l10n.kde.org and we will move KDE forward together! :)

10 Mar 2014 10:08am GMT

This is a heads up that ownCloud is participating in two internship programs this summer!

Google Summer of Code 2014 (GSoC)

Thanks to openSUSE for hosting us again!

Check out the openSUSE GSoC portal and the ownCloud GSoC portal for more information

Student application starts tomorrow. It's important that you come up with a draft of your proposal as soon as possible, so that you can get feedback from your mentor.

Outreach Program for Women (OPW)

Thanks to the OPW organizers for accepting our application ;-)

Check out the ownCloud OPW portal for more information.

Remember that you have time until March 19 to get in touch with us and make a small contribution.

--

Here is the list of Projects Ideas we propose. Check out this list and contact the mentors of the projects you are interested in. Notice two things:

• in order to participate in OPW, you don't need to be a student;
• GSoC projects are restricted to coding. If you are applying for GSoC, look only for projects in that category;
• both the programs have hard deadlines, mind the dates!

If you have any question, don't hesitate to swing by our IRC channel! (#owncloud on Freenode - I am 'cosenal')

Here it's still -11°C, as I write, but I'll say it anyway, as an omen: Happy Summer Of ownCloud!

09 Mar 2014 3:23pm GMT

08 Mar 2014 1:46pm GMT

If you haven't seen the previous post, I've posted a question of what style would you prefer (I've simplified it a bit here, for the original, go for the link above):

(A)                        | (B)
                           |
if (ratio < 1.5) {         | result = (ratio < 1.5) ? 1.0 :
    result = 1.0;          |          (ratio < 2.0) ? 1.5 :
} else if (ratio < 2.0) {  |          (ratio < 3.0) ? 3.0 :
    result = 1.5;          |          /* otherwise */ ratio;
} else if (ratio < 2.5) {  |
    result = 2.0;          |
} else if (ratio < 3.0) {  |
    result = 3.0;          |
} else {                   |
    result = ratio;        |
}

As expected, people are split into two similarly sized groups. It is a matter of style after all.

Neither of these is better, but they both have their pros and cons. Lets see what we have collected so far.

Firstly, lets deal with the elephants in the room:

- Is this an academic question? (as suggested by krake)

Yes and no. Yes, because it is not really that important - people will continue using what they used before. No, because it might influence the different aspects of the resulting code. (see below)

- You can use if-return format: (suggested by cyber_fusion)

if (...) return ...;
if (...) return ...;
...

This seems to be a popular variant of (A) when the purpose of the result variable is to be returned from the function we're in (as it was the case in the original post). It does not work in other cases.

While it is a good approach (and preferred by a significant number of people), there was one statement for it, that is not correct - (Alex) "it shows structure, it will not execute if statements after a successful one". All the proposals behave the same - neither executes statements after the first successful one.

The issue some people pointed out is the lack of braces for the if body which is frowned upon by a significant number of coding styles used across the world. If somebody questions why would missing braces would ever be a problem, just search for the 'apple goto fail'. When you add braces, the solution stops being as visually attractive.

-

Now, we can start with the reasons people wrote for one or the other. In no particular order, to avoid the trap of actually counting pros and cons.

(shamaz) The big difference here is that the 2nd solution is ONE statement. This means that it's less simple to debug : you won't see which branch is chosen (similar comment by Morten)

It is a single statement, but it has multiple sequence points[↗] (or whatever they are called in the new standard). The same sequence points an if/else construct does. So it will show up (tested in gcc+gdb¹) as separate steps while debugging². You will be able to see where you left the statement.

Edit: ¹ clang does not create the same debugging info, so it does treat it as one execution step.

² It has a big uglier debugging output, but still is quite usable.

(Lihnell) I'd like to add that putting the else in a comment for readability is a clear indicator that the language used is not suitable to the person using it

I do agree. It essentially boils down to the fact that ?: syntax (for this) is not something people are used to. So adding 'else' or 'otherwise' is a nice way to make it more readable.

(konqoro) I guess it was how we were told to better understand the if-else statements.

There were a few similar comments to this one.

Yes, if-else approach is ubiquitous, and therefore understandable by everyone. IMO, it is the strongest reason for going for it - people are not used to (B) even if (Jeff) "the notation fades into the background, and the structure of the actual operation pops out".

(dhardy) I find the second much easier to read. My preferences are (a) avoid re-assigning variables

Thanks to some pure functional languages like haskell, the concept of immutability started to spread out to other paradigms. The second approach is also usable in C++11 constexpr functions, while the first one will be allowed in C++14.

One of the approaches to make the result variable const for the (A) variant would be to use lambda-initialization, thus localising the mutable variable inside the lambda. Like:

const double result = [] { ... }();

(Alex Elsayed) I doubt you care overmuch, but PHP will not do what you expect on the second one

You are right that I do not. But, this is a useful information for the future - if I get to hack on some PHP code. Thanks!

(shamaz) For the 2nd solution, if someone try to format your code automatically with his IDE, it may become hard to read.

Yes, unfortunately. I've tested it with clang-format and it essentially killed it. I guess if it became a common idiom, formatters would learn to deal with it. :)

-

Epilogue:

Personally, I prefer the second option although I don't use it that often mainly because it is not that common and people are not used to it.

I do prefer it on the technical grounds, though. It is perfect for const initialization / constexpr functions, the syntax stops you making code-evolution mistakes similar to the 'goto fail', and different mistakes that the original code (which inspired me to write this) had. (the original code was posted for half an hour in the previous post, but I decided to edit it to show only the styling differences, without other issues)

08 Mar 2014 11:48am GMT

Since KDE SC 4.12 kate has a Python plugin which can help to edit colors in various files like CSS, kate syntax, HTML, QML… First of all, one ought to enable that plugin in the Python plugins manager dialog.

The plugin provides a Palette tool-view which contains all colors found in the current document. For example here is the palette for http://cdn.kde.org/css/bootstrap.css:

When a text with some #hex color gets selected, a tooltip with that color will appear. Clicking on a color cell in the tool-view moves a cursor to the location, where that color has defined. This plugin add a new action to the context menu of a document:

This action show a "completion" popup with a color-chooser widget containing all used colors, so it is easy to choose some, using a keyboard or mouse.

08 Mar 2014 8:00am GMT

I had been postponing setting up an IRC bouncer for a long time inspite of its benefits, until recently, when I actually went through with the really easy process even for lazy people like me. This is all you really need to do:

1. Go to https://sysadmin.kde.org/tickets/ and login using your identity.kde.org username and password (Here I am assuming you already have a KDE identity account)
2. Go to 'Submit A Ticket' and select 'IRC' from the list of options available.
3. File a bug with appropriate information for 'Subject', 'Priority' and 'Freenode Nickname' and provide some other relevant information in the text field.
4. Once this ticket is closed by KDE sysadmin, which might take 1-2 days, you will receive a login id and password through email.
5. Open https://bnc.kde.org:7778/ and login using the above login id and password.
6. In 'Your Settings' you can configure your account which includes changing the password set by sysadmin, adding your Freenode network and then adding the channels you want to stay connected to.
7. Just remember that when you add servers to your network which is Freenode, the format is 'One server per line, host [[+]port] [password]'. For example:
   irc.freenode.net 6667 <your_password>
   
8. Once you are done with this you need to configure your IRC client. For Konversation which is the client I use for IRC, all you really need to do is follow the steps here: http://community.kde.org/Sysadmin/BNC#Settings_for_Konversation. However, do note that 'yourusername' == <your_kde_identity_username>/Freenode.

That's all that you need to do! Also this is the wiki page that talks about setting this up for other IRC clients: http://community.kde.org/Sysadmin/BNC. So go ahead and setup your IRC bouncer; and you can always see what happened on a channel even when you are not connected.

Cheers!

07 Mar 2014 11:22pm GMT

Kate Part gained 17 new default styles in addition to the existing 14 default styles. These changes are available for Kate based on the KDE frameworks 5 initiative and currently live in ktexteditor.git module.

Default Styles are predefined font and color styles that are used by Kate Part's syntax highlighting. For instance, Kate Part always had a default style for comments. Therewith, the comments in all syntax highlighting files look the same (by default, a gray color). Or keywords are by default always bold and black.

However, during the last years it became apparent that the list of 14 default styles were not always enough. Consequently, lots of syntax highlighting files defined their own hard-coded colors. For instance, doxygen comments were hard-coded in a dark blue color. The problem with hard-coded colors is that they do not adapt when changing the default styles. Hence, doxygen comments were barely readable on a dark color scheme.

Therefore, a discussion took place on kwrite-devel (thread 1, thread 2, thread 3) that ended in 17 new default styles and a categorization of these as follows (the new default styles are bold):

Category "Normal Text and Source Code"

• dsNormal: default for normal text and source code.
• dsKeyword: Used for language keywords.
• dsFunction: Used for function definitions and function calls.
• dsVariable: Used for variables, if applicable. Example: $foo in PHP.
• dsControlFlow: Used for control flow highlighting, e.g., if, then, else, return, continue.
• dsOperator: Used for operators such as +, -, *, / and :: etc.
• dsBuiltIn: Used for built-in language classes and functions, if applicable.
• dsExtension: Used for extensions, such as Qt or boost.
• dsPreprocessor: Used for preprocessor statements.
• dsAttribute: Used for attributes of functions or objects, e.g. @override in Java, or __declspec(…) and __attribute__((…))in C/C++.

Category "Strings & Characters"

• dsChar: Used for a single character.
• dsSpecialChar: Used for an escaped character in strings, e.g. "hello\n".
• dsString: Default for strings.
• dsVerbatimString: Used for verbatim strings such as HERE docs.
• dsSpecialString: Used for special strings such as regular expressions in ECMAScript or LaTeX math mode.
• dsImport: Used for includes, imports, modules, or LaTeX packages

Category "Numbers, Types & Constants"

• dsDataType: Used for data types such as int, char, float etc.
• dsDecVal: Used for decimal values.
• dsBaseN: Used for numbers with base other than 10.
• dsFloat: Used for floating point numbers.
• dsConstant: Used for language constants, e.g. True, False, None in Python or nullptr in C/C++.

Category "Comments & Documentation"

• dsComment: Used for normal comments.
• dsDocumentation: Used for comments that reflect API documentation, e.g., the default style for /** */ comments.
• dsAnnotation: Used for annotations in comments, e.g. @param in Doxygen or JavaDoc.
• dsCommentVar: Used to refer to variables in a comment, e.g. after @param <identifier> in Doxygen or JavaDoc.
• dsRegionMarker: Used for region markers, typically defined by BEGIN/END.
• dsInformation: Used for information, e.g. the keyword @note in Doxygen.
• dsWarning: Used for warnings, e.g. the keyword @warning in Doxygen.
• dsAlert: Used for comment specials such as TODO and WARNING in comments.

Category "Miscellaneous"

• dsOthers: Used for attributes that do not match any of the other default styles.
• dsError: Used to indicate wrong syntax.

Existing Syntax Highlighting Files

If the new default styles are not used, syntax highlighting files are backwards compatible to Kate Part in KDE SC 4. However, the plan is to use the new default styles where applicable to avoid hard-coded colors. To this end, the kateversion attribute in the language element will be set to 5.0 (yes, Kate Part's version changed from 3 to 5 to match KDE frameworks 5) to avoid loading incompatible syntax highlighting xml files in older Kate Part versions. Example:

<language name="C++" kateversion="5.0" [other attributes omitted]>

With the new default styles, the Default Styles tab looks as follows:

In comparison, the KDE 4.x version looks like this:

The new default style colors are not fixed yet, so improvements and additional color themes we can ship with Kate Part by default are a welcome addition!

A Note at 3rd Party Developers

There are other implementations (such as in Qt Creator or for Haskell). If you developers read this, we encourage you to add these default styles as well once Kate Part 5 is released (stable). Otherwise, the new syntax highlighting files may not be compatible.

07 Mar 2014 9:31pm GMT

Yesterday KDE released their first beta of the upcoming 4.13 version of Workspaces, Applications and Development platform. As usual with the major releases from KDE, it's packed with a lot of "good stuff". Giving a list of all the improvements is daunting, however there are some key points that stand out:

• Searching: KDE's next generation semantic search is a prominent feature of this release. It's several orders of magnitude faster, much leaner on memory and generally is a great improvement from the previous situation (this writer has been testing it for the past months and he's absolutely delighted about it).
• PIM: Aside with tight integration with the new search feature, KMail gained a new quick filter bar and search, many fixes in IMAP support (also thanks to the recent PIM sprint) and a brand new sieve editor.
• Okular has a lot of new features (tabs, media handling and a magnifier)
• A lot more ;)

Given all of this, could the openSUSE KDE team stay still? Of course not! Packages are available in the KDE:Distro:Factory repository (for openSUSE 13.1 and openSUSE Factory) as there are lot of changes and need more testing. The final release will be provided also in the KDE:Relase413 repository (which will be created then).

Some notes on the search changes: you will need to migrate existing data from Nepomuk (should you want to: it's optional). You can do that by running "nepomukbaloomigrator" when Nepomuk is running: it will automatically migrate your data and switch off the old system (virtuoso-t included). Also bear in mind that since the old Nepomuk support is considered "legacy" (but still provided), the programs that have not yet been ported to the new architecture have their Nepomuk integration disabled. One significant regression is file-activity linking, which will not work.

As usual, this is an unstable release and it is only meant for testing. Don't use this in production environments! If you encounter a bug, if it is packaging related use Novell's Bugzilla, otherwise head to bugs.kde.org. Also, before reporting anything, please check out the Beta section of the KDE Community Forums first.

That's all, enjoy this new release!

07 Mar 2014 7:45pm GMT

Work in Plasma Next is proceeding frantic as usual.
We are around a week from the release of the first Alpha (mark your calendard from a week from now), and the feature count is getting close the current release of KDE Plasma Desktop, in order to get the transition as smooth as possible.

Of course we aren't trying to just do a carbon copy port, but to give some nice new features and improvements, such as a dramatically better behavior of the system tray (no more weird popups-from popups!), waay better support for high DPI screens and a nice new rewamped notifications system and UI.

The big thing tough is the new capabilities of the frameworks: KDE Frameworks 5 and the new Plasma Framework, with a desktop shell all based on QML2: so many things that in the past we couldn't do, now will be possible.

And now as usual, a sneak peek of something that will not be in the alpha release yet.

The KDE Visual Design Group is doing a terrific job across very different areas of Plasma Next, the little area I'm collaborating with is the Plasma theme itself (a lot more nice stuff in many different areas will arrive from them in the future). I must say I'm impressed by their work.

But what if I have a screen with a ludicrous amount of DPI?

All of this is heavy under construction, so is still subject to a *lot* of changes until the final version

07 Mar 2014 4:28pm GMT

For the second year, next month I'll run a professional training session about drawing with Krita at ActivDesign in Rennes.
It will take place the week right after the Libre Graphics Meeting, from 7 to 9 April.
It is still possible to register if you're interested (note: french-speaking session).

Besides, if you want some local personal training about Krita, in French like this time but also in English, you can always contact me directly on my contact page.

Here a little illustration made for the guide to Krita 2.8′s features pdf file, as you must already know 2.8 has been released a few days ago ;.)

07 Mar 2014 1:46pm GMT

The following is a deceptively unsimple tutorial on how to draw a red square in QML onto a scenegraph.

The normal approach is as follows:

test.qml

import QtQuick 2.0

Item
{
    Rectangle {
        color: "red"
        width: 100
        height: 100
        x: 100
        y: 100
    }
}

Easy.

Going Native

However in some cases, we want a lot more control and to paint something slightly more complex than a red square.

Qt has an API to use the classic QPainter interface to draw our QQuickItems. In order to do this we must create a new QQuickPaintedItem, and register it for use from QML

reditem.cpp

#include <QPainter>
#include <QQuickPaintedItem>

class RedItem : public QQuickPaintedItem
{

    void RedItem::paint(QPainter* painter)
    {
        painter->setBrush(QBrush(Qt::red));
        painter->drawRect(contentsBoundingRect());
    }
}

At some point we need to register our type for qml with

    qmlRegisterType<RedItem>("org.dave", 1, 0, "RedItem");

Our QML file then needs to change to use our new item instead.

Deeper!

Interally the QQuickPaintedItem approach is very different to how the orignal Rectange approach works. Here we are generating a giant pixmap of our red square and uploading it to an openGL texture. Given openGL can draw coloured squares natively this is a rather giant waste of memory and processing.

In order to utilise this behaviour we have to manipulate the scene graph directly.
Scene graph objects are split into two types QSGSimple* and QSG*. The former being a convienient wrapper round the second with some standard functionality.

reditem.cpp

RedItem::RedItem(QQuickItem* parent):
    QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents, true);
}

QSGNode* RedItem::updatePaintNode(QSGNode *oldNode, QQuickItem::UpdatePaintNodeData*)
{
    QSGSimpleRectNode *rectNode = static_cast<QSGSimpleRectNode*>(oldNode);
    if (!rectNode) {
        rectNode = new QSGSimpleRectNode;
        rectNode->setColor(QColor(Qt::red));
    }
    rectNode->setRect(0, 0, width(), height());
    return rectNode;
}

In updatePaintNode we are given a pointer to the previous node (which may or may not be null) and update any properties on it. We are also able to delete the previous node, and create a new node or return a complex tree of nodes.

As updatePaintNode is called frequently it is a good idea to not update properties that have not changed, as to do so will mark them as "dirty" and perform more calculations on them.

Deeper Still

We can go lower still, and directly write openGL.

We now have 3 parts; The node, a material and a material shader.

The material shader is responsible for actually determining the colours and position of what gets painted.
This is run as two tiny programs that are compiled in the openGL context; the vertex and fragment shader.

In order to not have the same data for every node, there is only ever one shader in use.
Materials act as factory objects for the MaterialShader. Each Node will own a material, which will instantiate and share a single MaterialShader between them.

class RedMaterialShader : public QSGMaterialShader
{
public:
    virtual const char* const* attributeNames() const
    {
        static char const *const attr[] = { "vCoord", 0 };
        return attr;
    }

    virtual const char* vertexShader() const
    {
        return  "attribute highp vec4 vCoord;"
                "uniform highp mat4 matrix;"
                "void main()"
                "{"
                    "gl_Position = matrix * vCoord;"
                "}";
    }

    virtual const char* fragmentShader() const
    {
        //fragment shaders adjust the colour of each pixel
        //there is a special variable gl_FragColor which determines the colour of
        //the pixel at coord
        //in our case, always red
        return "void main() {"
               "  gl_FragColor = vec4(1, 0, 0, 1);" //R, G, B, A
               "}";
    }
    virtual void updateState(const RenderState& state, QSGMaterial* newMaterial, QSGMaterial* oldMaterial)
    {
        if (state.isMatrixDirty()) {
            program()->setUniformValue("matrix", state.combinedMatrix());
            //in reality you want to cache the uniform location to save a lookup on every update
        }
    }

    static QSGMaterialType type;
};

QSGMaterialType RedMaterialShader::type;

class RedMaterial : public QSGMaterial
{
public:
    virtual QSGMaterialShader* createShader() const {
        return new RedMaterialShader;
    }
    virtual QSGMaterialType* type() const {
             return &RedMaterialShader::type;
    }
};

RedItem::RedItem(QQuickItem* parent):
    QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents, true);
}

QSGNode* RedItem::updatePaintNode(QSGNode *oldNode, UpdatePaintNodeData*)
{
    QSGGeometryNode *node = static_cast<QSGGeometryNode*>(oldNode);

    if (!node) {
        node = new QSGGeometryNode;

        RedMaterial *m = new RedMaterial;
        node->setMaterial(m);
        node->setFlag(QSGNode::OwnsMaterial, true);

        QSGGeometry *g = new QSGGeometry(QSGGeometry::defaultAttributes_TexturedPoint2D(), 4);
        node->setGeometry(g);
        node->setFlag(QSGNode::OwnsGeometry, true);
    }

    QSGGeometry::updateTexturedRectGeometry(node->geometry(), QRect(0,0, width(), height()), QRect(0,0,1,1));

    return node;
}

There is a wrapper QSGSimpleMaterialShader, that reduces some of the boilerplate code, but is effectively the same.

Wrap up:

The Qt Quick and SceneGraph libraries are very well structured.

• You can write QML without ever caring about underlying QQuickItems, but it's there if you need it.
• You can write QQuickItems wihtout ever caring about the underlying scenegraph, but it's there if you need it.
• You can write SceneGraph without ever caring about OpenGL, but it's there if you need it.

In general an application developer you should never need to touch scenegraph. The complexity is far higher than using QML. It is designed around speed rather than easy to use APIs. A lot of memory allocation and boiler plate code is the responsibility of the developer.

However, touching scenegraph directly is possible, and nothing to be too afraid of. It is worth having some knowledge in order to understand how the current QML items work underneath and how best to use them.

For those who make libraries; Plasma, Jolla, Ubuntu etc. this is something we will need to do in order to fully make use of the resources available.

Later I will blog about the changes I'm making in Plasma to use this for our custom SVG rendering making use of our existing caches and hopefully share textures and reduce our overall memory footprint.

Code

My examples are available at : git@git.kde.org:scratch/davidedmundson/qtquickplayground

Please note, the above examples deliberately focus on simplicity to explain the point, rather than speed. Additionally this is a new area for me, and I do not claim to be an expert yet. It is worth reading Qt docs heavily and reading through the original Qt code to see how to achieve the best performance.

07 Mar 2014 12:33pm GMT

This is a excerpt from a real project, just with variables renamed.

EDIT: * I've removed the issues from the original code so that this can be a real style vote, without sidetracking the readers.

Although, by fixing the code, I removed one of the things that I think the advantage of the second one is - it is much harder to make errors and dead code.

const qreal ratio = someFunction();

if (ratio < 1.5) {
    result = multiplier;
} else if (ratio < 2.0) {
    result = multiplier * 1.5;
} else if (ratio < 2.5) {
    result = multiplier * 2.0;
} else if (ratio < 3.0) {
    result = multiplier * 3.0;
} else {
    result = multiplier * ratio;
}

return result;

This was the usual imperative code that you'd find almost everywhere. And this is the alternative (functional) way of doing the same:

const qreal ratio = someFunction();

return multiplier * ( 
    (ratio < 1.5) ? 1.0 :
    (ratio < 2.0) ? 1.5 :
    (ratio < 2.5) ? 2.0 :
    (ratio < 3.0) ? 3.0 :
    /* else */      ratio
);

The second one is kinda what you'd do in maths:

       /  1.0     x < 1.5
       |  1.5     1.5 ≤ x < 2.0
f(x) = <  2.0     2.0 ≤ x < 2.5
       |  3.0     2.5 ≤ x < 3.0
       \  x       otherwise

What do you find more readable?

07 Mar 2014 9:14am GMT