Hello openSUSE translators everywhere,

You love gtranslator and want to use it to localize openSUSE to your native language, but hey! there is a slight problem when you try to create a local translation memory to ease your task. It crashes!

Well, I don’t know if it really happens in Gnome, but in XFCE, when it is the only desktop environment in a default openSUSE installation (of which I am a very happy user), it definitely happens.

So, there is nothing wrong with the program itself. It is more of a packaging issue and a missing runtime dependency. A fix should be on the run (let’s see if I did it correctly on the OBS).

However, until the fix is accepted you can just sudo zypper install libgda-5_0-sqlite and it should crash no more. This fix should work in openSUSE 12.3. Please, drop me a note if it doesn’t work for you.

Have fun translating,
efagra

I have written quite some Ruby code recently which worked with files in a file system somehow. Reading, writing, manipulating data stored in a file, or in a set of files in a directory, or in a set of directories, or one of the countless variations of this. There is a lot of code like this, and one question always is: How do I write unit tests for this code?

You need test files as input for tests. You need space to write files, which is cleaned up after the test. You often have series of tests which use similar but not quite identical sets of files. Doing all this in unit tests is inconvenient, as you usually can't just do it in the test code, but have to interface with some actual file system.

One approach is to stub all the interfaces dealing with the file system and fake them with test code, which mirrors the desired environment without ever hitting a real file system. FakeFS is one low-level way of doing this. You can also often do something similar on a higher level stubbing functions of your own code, when interaction with the file system is well encapsulated.

But this approach often is too limited. When you are using external libraries or calling external tools, you don't have access to the code interacting with the file system, so you can't stub it. You also limit your test coverage, as the actual interaction with the file system usually is an essential part. Finally it can be quite some work to isolate, separate, and fake the code, which interacts with files.

So we do want to have a better solution, right?

My solution is GivenFilesystem. It is a set of helpers for use in RSpec-based tests. It also provides a basic class, if you prefer more direct access or want to integrate it with some other test framework.


GivenFilesystem provides a simple and convenient way to create test files and directories. These can be structures as complex as needed. They are built up from test data you store as part of your tests. But you only need to store the data once, and create different scenarios using this data in your unit test code. GivenFilesystem also provides an easy way to create temporary locations in the file system for writing files. These are automatically cleaned up after the tests.

Here is an example of some code creating test files (see the details in the docs):

path = given_directory "mydir" do
  given_directory "one" do
    given_file "myfile"
    given_file "myotherfile"
  end
  given_directory "two" do
    given_file "myfile2", :from => "myfile"
  end
end

The only assumption is that you have a way to specify the path your code uses to read and write files. There is no magic behind the scenes, which replaces internal code accessing the file system, but your code has to be structured in a way that you can tell it where files are. Usually this is something you want to have anyway, and which gives nicely structured code.

So if you come to the point, where you need to set up files for unit tests, or worry about cleaning up files written by your tests, consider giving GivenFilesystem a try. It has made my life a little bit more simple and convenient, maybe it can do the same for you.

I put some effort into polishing GivenFilesystem. It comes with tests, has full test coverage, and clean code. This turned out quite nicely, also thanks to the magic of code review.

Get the gem, read the docs, get started.

Feedback and other contributions are always welcome. Or if you just want to talk about it, simply drop me an email.

Herewith I announce the availability of the new Kraft release 0.55.

It was finished today and fixes two issues that came up after the release of the previous version: A compile fix for compiling Kraft against the latest version of ctemplate, which did not work out of the box with Kraft 0.54. The other fix is a fail in generating PDF documents which is a pretty severe problem for Kraft. Both is now working well with the new version 0.55 which can be downloaded here.

Thanks a lot to the Kraft community for testing!

If you find other problems, want to give feedback or seek help, please see here how to proceed. Thanks!

Fosscomm is the annual conference of the Greek Free Software communities. This year the event took place on May 3 & 4 at the Technological Educational Institute(TEI) of Lamia. This time we organized the road trip with Pavlos Ratis (dastergon) from Thessaloniki.

##openSUSE-el

