It’s release day today: This morning, ownCloud 4 was released! With a very cool set of features it’s even more useful and again more fun to use.

Along with that I am happy to let you know that we also released the ownCloud Desktop Client in version 1.0.2.

It is a maintenance release with a couple of important bugfixes, such as the cross platform filename encoding problem I was already talking about. Apart from that big blocker a couple of smaller, but annoying problems were fixed. Also the GUI was polished, text changes here and there and a new icon set that looks more cool and more like ownCloud.

Version 1.0.2 is also the version that is released on all big desktop platforms the first time. Now we also offer a dmg for MacOSX as well as a Windows Installer and packages for the major Linux distributions. Have fun!

If you want to talk about ownCloud, file synchronization or such, we have a booth on Linuxtag in Berlin and I will be there. I am looking forward to meeting you.

Apper has finally a new version!!

Last release is from February, not much changed in PackageKit since that time this is why you haven’t seen a new release, but this release doesn’t include last PackageKit feature (repair system). The focus I’ve put on this was fixing most of the important bugs we had in Apper, so it should be a rock solid release, it is surely not bug free as there is one bug that I won’t fix (I can’t reproduce nor have an idea how to fix, and the QML port will kill it).

The next release will include repair system, showing which packages are untrusted before installing them, and maybe some initial QML usage. Yes, I’m very excited with QML, it allows for a really cool flow especially for this kind of app, though we don’t have Desktop components yet, we can already do lots of cool stuff with it, but first I want to see Matthias work on Appstream and Software Center with openSUSE, that way we can have application data to browse without worry about the distribution!

What this new version includes:

• Automatic Refresh Cache properly fixed
• Initial Listaller support (optional)
• Supported filter added (depends on the backend)
• KDED plugin runs on a separate thread to avoid
  desktop freezes
• Fixed updating packages that were on untrusted repos
• Some man pages (thanks to ximion)
• Many other bug and Krazy fixes

Download (now from KDE ftp’s), mirrors might be still syncing: http://download.kde.org/stable/apper/0.7.2/src/apper-0.7.2.tar.bz2.mirrorlist

Enjoy

Every now and then I’m visting my best friend’s mom (generation > 50a) to update her old Pentium 4 system with the last opensuse software. Each time, I have to restore her Desktop to provide the basic features like managing opened windows, add the clock again, etc. Each time, I pay carefully attention to lock the screen afterwards. Sometimes I get doubts, that they are just fooling me, but my friend declined this, of course.

This time they disarranged the screen in a very extreme way1. Take it for amusement or for considering a clearer warning of unlocking the screen. I vote for:

You might end with a coruppted system!
Please copy this into the form field below:
I asked my son’s friend and got his permission.

;)

1. Did you recognize these empty plasma panels on each edge of the screen which prevents all application to get maximized properly?↩

Until now Plasma active had an on screen keyboard that served us well, but due to its implementation had some limits that couldn't be easily overcome.

However there is a Qt based virtual keyboard project that is very promising: Maliit

It's the one that was used in the Nokia N9, and already made a good progress since the version used there.

