Yesterday, I continued my work on the Nepomk Query parser (currently out of tree, available here), and I have enhanced several aspects of it. My aim was to have it clean and powerful enough to be able to parse completely the example query I gave in this entry. Even thought I’m not quite there yet, most of the query can already be parsed.

Regular expressions and unit splitting

The first two modifications of yesterday are ones I talked about in my previous blog entry.

Sometimes, matching exact words in rules is not enough. For instance, you may want to match words that can be in singular or plural form. In English, this is simple (just duplicate the pattern and write one in the singular form, the other in the plural form), but other languages have declinations or complex word forms.

The philosophy of the parser here is to match everything the user wants to be matched, even if it is a mistake. For instance, there is no need to reject queries having plural and singular forms interleaved, as they may be typos or the user just made a mistake.

The syntax of these regular expressions is simple : everything that is not a placeholder in a pattern is a regular expression, so “sent by %1” contains two very simple regexps, and “%1 (th|rd|nd) of %2” contains a more complex one.

Another modification of the parser was needed due to the fact that units can be part of an integer, or be separate from it. For instance, I can write “3GB” or “3 GB”. I don’t know if only one of these spelling is correct in English, but the parser has to handle the two as other language could even swap the unit and the number, or put words in-between them.

A special parser pass now separates units from numbers. The locale provides a list of suffixes/prefixes (they are matched at the two ends of a number). Currently, the English locale provides the standard file-size units (MiB, GiB, etc), the base-10 version of them (used by Windows, this is MB, GB, KB, etc), and ordinal suffixes (th, rd, nd). These units are matched case-insensitively. When a number is followed by or prefixed with one of these words, the word is split apart. “3GB” becomes “3 GB”.

Comparison operators

When I started to think about this parser, I wanted each value (a name, a number, everything that is not a property name) to have a type hint. If I enter “3GB”, I want to match a file size. If I enter “#something”, I want to match documents that are tagged as something.

The problem is that the Nepomuk classes I use (the ones in Nepomuk2::Query, that are very well designed by the way) do not allow me to store arbitrary type hints into value. Sure, if the value is a constant, I know that it is a string, an integer or a date, but nothing more precise.

The solution I am currently experimenting with is to replace values with comparisons. Plain strings and integers remain literal values (constants), but things like “3GB” become comparisons. The property which is compared to the value is the type hint, and the operator is the equality. So, “3GB” is parsed to “nfo:fileSize=3GB”.

Now, the default property or the operator may be wrong. The operator can be modified using the PassComparators pass. Patterns like “less than %1” are matched, and if “%1” is a comparison term, its operator is changed to the correct value. If “%1” is a literal value, a new comparison is created. Its value is the literal term, its operator is the one corresponding to the pattern, and its property is null.

The parser is therefore able to parse “> 3KB” to nfo:fileSize>3000, and when dates will be implemented, “mails sent before June 13” will produce the expected query.

Simpler pattern language

You may remember that my previous blog post presented a pattern language that was fairly complex (it was also complex to parse). Patterns were made of words, separated by spaces, that could be literals to be matched exactly or placeholders. A placeholder was like “term0”, “string1”, etc.

The first modification was to match literals not exactly but using regular expressions. The second one was to simplify the placeholders.

When I write new parsing passes, I know exactly what kind of terms I want to match. Me, as a developer, I know that the first term matched must be a string, and the second one can be anything (“term1”). If one of these placeholder is changed, the parsing pass may cease to work correctly.

So, I thought that translators do not have to (and must not) change the placeholder type. They just need to reorder them if needed and to put words between them. They are only interested in their position, not their meaning. I therefore replaced the complex matching syntax with simple numbers prefixed with a percent, like the ones you use with QString::arg. Now, “sent by ” becomes “sent by %1”.

Matching properties

In order to experiment the architecture of the parser, I wrote a small parser pass that recognizes “sent by X” and changes that to nmo:messageFrom=X. Yesterday, I wanted to add more properties, and I noticed that every parser pass would be the same, except that the property matched would be different. All the work is done by the pattern matcher.

So, I replaced the “sent by” pass with a more general “property” one. This avoids code duplication and allows to quickly add patterns for new properties. No need to write a pass, just add a line like this in parser.cpp:

1
2
3
4

d->pass_properties.setProperty(
    Nepomuk2::Vocabulary::NMO::messageSubject());
progress |= d->runPass(d->pass_properties,
    i18nc("Title of an e-mail", "(en)?titled? %1;title is %1;%1 as title"), 1);

The pattern in this example seems awkward, but allows the parser to match “mails having Foo as title”, “documents entitled Foo”, “file whose title is Foo”, etc. This complex pattern shows all the features of the pattern matcher, and is normally not too difficult to translate. The semicolon separates independent rules of the same pattern. I changed the pipe separator to a semicolon because the pipe can now be used in regular expressions.