Most of the greek community was recuperating from the long and tedious journey to Dubrovnik, Croatia for the Annual openSUSE conference where some had a series of presentations while the rest helped as volunteers there. That left me practically alone at Fosscomm to have a talk and man a booth which we co-hosted with dastergon as a multi-community booth (openSUSE/Gentoo).

The booth had a wide assortment of stickers, flyers, CDs and DVDs for both openSUSE and Gentoo.
My talk, entitled “Enlightening Lizards: Getting the Enlightenment experience & Being part of the effort”, was about the effort we put for packaging the environment and associated libraries and the current status in recent openSUSE versions.
I started the talk with a brief historical overview about the Enlightenment project, then moved on to an introduction of the Enlightenment Foundation Libraries (EFL) and the Enlightenment window manager to conclude with a briefing of the team members and plans for the future.

Finally, I talked about how we coordinate the work in distribution level and how to work with upstream so that we can provide a full and enjoyable environment for openSUSE users.

##Gentoo-el

The Gentoo community had 2 presentations one by dastergon, entitled “Btrfs: A next generation filesystem”, in 35’ Pavlos managed to get us up to date with the current developments regarding btrfs, the ecosystem that has developed around it, its users the architecture and workings of the filesystem.

The second presentation was one that is more upstream in character and also one I personally consider far more important. This one Pavlos co-presented with Panayiotis Christopoulos (pchrist) they talked about package maintainership and the distinction between distribution and upstream level packaging. In quite an effective and coherent manner they switched places each talking about a specific environment and its tooling and packaging tactics.
Finally after having switched quite a few distros before they both ended up as Gentoo users (later Gentoo developers) they gave a handful of tips about packaging and working with upstreams gathered from their experience with said distros and packaging schemes.

##The rest

I spent the rest of the conference at our booth helping people, answering questions and generally socializing and talking with old friends.

Congratulations to the people from the TEI of Lamia for the organization! :)

Here is their photostream on flickr

• Update: Fixed Gentoo-el photos.

It is not without emotion that the Document Liberation Project announces today the first release of the new framework library, librevenge-0.0.0. This release means that the API of librevenge is now set into a stone (at least until the 0.1.x series) and thus the library can be used by willing filter-writers.

You might be familiar with some aspects of the librevenge framework from this blog or from this FOSDEM 2014 presentation. David Tardon started a nice serie of articles explaining how to use the framework. So, there are no valid excuses remaining not to use it and not to contribute to the world domination that is the ultimate destiny of the Document Liberation Project.

Standing on the shoulders of giants

But the first release of a new framework would be empty without mentioning those on shoulder of whom we stand. First we would love to thank Will Lachance and Mark Maurer for having started more then 10 years ago the development of libwpd. It is this library and its wise interface design that allowed us to move incrementally to the current framework. Thank you guys, you know that without you we would be nowhere!

Besides your servant, David Tardon, and Valek Filipov, we would love to single out a discrete person, who speaks little but codes a lot. It is Laurent Alonso, without whom we would never be able to recover a huge amount of old MacIntosh documents. We thank equally to all our past and present Google Summer of Code students, without whom the road would be much more thorny.

LibreOffice and The Document Foundation

It would be a very big mistake if we did not thank the project from which we all originate, the LibreOffice project. The community gravitating around LibreOffice creates is caring, encouraging and creates the right environment to foster innovation.

Last but not least, our thanks go to The Document Foundation that did not hesitate to take us under its umbrella and provide all the necessary institutional support.

How to contribute

Now a new phase starts and you can be part of it! There are many ways to contribute. You drop by at the #documentliberation-dev channel at irc.freenode.net. There will always be someone to help you to join this exciting journey.

For more information about our activities, follow @DocLiberation on twitter, Join our Google plus community or like us on Facebook.

Here we are, at the beginning of a great summer!

This time, Google has given plenty of slots to the GNOME project, so we could accept many participants, including 3 brilliant students to work on the Banshee project. In case they haven't blogged about it, or didn't give much detail, I'll elaborate a bit about what they will be aiming to do these months:

