fidzu : KDE

Having announced qmlbook.org yesterday, the reception has been fantastic! Over two thousand unique visitors from all over the world (see the map below) and almost 8000 page views. Add to this that we clashed with the Qt 5.2 release announcement, and I'm overwhelmed.

13 Dec 2013 6:40am GMT

With KDE Applications 4.12 about to be released, it's time to look at the changes which went in Gwenview during this cycle. Unfortunately, I am afraid the answer is : not much.

I just went through the revision log and despite the usual bug fixes, I could only find two relatively significant changes.

Nicer meta information sidebar

I have never been happy with the way the sidebar displayed meta information about the image. I finally took some time to work on it. Here is a before / after:

As you can see, I went for a stacked design with wrapping text. It makes better use of the space, providing more room for the content.

Nicer meta information window

Related to the meta information sidebar, I worked a bit on the window which opens when you click the "More..." link in the meta information sidebar. The properties listed in the window were not sorted, making it difficult to find what one is looking for. They are now sorted alphabetically by property keys, and some useless properties, either unnamed or filled with large binary content, are now hidden.

Retrospectively, I should have added a search line in there as well. Unfortunately it is too late for 4.12.

What about 4.13?

Not much planned from my side for now, as you guessed I am not very active on Gwenview these days. There is a fancy new feature nevertheless, which I know some of you have been asking for a while: raw file preview support!

Thanks to great work from Martin Kyral, Gwenview can now display previews embedded within raw files. I am not the target audience for this feature, so I'll quote Martin instead:

[Raw support] theoretically enables gwenview to support everything dcraw supports (I haven't found a raw file that gwenview doesn't show with this patch). The patch does not perform full demosaicing nor any tweaks (set white balance or so) and I don't think it shall - digikam, darktable or rawtherapee are much more suited for developing the 'digital negatives'.

That's it for this cycle. Hope you are going to enjoy your (slightly) refreshed Gwenview 4.12!

12 Dec 2013 5:00pm GMT

ownCloud and openSUSE are two of my favorite projects. After they both have released major new versions I have updated my ownCloud in a box appliance now, so that it's easy to get the latest and greatest what ownCloud and openSUSE have to offer. The appliance is built with SUSE Studio as usual and comes in a variety of formats to allow installation on physical and virtual systems, running it from live media, or deploying it to the cloud. Check it out on SUSE Studio's gallery.

One of the big new features of ownCloud 6 is ownCloud Documents, a collaborative editor based on ODF. This is a pretty cool feature as it allows groups of people to work together on a document with rich text. The best is that it's all free and open and you can run it on your own server so you have full control about your data.

There is much more. Read on about what's new in ownCloud 6 and what's new in openSUSE 13.1. Congratulations to both projects for two fabulous releases. I'm looking forward to more to come.

12 Dec 2013 4:48pm GMT

Qt 5.2 has just been released! Coming only five months after 5.1, the new release brings in a huge number of new features, as well as many bug fixes. For the first time ever, Qt is officially supported on two major mobile platforms: Android and iOS.

KDAB contributed over 300 commits to Qt 5.2, both in terms of new features and bug fixes, making it the second largest company contributing to Qt (after Digia itself). The commit stream has been constant, as you can see in this graph showing the last 16 weeks:

Contributions to Qt by employer (excluding Digia), from here

In this blog post I'll show some of the notable features developed by KDAB engineers that you are going to find in Qt 5.2.

Official Android support

For more information about what you will find in Qt 5.2, check out the Qt on Android blog series authored by my colleague BogDan Vatra, who created the Necessitas project and originally ported Qt to Android.

QVariant and QMetaType improvements

Our engineer Stephen Kelly presented these features in his talk at the last Qt Developer Days (slides).

Custom conversion and comparison operators

QVariant and QMetaType have always supported working with user-defined data types, but somehow user types have always been "second class citizens". For instance, QVariant is able to perform type conversions between Qt types:

QDate d(2013, 12, 11);
QVariant v(d);
qDebug() << v.toString(); // prints "2013-12-11"

However, the same code fails for user-defined types:

MyDate d2(2013, Dec, 11); // custom date class
QVariant v2 = QVariant::fromValue(d2);
qDebug() << v2.toString(); // prints ""

This happens because these type conversions are actually hardcoded inside Qt, and the user had no means to register custom conversion functions.

QVariant conversions between any pair of types has become possible starting with Qt 5.2. Now we can register a free function or a member function within Qt's meta type system:

QString myDateToString(const MyDate &d)
{
    return QString("%1-%2-%3").arg(d.year()).arg(d.month()).arg(d.day());
}
// ...
qDebug() << v2.canConvert()<QString> << v2.toString(); // prints "false """
QMetaType::registerConverter(&myDateToString);
qDebug() << v2.canConvert()<QString> << v2.toString(); // prints "true 2013-12-11"

Of course, at least one of the types must be a user defined type - we can't override the converters amongst Qt's built-in data types.