All in all, the parser is advancing, and even if it is still an experiment, it seems that its architecture is not too bad for what I want to do. In the coming days, I will implement nested queries (explicitly enclosed in parenthesis by the user, or matched by patterns like “related to … ,” the comma being an indicator of the end of the subquery, like in “documents related to mails sent by Jeff, and having a size smaller than 2MB”), and the actual production of the Nepomuk query (Nepomuk2::Query::Query, a very powerful and well-designed class by the way).

Another thing I want to do is to have a mean to get metadata about properties. The most interesting one is their range. For instance, if I enter “mails sent by X”, I must know that X has to be a nco:PersonContact. One general solution would be to maintain a database of metadata about properties (I know that Nepomuk already does that, but uses queries to the Nepomuk server in order to retrieve the properties, this may be a bit too slow for being used by the parser). Another one would simply to hard-code the metadata into the PassProperties::setProperty method calls.

I also need to think about the auto-completion and syntax-highlighting. The syntax-highlighting only requires that terms have a positional information (to be able to match parsed terms to positions into the input query), but the auto-completion needs the pattern matcher to be able to partially match patterns (and to report what was expected at the location of the cursor), and will use the property ranges to show nice drop-down lists (if I enter “mails sent by”, I will see the list of my contacts).

As a consequence of the recent changes in the repositories, the openSUSE KDE team is happy to announce the availability of packages containing the first beta of the KDE Platform, Workspaces and Applications 4.11. 

This post describes a few of the coordinate systems that KStars uses to keep track of the positions of various astronomical objects, and how they relate to one another.

All of the points used in KStars can be thought of as lying on a sphere, because it really makes no difference how far away a sky object like a star is – we only care about the direction. We can then imagine that these points “live” on the celestial sphere, an imaginary sphere surrounding the Earth. The problem of rendering a map of the night sky is then the problem of figuring out how to transform this sphere onto the screen.

Horizontal Coordinates

Horizontal coordinates are defined strictly relative to the observer. We usually use two angles, the altitude, which measures the angle from the point to the horizon, so that 90° is straight up, 0° is on the horizon, and -90° is straight down, and the azimuth, which measures the angle eastward from the north direction to the direction of the point.

Equatorial Coordinates

There are two important lines on the celestial sphere that we’ll use to define our coordinate systems. The first is the celestial equator, which is just the Earth’s equator, extended outwards and projected onto the celestial sphere. The second is the ecliptic, which is the intersection of the Earth’s orbital plane with the celestial sphere. Since the Earth’s axis is tilted, these two lines are distinct, and they intersect at two points, as seen in this drawing:

From the point of view of the Earth, the Sun travels along the ecliptic. When the ecliptic intersects the equator, it means that the Sun is directly above the equator, so night and day have the same length everywhere on earth. Thus, these points are the spring (vernal) and fall (autumnal) equinoxes.

The equatorial coordinate system describes a point p in terms of its relation to the vernal equinox, usually by means of two angles, called right ascension and declination. The right ascension, RA or α, is the angle running eastward from the vernal equinox along the equator, while the declination is the angle from the object to the equator.

Wikipedia provides a nice summary in GIF format:

J2000 and standard epochs

One thing to note about this system is that the Earth does not orbit the Sun perfectly. The Earth has precession and nutation, which are respectively a slow drift in the earth’s rotational axis and a slight, gradual wobbling motion. These motions cause the positions of the equinoxes to shift slightly, which means that the equatorial coordinates of even “fixed” objects vary over time, since they’re defined in reference to a moving point!

To solve this problem, astronomers agree on particular times (“epochs”) to reference their coordinates. The most common is the J2000 epoch, which is defined to be the equatorial coordinates of a point in reference to the vernal equinox at noon on January 1, 2000.

These coordinates have the time already specified, so we’re not missing any information, and we can use them in catalogs and databases.

As an example, the Andromeda galaxy currently has equatorial coordinates of RA = 00h 43m 29s, Dec = 41° 20’ 22“, but the catalog coordinates are RA = 00h 42m 44s, Dec = 41° 16’ 08”.

Ecliptic coordinates

Ecliptic coordinates are pretty similar to equatorial coordinates, but they’re defined in terms of the ecliptic plane, instead of the equatorial plane. We describe a point in terms of its ecliptic longitude, which is measured eastward from the vernal equinox, and its ecliptic latitude, which is the angle from the point to the ecliptic plane.

The same points about time dependence hold for ecliptic coordinates as well as equatorial coordinates, but in KStars we don’t store any data in ecliptic coordinates, so it’s not as important to define reference epochs for ecliptic coordinates.

Galactic coordinates

Finally, there’s the galactic coordinate system. This system places the Sun at the centre and uses the disk of the Milky Way to define the galactic equator. It describes a point in terms of its galactic longitude, measured eastward from the centre of the galaxy, and its galactic latitude, which is the angle to the galactic plane.

KStars doesn’t actually make use of these, but we have the ability to calculate them, and this is exposed to the user as part of KStars’ tools collection.

Converting between coordinate systems

A lot of the work that KStars does goes into converting between these coordinate systems. We have a lot of different types of objects, which are grouped into SkyComponents. Currently, KStars deals with the problem of different objects needing different calculations by making each sky object have its own class, with its own object-oriented code for computation. This is really, really, bad for performance in a lot of ways, because it has fragmented memory access patterns, a virtual function call for each point, and a lot of duplicated work.