• Nicholas Little will be working on creating a new extension for Bluetooth synchronization, and if time permits, refactoring our MTP support. In regards to the latter, if you have an Android phone you might have experienced some bugs getting it to work with Banshee lately (our MassStorage synchronization support is great, but the latest versions of Android have been deprecating this mode in favour of MTP, which we never supported very well); we have been working hard on fixing them, but Nicholas is going to try to give it that extra push at the end of the summer, which I'm confident he will do very well (he was the developer who brought Symbian support for the masses -or rather, for his Nokia N95 ;) -, on Banshee 2.9.0). And you may be wondering, why do we need Bluetooth sync? Well, we understand that it's much slower than USB or Wifi, but:

1. USB can work for the first sync, but whenever you update your library, I never remember to connect my phone again with my cable, or I'm too lazy to do it. Now imagine that whenever your phone is near your computer (and of course if you have Banshee running), they could negotiate together to update the sync without the need of moving a finger!
2. Wifi could work also for the use case I just explained, but getting Wifi to work, compared to Bluetooth, would involve creating an app for the phone that could talk with Banshee. And we all know what are the problems associated with that: we would need to be cross-platform for at least the 3 main mobile platforms out there (well, iOS wouldn't even work neither with this nor with Bluetooth, because there are no public APIs to integrate with the music database of the OS, sigh iTunes...), and that means a lot of maintenance burden (even if we choose a same-language native platform like Xamarin), and a user experience that is not so seamless (as it would require the user to install an app first).

• Marcin Kolny, which has convinced us that he will do a great job given his great patches and the fact that he's already very involved in opensource (maintainer of C++ bindings to GStreamer if I recall correctly), will be working on integration with AcoustID. To summarize it very bluntly, AcoustID is the open-source alternative to Shazam, so thanks to this, if you have many tracks in your library which didn't get ripped properly with tags, or you got from some friend which is not very metadata-driven ;) then you will be able to fix this situation! We will be likely reusing the MetadataFixer extension that we already have in Banshee, to not reinvent the UI wheel.

• Dmitriy Petukhov, a very motivated Russian student, will be helping us get two extensions in shape, which were developed in the last GSoC (more details about this in my previous blog post), but were not ready for mainstream yet. The FanArt.TV extension, which retrieves artist logos and shows them next to your album icons, needs some caching (we could even violate FanArt.TV service's ToS if we don't do this) and UI polish (our ListView widget doesn't play well with differently-sized images, so we need to modify this custom GTK widget to allow rendering rows with different heights). The SongKick extension works great, but also needs caching, and it especially needs GeoLocation to maybe even work autonomously (imagine, you don't even know what SongKick is, and because you installed the banshee-community-extensions package of your distro, you suddenly get told that one of your favorite bands is soon playing a gig near your city!).

As you can see, most things are work under-the-hood this year, with little UI work. That's good for me because I'm no design expert. However, there is one area which we could do with some help: the new backgound tasks that will be implemented will need a way to notify the user (i.e. SongKick: when a new gig is discovered; AcoustID: when new/better metadata is found). In this respect, maybe Hylke Bons (our chief designer for the last Gnome .NET hackfest) and Garrett LeSage (assistance that Hylke proposed now to avoid getting himself swamped!) will be able to help! (BTW, if you're interested in participating in this year's Gnome .NET hackfest, message David Nielsen, which started to plan it recently.)

I'm very happy about starting the mentoring of these projects this year. And I'm specially jealous about my students... I became mentor of GSoC myself without being GSoC student first! (Maybe I should switch roles in the future?)

Wish them good luck! It was actually just yesterday when GSoC really started! (gotta love mondays)

UPDATE: Fixed embarrassing typo: I meant AcoustID, not OpenID!

Payable hardware for professionals is capable of 30-bit throughput since quite some years. And costs continue to go down. This means even budget setups are possible with this kind of gear. So lets follow the question why, who and how monitors capable of displaying 30-bit alias 10-bit per red, green and blue channel can be used. This blog article will first touch some basics, followed by technical aspects below.