We can also register custom comparison operators (that will be used by QVariant's operator== and operator<) and custom QDebug streaming operators (that will be used when dumping a variant via the debugging streams, such as qDebug()).

Type-erased container iteration

This is a nice little feature that allows to iterate on any QVariant which is holding a sequential or an associative container (such as QList, QVector, QHash, but also std::vector, std::map, etc.), and doing that without knowing the exact type of the container held (that is, performing type erasure) and without paying the cost of copying the container out of the QVariant object.

Starting from 5.2, any QVariant object holding a sequential container or an associative container will report true when asked if it be converted to a QVariantList or a QVariantHash respectively. We can then use the special types QSequentialIterable (for sequential containers) and QAssociativeIterable (for associative containers) to iterate on the container's contents.

For instance, this code iterates in a type-erased fashion on a list stored within a QVariant object:

QList<int> intList;
intList << 42 << 51 << -24;
QVariant variant = QVariant::fromValue(intList);
if (variant.canConvert<QSequentialIterable>()) {
    QSequentialIterable iterable = variant.value<QSequentialIterable>();
    QSequentialIterable::const_iterator it = iterable.begin();
    const QSequentialIterable::const_iterator end = iterable.end();
    for ( ; it != end; ++it) {
        qDebug() << *it;
    }
}

Note that there's no mention within the cycle of either the container's type or the container elements' type.

Automatic smart pointer unwrapping

QVariant API is very convenient to use when it comes to value types, such as strings (QString), date/time objects (QDateTime), and so on. It's also possible to use it to hold an instance of a so-called identity type, most notably QObject subclasses - or, better, hold a pointer to an instance of a QObject subclass. (This happens because identity types do not match QVariant requirements - for instance, they are not copyable.)

Moreover, identity types have the problem of ownership: one can use the parent/child system (to delete the children when the parent gets destroyed), but also have a more complex ownership. For instance, one might employ shared ownership by using smart pointers, such as QSharedPointer (for strong ownership) and QWeakPointer (for weak).

Before Qt 5.2 it was perfectly possible to create a QVariant that encapsulates a smart pointer to an instance of a QObject subclass. Actually, Qt 5 even removed the need to declare the smart pointer metatype - in other words, Q_DECLARE_METATYPE(QSharedPointer<T>) was no longer needed.

Starting with Qt 5.2 QVariant can also unwrap the raw QObject pointer:

class MyObject : public QObject
{
    Q_OBJECT
    // ...
}
QSharedPointer<MyObject> sp = QSharedPointer::create(arg1, arg2);
QVariant v = QVariant::fromValue(sp);
QObject *obj = v.value<QObject *>(); // works in 5.2

OpenGL improvements

Qt Quick 2 now works with the OpenGL Core Profile

As you might know, Qt Quick 2 contents are drawn using an OpenGL scene graph.
The renderer visits the QML object tree and builds a tree of QSGNodes that constitutes the scene to render. This scene is visited again and then drawn using OpenGL or OpenGL/ES 2 commands (depending on the platform); please refer to the above link for a more in-depth explaination about the renderer (which by the way got an overhaul in Qt 5.2).

However, the new renderer (and the old one) had a limitation: it required the usage of a so-called compatibility profile, that is, an OpenGL implementation which offers all the old, legacy functionality that has been deprecated in OpenGL 3.0 and removed from OpenGL 3.1.

Vendors are not mandated to offer such a profile - the OpenGL standard lets the vendors decide whether they want to implement it, or just implement the non-deprecated set of functionality, i.e. the so called core profile. Such a vendor is for instance Apple: both in OS X 10.8 (Mountain Lion) and 10.9 (Mavericks) one can't create a >= 3.2 OpenGL compatibility profile context.

Hence, a developer targeting these systems couldn't for instance mix Qt Quick 2 with pure OpenGL content, if the content actually requires features introduced in OpenGL 3.2 or later! (For instance, geometry or tessellation shaders.)

We took care of this problem with a massive refactoring effort, which included extracting and adapting over 50 shader programs; we're happy to announce that it's now possible to use Qt Quick 2 with any OpenGL core profile (such as the OpenGL 4.1 profile offered by OS X Mavericks).

QOpenGLTexture

OpenGL is a key technology in Qt 5. For this reason, the OpenGL support was moved into QtGui, which since from 5.0 has offered OpenGL enablers - convenience, high level classes to wrap the OpenGL APIs in a more object-oriented design.

We now have classes for wrapping buffer objects, vertex array objects, framebuffer objects, shaders and shader programs, and so on.

KDAB has contributed the QOpenGLTexture class to Qt 5.2, which encapsulates an OpenGL texture object. It offers all the features you'd expect from a modern texture class: immutable storage, texture views, a direct state access-like API (emulating it if necessary), and so on.

If you missed it, you can check out the awesome OpenGL in Qt blog post series that explained many of the features introduced in Qt 5.0 and 5.1.

QNX maintenance

As shown by the commit graph above, KDAB is still putting efforts at improving Qt support under the QNX operating system (used for instance on BlackBerry phones and tablets). Amongst the features you can find in 5.2 there is support for QNX's mm-renderer multimedia APIs in QtMultimedia, preliminary support for the BlackBerry native file dialog, improved camera handling, as well as many bug fixes.

Other contributions

QAbstractScrollArea

QAbstractScrollArea (and therefore its subclasses, such as QListView, QTableView, QGraphicsView, and so on) can now honour the size hint of the contents (the viewport), by setting the size adjust policy. This allows QAbstractScrollAreas to resize when the contents change (for instance, when new columns are added in a QTableView).

QCommandLineParser

Command line parsing is a very common task in console-based application. Qt now offers the QCommandLineParser class to ease the task for developers; my colleague David Faure took the initial contribution (coming from Laszlo Papp, of KDE and QtSerialPort fame), polished it and went through endless review iterations in order to merge it in time for Qt 5.2.

He also went further, and rewrote the command line parsing of Qt's own tools (moc, uic, etc.) to use the new class.

Conclusions

Qt 5.2 is the best release of Qt ever. It allows developers to target a broad range of devices and operating systems, from modern mobile platforms to the traditional desktops, while keeping the stability and the quality we expect from it. We're glad to be contributing to its success.

The post KDAB contributions to Qt 5.2 appeared first on KDAB.

12 Dec 2013 2:00pm GMT

Next in Kubuntu:

Allowing you to give us viable information on a crash even if you don't feel like reporting a lengthy bug report over at bugs.kde.org.

12 Dec 2013 12:19pm GMT

Since I took over Dolphin's maintainership almost a year and a half ago, we have not only fixed lots of bugs and improved many details which make Dolphin more pleasant to use, but also made quite a few changes under the hood to make Dolphin faster and less memory-hungry. The other day, I compiled a few different Dolphin versions and ran some benchmarks to see how much has changed during the past 18 months.

The most straightforward way to get an idea of an application's performance is to see how it can handle a large amount of data, so I created 100,000 empty files in a new directory using

touch a{1..100000}.txt

I then built the tags v4.9.0, v.4.10.0, v.4.11.0, and the KDE/4.12 branch (to be precise, commit f863968b7) of the kde-baseapps repository in release mode, and checked how long it takes to open the directory with my rather old computer (Athlon 64 X2 5000+ CPU) in all view modes: Icons, Compact, and Details. For all my tests, I used the same recent KDE/4.12 checkout of kdelibs (commit 3028cc4b6). I opened the directory in Dolphin once and then closed the application before starting the measurements, to ensure that the files are cached by the kernel, and that slow disk reads with non-reproducible access times do not add noise to the results.

The time required to load the directory is measured and written to the shell that Dolphin is run from with a simple patch. After the initial loading, I pressed F5 eight times and calculated the mean value of all results to reduce random fluctuations. Here are the results:

Moreover, I measured with KSysGuard how much memory the Dolphin process uses. The memory usage fluctuates less than the time which is required for loading the directory, but still, I started Dolphin five times and calculated the mean value.

I hope that you like these results as much as I do! All Dolphin users should see similar relative savings, but the absolute values might obviously be different. E.g., the memory usage will be much lower on a 32-bit system because all pointers need only 4 bytes instead of 8.

I will tell you in a minute how these savings were achieved, but let me first make some remarks, which will also answer the questions that some readers might already have.

• The timer whose measurements the first plot is based on is started just before the KDirLister's openUrl(const KUrl&) method is called, and stopped when the files are shown on the screen. In v4.9.0 and v4.10.0, the CPU and disk were still busy for quite some time after that, because Dolphin versions before 4.11.0 loaded the icons for all files in the background (some details can be found in a recent blog post). In v4.10.0, it took more than two minutes on my system until this process was completed. During these two minutes, the memory consumption grew very slowly, but constantly, until it reached the final value which is shown in the second plot. In v4.9.0, that took even much longer due to some inefficiencies which were fixed before v4.10.0 (for example this one). Therefore, it was not really possible to perform detailed memory usage measurements for v4.9.0. I just took a single data point and found that there is not a huge difference between v4.9.0 and v4.10.0.
• The reason why Details View often requires more memory than the other view modes is that the correct handling of expanded folders requires some additional data, and earlier Dolphin versions initialized the corresponding data structures even if it was not clear yet if these data would be needed or not. This is also the reason why Details View was the slowest view mode in v4.9.0 and v4.10.0.
• In Icons and Compact View, more time is spent on the item layout because the height of a row (in Icons View) or the width of a column (in Compact View) depends on the file names. In Icons View, we calculate how many lines of text will be shown under each icon, and in Compact View, we calculate the width of the text (which is slightly cheaper because no line breaks have to be taken into account). This information is needed to initialize the scroll bar correctly. We might consider using guessed values for the files far from the ones which are visible on the screen, but ensuring that this works correctly in all cases when scrolling in the view, and no subtle bugs occur when items which had their on-screen size guessed suddenly become visible, and the maximum value of the scroll bar needs to be updated, is not trivial.

Now I will summarize some of the main ideas that were used to achieve these results. Maybe some of them are also interesting for other applications and libraries.

Dolphin 2.2/KDE SC 4.10.0

• Emmanuel Pescosta speeded up sorting by modifying our Merge Sort implementation such that it makes use of multiple CPU cores.
• He also modified a function that is responsible for loading icons: all recently loaded icons are now cached, which reduces the CPU and memory usage if there are many items shown on the screen which share the same icon.

Dolphin 4.11.0

• We no longer load icons and previews for all files in the current directory.
• The amount of data which are stored in advance for the "expanded folders" bookkeeping in Details View was reduced.
• We ensure that all QByteArrays with equal contents share the same memory (for details, see my recent post about Dolphin 4.11).
• We use QVector, rather than the wasteful QList, for storing items which need more space than a pointer. In that case, QList would not store the items directly, but allocate space for them on the heap, and store pointers to them. Therefore, there is an overhead of one pointer for each item, plus any overhead that the memory allocator adds.
• Some functions which add or remove items from the view have been made faster, see the Dolphin 4.11 post for details.

Dolphin 4.12.0 (not yet released)

• The view receives all data for each item from the class KFileItemModel in a QHash<QByteArray, QVariant>. The QByteArray key is something like "text", "size", "iconName", "iconPixmap", etc., and QVariant is a very flexible data type that can wrap, e.g., a QString or a QPixmap. In earlier Dolphin versions, KFileItemModel initialized this QHash for every item in the current directory before anything was shown in the view. This took quite a bit of time and memory - there is a Qt Quarterly article which visualizes the overhead that QHash adds to the actual data that it stores. In most cases, we now initialize this QHash lazily, i.e., only just before the item that it belongs to is really shown on the screen. The corresponding patch could only work because some code that relied on the QHash always being initialized had also been modified (1, 2, 3).
• Even if we have to initialize the QHash for an item, we do not store "default" values any more. One example: the QHash stores, among other things, the information if the item is "expandable", i.e., if it is a non-empty folder that can be expanded in Details View. However, if we have a

  QHash<QByteArray, QVariant> hash
  

  that does not contain the key "isExpandable", then

  hash.value("isExpandable").toBool()
  

  will return false. Therefore, it is not necessary to store the value "false" at all.

  Similarly, storing other kinds of data in the QHash which are equal to the default values returned by QHash::value(key) is not necessary.

• Sorting the files "naturally", i.e., sorting them such that the order in the view is

  file1.txt
  file2.txt
  ...
  file9.txt
  file10.txt
  

  rather than

  file1.txt
  file10.txt
  file2.txt
  ...
  

  is quite time-consuming because the string comparison function

  KStringHandler::naturalCompare(const QString &a, const QString &b)
  

  essentially has to chop the two strings a and b into little "number" and "text" chunks, which are then compared in a locale-aware way.

  Qt 5 provides a class QCollator (public API since Qt 5.2 thanks to the awesome work of Aleix Pol), which can be used to pre-compute a "sort key" for every QString in advance. Comparing two "sort keys" is much faster than comparing the QStrings in a natural and locale-aware fashion. This means that O(N log(N)) expensive comparisons are replaced by O(N) "sort key" calculations, which might be expensive, and O(N log(N)) cheap comparisons.

  However, it turned out that we can improve the sorting performance even while we are still using Qt 4.8. The key observations are:

  1. Sorting the items with QString's operator "<" as the comparison function is very fast.
  2. After this fast sorting, the order of the items is not totally correct, but most of the time, the order is quite close to the correct one.
  3. The number of comparisons that our Merge Sort implementation needs is greatly reduced if the order of the items is "mostly correct".

  Therefore, we now sort the items twice: first using QString's operator "<", and then using KStringHandler::naturalCompare. This simple change reduced the time required for sorting by 63% in my tests.

  Some readers will probably have noted that there is a sorting algorithm which is designed to make use of input data which are "mostly sorted" already, and which might therefore improve the performance even further: Timsort, which is used, e.g, as the default sort algorithm in Python (1, 2). Maybe we will use it in future Dolphin releases.

• In the class KItemListViewLayouter, which is responsible for the layout of the items in the view, we calculated and stored some redundant data for all files in the current directory: both the size of an item (i.e., how much space the icon and text need on the screen, that is 2 numbers for width and height), and the rectangle that contains the item (storing a rectangle requires 4 numbers). Before an item was shown on the screen, the rectangle was adjusted according to the current value of the scroll bar(s). Now we only store the size and the position of the top-left corner of the rectangle. The final rectangle can easily be constructed from these once it is necessary.

Outlook

I still have some ideas for improvements inside Dolphin, but as Mark Gaiser pointed out in his comment to a review request, the major remaining consumer of huge amounts of memory is the class UDSEntry from kdelibs. I assume that few people know this class, but it's being used indirectly by every application that uses the KIO framework to access directory contents either directly or indirectly (e.g., via the "Open/Save File" dialog).

UDSEntry is used to transmit all kinds of information about files from kioslaves (which are the helper applications that read files from disk, or access remote files via sftp, smb, etc.) to the applications. A first optimization which is already in the master branch of kdelibs is to make use of Milian Wolff's implicit sharing trick once more. The idea is that the user name and the group are very often the same for many files in a directory. Therefore, the function that receives the UDSEntries from the kioslave now checks if, e.g., the user name for a file is the same as the one for the previous file. If that is the case, the same implicitly shared QString is used for both. If all files in a directory belong to the same user, the same implicitly shared QString will be used for all.

In the benchmarks I discussed at the beginning of this post, there were 100,000 copies of my user name, and 100,000 copies of the group name "users" in memory - it should be obvious that this is not really efficient.

I will discuss further possibilities to optimize UDSEntry in a future blog post. For the time being, here are the raw data for the plots above, including the benchmark results for the master branches of kde-baseapps and kdelibs, which include the first UDSEntry optimization:

Conclusion

I hope that I made clear what the key ideas are, and that these might be useful also for some readers of this post:

• Do not determine large amounts of data in advance if it is likely that most of these data will never be needed.
• Do not store redundant data: think twice if everything that is stored in memory is really needed, or if there is another solution that can achieve the same with less memory.
• Make use of implicit sharing: if there are many QStrings, QByteArrays, or other implicitly shared data in an application, many of which are likely to be equal, check if they can share their memory.
• If some calculation takes very long, try to find a more efficient algorithm.

Finally, I would like to thank everyone who helped to make these improvements possible. In particular, I would like to mention Mark Gaiser, who loves to stress-test file managers with half a million files and share his findings on our mailing list. Without his challenges, some of the work presented here might not have happened.

12 Dec 2013 7:59am GMT

Juergen Bocklage-Ryannel and myself are writing a book! As we've reached the point where we want to share our work with the workd, we are happy to open the doors to the book Qt 5 Cadaques - A Book about Qt 5! It all started a couple of years back, when two developers saw a need: there where no books approaching Qt from the QML side. We decided to solve the problem by writing a book.

During these years, lots has happened in the land of Qt. The ecosystem around the Qt Project has stabilized after the whole Microsoft-Nokia thing. Jolla has released a phone with Qt 5, as has Blackberry. Ubuntu Phone will be based on Qt 5. The Raspberry Pi has taken on the whole world with a great hardware that runs great with Qt 5. It is now possible to target both Android and iOS using Qt 5.

Looking at these changes, one can see that Qt really has grown towards mobile. Towards device user interfaces. User interfaces where the look and feel has to be integrated into the context of a physical device. This is where Qt Quick and QML really shines. Before I go on, it is worth pointing out that the Qt ecosystem has grown towards mobile, it has not moved there. The cross platform desktop support is still there and works just as great as it has for almost 20 years now!

For aspiring Qt developers, there is a plethora of documentation for using Qt from C++. There are multiple books on the topic. However, when targetting devices, C++ is only a part of the story. Here, Qt Quick and QML are equally important. That is why we are happy to make Qt 5 Cadaques available!

A final word of warning. The book is being written as you read it. We believe in the open source mantra release early, release often. This means that the text currently is in its early stages. We have setup a feedback system so that you as a reader can help us improve the material by pointing out issues. We are also looking for ways to grow the contents. We also keep a project blog on the site to announce our releases and to ask you about your opinion on the book. We would love for you to tell us what you want to read about!

12 Dec 2013 6:43am GMT

November has been very hectic for most, let's have a look at what we've achieved

Network management (plasma-nm | libnm-qt | libmm-qt)

: jgrulich, ltinkl

• finished ModemManager 1.0 support in libmm-qt
• new releases - plasma-nm 0.9.3.2, libmm-qt 1.0.0, libnm-qt 0.9.8.0
• plasma-nm usability study - http://user-prompt.com/shape-the-future-of-managing-network-connections-in-kde/
• usability discussion on the KDE PIM Sprint
• started working on usability improvements

Fixed bugs:
kdebz#326274 - Newly created shared wireless network cannot be seen if disconnected once
kdebz#327160 - No warning when trying to connect to VPN withouth plasma-nm-vpnc installed
kdebz#326991 - Connection editor bug reporting refers to non-existing component
kdebz#327386 - Can't enable AP mode if there are other saved wireless networks
kdebz#327758 - Report bug freature does not work
kdebz#327759 - Edit connections dialog looks bad on high DPI screens
kdebz#328138 - Plasma widget network manager uses wrong (bold) font

Display management (sddm, kdm)

: mbriza
Change tracking bug: rhbz#998542

• First, on November 26th on the KDE SIG meeting we decided to push the feature forward to the next Fedora release because bugs that were discovered during pre-release stages of Fedora 20 were not fixable until the final release. I will continue to work on it to make a better substitute for KDM.
• again, spent a lot of time working on the authenticator, discussed it with David Edmundson, we'll work on making it a completely separate library in the future, to be used by some KDE tools, too
• designed a new configuration parser and definition classes
• some other bugfixes, minor compared to the listed ones.

Multimedia (phonon)

: dvratil
Phonon GStreamer

• finally tracked down and fixed a crash when closing Amarok when using phonon-gstreamer 1.0 (kdebz#320448)
• started investigating Amarok crash with phonon-gst (kdebz#290706)

PIM

: dvratil
Akonadi

• continued working on Akonadi IDLE (now in sort-of-works state)
• finished migration code in parttable-optimization branch and merged to master for 1.12
• fixed a regression introduced in the branch
• wrote proof-of-concept implementation of Akonadi-side tags
• started working on server-side search implementation
• released Akonadi 1.11.0
• ported Mail Filter agent to be an Akonadi Preprocessor

Fedora general

• Fedora KDE Test day

Other

• Nov 11 - Nov 15: hosted a small hackfest with several KDE hackers to work on Solid, KScreen, plasma-nm, KDE Telepathy and Akonadi
• Nov 15 - Nov 17: hosted the KDE PIM Sprint - 20 KDE PIM developers met to talk about KDE PIM and Frameworks, discuss new features, nail some nasty bugs and have fun

[1] Martin Bříza (mbriza), Jan Grulich (jgrulich), Than Ngo (than), Lukáš Tinkl (ltinkl), Dan Vrátil (dvratil)


You can find us on #fedora-kde channel on Freenode IRC

11 Dec 2013 1:06pm GMT

• Quality. ownCloud is a very fast moving project so it is super important to balance innovative new features with rock solid stability. The ownCloud community introduced several important techniques to improve the quality. As a result we fixed a huge amount of bugs in this release. Also some very old and annoying issues are finally gone. I think this is very important for a lot of users. We will release a series of bugfix releases for in the next few month to iron out the last remaining issues. This is a big step forward.

• Performance. The performance of ownCloud 6 improved significantly over older versions. The overall file-handling is faster and more optimized. In some areas, like the mounting of SFTP, CIFS or Dropbox servers, the performance improved over 10x. This is great for people who run their ownCloud server on a small device like a Raspberry Pi or on a big cluster to serve hundred thousands of users.

• Innovation It was always to goal of ownCloud to deliver innovative features to our users and to be the innovation leader in our space. I don't want to repeat my previous blog posts where I announced the great new features of version 6. Just look at my posts here. http://blog.karlitschek.de/2013/10/introducing-owncloud-6.html and http://blog.karlitschek.de/2013/10/welcome-owncloud-documents.html
• But I have to say that I'm especially proud about what we did with ownCloud Documents. This is a feature that doesn't exist anywhere else. Other collaborative editing solutions are 1.) proprietary or 2.) don't run on your own hardware or 3.) don't work on top of normal files that you can also sync and share or 4.) a combination of all of this. I belief that this features is super important for the future and the huge response we got from users clearly show that I'm not alone here. This is only the first version of this feature of course. We will keep on improving and polishing it in the future.