Simplfying this requires carefully laying out what kinds of computation we do for each kind of sky object, which I’ll do in a future post. For now, I’ll just give a brief description of what goes into the conversion from one coordinate system to another.

To convert from horizontal coordinates to equatorial coordinates, we need to know the time and location of the observer. Going back to the description we had of the equatorial coordinate system, we have a (relatively) fixed sphere, with the earth rotating around inside. All we need to do is compute the rotation of the earth, and apply that rotation to all of the points we want to convert. (Interestingly enough, at the moment KStars computes this rotation for each point we want to compute, because we never compute multiple conversions at the same time). If we want to be very precise, however, we need to compute the effects of atmospheric refraction, which makes our points appear higher in the sky then they actually are.

As we noted, equatorial coordinates change over time due to the effects of precession and nutation. Converting equatorial coordinates in one epoch to another epoch requires computing the effects of precession and nutation. But there’s an extra complication there, too: we also need to compute the effects of aberration, which is caused by relativistic effects: the earth is moving around the sun, and this movement causes the apparent position of the stars to shift depending on the relative velocity of the earth to the star.

Converting from equatorial to ecliptic coordinates is a simple rotation, and we just need to know the angle between the Earth’s equator and the ecliptic plane. This varies over time, so we need to compute precession and nutation as before.

However, this isn’t the full story: some objects have extra calculations that need to be done, and we also want to be able to do these computations in a way that avoids trigonometry as much as possible. To be continued…

A few days back I attended the first freedesktop summit/sprint where a few hackers from different free desktops met with the objective of working together. We were people from Razord-qt, GNOME, Unity and of course KDE.

Even though we did not had the chance to discuss all the topics I was specially interested in like Notifications or Session Inhibition I did had the chance to get involved in other topics that are equally interesting like the shared Desktop Files cache or the “Trash size cache” that will enable a cross desktop way of caching the size of the Trash folder getting better performance across desktops.

The social part of these kind of events is important as well, even though I already knew Ryan and David a week of working together makes the collaboration more smooth, and of course I also met new people as well like Lars, or Jeft.

I’m quite happy to have pushed together with Ryan this event, we definitively moved forward the collaboration between desktops and even though freedesktop is still far from being perfect I do believe we did a step into the right direction.

Can’t wait for the next Fd.o Summit.

I’m pleased to announce that choqok development mailing list is up and ready (thanks to KDE sysadmins)

and from now on, we will talk about development stuff there. So I invite anyone who is interested to involve in Choqok development and contribute code, subscribe to choqok-devel mailing list.

Filed under: Choqok, PlanetKDE

Hey! My name is Konrad Zemek, I’m a student at AGH University of Science and Technology, Kraków, Poland. I study Computer Science, currently finishing my second year. I’m a programmer. Mainly a C++ programmer, but that’s just because I write in C++ professionally – I know a few other languages and I’m fast to pick up new ones. I could write about this a lot more, but I guess it all just comes to that: I’m a programmer, and a good one.

And I have other traits, too! I love gaming, particularly video gaming. I eat through books, mostly of the fantasy kind. I ride a bicycle almost every single day, and I’m learning to play the electric guitar, dreaming that I could someday justify buying a Stratocaster.

I’ll get to placing my photo, not made hastily with a cellphone, somewhere around here – in the meantime I redirect you to my Google+ page.

The blog

I really tried not to commit too much time to deploy this blog, as I’m behind my schedule already. And believe me, it was hard – I’m the type of person who spends weeks reading about color theory and typography before deploying a website. This time, at least from the visual side, everything is pretty generic – still, I see great many hours of tweaking and customizing this blog in my future.

Just not now.

It’s a bit more interesting from the technical side. I deployed the WordPress application on the Amazon cloud, AWS; its code (the “application” part) resides in a git repository, which I push to “Elastic Beanstalk” (a Platform-as-a-Service) after every update, which in turn spins up a generic instance of GNU/Linux and deploys the application there. Nothing on this instance is persistent, so no actual content can be stored there. The blog connects to a SQL database, which is provided by another part of AWS. Then there’s persistent content that is neither a part of the application nor it belongs in the database, like uploaded images and other post attachments – these are stored by Amazon S3 service. CloudFlare provides DNS, caching, and some anti-bot screening.

There are a lot of things on the technical side that I’m itching to talk about, but I’ve got more important thing to write about, that being…

Google Summer of Code

The main purpose of this blog, or rather the reason it came into existence, is to write about Google Summer of Code, more specifically about my own GSoC project. The title of this proposal is Reimplement Amarok 1.4 (FastForward) & iTunes importers on top of Statistics Synchronization framework, and add Amarok 2.x and Rhythmbox as synchronization targets. Amarok is a legendary music player, part of the KDE software suite (I’d say it’s a Linux music player, but that’s not entirely true).