Why is it useful to display graphics on a 30-bit monitor setup?
It is essential for graphical editing, to see what effect a editing step has. It is pretty common that low resolution monitors impose a barrier to reliably predict the intended output. This is true for geometrical resolution like for colour resolution and for gamut. The rule of thumb is, the graphics editor needs the most information available to do here/his job and spot artefacts and issues early in the process. This principle is deployed for print, web, film and video editing to reduce costs. You know, redoing something costs time and is part of the jobs calculation. More image information means as well more certainty to reach a graphical result. The typical artefact caused by low colour resolution is reduced tonal range. Colour conversions can reduce the tonal range further. So a sRGB image will look different on a 8-bit per channel monitor with a native gamma close to 2.2 compared to a pipeline with 10-bit per channel. The 8-bit output imposes a bottleneck resulting in loosing some tonal steps known as banding, which must not necessarily be present in the observed sRGB image. One very often read argument against higher bit depth is, that editing hardware shall be as close as possible to customers ones. But that is a illusion. The wide diversity of media and devices makes this nearly impossible. But simulation of end customer hardware is of course an issue and many graphics software has implemented simulation capabilities to address that concern.

Who is most interested in 30-bit colour editing on Linux?
Graphics professional and ambitious users closely observe Linux since many years and deploy it. Many block busters are produced and rendered on Linux machines. Web graphics is well supported since years and camera raw programs implemented a impressive level of features in the last years. So Linux is a potential content creation platform beside content consumption. The typical work flow for content creating people is to generate and edit their art work in high geometrical and colour resolution and down convert to lower resolutions as fits for the job, be that web, print, catalog previews and more flexible high quality delivery depending on actual contract. For instance many photographers archive their shootings in the cameras native format to preserve all available information for later editing or improved rendering. This is a important investment in the future for non short lived work, where old files can shine in new light. Motion picture productions are often rendered and color graded in floating point space by using the OpenEXR intermediate file format and output to 12 bits per component for playback in a cinema. Video production uses in parts raw workflows for advertisements. Medical-, scientific- and archival imaging are potentially interested too and require in parts 30-bit setups like in the DICOM standard. The benefit of 10-bit per channel versus 8-bit does not matter to everyone. Most consumers will not spot any difference while watching web video. But in more demanding areas it is a small but helpful improvement.

How to deploy 30-bit displays on Linux?
That feature was implemented by several companies starting on low level software components like X11, Cairo and pixman. However desktops where pretty slow to adapt software to the new needs and fix bugs. That was in part of the initially higher costs for the hardware. Only few developers in the open source community had early access to suitable gear. I do not write here about suitable graphic cards and monitor combinations. You should consult the web for this. Search for 30-bit monitor. Many early adopters observed psychedelic colours, not working graphics areas and more. Here the state on the well known KDE X11 desktop in release 4.11 on a openSUSE-13.1 . The login screen colours are broken. The splash screen after login looks correct and after some period the desktop becomes visible with again broken colours. To manually fix most of that, one have to tell that Qt shall use native colours. Create following text into a file called ~/.kde4/env/qtnative.sh .

$ kwrite ~/.kde4/env/qtnative.sh

#!/bin/sh
export QT_GRAPHICSSYSTEM=native

With the above variable the desktop should look reasonably in KWin, which is really great. Automating that in Qt would be appreciated.

However 30-bit monitors typical aim at high quality setups. Beside colour resolution they often enough offer a wider gamut than usual monitors. This results in partially heavily saturated colours, which burns in sensible eyes. Those people who do colour grading or photo editing are mostly affected, otherwise they can not easily play this work. So desktop colour correction is an other important feature to enable here. KWin supports ICC based colour correction through KolorManager, which would be useful for the colour saturation. But KWin disables all effects for 30-bit OpenGL visuals. The alternative Compiz-0.8 series has the CompIcc colour server plug-in, which provides the same ICC colour correction feature. To make use of it, one needs to install following packages: compizconfig-settings-manager, CompIcc-0.8.9. Unfortunedly the KDE decorator is no longer available. So use the Emerald decorator from X11:Compiz with the 30-bit-shadow.patch in order to avoid artefacts in the shadow code. Compiz can be used as a default window manager application. Use the system settings to switch to Compiz. Use ccsm to switch on Color Management if not done automatically. And voila the 30-bit desktop should be ready to explore.