11 Dec 2013 1:06pm GMT

KDE's integrated development environment has released a new version.

Packages for the release of KDevelop 4.6 are available for Kubuntu 13.10. You can get it from the Kubuntu Backports PPA. They are also in our development release.

Bugs in the packaging should be reported to kubuntu-ppa on Launchpad. Bugs in the software to KDE.

11 Dec 2013 12:42pm GMT

Today I'd like to share a revelation with you:

Developing C++ can actually be fun.

How you work can define your productivity

In the next sections I will tell you a bit about how I develop KMix today, and why the newest toolchain gave me a productivity boost. As a peek ahead, this post is mainly about developing KDE applications with Eclipse.

If you just came across this post via searching for Eclipse, C++ and cmake, then you might want to directly head to the practical example at the end of this post.

The core message is that the environment you work with can have a very high impact on productivity. As an example, see the picture to the right from my office: Isn't this a more comfortable environment than - a cubicle? OK, I was talking about productivity, wasn't I? So lets forget the image quickly.

The C++ nuisance and rant

Honestly, most of the time C++ development is a nuisance for me. For a better understanding, you should know that I am a 95% Java developer nowadays. And if you do a lot of Java, C++ is full of strangeness:

• Incompatible Headers (try to compile http://thrift.apache.org/, if you are really masochistic)
• Too many standards (SUSv3, misc POSIX variants, various C++ standards, half-implemented)
• Nearly worthless constructs like volatile (https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt)
• Complicated threading, no real Unicode in the standard, and so on and so forth

CMake and Eclipse as a rescue boat

If you get good tool support, C++ can still be a very good language. CMake helps a lot. For the source code editor it is more complicated: In the past I used every viable tool for KMix development, including misc versions of emacs, vi, aXe, kate, KDevelop and Eclipse CDT. All have their own strengths, but I could use none of them well for KMix development. Then recently I did a new shot at Eclipse CDT (Kepler based), and I am actually delighted.

• The CMake integration now works flawless for me
• The C++ indexer is super-fast and reliable (a massive weakness in former versions)
• Navigation for header to source and back finally works and is very fast. Signals and Slots are parsed correctly and can be navigated.
• Call hierarchies work great most of the time. In some C++ specific constructs they do not work, but using "references" is a good alternative.
• Even the strangest #define and #include constructs work as expected.
• Warnings, Errors, TODO's and so forth are shown by default very appropriately in the editor and the other Eclipse Views. Very comfortable if one is accustomed to Eclipse.

KMix is a pretty small project, so mileage may vary for your project. Still I recommend to try "Eclipse Kepler CDT" if you have not done so recently. It brought back the fun in development for me.

Practical guideline for developing KDE applications with Eclipse

The basic step to build an Eclipse project is:

cd kmix-git-trunk.obj; cmake -G"Eclipse CDT4 - Unix Makefiles" ../kmix-git-trunk

As a reference, kmix-git-trunk.obj is where I build kmix, kmix-git-trunk is the GIT checkout. After that you can import the project into Eclipse. Run the above command again whenever required and refresh the whole source tree in Eclipse (F5) after that. Personally I am using Eclipse only to edit the source code, to navigate and browse quickly through sources, headers and includes. Everything else I am doing from a console window, like building, running, debugging and version control (GIT).

Thanks if you read until the end. If you have any input, experience or feedback, please leave a comment.

Christian

11 Dec 2013 12:39am GMT

Once more, I'm going to FOSDEM 2014, the largest Free/Libre/Open Source Software event in Europe (5,000 attendants every year).

As usual, I will be in charge of the Desktops DevRoom, together with our friends from Gnome (Christophe Fergeau), Unity (Didier Roche), Enlightenment (Philippe Caseiro) and others.

See you in Brussels 1-2 February 2014!

BTW, have you already submitted your talk proposal for the Desktops DevRoom? The deadline (15th December) is very close! Do not wait any more!!! See the details here: FOSDEM 2014 Desktops DevRoom Call for Talks

09 Dec 2013 10:06pm GMT

I just had the most curious encounter in a bar. Well, not entirely new - I've met my share of weirdo's over the years, but it has been a while. My problem seems to be that I'm too nice: I smile and nod at people that ramble and complain to me about life, the universe and everything like I enjoy their company. And what can I do? I LIKE being a nice person, it matters to me. Anyway, on to the story and its consequences.

Food in Nürnberg

Around 8 PM I went to the Bar & Grill California for dinner. Looking around for a place to sit, I smiled at a few folk looking back. As soon as I sat down, one of them came to me and asked if I didn't want to drink a beer with him and have a conversation. I didn't really know what to say, other than disappoint him partially by explaining I don't really drink beer. I would eat and drink something, however. He didn't mind and joined.

The conversation started curious: he shared that he had just kicked at the mirror of a police car and asked what I thought of that. I replied that, besides not liking violence in general, I saw little point in doing that. He pointed out that "cops are thieves, just like everybody else". "Well", I said, "some are, perhaps - rotten eggs can be found anywhere. But by an large, society needs a decent police force. And still, how does kicking a mirror help?". He explained that indeed, police is good, but "they have to be kept under control". Somehow, kicking mirrors helped with that, I didn't really get his argument here (if there was one). Besides, he didn't know what else to do: he had been mistreated by cops, he told me. He explained me he had pressed charges but it was "all covered up". Did he go to a lawyer? No, "they are all like puppies. Afraid of the police." I didn't really agree, but the conversation (or rather, he) became hard to follow.

What do you do for a living?

I decided to inquire into what he did for a job. After a few failed attempts he told me he was a doctor, or at least, learning to be one. Most physicians I know are rather less rambling so I inquired further. It turned out that, indeed, 'normal' physicians are actually trying to kill us. Murderers, he said. Especially psychiatrists. I tried to pursue the subject, instead the discussion turned to politics. He said it's bad in Germany. All politics is corrupted, as bad as in the US. I shared my conviction that while there are corrupt politicians for sure, at least in the Netherlands I'm convinced the vast majority of elected representatives honestly wants to do the right thing. He noted, surprisingly on-topic, that they just don't know what they're doing - something I can't disagree with entirely. After all, the world is a complicated place and honestly, most politicians seem under-educated especially in the area of science. I don't think this argument landed, however, he had turned back to the medical world.

He started talking about evil psychiatrists and mind control, and I decided to tell him I'm a psychologist. He moved a bit away from me, telling me he didn't trust psychologists. "They always blame you for everything!" he said. I answered: "Well, I do believe we are responsible for what we do in the world...". He shared that the medicine you're given is to keep you under control. Knowing the side effects of the medical treatments available to psychiatry (especially anti-psychotics) I couldn't really disagree that much. Meanwhile, he seemed to decide he could trust me, at least for now.

Berlin and the New World Order

He switched subjects again, asking where I came from and I told him I live in Berlin but I was Dutch. He was intrigued. "A while ago", he explained, "I met a very interesting guy. He lives in Berlin, but he is family of the Spanish King. Actually, he SHOULD BE the Spanish king, but..." I didn't really understand the reasons behind this, however, he suggested we (him and me?) should do something about this, put him back on his throne.

Before we could dive in details of this revolution, he moved closer to me, so nobody could hear: "Do you support the New World Order?" I told him I had heard the term but didn't know what it meant. He explained: "It will happen, like, 200 years from now. The human population will be reduced to about the size of Berlin". I asked what would happen to all the other people and he told me people would get injections with feminism (yeah, he really said that, I asked him to repeat it twice) and that would reduce the number of children we had. It had already started, that's why the population in Germany was getting smaller. I told him I thought it was scary and I would be against it. He noted he was a bit torn on the subject: on one hand, killing people is bad, but it would be good for the planet, the environment. Well, yes, it would, I suppose. When asked about how it had already started, he explained: "It is done by their leaders". Who? "Osama Bin Laden, others... Obamasama" (he made a bit of a word jumble there). I noted that Osama was dead but that didn't seem to be a problem: "He is the anti-christ!". We made a short detour to religion - he strongly believed in God, I couldn't figure out which one, although he didn't seem impressed with Allah and it wasn't Santa either. He did note that Jesus was a "servant of God, he was not crucified, they tried but you can't kill a servant of God".

At this point, I decided I really would prefer a quiet dinner, and told him that my food was coming and I'd like to eat that alone, but it was a nice conversation. He agreed, we shook hands - and he left. And I was proud of myself for having ended it in a friendly but firm manner... I am learning, too!

Psychotic? Oh yes.

I've had enough contact with people going through a psychotic episode that I can tell he is. The above 'report' is omitting at least half the rambling and hard to follow conversation (if you can call it that): conspiracy after conspiracy is thrown over the table, often clearly connected to things mentioned earlier. For example, the world population will be reduced to the size of Berlin, because - I just mentioned I live there. Once you notice it, it becomes hard to miss. There is logic - but often twisted and coming from certain (utterly insane) axioms. Overall, there's a lot of free association going on - I guess a psychosis would be awesome in a brain storming session. If you could only keep them on topic at least a little.

It is a REAL disease, harming those who have it

Unfortunately, a psychosis gets worse as these diseases are really damaging to the brain, essentially turning chronic if not treated. Compare it to a untreated wound - it isn't going to get any better if you let it fester. And I know that, while not very pleasant, there are decent medications and treatments out there that can really help. Unfortunately, I also know that as long as somebody is not a danger to him/herself or others, and sufficiently lucid to refuse any help (and the paranoia obviously doesn't help), there is little a doctor can do. Judges often simply lack the experience and knowledge to be willing to lock somebody up who doesn't do any harm and can still reasonably convincingly claim to be just fine. Despite believing Elvis is still alive, Aliens do anal probing and Jesus will walk again, soon. Worse, if they don't have friends or family pushing them to a doctor, chances are that they won't even be on the radar anywhere.