Every but the most basic music player collects data about music being played – it’s called personal metadata, and includes information like number of times a given track has been played, or user’s rating of the track. For users who use those features, it’s quite a big deal – it allows for playing favorite tracks, or maybe the tracks which were not listened to enough, all without any need to spend time setting up custom playlist. Or perhaps you like to share your most-loved tracks through a service like Last.fm? None of that would be achievable without personal metadata.

Currently, if you’re using iTunes or an old Amarok version, you are able to share this metadata with Amarok, although there’s no easy way to keep it synchronized. At a basic level, my project aims to add that very capability – to easily resynchronize Amarok with iTunes, previous Amarok versions, and Rhythmbox, Ubuntu’s default music player. There are also some stretch goals, like being able to do a two-way synchronization (update metadata on the other player), and I’m also quite confident of reaching those. I will post my weekly progress updates here during the course of next three months, and I think my planned schedule will end up in a widget somewhere on this site. There also will be more details coming. I’ll get to it, I promise!

So that’s me done for this post, before I run out of things to say in the next one. Thanks for reading. :)

The coding period of this year’s Google Summer of Code starts this Monday, and I have just finished my exams. It is a good time to start working on my project, a Nepomuk query parser.

When I learned that I was accepted as a GSoC student, I began defining a grammar that will be used to parse Nepomuk search queries. I sent several mails to the nepomuk mailing list, and received very good feedback.

Formality and User-Friendliness

My first mail described a very formal grammar, very much like the one used by the current parser, that uses a key:value syntax (for instance, reservation house hasTag:holidays). The first comments said that this was not user-friendly enough, and pointed me to alternative syntaxes. In fact, I had only a small idea of what would be user-friendly, so these examples greatly helped me.

I then proposed a small modification of my syntax. The first version was purely key:value based, and relied heavily on special characters, parenthesis, colons, operators, etc. The second version made most of these special characters optional, and allowed keys to span multiples words. sent_by:Me could then be replaced by sent by Me, a far more user-friendly syntax.

Simplifying the Parser

The problem with my second syntax is that it is fairly complex. It is a full formal grammar, with nested queries, and even with that the parser is unable to parse something that is not a sequence of key with spaces value statements. In English, nearly everything can be expressed with these kinds of sequences, but other languages in the world need to split the key around the value (if they have detached postfixes for instance), and even “sent last week to Jimmy” cannot be parsed, even if it is a simple rewording of “sent to Jimmy, sent last week”.

After having discussed a bit with Vishesh Handa, my mentor, I began thinking about how a parser could handle these kinds of weird queries. Vishesh also told me that I do not need to keep the new syntax compatible with the old one, so I can simplify my reflection.

Before being accepted as a GSoC student, I developed a small library that parses human-entered date-times. “first Monday of next month” will be parsed to the date of the first Monday of next month. This “parser” is not really one following the strict definition of the term. The date-time is not parsed from left to right (from start to finish), but information is cherry-picked. Rules say for instance that “first X”, where X is a day, sets the day of the current period to 0. “next X” is also a rules, and here is responsible for incrementing the month number.

This approach is not very formal, but allows rules to be written independently of the parser. The parser ceases to be a parser and becomes a scripting environment. In fact, the human date-time parser used per-locale XML files and relied on KDE’s KCalendarSystem class.

For the Nepomuk query parser, I plan to use an approach like this, but a bit enhanced. The idea of rules is kept, but rules become more powerful and less painful to translate.

Architecture of the Parser

I will explain the general architecture of the parser using an example query made of words, English-specific constructs and key/value pairs:

1

e-mails sent by Jimmy, containing "hot dogs", and received before June 13

Don’t be afraid of this query, the plain list of keywords is also recognized by the parser.

The first step is the splitting of the query into words. The split is operated at every character for which QChar::isSpace returns true. Normally, this covers every spacing character for every language handled by the Unicode character set.

When the words are split, the parser uses them to build a list of Nepomuk2::Query::LiteralTerms. This list can be used to search for documents by keywords. The next passes are only here in order to improve the search results, and also to change the simple literal values into something more precise, that can be used for auto-completion when needed.

1

(e-mails) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (13)

The first pass transforms string constants into constants of a more suitable type. For instance, “13” is converted to 13 (the integer), “3.14” becomes a double, “2MB” becomes 2.000.000, and finally “2MiB” is converted to 2.097.152.

1

(e-mails) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13)

Another pass that I have already implemented is what I call type hints. If you have a generic search interface (like KRunner or the equivalent in Plasma Active), the queries entered in them can concern any data indexed on the computer, like files, e-mails, photos, etc. Even if we only think about Dolphin, Nepomuk knows that a file is not only a file, but a document, a picture, a movie, etc. This second pass recognizes type hints in the query and transforms them into filters on the document type.

1

(ResourceType=nmo:Email) (sent) (by) (Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13)

The third pass already implemented matches “sent by X” and “from X” and adds a filter on the sender of an e-mail

1