What works and what not?
The Plasma desktop is fine including all menus. Dolphin, KWrite, and other applications work. Thunderbird shows some artefacts due to not properly supporting the R10G10B10A2 pixel format. The same is true for Firefox, which lets in parts shine through content behind the Firefox window. Gwenview and ShowFoto work fine within their 8-bit drawing. Only the preview is broken in ShowFoto. Krita supports with the OpenGL backend even native 10-bit per colour component. Menus in Sketch are black. Krita shows minimal artefacts through twice colour converting from image to sRGB by Krita and from sRGB to the monitor colour space by CompIcc. But this effect is much lesser visible than the improvements through its 30-bit support. Applications which try to code 24-bit colour themselves are broken like Konqueror. Gtk and hence Gnome applications with graphical areas do not work. They show black areas. VLC works fine. So daily work should be fine in with 30-bit in the KDE application family depending what you do, with some minor glitches. Valuable Gtk applications as is like Inkscape and most Gtk applications are unusable in a 30-bit setup, with Gimps drawing area being a exception. Thunderbird/Firefox are guessedly affected by the same Gtk bug for which a patch was created some time ago. A patched libgtk-2 is available for testing on openSUSE, which appears to have fixed the problem almost for me.

Beside the need to exchange a windowmanager, to patch a few components and do some manual settings, Linux appears almost there in support of 30-bit setups. Polishing of that feature needs testing of patches and finally acceptance for distribution. Your feedback about bugs, tests and patches can make a difference to developers.

I participated in the Gran Canaria LibreOffice Hackfest recently, and once again, it was a great one :-) - I am looking forward to the next hackfest from the very minute I boarded the plane home.

As always, it was lots of talking to others, sharing ideas, plugging in the new people (few students appeared, and were interested - one even drew few dialogs in Glade, still need to integrate them). And the rest of the time, I was hacking - LibreOffice Start center again:


This time, it was the removal of files from the recent documents in the Start center; you can now point the mouse to the cross at the top right side of the document you want to remove from the list (but not from the disk of course!), a click - it is gone.

It will be available in LibreOffice 4.3; try the betas soon!

I am happy to tell about the new release 0.54 of Kraft which was released a couple of days ago.

It is not only a maintenance release but also comes with a couple of new features, the most outstandig is the ability to handle a new document type, the delivery note which prints no prices. That closes a gap for interesting use cases. Here is a more detailed log of what was added to this release.

Kraft is KDE software to help people driving a small business. Emphasis is on small and business. We are not talking CMS, ERP or any other monster. Kraft is about a handy alternative for people who wrote their first 25 invoices using Libre Office and now start to think of how they could could be more efficient in doing that: Using structured templates, being able to create an invoice based on a quote that was done before, no need to fiddle around with slipping paragraphs, a proper address book, such stuff. Software for people who have other things to do than sit in front of their computer. Hard to understand for geeks like us who enjoy this technology, but yes, there are a lot of people who do not, who just use computers because they must, because they have a business.

I started to work on Kraft in 2006, and worked on similar software before, well, we all have our dark history. I always enjoyed doing software for people who would prefer to not use the computer. And the more I got involved into KDE the more obvious it became to me how perfectly KDE is able to help with that. High level classes, components to reuse, other projects aiming the same direction, and a community of helpful, friendly and open minded people. Also I think software like Kraft is a good addition to the KDE family as it has potential to bring more and different users to KDE.

However, if measured by the number of known users of Kraft, this idea failed completely. Compared to other KDE software, Kraft has disappointing little (known) users. Also contributors: Apart from very few brave developers who spent some time on Kraft, I am the only contributor. The reasons for that can be discussed in another thread.

What still keeps me motivated to work on Kraft is that the few users often tell how happy they are with it. And that Kraft really helps them to drive their business and save time. Also that they found with Linux and KDE a computer “environment” that really helps them reliably instead of facing them with scary stuff. That is really cool, and the best is that this recently happened more often than the years before.

That is what keeps me around with Kraft.

For the future, there are enough ideas: “Combined Kraft” which means using one instance of Kraft from distributed home offices, with ownCloud as sync hub, or an easy to use project management and of course a port to KDE Frameworks 5 to be able to ship for Mac and and and…

Well, it’s a pet project, and my day unfortunately does not leave very much energy behind for that currently, so don’t expect big movement, but be sure that there will be small steps.