I've heard stories and cases like these recently, in Berlin but also in the Netherlands. And it often goes unnoticed. Most people just think him or her to be 'an odd duck' and there's often drugs involved which can be blamed. This good men was convinced beer helped him, taking his inhibitions away. Yes, it does, but I don't think that that is a good thing... At least, beer isn't as bad as the stuff some patients 'self-medicate' with. The thing is: this is a real disease. As real as cancer or a broken leg. It doesn't SEEM like that as you don't see it on the outside, but having your brain out of whack is seriously bad. Not only for them but, indeed, potentially for others too. After all, if you truly believe the police are the agents of the apocalypse and you get your hands on a guy, doesn't it make perfect sense to shoot a few? Exactly.

And then?

Our modern society seems to, on one hand, increase stress and pressure so more people suffer from these (and other) psychological disorders, yet the decaying social fabric means they get less and less social and medical support. And this is just the worst and most obvious side of it - what about all these people who quietly suffer from anxiety disorders, depression? Really, feeling like killing yourself is NOT healthy. There is something wrong and while indeed it can't be cured by a simple pill, there ARE things which can be done.

As society, we need to be more aware of these issues. Only thing I can do here is urge you to not leave people around you alone if they start to become paranoid and ramble like this: this is most likely caused by a real, tangible, curable medical condition, not an actual alien obduction, religious epiphany or government conspiracy. If a friend of you breaks a leg, you do visit them, help them, don't you? Do the same when they develop a psychosis, please...