(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (containing) (hot dogs) (and) (received) (before) (June) (int:13)

Currently, my small experiment does not get the list of known contacts from Nepomuk, but instead tries to directly compare the nmo:messageFrom property with a string. I is not correct and will not work, but I first wanted to have a working parser before being able to generate real queries.

The next passes are not already implemented but will be in the coming days or weeks. One of them could match “containing X” and change the query like this (bif:contains is what the current parser seems to use to match documents containing something, but there may be a better way of doing this):

1

(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (received) (before) (June) (int:13)

The next one matches a day of a month. In English, the month name comes before the day number, but other languages do things differently. This kind of pattern matching can be done using a small pattern language developed for the parser. Each word in the pattern is either an immediate value (it matches a literal value having exactly this value) or a constraint on the term to be matched. For instance, June <integer0> matches “June 13”. The 0 after integer allows the translators to move placeholders around in the pattern, everything will be kept ordered on the C++ side.

So, a day-of-month rule could be <string0> <integer1> in English. The C++ handler for this pattern will first check that string0 is a month name and integer1 is comprised between 1 and 31. Then, the according filter can be output. This rule can be translated in French to <integer1> <string0> as month names and day numbers are inverted in French (we say “13 Juin”). In fact, even in English the phrase can be “13th of June”. No problem, the parser accepts multiple patterns for a rule:

1
2
3
4

d->runPass(d->pass_dayofmonth, i18nc(
    "Day number of a month",
    "<string0> <integer1>|<integer1> (?:th|rd|nd) of <string0>|<integer1> <string0>"
), 2); // 2 = there are two arguments in the pattern

Translators are free to add as many rules as they want. Notice that regular expressions will be allowed (currently, they are not yet implemented). Another modification to the current parser that has to be done is to split “3rd” into “3” and “rd”. This could also be used to split “3GB” into “3” and “GB”, thus simplifying the handling of file sizes.

With that said, the query is now:

1

(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (received) (before) (date:2013-06-13)

The last thing that would be nice to have parsed is the “received before” thing. Here, the parser needs to parse “before ” to produce a new date, but with a hint that the comparison to be done with this date is not the equality, but an ordered relation. Then, the parser has to match “received ” and do the actual comparison:

1

(ResourceType=nmo:Email) (nmo:messageFrom=Jimmy) (,) (bif:contains="hot dogs") (and) (nmo:receivedDate<=2013-06-13)

Now, there is nothing more to do. The parser stops trying rules (it does so in a loop, like optimization passes of a compiler, each rule being able to possibly alter the query and to expose further refinements), and proceeds to the final step: literal values smaller than a minimum size are removed. This removes the comma and the and. We get the final query:

1

(ResourceType=nmo:Email) AND (nmo:messageFrom=contact:Jimmy) AND (bif:contains=string:"hot dogs") AND (nmo:receivedDate<=date:2013-06-13)

If there was a literal value bigger than the threshold and not matched to anything, it would have been matched against its default property. If the literal value is a string, its default property is bif:contains. For a date, it is a set of properties like the date of creation/receiving, modification, etc.

Current state and future plans

• Source code : nepomukqueryparser on GitHub, LGPLv2.1+

Currently, the parser is completely experimental and cannot be used to do anything even remotely useful. I blog about it in order to have comments about the current implementation direction, and to present how I see the parser. I like to communicate regularly on my blog, my average for my GSoC two years ago was one blog post per day or two. Feel free to comment and to find examples of difficult to parse queries, I will try to organize and architecture the parser in order to have it able to parse your query (if it is user-friendly enough).

Another point is that my GSoC project is also about implementing an auto-completed input field. I currently have thought of two strategies that can be used to present auto-completion propositions to the user:

• Patterns are matched from left to right. If the start of a pattern matches (say, more than 50%, or anything containing an immediate value like a keyword), the end of the pattern can be presented to the user. For instance, if I enter “sent by”, the parser knows that the last part of the pattern is a contact, and the auto-complete box can show the list of my contacts.
• Terms are typed. When the user edits the query, his or her cursor is not at the end of the input field, and the parser must be more careful (the user may be breaking already-parsed statements or inserting things between them). The already-parsed terms can be used to know what the user is editing. If the user places its cursor on something that was found to be a date-time, a calendar can be shown.

The current implementation is able to parse things like “mails sent by Jimmy”, and gives the following result:

1
2
3
4
5
6
7

<?xml version="1.0"?>
<type uri="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#Email"/>

<?xml version="1.0"?>
<comparison property="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#messageFrom" comparator="=" inverted="false">
    <literal datatype="http://www.w3.org/2001/XMLSchema#string">Jimmy</literal>
</comparison>

I will post more details in the coming days, as I advance in the parser and solve different problems.

We saw last week the release of the first beta of KDE Plasma Workspace and applications 4.11

From my side, that’s a very important milestone, because it’s pretty much the coronation of what we intended the 4.x series of the workspace to be. It was a long ride, but I think this future release will be pretty stable and “defined” in its own identity.

The 4.11 release of the Workspace will be supported for years to come, marking in fact the last big feature release of the 4.x series.

This sounds pretty scary, but it indicates a lot of maturity, 4.11 will be a release you can count on being maintained abd bugs fixed for a long time. Nice for home users, utterly awesome for bigger deployments.

Just to clarify: this regards only Plasma Workspace so far. Applications will continue feature releases as usual, after all KDE is not a software, is a community that releases a lot of eterogeneous pieces of software.

So, were are now?

• The desktop shell is useful by default. A default setup has all the typical functionality that a typical desktop usage needs, but.. one size does not fit all.
• The desktop shell is very flexible, trying to not force a paradigm on you, assemmble it at your liking.
• We have at least 5 different shells: Desktop, Netbook, Plamsa Active, Media center, part for application dashboards. Because one size does not fit all, on different devices we try to give you the best experience given the particular device.
• QML: It’s very easy to write new components for your desktop/tablet/mediacenter/whatever with an easy scripting language.

But of course we never are happy: we want to do new things and have new features in the future..

• We are porting to Qt5 and QML2
• The whole workspace will be rendered by the GPU: faster and will be possible to have beautiful effects.
• We will have one shell to rule them all: the actual Plasma Shell becomes just a generic “viewer” with no UI whatsoever by itself. Since all the UI elements will be done by QML, they can be loaded and unloaded, so a different device experience can be dynamically loaded when for instance you plug your tablet to a docking station, the full Desktop shell starts.
• Even tough it will mean a quite big technology change, since we are quite happy with the overall direction of each one of our shells, there won’t be radical UI changes, except of course the usual incremental upgrades and refinements.

I’ll do a talk about Plasma2 at Akademy, going a bit more in deep about the technology, the big picture concept and how to get involved in, so see you there

from high languages like java or c# interfaces are known since the very first time, unfortunately this feature is not available in c++. But c++ has a different feature that java for instance does not support: multi inheritance.

meta object system and multiple inheritance

// IContainer.h

class IContainer {

public:
    virtual bool isValid() = 0;
    virtual ~IContainer() {};
};
Q_DECLARE_INTERFACE(
    IContainer,
    "com.sample.Demo.IContainer/1.0"
)

// MessageContainerBase.h

#include "IContainer.h"

class MessageContainerBase : public QObject, 
                             public IContainer {
    Q_OBJECT
    Q_INTERFACES(IContainer)
public:
    MessageContainerBase();
    virtual             ~MessageContainerBase() { }

    virtual bool        isValid();
};

The Benefit

// Foo.cpp

#include "IContainer.h"

void Foo::bar(QObject* bak) {

    IContainer* container = NULL;
    bool valid = false;

    container = qobject_cast< IContainer* >(bak);
    if(container) {
        // inerface is supported, do some nice stuff
        valid = container->isValid();
    }
}

Hello planet!

SFLPhone-KDE 1.2.3 have been released today as a bug fix release 6 months after 1.2.2. This version is (hopefully) the last in the 1.2.* serie. The next generation (1.3) is under heavy development since the last release. According to git diff –stat, 1.3 branch have a massive 16000 lines of changes. It is also 10x faster, less memory hungry and usable (more on that in an upcoming blog post(s)). As for 1.2.3, the new features include macro support, new command line options and being able to be invoked from KaddressBook. Important bug fixes include compilation fix on Fedora 19 beta, prevent race condition when launching SFLPhone-KDE in autostart. On the daemon side, many bugs have been fixed there too. Overall, this release should be quite stable.

The Ubuntu packages should be available soon at https://launchpad.net/~savoirfairelinux/+archive/ppa and on KDE servers.

Enjoy!

Current status

It has been more than 3 months since we started writing a new plasma applet for NetworkManager. Now we are getting closer to have a properly working applet and connection editor for NetworkManager in KDE. Since the last blogpost there are not many big changes but there are a lot of  bugfixes and small improvements, the only one big change is that we implemented the rest of VPN plugins. It’s the time when we would like to release some alpha version or something like that to get users know that plasma-nm is usable and we want some feedback, reported bugs etc. to make it even better. Current maintainer of the old applet and libmm-qt/libnm-qt libraries is going to make a release of these libraries at Akademy so we can release it together and probably deprecate the old applet.  For those who have not seen our applet, there are a couple of screenshots:

If you like it, you can find packages with plasma-nm in some distributions. We have packages for Fedora (provided by me) and as I know also Arch, Gentoo, OpenSuse should have plasma-nm in their repositories. If your distribution doesn’t have plasma-nm packaged you can compile it from sources. You will find more information about compilation and links to sources in the previous blogpost. You can report your problems to KDE Bugzilla.

Plasma active

Well, there is one big news about plasma-nm. Due to the fact that my proposal for GSoC was accepted, I’ll start working on customizing plasma-nm for PA. The current applet for NetworkManager in PA is not much usable for touch devices and even our plasma-nm is not much better so I decided to come with something better. I’m also planning make some PA setting module to allow you to configure some basic things like in Android or in iOS, because for PA running on touch device you won’t use a lot of things we have in the editor from plasma-nm. Finally I have working Plasma active on my Nexus 7, but it has quite annoying issues and I was not able to make it work with MultiBoot to have Android and PA on the same device so I had to replace my Android with PA. Here is a couple of screenshots of plasma-nm running on Nexus 7 with PA:

Akademy 2013

And the last thing and the most exciting for me is that I will attend Akademy 2013. It will be my first Akademy and even my first flight and visit Spain. I have booked a flight and hostel so I hope nothing won’t stop me.

See you in Bilbao

Years ago I had a clear political opinion. I was a civil-rights activist. I appreciated freedom and anything limiting freedom was a problem to me. Freedom of speech was one of the most important rights for me. I thought that democracy has to be able to survive radical or insulting opinions. In a democracy any opinion should have a right even if it’s against democracy. I had been a member of the lawsuit against data preservation in Germany. I supported the German Pirate Party during the last election campaign because of a new censorship law. That I became a KDE developer is clearly linked to the fact that it is a free software community.

But over the last years my opinion changed. Nowadays I think that not every opinion needs to be tolerated. I find it completely acceptable to censor certain comments and encourage others to censor, too. What was able to change my opinion in such a radical way? After all I still consider civil rights as extremely important. The answer is simple: Fanboys and trolls.

When one starts to have a blog in free software one learns the hard way that being a relatively good developer means that you get hated. If you achieve something you get attacked, you get insulted, you get called a dictator [1], you get compared to Hitler [2], etc. etc. People say that you need a thick skin if you want to work in free software. I disagree. There shouldn’t be a need to have a thick skin. We are improving the world, we donated lots of our spare time to work on free software, we donate the source code we write for the public good and we are thanked by insults. This is not acceptable! Even if people dislike some specific software or are a great supporter of another software there is no reason to insult the people or the products. It never is! Not even if it is Microsoft or Apple or Google. There is no reason to attack them.

One of the first experiences I made in this regards was blogging about performance improvements. We can see that most users are thankful for the improvements but that there are also direct attacks. These are irrational, why would one attack the person who improved the situation? Why kill the messenger? People tend to discard it as “haters gonna hate”, but is that the answer to the problem? Do we have to tolerate such comments? Do we need to be hated just because we improve software and blog about it? Nowadays I would just delete such comments, that’s the change in my reaction to handle such situations. My skin became thicker over the years, but overall I prefer to have a thin skin as I used to have – it fits my overall character better.

Over the years I started to observe the behavior of the “haters”. For example I noticed that in the time after the release of GNOME Shell and Unity the hate against KDE increased. This was irrational, especially the reasons for the hate. KDE’s software had matured at the time when GNOME Shell and Unity did their release, so why attack KDE then. Yes after 4.0 that was kind of rational, but the attacks had mostly stopped. So why did they start again? I’m nowadays quite sure that if we would go back we would find an increase of attacks against GNOME at the time of 4.0/4.1.

Free software users are very enthusiastic about their used software. One could even say that they are religious about it. Not only that they also create a kind of split between mostly GNOME and KDE community. The decisions to use either KDE Plasma or GNOME Shell are hardly rational. There are emotions involved and used at the rational for why one uses KDE Plasma or GNOME. The software of the other projects is evil and one cannot use it. We tend to call users with such opinions as “fanboys”, but I find this word unsuited, I call them “religious fanatics”. I will explain in more detail why I compare to religion later on.

Now we all know the irrational reasons on why to not use GNOME software. GNOME is removing features, they are “interface Nazis” and don’t care about their users. KDE software on the other hand is ugly, too complex, slow and unstable.

When basing your decisions on irrational reasons it is inevitable that you will face cognitive dissonance. The introduction of GNOME Shell and Unity at the same time are good examples for triggering cognitive dissonance. The fanboys are convinced that GNOME is the best software in the world, but now they are transited to at that time incomplete software breaking their existing workflows and requiring to relearn. Many things are no longer possible. The belief that GNOME is better than KDE software is seriously challenged by the new experience.

One of the solution to solve this cognitive dissonance is to make KDE software worse in comparison to GNOME Shell or Unity. Being convinced that KDE software is still worse than the other software the dissonance is resolved. That is a blog post about performance improvements is a wonderful way to be confirmed that KDE software is slow, a news about fixed bugs is a wonderful way to show that KDE software is unstable. This explains the strong hate against KDE starting with the releases of GNOME Shell and Unity. Fanboys are trying to resolve their cognitive dissonance.

Obviously GNOME Shell and Unity are only an example. We can observe the same kind of cognitive dissonance with KDE fanboys. An example I can observe in regular intervals is that “the next version is much better and solves all problems” whenever a user is reporting about instabilities or other problems. The fact that another user is experiencing problems is challenging the beliefs of the fanboys which can be resolved by stating that the next version resolves it. We can see these comments for each version since 4.1.

Quite recently we could observe the same kind of cognitive dissonance with the Ubuntu fanboys. Mir was a real challenge to anybody who deeply believes that Canonical is doing the right thing all the time. Given that I wrote a few blog posts on that topic I was able to observe how fanboys tried to resolve their cognitive dissonance. My favorites were that I am the reason why free software is failing because I don’t support Mir. Canonical made it quite difficult for their fanboys to resolve the created cognitive dissonance. Of course reasons were provided but those had been shown as wrong very fast. Fanboys tried to resolve the dissonance by coming up with reasons like “development was too slow, someone had to do something”, which didn’t really resolve it as it’s obvious that the development power would have also helped Wayland. Just yesterday I was able to observe a fanboy in my blog comments. “Please re-read it and make it logically sane and spelling error free.” A wonderful example of adjusting the reality by making my arguments invalid because I had a typo in a reply. My argument that we cannot support distro-only solutions got discarded because there is also YaST which is also distro-specific. On a rational view this argument doesn’t make any sense but under the light of resolving cognitive dissonance it makes all the sense in the world. The fact that distro-specific software is a problem is diminished by pointing out other distro-specific software even if doesn’t matter for the argument (we do not depend on YaST).

I consider these fanboys as a threat to free software. By being irrational they harm everyone. They use emotions for something which should not have emotions. They make it difficult to work in free software. In fact it’s not a problem specific to free software, but can be observed overall in IT. Apple is also a good example for such fanboys. But only in free software fanboys can interact directly with developers and spread their harmful behavior. In the proprietary world they are blocked at the marketing department which is trained to work with such situations.

We need to find solutions to the fanboys and one of the solutions I came up with is to block them on my blog posts. I can tolerate trolls as it’s much easier to handle them. But fanboys are only there to harm you to diminish your work so that their world view doesn’t break. And that’s why I call them religious fanatics. They behave exactly the same. Just compare that to Intelligent Design to resolve the cognitive dissonance caused by evolution. I dislike any religious fanaticism whether it’s a crusade, jihad, IRA or free software. Any religious motivated fanaticism is harmful and needs to be fought, even if it is free software. Yes one can grow a thick skin to handle the fanboys, but that just shouldn’t be needed. Being compared to Hitler hurts no matter how thick your skin is. And if a GNOME developer stops work because of KDE fanboys it’s not GNOME who lost a developer, it’s free software who lost a developer. It’s one of us. We are also GNOME!

Final remark: please don’t come and tell me that I’m the same by criticizing Mir. It’s not the same. Criticizing decisions and having discussions is important, but of course critic has to be constructive. I have never attacked any of the Mir developers or have attacked the software in any way. I criticized the decision and the reasoning and pointed out the problems it causes for us, but I have in no way attacked Canonical, Ubuntu or Mir.

[1] Yes there are free software developers who are called a “benevolent” dictator. I disagree. There is no such thing as a benevolent dictator. Every dictator is bad and one shouldn’t define dictatorship down by calling someone a benevolent dictator.

[2] Yes all of that happened to me. Someone even compared me to one of the worst mass-murderers in human history because I do free software and have an own opinion.

Since KDE has released the first beta of Platform, Workspaces, and Applications 4.11, there will be some changes in the packages offered in the openSUSE repositories.

Last week we had our monthly Gentoo KDE team meeting; here are few details that are probably worth sharing.

• So far we've provided the useflag "semantic-desktop" which in particular controls the nepomuk functionality. Some components of KDE require this functionality unconditionally, and if you try to build without it, bugs and build failures may occur. In addition, by now it is easily and reliably possible to disable e.g. the file indexer at runtime. So, we've decided that starting with KDE 4.11 we will remove the useflag and hard-enable the functionality and the required dependencies in the ebuilds. The changes are being done already in the KDE overlay in the live ebuilds (which build upstream git master and form the templates for the upcoming 4.11 releases).
• After recent experiences the plan to drop kdepim-4.4 is off the table again. We will keep it in the portage tree as alternative version and try to support it until it finally breaks.
• In the meantime we (well, mainly Chris Reffett) have started in the KDE overlay to package Plasma Active, the tablet Plasma workspace environment. Since Gentoo ARM support is already excellent, this may become a highly valuable addition. Unfortunately, it's not really ready yet for the main tree and general use, but packaging work will continue in the overlay- what we need most is testing and bug reporting!

Today we bumped  KDE SC 4.11 beta 1 (4.10.80) in the gentoo kde overlay. The semantic-desktop use flag is dropped in >=kde-base/4.10.80, as you may already noticed or read in dilfridges blog post. So if your hardware is not powerful enough or you just don’t want to use the feature you can easily disable it at runtime.

1. Go to the “System Settings” and search for “Desktop Search”

2. Uncheck at least the file and email indexer. You can also disable the “Nepomuk Semantic Desktop”.

Have fun!

Update

If you want to disable Akonadi you can check out this blog post.

A fresh installed Ubuntu 13.04 offers a guest account at the login prompt. That might be handy for others, but I wanted to get rid of it. This can easily be done by adding an appropriate configuration flag to the LightDM configuration at /etc/lightdm/lightdm.conf: allow-guest=false.

$ cat /etc/lightdm/lightdm.conf
[SeatDefaults]
user-session=ubuntu
greeter-session=unity-greeter
allow-guest=false

After a LightDM restart (or simply a machine restart) the guest account is not offered anymore.