To have a good user experience on Plasma Active it should be well integrated, both as in look and behavior with the rest of the environment. Luckily Maliit is transitioning itself as well to the use of QML to write the user interface, making very easy to switch to a platform specific UI while all the logic stays untouched (I must say I'm quite impressed by this input method framework).

This is the result of just some hours of work towards a keyboard interface that uses Plasma UI components, and hopefully it will be in the next Plasma Active release.

OGG version

Speaking for myself and not for RIM

With RIM's serious push for Qt as part of the core frameworks and a more Open Source push for its ecosystem, it's the right time for me to jump in.

I Just started my initial porting of the Weather Forecast engine and applet to BlackBerry 10. It won't be Plasma based but pure Qt and Cascades UI with the kinds of effects that I really want to use.

I have to say it's pretty easy to get going. You go here: BlackBerry 10 Development

Download the Simulator VM image for the BB10DevAlpha device, get VMPlayer and the BlackBerry NDK+IDE. Qt and Cascades builds are already in the VM image.

Although we're using VMPlayer, It's ok but mouse cursor is sluggish for some reason. I'd rather we had used VirtualBox.

The only real irritant which I hope is fixed is the IDE Cascades QML previewer. It requires legacy Mesa, jpg/png libraries not found in Fedora (I use rawhide but Fedora isn't supported only Ubuntu) any more but I can workaround this issue in other ways (maybe Qt Creator for QML previewing).

Since QNX/BlackBerry 10 are POSIX, porting my code won't be much an issue. At most, I have to just re-implement some methods similar to what Plasma has in pure Qt but that won't be difficult.

I already have the plugin mechanism working. The fun part will be the Cascades UI framework to look at. It is similar to QtUi but different enough for mobile use, takes the pain of layouts out, extends QML usage and adds a rich set of functionalities that are common across the platform which I plan to take advantage of when those APIs are ready.

The embrace of Qt with QNX/BlackBerry 10 should be applauded and I hope more KDE and Qt developers look at the platform.

Porting parts of KDE to BB10 is possible but I don't know the logistics or restrictions that would be placed on it since we want a secure platform for people to trust. But I would certainly like to see KDE apps running on BB10!

Check out the Freenode IRC Channel #qt-qnx too.

Blog Tags: 

• News
• planetkde

Skrooge crashes on start with SQLite 3.7.12. The bug report is here.

Users

Your data is safe. It is not corrupted, and will be accessible again as soon as the bug is fixed. As a workaround, you can revert to SQLite 3.7.11

Developpers

I can't get in touch with Stéphane at the moment, and I don't have the skills to understand what causes the crash. Any help would be greatly appreciated ! You can read the backtrace here. I've contacted the SQLite team, of course, but didn't get an answer so far.

Edit : 

The SQLite devs have looked into it and a ticket is opened in their system too

CMake is a buildsystem generator developed in the open, and widely used for Qt based development. Especially when creating large or complex software, CMake can be more suitable to use than QMake. KDE was even the tipping point for the popularity of CMake in general, and with Qt 4 in particular, according to Bill Hoffman. KDAB engineers have contributed some features to CMake to ensure that the Qt 5 support for CMake is as good as possible.

KDAB contributed some new CMake Config files for Qt 5 to ensure that the integration between Qt and CMake can be even better. The updated documentation for using CMake with Qt 5 is has been reviewed and generated and repeats the relevant information in this blog post.

Finding Qt 5

One of the major changes when using CMake with Qt is the result of increased modularity in Qt itself. Whereas when finding Qt 4, with CMake you use

find_package(Qt4 COMPONENTS QTCORE QTGUI)

To find Qt 5 you can find all of the modules you wish to use with separate commands:

find_package(Qt5Widgets) find_package(Qt5Declarative)

There is likely to be a way in the future to specify the specific modules in one command, but this will not be available with Qt 5.0:

find_package(Qt5 COMPONENTS Widgets Declarative) Building Qt 5 projects with CMake

Once the package has been found, Qt 4 users would use the CMake variables ${QT_INCLUDES} to set the include directories while compiling, and ${QT_LIBRARIES} or ${QT_GUI_LIBRARIES} while linking. Users of CMake with Qt 4 may have also used the ${QT_USE_FILE} to semi-automatically include the required include directories and required defines.

With the modular Qt 5 system, the variables will instead be ${Qt5Widgets_INCLUDE_DIRS}, ${Qt5Widgets_LIBRARIES}, ${Qt5Declarative_INCLUDE_DIRS}, ${Qt5Declarative_LIBRARIES} etc for each module used.

This is a source-incompatibility in your CMake based buildsystem which will affect porting from Qt 4 to Qt 5. Luckily though, it is easy to add source compatibility back to the CMake variables and macros using some simple variable mappings.

Building executables with Qt 5 is slightly more complex than with Qt 4. One of the changes to how Qt 5 is built and packaged compared to Qt 4 is that the -reduce-relocations configure option became the default. The effect of this is that compilations are run with the -Bsymbolic-functions option, which makes function pointer comparison ineffective, unless the -fPIE flag is also supplied when building executables, or -fPIC when building libraries for position independent code.

If Qt is configured manually, it is of course possible to configure with -no-reduce-relocations and avoid the issue, but the default will be a requirement for all third parties to add compiler flags for position independent code. This can be done in the normal way with CMake:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}")

There is a Qt5&ltmodule>_EXECUTABLE_COMPILE_FLAGS variable for each module available in Qt 5 which expands to either -fPIE or the empty string, depending on how Qt was configured. Hoewever, the -fPIE flag is really only for executables and should not be used for libraries.

Setting -fPIC globally even when building executables may also work sufficiently, but shouldn’t be the first option.

set(CMAKE_CXX_FLAGS "-fPIC")

Together with some other newer features in CMake, such as automated moc invokation, a simple CMake based build system using Qt 5 which is roughly equivalent to a Qt 4 buildsystem will look something like this:

cmake_minimum_required(2.8.7) project(hello-world) # Tell CMake to run moc when necessary: set(CMAKE_AUTOMOC ON) # As moc files are generated in the binary dir, tell CMake # to always look for includes there: set(CMAKE_INCLUDE_CURRENT_DIR ON) # Widgets finds its own dependencies (QtGui and QtCore). find_package(Qt5Widgets REQUIRED) # The Qt5Widgets_INCLUDES also includes the include directories for # dependencies QtCore and QtGui include_directories(${Qt5Widgets_INCLUDES}) # We need add -DQT_WIDGETS_LIB when using QtWidgets in Qt 5. add_definitions(${Qt5Widgets_DEFINITIONS}) # Executables fail to build with Qt 5 in the default configuration # without -fPIE. We add that here. set(CMAKE_CXX_FLAGS "${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS}") add_executable(hello_world main.cpp mainwindow.cpp) # The Qt5Widgets_LIBRARIES variable also includes QtGui and QtCore target_link_libraries(hello_world ${Qt5Widgets_LIBRARIES})

You can see though that there is a lot of repetition in the snippet, and a lot of things to take care of using.

The Qt5Widgets_EXECUTABLE_COMPILE_FLAGS use is particularly forgettable, and even difficult to get right – it should not be used if building shared libraries for example, so it requires some maintenance if that is required within the same scope as building an executable.

There is even a subtle bug which people who have unit tested their Qt 4 core-only code will know. If the -DQT_GUI_LIB definition is set (which happens if using QT_USE_FILE for example), all unit tests need to link to QtGui, even though it is not used by the tests.

That is because of some magic in the header files of QtTest. The workaround is either careful scoping of targets and directories, or tricky manual manipulation of the definitions or variables controlling how Qt 4 is found.

Towards more modern CMake usage

Starting with CMake 2.8.8, we can do a lot better:

cmake_minimum_required(2.8.8) project(hello-world) # Tell CMake to run moc when necessary: set(CMAKE_AUTOMOC ON) # As moc files are generated in the binary dir, tell CMake # to always look for includes there: set(CMAKE_INCLUDE_CURRENT_DIR ON) # Widgets finds its own dependencies. find_package(Qt5Widgets REQUIRED) add_executable(hello_world main.cpp mainwindow.cpp) qt5_use_modules(hello_world Widgets)

The qt5_use_modules CMake function encapsulates all of the set-up required to use a Qt module. It can be used with multiple arguments at once for brevity, such as:

qt5_use_modules(hello_world Widgets Declarative)

This is similar to how qmake operates:

TARGET = hello_world QT += widgets declarative

All properties are scoped to the particular target the function is used with, instead of being scoped to the CMakeLists.txt file it appears in, and affecting all libraries and executables.

For example in this snippet:

add_executable(hello_world main.cpp mainwindow.cpp) add_library(hello_library lib.cpp) add_executable(hello_coretest test.cpp) find_package(Qt5Widgets) qt5_use_package(hello_world Widgets) qt5_use_package(hello_library Core) qt5_use_package(hello_coretest Test)

Because all of the settings are scoped to the target (executable or library) they operate on, the -fPIE doesn’t get used when building the hello_library library, and the -DQT_GUI_LIB doesn’t get used when building hello_coretest.

It’s a much cleaner way to write CMake based build systems.

Looking forward, we expect a similar but more powerful feature to be possible in upstream CMake too, so that you can expect to be able to use a similar function with any CMake package.

Implementation details

One of the features of CMake that many developers who used it will be familiar with is Find files. The idea is to write a Find file for each dependency your project depends on, or use an existing Find file provided elsewhere. CMake provides a large set of Find files already, and KDE is preparing to make the Find files developed through the years available to all users of CMake.

One of the Find files provided by CMake is the FindQt4.cmake file. This file is responsible for finding Qt on your system so that you can invoke:

find_package(Qt4)

That Find file makes available the variables ${QT_INCLUDES} to set the location of header files, and ${QT_QTGUI_LIBRARIES} for linking, for example.

One of the disadvantages of this file being part of CMake, and not part of Qt, is that the file could get out-of-date. For example, when Qt 4.6 was released in December 2009 it included a new QtMultimedia module. Support for that module was not complete until CMake 2.8.2, released in June 2010.

That means that if someone wanted to use QtMultimedia, they could either have to wait for and then depend on the new CMake release, or attempt to copy the Find file into their project to work with their existing CMake version. The copying may not even work if the updated Find file uses features of the newer CMake.

Behind the scenes, Qt 5 is now found in a slightly different way too. Apart from making it possible to find your dependencies using a Find file, CMake is also able to read files provided by the dependency itself to locate the libraries and header files. Such files are called Config files, and usually they are generated by CMake itself.

A Qt 5 build, will also generate the CMake Config files, but without causing Qt 5 to depend on CMake itself.

The primary benefit of this is that the features of Qt (and the modules of Qt) which can be used with CMake do not depend on the version of CMake being used. All Qt Essentials Modules and Qt Addons Modules will create their own CMake Config file, and the features provided by the modules will be made available through the CMake macros and variables immediately.

As new modules become available, they will also be usable with CMake as soon as they are checked into a repository, so experimenting or prototyping can begin immediately and does not have to wait for a new CMake release.

Another benefit of using Config files instead of find files is that the config files have access to all aspects of the build of Qt itself including how it was configured and where it is installed to, which helps keep complexity under control when supporting static builds, and cross compiling for example.

QStringLiteral is a new macros introduced in Qt 5 to create QString from string literals. (String literals are a string within "" included in the source code). In this blog post, I explain its inner working and implementation.

Summary

Let me start by giving a guideline on when to use it: If you want to initialize a QString from a string literal in Qt5, you should use:

• Most of the cases: QStringLiteral("foo") if it will actually be converted to QString
• QLatin1String("foo") if it is use with a function that has an overload for QLatin1String. (such as operator==, operator+, startWith, replace, ...)

I have put this summary at the beginning for the ones that don't want to read the technical details that follows.

Read on to understand how QStringLiteral works

Reminder on how QString works

QString, as many classes in Qt, is an implicitly shared class. Its only member is a pointer to the 'private' data. The QStringData is allocated with malloc, and enough room is allocated after it to put the actual string data in the same memory block.

// Simplified for the purpose of this blog struct QStringData { QtPrivate::RefCount ref; // wrapper around a QAtomicInt int size; // size of the string uint alloc : 31; // amount of memory reserved after this string data uint capacityReserved : 1; // internal detail used for reserve() qptrdiff offset; // offset to the data (usually sizeof(QSringData)) inline ushort *data() { return reinterpret_cast<ushort *>(reinterpret_cast<char *>(this) + offset); } }; // ... class QString { QStringData *d; public: // ... public API ... };

The offset is a pointer to the data relative to the QStringData. In Qt4, it used to be an actual pointer. We'll see why it has been changed.

The actual data in the string is stored in UTF-16, which uses 2 bytes per character.

Literals and Conversion

Strings literals are the strings that appears directly in the source code, between quotes.
Here are some examples. (suppose action, string, and filename are QString

o->setObjectName("MyObject"); if (action == "rename") string.replace("%FileName%", filename);

In the first line, we call the function QObject::setObjectName(const QString&). There is an implicit conversion from const char* to QString, via its constructor. A new QStringData is allocated with enough room to hold "MyObject", and then the string is copied and converted from UTF-8 to UTF-16.

The same happens in the last line where the function QString::replace(const QString &, const QString &) is called. A new QStringData is allocated for "%FileName%".

Is there a way to prevent the allocation of QStringData and copy of the string?

Yes, one solution to avoid the costly creation of a temporary QString object is to have overload for common function that takes const char* parameter.
So we have those overloads for operator==

bool operator==(const QString &, const QString &); bool operator==(const QString &, const char *); bool operator==(const char *, const QString &)

The overloads do not need to create a new QString object for our literal and can operate directly on the raw char*.

Encoding and QLatin1String

In Qt5, we changed the default decoding for the char* strings to UTF-8. But many algorithms are much slower with UTF-8 than with plain ASCII or latin1

Hence you can use QLatin1String, which is just a thin wrapper around char * that specify the encoding. There are overloads taking QLatin1String for functions that can opperate or the raw latin1 data directly without conversion.

So our first example now looks like:

o->setObjectName(QLatin1String("MyObject")); if (action == QLatin1String("rename")) string.replace(QLatin1String("%FileName%"), filename);

The good news is that QString::replace and operator== have overloads for QLatin1String. So that is much faster now.

In the call to setObjectName, we avoided the conversion from UTF-8, but we still have an (implicit) conversion from QLatin1String to QString which has to allocate the QStringData on the heap.

Introducing QStringLiteral

Is it possible to avoid the allocation and copy of the string literal even for the cases like setObjectName? Yes, that is what QStringLiteral is doing.

This macro will try to generate the QStringData at compile time with all the field initialized. It will even be located in the .rodata section, so it can be shared between processes.

We need two languages feature to do that:

1. The possibility to generate UTF-16 at compile time:
   On Windows we can use the wide char L"String". On Unix we are using the new C++11 Unicode literal: u"String". (Supported by GCC 4.4 and clang.)
2. The ability to create static data from expressions.
   We want to be able to put QStringLiteral everywhere in the code. One way to do that is to put a static QStringData inside a C++11 lambda expression. (Supported by MSVC 2010 and GCC 4.5) (And we also make use of the GCC __extension__ ({ }) )

Implementation

We will need need a POD structure that contains both the QStringData and the actual string. Its structure will depend on the way we use to generate UTF-16.

/* We define QT_UNICODE_LITERAL_II and declare the qunicodechar depending on the compiler */ #if defined(Q_COMPILER_UNICODE_STRINGS) // C++11 unicode string #define QT_UNICODE_LITERAL_II(str) u"" str typedef char16_t qunicodechar; #elif __SIZEOF_WCHAR_T__ == 2 // wchar_t is 2 bytes (condition a bit simplified) #define QT_UNICODE_LITERAL_II(str) L##str typedef wchar_t qunicodechar; #else typedef ushort qunicodechar; // fallback #endif // The structure that will contain the string. // N is the string size template <int N> struct QStaticStringData { QStringData str; qunicodechar data[N + 1]; }; // Helper class wrapping a pointer that we can pass to the QString constructor struct QStringDataPtr { QStringData *ptr; }; #if defined(QT_UNICODE_LITERAL_II) // QT_UNICODE_LITERAL needed because of macro expension rules # define QT_UNICODE_LITERAL(str) QT_UNICODE_LITERAL_II(str) # if defined(Q_COMPILER_LAMBDA) # define QStringLiteral(str) \ ([]() -> QString { \ enum { Size = sizeof(QT_UNICODE_LITERAL(str))/2 - 1 }; \ static const QStaticStringData<Size> qstring_literal = { \ Q_STATIC_STRING_DATA_HEADER_INITIALIZER(Size), \ QT_UNICODE_LITERAL(str) }; \ QStringDataPtr holder = { &qstring_literal.str }; \ const QString s(holder); \ return s; \ }()) \ # elif defined(Q_CC_GNU) // Use GCC To __extension__ ({ }) trick instead of lambda // ... <skiped> ... # endif #endif #ifndef QStringLiteral // no lambdas, not GCC, or GCC in C++98 mode with 4-byte wchar_t // fallback, return a temporary QString // source code is assumed to be encoded in UTF-8 # define QStringLiteral(str) QString::fromUtf8(str, sizeof(str) - 1) #endif

Let us simplify a bit this macro and look how the macro would expand

o->setObjectName(QStringLiteral("MyObject")); // would expand to: o->setObjectName(([]() { // We are in a lambda expression that returns a QStaticString // Compute the size using sizeof, (minus the null terminator) enum { Size = sizeof(u"MyObject")/2 - 1 }; // Initialize. (This is static data initialized at compile time.) static const QStaticStringData<Size> qstring_literal = { { /* ref = */ -1, /* size = */ Size, /* alloc = */ 0, /* capacityReserved = */ 0, /* offset = */ sizeof(QStringData) }, u"MyObject" }; QStringDataPtr holder = { &qstring_literal.str }; QString s(holder); // call the QString(QStringDataPtr&) constructor return s; }()) // Call the lambda );

The reference count is initialized to -1. A negative value is never incremented or decremented because we are in read only data.

One can see why it is so important to have an offset (qptrdiff) rather than a pointer to the string (ushort*) as it was in Qt4. It is indeed impossible to put pointer in the read only section because pointers might need to be relocated at load time. That means that each time an application or library, the OS needs to re-write all the pointers addresses using the relocation table.

Results

For fun, we can look at the assembly generated for a very simple call to QStringLiteral. We can see that there is almost no code, and how the data is laid out in the .rodata section

We notice the overhead in the binary. The string takes twice as much memory since it is encoded in UTF-16, and there is also a header of sizeof(QStringData) = 24. This memory overhead is the reason why it still makes sense to still use QLatin1String when the function you are calling has an overload for it.

QString returnAString() { return QStringLiteral("Hello"); }

Compiled with g++ -O2 -S -std=c++0x (GCC 4.7) on x86_64

.text .globl _Z13returnAStringv .type _Z13returnAStringv, @function _Z13returnAStringv: ; load the address of the QStringData into %rdx leaq _ZZZ13returnAStringvENKUlvE_clEvE15qstring_literal(%rip), %rdx movq %rdi, %rax ; copy the QStringData from %rdx to the QString return object ; allocated by the caller. (the QString constructor has been inlined) movq %rdx, (%rdi) ret .size _Z13returnAStringv, .-_Z13returnAStringv .section .rodata .align 32 .type _ZZZ13returnAStringvENKUlvE_clEvE15qstring_literal, @object .size _ZZZ13returnAStringvENKUlvE_clEvE15qstring_literal, 40 _ZZZ13returnAStringvENKUlvE_clEvE15qstring_literal: .long -1 ; ref .long 5 ; size .long 0 ; alloc + capacityReserved .zero 4 ; padding .quad 24 ; offset .string "H" ; the data. Each .string add a terminal '\0' .string "e" .string "l" .string "l" .string "o" .string "" .string "" .zero 4 Conclusion

I hope that now that you have read this you will have a better understanding on where to use and not to use QStringLiteral.
There is another macro QByteArrayLiteral, which work exactly on the same principle but creates a QByteArray.

Soft proofing is a technique which allows you to see what the photo will look like when printed using a specific printer and photo media (paper, canvas, etc.) without actually printing the photo. Many professional photo processing applications support soft proofing, and digiKam is no exception.

To make this feature work in digiKam, you need to specify color profiles for your display and the output device (e.g., printer). But before you do that, you need to obtain the ICC color profile for your specific printer and print media.

Continue to read

read more

I'm pleased to announce the new available EBook-Manager calibre package 0.8.52 for Balsam Professional / openSUSE.

Whats happend since the last Minorupdate? New Features

• EPUB Input: When setting the cover for a book that identifies its cover image, but not the html wrapper around the cover, try to detect and remove that wrapper automatically.
• When deleting books of a specific format, show the number of books with each format available
• Linux install: No longer create MAN pages as all utilities have more comprehensive command line --help anyway
• Add a tweak Preferences->Tweaks to control the default choice of format for the Tweak Book feature
• Conversion: Allow setting negative page margins. A negative page margin means that calibre will not specify any page margin in the output document (for formats that support this)

Bug Fixes

• Tweak book: Fix handling of covers when tweaking KF8 books
• KF8 Output: Handle input documents with out of sequence ToC entries. Note that currently section jumping in the KF8 output produced by calibre for such files does not work.
• Edit metadata dialog: Fix the edit values button for custom tag-like columns showing a unneeded warning about changed values
• EPUB Output: Be a little more conservative when removing  tags. Only remove them if they have actual forms inside.
• EPUB Input: Correctly update the Cover entry in the ToC even when the entry has a fragment reference.
• Update ImagMagick DLLs in all calibre binary builds to fix security vulnerabilities in ImageMagick
• Advanced search dialog: Fix equals and regex matching not being applied for custom column searches.
• RTF Input: Handle old RTF files that have commands without braces.
• Get Books: Diesel, fix results not showing when only a single match is found
• Get Books: Fix DRM status indicators for Kobo and Diesel stores. Fix smashwords not returning results.
• Fix regression in 0.8.51 that broke viewing of LIT and some EPUB files

Where to get Calibre?

You just can add the Documentation:Tools Repository and install it via YaST or zypper. You also can use one of the following 1-Click Installer:

This one for the openSUSE 12.1 Documentation:Tools (12.1 Standard)

 

This one for the openSUSE 12.1 Documentation:Tools (12.1 KDE 4.8)

 

You wish to donate anything to the Packager?

Sounds good. Just read Donate a Coffee. 

You want to try out calibre with faenza Toolbaricons?

Have a look there (German Article). If you don't know german, just add the Documentation:Tools Repository and install "calibre-faenza-icons".

A couple of weeks ago was the first anniversary of orphaning Qt3 in Debian, see bug 625502.

In this year, Qt3 has got a few QA uploads with the most relevant change being support to multiarch. And, more importantly, nobody seemed to care enough to step into maintaining it.

In the last days, I have taken a look into how much needed to be done to remove Qt3 and there were slightly more than 50 packages depending directly or indirectly from Qt3. A removal from Wheezy seemed doable given that removing packages is never a problem during the Debian freeze ;-)
All the packages affected have a bug opened since more than one year and half ago and I have pinged all the bugs with some maintainers responding quick (thanks!). I also filed some removals for packages that were clearly unmaintained and didn’t seem worth keeping, with ftp-masters responding quick too (Thanks!). And finally, a couple of QA upload for orphaned software that were still useful without Qt3.

There is a wiki page tracking the status of the removal if you are curious:
http://wiki.debian.org/qt3-x11-freeRemoval

If in the future, you are reading this and you need Qt3 in Wheezy, you can fetch it from Debian snapshots.

So, Blaine Bublitz of IcedDev volunteered us to give a talk at next month’s Phoenix Mobile Technology Group meetup on the EnyoJS web application framework.

I’ve been doing EnyoJS for about a year now, having dabbled in it when I first got my HP Touchpad (which ran Enyo1 as its primary toolkit). I wrote a lock system for our hackerspace’s 23b access system and some other random things not worth sharing and have been playing with Enyo2 since it was open sourced earlier this year.

Of course, it was only natural to design our presentation in EnyoJS.

And of course, we wanted to make it extensible so that anyone else could make a presentation using it as well. We started hacking on it for a while, then we started daydreaming – Enyo as a toolkit is robust enough to allow you to design beautiful, fluid interfaces but light enough to let you do some really incredibly cool things.

It's just a button, but it's so much more.

Like creating slides that contain full, interactive user interfaces.

Or a slide with a text area that creates a user interface live and lets you interact with it right there.

Or using WebSockets to sync where in the presentation a presenter is with an arbitrary number of viewers.

Or using WebSockets to have a chat room for each presentation where viewers can ask questions and leave comments right on the presentation.

Simple things like that. And we’re planning on building most of that by next month. That’s only possible because Enyo has a great community behind it constantly developing cool new toys and addons for it, so there’s a ton of things that we can do already, and a lot more being written daily. And when you’re all ready to launch, you can take a single source repo and deploy it to a webserver, or a webOS device, or wrap it in PhoneGap and deploy it to Android, or iOS. It’s a pretty powerful toolkit. For me, it’s much like Qt, but using web technologies instead of native technologies: Code once, compile and deploy anywhere.

If you want to learn about a really awesome mobile and web toolkit, come by UAT at 19:00 on June 21 and see us stretch it to its limits. Blaine and I will be working on getting our presentation ready on our respective github project forks so keep an eye on it. There’s already some pretty nice stuff there, even if it’s a little bit raw. I’m really excited about this project, and there’s a lot of cool things we could do with it.

Due to a rather small config error, we lost the network connection to dot, forum, userbase, techbase, community and blogs.kde.org. We hope the hoster can help us to get them up again soon. Sorry for the inconvenience.

Recently, when building qt5, I'd started noticing some very strange errors from the configure script. The errors seemed to indicate that an awk script was being used as a filename - very strange. Even stranger was that other people weren't hitting this issue - just me. Never a good sign. Today, I finally got around to debugging it and the issue was rather weird.

My initial thought was that my version of bash was incompatible with the script in some way, so I copied the code for the function that was erroring and made a standalone version - it worked fine. I then tried to run the configure script using sh -x to watch it was doing, but unfortunately that seemed to confuse the script. Finally, I started to read the code. The relevant function reads:

$awk ' BEGIN { lots of awk } '

Finally, I spotted that $awk was not being set. If you look at the script then you can see that the qt5 configure looks for gawk, nawk then finally awk. So, the obvious step was to see if I had a version of awk installed. Using 'which' told me I didn't have one, but using rpm -q told me I did - curiouser and curiouser.

I checked what the gawk package installed and I could see that at least part of it was there, but running it gave an IO error - very weird. In fact, I could see that I was running a symlink that pointed to a file that wasn't there. At this point, I assumed a bad update of some kind, so I ran:

zypper install gawk

It said my gawk was the lastest. I then tried

zypper install -f gawk

to force the install and it gave an IO error. Spot the pattern? Every
time I try to do stuff to the gawk binary I get an IO error. At this point, I looked at /var/log/messages and saw a lot of messages like this:

May 19 18:51:06 linux-h33o kernel: [ 58.719815] EXT4-fs error (device sda6): ext4_ext_check_inode:403: inode #393297: comm rpm: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

Not good.

This seemed like some kind of file system corruption, so I backed up my files immediately before I carried on investigating. Running fsck from a rescue system showed a few errors, but nothing major, and all were fixable. After allowing the repair I rebooted, sure in the knowledge that the problem was solved.

All I needed to do was reinstall the corrupted gawk package:

linux-h33o:/home/rich/src # zypper install -f gawk Loading repository data... Reading installed packages... Forcing installation of 'gawk-4.0.0-3.1.2.x86_64' from repository 'openSUSE-12.1-Oss'. Resolving package dependencies... The following package is going to be reinstalled: gawk 1 package to reinstall. Overall download size: 820.0 KiB. No additional space will be used or freed after the operation. Continue? [y/n/?] (y): Installing: gawk-4.0.0-3.1.2 [error] Installation of gawk-4.0.0-3.1.2 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /bin/gawk: cpio: rename failed - Input/output error error: gawk-4.0.0-3.1.2.x86_64: install failed

Oh dear. It's not good when fsck says the file system is ok, but the driver disagrees.

At this point, I started doing some serious googling to figure out wtf was going on. Happily, I came across the following bug report that let me resolve the issue https://bugzilla.kernel.org/show_bug.cgi?id=32182 . By following the debugfs steps described, I was able to kill the bad inode. Thank fully this fixed my file system.

So what can we learn from this? Obviously, we can learn that the configure script wasn't the source of the problem, but simply the way it manifested. It also shows that the configure script has a bug in that it doesn't report when awk is missing. We can also learn that a bit of googling can solve a lot of problems.

A final point to note if anyone is considering doing evil things with debugfs like this is that as soon as I figured out I had a corrupt file system I made a backup. This gives you a nice warm glow inside as you know you can attempt things that would otherwise be insanely risky.

After the KDE SC 4.9 is released, projects inside KDE Projects: Activities will start requiring more up-to-date compilers and will start (ab)using more modern C++.

For the library, the requirement will be GCC 4.6, clang 3.0 or whatever version of MSVC++ has the equivalent features. GCC 4.6 is chosen since it will be a dependency of Qt 5, so eventually the rest of KDElibs/KDE Frameworks will foolow suit.

Since GCC is the main targeted compiler, the library will be regularly tested against 4.6. For Clang, I’ll test with the latest version provided by Debian (currently 3.0).

With that said, I don’t expect that the library will really be uncompilable with older compilers, it is just that I have no intention keeping the compatibility and testing for it.

Service

For the service, the requirement will be more obvious – compilation will likely fail on older compilers. I’m currently pondering whether to require GCC 4.6 or 4.7. The later has some rather nice additions from C++11 standard (that are present in Clang 3.0) like Non-static data member initializers (N2756), Template aliases (N2258), Delegating constructors (N1986), Explicit virtual overrides (N2928, N3206, N3272).

I guess I’ll start of with 4.6 and see whether it is enough and whether I can live without a few adorable N****s

Edit: Regarding kde-core-devel – I will start this discussion on k-c-d once 4.9 is out of the door. The point of this post is to test the public responses. Don’t want to bother everybody on k-c-d for something that is not intended for this release.

Some time ago I wrote about the possibility to make activities private, that is, to encrypt the files that relate to it. And, I wrote it will be available in KDE SC 4.9

In short, it will not. You’ll need to wait, or risk your data.

Status

Essentially, the encryption works. There are also some neat features like if your screensaver is started, the current activity (if marked as private) gets automatically locked. Only one activity is unlocked at a time – it is automatically locked when you switch to another activity. The files/documents you link to a private activity are automatically moved into the encrypted filesystem and removed from the original location. And so on…

So, what doesn’t work?

There’s no UI to set the activity as private (at least, not in the Plasma Desktop). And this is intentional. Security is not something that I take for granted. Anything related to privacy needs to be tested by us before we push it into the hands of ordinary users.

This means that the implementation is there, and is present in 4.9, but it is not available to you if you don’t plan to experiment and get your hands dirty.

What are the known issues?

The files on the encrypted partition are (without custom patches to kdelibs and co.) not treated any special by Nepomuk. This means that either (1) the files will be indexed as if they were public, (2) the will not be visible to nepomuk at all (which would render the /link to activity/ useless) or (3) the files will be in nepomuk without any sensitive data and without the possibility to be reindexed. This is not something that I’m satisfied with, and I’m considering it a big release blocker.

I want to try it anyway!

If you are sure that you want to use this feature now, and want to avoid the issues mentioned above, you can do the following:

# get the uuid of the current activity: qdbus org.kde.ActivityManager /ActivityManager \ CurrentActivity # use that result in the following line: qdbus org.kde.ActivityManager /ActivityManager \ SetActivityEncrypted UUID-of-the-activity 1

You’ll be asked for the password to use for the encryption.

When this is done, the FUSE encfs system will be set up and you’ll be able to use it. But do use it directly – save files in the encrypted folder manually, delete them manually and so on. Do not /link files to a private activity/ don’t mark as private an activity that already has some files linked to it.

If you follow the above, you will not experience any nepomuk indexing related issues, while being able to keep sensitive data encrypted.

Edit:

KIO

Previously mentioned KIO slave is able to browse the private activities, so you have no need to know where the activity manager mounts the encrypted filesystem.

There is one feature whose implementation got dragged out for quite a while now, and gets requested with each new release of the KDE Workspace – being able to tell an application always to be shown on all activities, or on a specific one.

The reason for this taking so long is that KWin <-> Activities relationship started in the era when I did the activity manager related things (aka /the under the hood stuff/) while Chani connected them to Plassma and KWin. She is not working on KDE anymore, so these areas got a bit forgotten.

Now, the feature will be finally available in KDE SC 4.9.

This is the first in what is going to be a series of blogs about UserBase and what it can be to your favourite project. UserBase is a community wiki aiming to provide useful information to users of KDE software. We have pages about individual applications, introductions to various aspects of the desktop, guides to solving tricky hardware problems, and even entire handbooks. And all this content is being translated into many languages.

The first showcase: digiKam

A picture speaks louder that a thousand words, they say. The author of the digiKam page has taken those words to heart, and presents the application in a thematically ordered series of screenshots.

Part of digiKams UserBase page. The Brazilian translation is shown.

Sometimes, however, words are needed to explain things in detail. Fortunately a number of bloggers have provided a wealth of information and allowed us to add all this content to UserBase. As a consequence these excellent texts are now being translated into many languages.

Part of a tutorial (from Mohamed Maliks blog). The Ukrainian translation is shown.

The take home lesson is, you don’t have to write a lot of new material in order to show your users some love. Just point us to relevant material, and we will add it to UserBase, format it appropriately, perhaps add a screenshot, and mark it up for translation. Then wait, and before you know it translations will begin to appear.

As we all know, Qt5 is approaching. The “big new thing” with Qt5 is the introduction of QtQuick/QML for writing dynamic user interfaces. If you are (somehow ) unfamiliar with QtQuick and QML, you can read up about it here. The rest of this post assumes that you know something about Qt Quick.

Qt5 is imminent, with a release set for sometime within the next few months. But as of currently, there seems to be several questions that remain in regards to QML. I have encountered several questions, some directed at me, such as “Why would a desktop application want to use QML?”, “How will traditional desktop applications be able to use QML?”, “How will QML applications integrate with KDE and its existing applications?”, and, more specifically, “How will Muon Discover integrate with KDE since it is using QML?”. In this post I will attempt to answer these questions, with my opinions and thoughts on the matters.

Why would a desktop application want to use QML?

Traditionally, user interfaces for applications have been written to be composed of discreet “forms” or “pages”,  with each form containing a (mostly) static collection of controls called “widgets”. To present new forms to the user, an application would either present the new form as a separate window/dialog, or replace the form in the main window with a new one entirely, using a widget stack to contain the forms.  These interfaces were coded either in straight C++ (or with language bindings), or by compiling XML files created with a WYSIWIG-esque interface designer. A common set of widgets is shared among applications of a particular toolkit. (Be it Qt or Gtk, etc) This, along with theming, allows for very tight graphical consistency between applications written in the same toolkit.

Now, there is nothing particularly “wrong” with the way things currently work, but that does not mean things couldn’t be better. Animations are a useful tool with regards to usability. Aside from looking slick, user interfaces that morph gradually are easier for the human mind to “track”, as opposed to instantaneous change. But until the advent of QML, providing animations (and fluid interfaces in general) with the traditional static widget-driven user interface, you had to roll your own. Qt did provide several APIs within the last few releases to provide animations/effects within QWidget-based interfaces, but even then doing animations and graphical effects was not exactly trivial to “get right”. And even when using these APIs, the effects’ drawing performance is tied to the painting backend in use with Qt, which can be slow (e.g. the old X11 Qt painting plugin), or at the very least can’t take advantage of the dedicated graphics hardware of the modern computer.

In short, QML makes it very easy to write fluid user interfaces, while retaining speed. The advantages expand well beyond the mobile application sphere, and represent a new way to do GUIs.(tm) [/marketing mode]

How would a desktop application use QML?

But what, specifically, would you use QML for within a desktop application? Aside from generally animating the interface, how would QML be used to provide advantages of the current QWidget paradigm?

For one, it makes it much easier to present non-control media such as pictures in an appealing fashion. Take for example, the slideshow for featured items in the home page of Muon Discover. It is written in a mere 126 lines of QML, and provides navigation between featured items, animated item switching, fading in new items, and it automatically pans around screenshots that are too big to fit in the banner. Doing the equivalent with QWidgets or even QGraphicsItem and friends would be a lot more involved, requiring lots of custom painting an animation code, with potentially worse performance.

Aside from the presentation of things that are strictly media (though to be fair, clicking on the aforementioned slideshow will take you to the app’s page), QML can also aide in the creation of user controls that themselves can incorporate media and animations.

Take delegates for list views as an example. If you want to go beyond the simple icon-and-text that the default Qt list view delegate offers, you must subclass your own delegate and re-implement the paint function. Re-implementing the paint function requires you to do a lot of pixel math with a lot of code that, frankly, I never mastered. Whenever I’ve needed a custom delegate, such as for the Muon Software Center and Muon Package Manager, I’ve resorted to searching lxr.kde.org for delegate subclasses, searching for a delegate that kind of does what I want, and tweaking that until I get something useful. At the end of the day, even creating a delegate that paints an icon, two lines of text, and a rating widget takes around 300 lines of code. You get a whole lot of control, at the expense of a whole lot of hassle.

300 lines of code for this itemview delegate

With QML, a similar listview delegate takes only a bit more than 100 lines of QML, without forcing the UI designer to do tons of pixel-based positional calculations within the QML script. With it being so easy to make itemview delegates in QML, Aleix was even able to create a second “icon grid view” delegate that incorporates animation within the delegate to show different information when moused over, as seen in his video here.

On the issue of integration and consistency

One of the strengths of KDE is how well its applications fit together. Most every applications share exactly the same set of controls. (Buttons, list views, line edits, scroll bars, etc, etc) Similarly, these common controls all follow a common theme. The combination of these two provide a consistent experience common to all KDE applications, which makes it easier for somebody new to KDE to pick it up. If you learn how a combobox or list view works in one application, generally, you’ve learned how they work in all KDE/Qt applications.

This level of integration is not yet available in QML, which is why we’re holding off from replacing the Muon Software Center with Muon Discover until things change. As of now, Qt does not offer a set of common components like we see with the current set of QWidgets. There is the set of common QML Elements that provide a rudimentary set of common components, but it’s nothing as extensive as what we have currently. If you need a UI control in QML, currently you must roll your own. Doing this results in un-integrated controls reimplemented by each application that potentially do not share a common theme. Muon Discover is currently using Plasma’s QML components, which while providing graphical and widget-level integration with Plasma and making Muon Discover fit in on a Plasma Active system, does not provide integration with most of the other QWidget applications on “the desktop”.

The solution to this does appear to be coming, however, in the form of the Qt Desktop Components for QML. The QML Desktop Components provide a set of UI controls analagous to the ones available with QWidgets. Additionally, they use QWidget theming, allowing graphical integration as well as behavioral integration with QWidgets. You can see them in action in KAlgebra Mobile here. Through the use of desktop components, we can make applications that utilize all the benefits of QML while retaining integration with the rest of the desktop. The only caveat is that the desktop components haven’t actually been released yet. Previews can be found at their Gitorious site, and we even have a git branch for Muon Discover that (partially) uses the desktop components. I’ve not heard a concrete release date for the QML desktop components, but seems like they will be The True Way Forward ™ for QML on the desktop.

Conclusion

I feel very strongly about consistency, so to re-iterate Muon Discover will not displace the Muon Software Center until we have a way to integrate with the rest of KDE. QML does, however, provide a very powerful way to create attractive, easy-to-use interfaces without too much effort. While we wait for a solution for the desktop to become available, we can continue to hack on Muon Discover and allow it to mature. And hey, it already integrates well with Plasma via the use of the Plasma QML components, so perhaps in the nearish future (with a bit of work to make Muon Discover touch-suitable) you could find Muon Discover on a Kubuntu Active spin near you.

Ah, love the smell of multiplicative groups in the morning. While digging into what makes the SMP tick I created a copy that is nowhere near as subscript heavy. Both wikipedia and the OTR page use the same subscripty maths. It is all the same of course, but I tend to delegate subscripts to conceptual sequences rather than being used for two "random values chosen by party alice".
Alice:

1. Picks random exponents a, b, and s
2. Sends Bob ga and gb
   
   Bob:
   

1. Picks random exponents c, d, and r
2. Computes j = gca and k = gbd
3. Computes M = kr and N = gr jy
4. Sends Alice gc, gd , M and N
   
   Alice:
   

1. Computes j = gac and k = gbd
2. Computes P = ks and Q = gs jx
3. Computes R = (Q / N) b
4. Sends Bob P, Q and R
   
   Bob:
   

1. Computes T = (Q / N) d
2. Computes Z = Rd
3. Checks whether Z == (P / M)
4. Sends Alice T
   
   Alice:
   

1. Computes Z = Tb
2. Checks whether Z == (P / M)
   

For bob’s check:Rd                 = P / M(Q/N)db         = ks / kr(gsjx / grjy)db = gbds / gbdrg(s-r)dbg(x-y)db  = g(s-r)dbIf x-y = 0 then the second term on the left side is forced to become 1. From an RTFM perspective, having javascript mouseovers and information flow throughout the formulas would be quite handy. Maybe for version 2.0.
So in this case you can prove that two parties both know the same shared secret (x == y) without the need for webs of trust and other systems.