09 Dec 2013 9:50pm GMT

Holy moly yet another KDevelop release - but this time a big one! Go and get 4.6.0 while it's fresh and read the full announcement on the KDevelop website:

http://kdevelop.org/46/kdevelop-460-final-released

09 Dec 2013 6:30pm GMT

We want to introduce an inline toggle button for the visibility of password fields. Please help us to define the optimal behavior.

When designing on the KNetworkManager, I kept stumbling over the 'show password' checkbox in the dialogue. The idea arose to move this directly into the input field using some inline toggle button. The whole thing would look something like the following:

Illustration 1: Mock up of the two states of the new password field.

Now there is the chance to introduce some magic and try to guess which state should be used initially. And we would like to get some feedback from you about the preferred way of using it, so, please participate in the following poll.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Of course you are happily invited to add your ideas and thoughts to the discussion!

09 Dec 2013 10:54am GMT

Opportunity ahead! Rex Dieter recently posted this link into the #kde channel: http://permalink.gmane.org/gmane.comp.video.kaffeine.devel/1255. Here we find that the Kaffeine maintainer Christoph Pfister has found it necessary to step back from maintaining Kaffeine. He says to be qualified if you should know a bit about Qt and KDE and preferably have some Dvb / Atsc equipment at hand.

This probably describes a lot of the folks reading this post. Do you have the time and desire to love and polish Kaffeine? Please join the Kaffeine-devel mail list and step forward. https://lists.sourceforge.net/lists/listinfo/kaffeine-devel

If you know of any other projects needing more love and care, please write the Community Working Group, Community-wg@kde.org. Another good list to connect to is the new general Community list: KDE-Community@kde.org.

Good cheer to all this holiday season!

09 Dec 2013 1:11am GMT