As announced earlier KDE will apply to become a mentoring org again for Google Summer of Code in 2012. We decided to focus on accessibility this round should KDE be accepted again. To make this happen KDE’s mentors need help. Most of the mentors do not have the knowledge needed to make good decisions when it comes to making our applications more accessible. We are therefor looking for co-mentors who can help them – people who either have a disability that requires changes in KDE’s software to make their life easier or people who are otherwise knowledgeable in the area. These co-mentors would not have to do any of the mentoring on the coding side but instead advice the student and main mentor on non-coding parts. Does that sound like something you can help with? Then please send an email to kde-soc-mentor@kde.org and introduce yourself and how you could help. Please also pass this on to anyone you think might be a good fit.

Since implementing the TV Show KIO slave was that easy I decided I could do the same for music – just to show how simple it can be. There a a few more lines but that is only because I added browsing by album, artist, and genre. So there are a lot of if/else constructs. Anyway, here goes:

Browsing music by artist is easy. As you can see I also implemented a preview generator plugin the same way I did for the TV Shows. The only problem is that there is no tool yet that automatically fetches those images. Thus, I had to do it manually for one example which looks somewhat like this:

qdbus org.kde.NepomukStorage /datamanagement org.kde.nepomuk.DataManagement.addProperty "nepomuk:/res/0152825f-5c49-4ca8-aa0a-23fc9a1305f1" "nfo:depiction" "/home/trueg/atb2.jpg" "shell"

This is part of the fancy Data management API which allows me to add the file atb2.jg as a nfo:depiction of the nco:Contact resource identifying the artist ATB.

Anyway, entering the artist themselves and what lies beyond:

(Again I had to fetch the cover art manually. I did not want to implement my own cover art retrieval tool and I found the Amarok code not to be very reusable. Again maybe someone wants to take up this task?)

Finally we end up in the album tracks. Sadly dragging an album to a media player playlist does not work yet. I am not quite sure how to fix that.

Last but not least a quick look at browsing by genre:

This was fun. But before I go to bed let me share with you the very simple code which is responsible for the nice previews (abbreviated of course):

bool MusicThumbCreator::create(const QString &path, int w, int h, QImage &img) { KUrl url(path); QStringList pathTokens  = url.path().split('/', QString::SkipEmptyParts); if(pathTokens.count() < 2) { return false; } // there are only two cases for us: artists and albums if(pathTokens[pathTokens.count()-2] == QLatin1String("artists") || pathTokens[pathTokens.count()-2] == QLatin1String("albums")) { const QUrl uri = recoverUriFromUrlToken(pathTokens.last()); // we just query the first depiction there is Soprano::QueryResultIterator it = Nepomuk::ResourceManager::instance()->mainModel() ->executeQuery( QString::fromLatin1("select ?u where { " "%1 nfo:depiction [ nie:url ?u ] . " "} LIMIT 1") .arg(Soprano::Node::resourceToN3(uri)), Soprano::Query::QueryLanguageSparql); if(it.next()) { img.load(it["u"].uri().toLocalFile()); return true; } } return false; }

The rest of the code can be found in the nepomuk-audio-kio-slave scratch repository. Maybe at some point I could just throw all of those things into some “Nepomuk KIO extensions” package… oh, well, off to bed now…

During the past month I’ve been working on a new GStreamer element called qtvideosink.  The purpose of this element is to allow painting video frames from GStreamer on any kind of Qt surface and on any platform supported by Qt. A “Qt surface” can be a QWidget, a QGraphicsItem in a QGraphicsView, a QDeclarativeItem in a QDeclarativeView, and even off-screen surfaces like QImage, QPixmap, QGLPixelBuffer, etc… The initial reason for working on this new element was to support GStreamer video in QML, which is something that many people have asked me about in the past. Until now there was only QtMultimedia supporting this, with some code in phonon being in progress as well. But of course, the main disadvantage with both QtMultimedia and phonon is that although they support this feature with GStreamer as the backend, they don’t allow you to mix pure GStreamer code with their QML video item, therefore they are useless in case you need to do something more advanced using the GStreamer API directly. Hence the need for something new.

My idea with qtvideosink was to implement something that would be a standalone GStreamer element, which would not require the developer to use a specific high level API in order to paint video on QML. In the past I have also written another similar element, qwidgetvideosink, which is basically the same idea, but for QWidgets. After looking at the problem a bit more carefully, I realized that in fact qwidgetvideosink and qtvideosink would share a lot of their internal logic and therefore I could probably do one element generic enough to do both painting on QWidgets and on QML and perhaps more surfaces. And so I did.

I started by taking the code of qtgst-qmlsink, a project that was started by a colleague here at Collabora last year, with basically the same intention, but which was never finished properly. This project was initially based on QtMultimedia’s GStreamer backend. As a first step, I did some major refactoring to clean it up from its QtMultimedia dependencies and to make it an independent GStreamer plugin (as it used to be a library). Then I merged it with qwidgetvideosink, so that they can share the common parts of the code and also wrote a unit test for it. Sadly, the unit test proved something that I was suspecting already: the original QtMultimedia code was quite buggy. But I must say I enjoyed fixing it. It was a good opportunity for me to learn a lot of things on video formats and on OpenGL.

How does it work

First of all, you can create the sink with the standard gst_element_factory_make method (or its equivalent in the various bindings). You will notice that this sink provides two signals, an action signal (a slot in Qt terminology) called “paint” and a normal signal called “update”. “update” is emitted every time the sink needs the surface to be repainted. This is meant to be connected directly to QWidget::update() or QGraphicsItem::update() or something similar. The “paint” slot takes a QPainter pointer and a rectangle (x, y, width, height as qreals) as its arguments and paints the video inside the given rectangle using the given painter. This is meant to be called from the widget’s paint event or the graphics item’s paint() function. So, all you need to do is to take care of those two signals and qtvideosink will do everything else.

Getting OpenGL into the game

You may be wondering how this sink does the actually painting. Using QPainter, using OpenGL or maybe something else? Well, there are actually two variants of this video sink. The first one, qtvideosink, just uses QPainter. It is able to handle only RGB data (only a subset of the formats that QImage supports) and does format conversion and scaling in software. The second one, however, qtglvideosink, uses OpenGL/OpenGLES with shaders. It is able to handle both RGB and YUV formats and does format conversion and scaling in hardware. It is used in exactly the same way as qtvideosink, but it requires a QGLContext pointer to be set on its “glcontext” property before its state is set to READY. This of course means that the underlying surface must support OpenGL (i.e. it must be one of QGLWidget, QGLPixelBuffer or QGLFrameBufferObject). To get this working on QGraphicsView/QML, you just need to set a QGLWidget as the viewport of QGraphicsView and use this widget’s QGLContext in the sink.

qtglvideosink uses either GLSL shaders or ARB fragment program shaders if GLSL is not supported. This means it should work on pretty much every GPU/driver combination that exists for linux on both desktop and emebedded systems. In case no shaders are supported, it will fail to change its state to READY and then you can just substitute it with qtvideosink, which is guaranteed to work on all platforms supported by Qt.

qtglvideosink also has an extra feature: it supports the GstColorBalance interface. Color adjustment is done in the shaders together with the format conversion. qtvideosink doesn’t support this, as it doesn’t make sense. Color adjustment would need to be implemented in software and this can be done better by plugging a videobalance element before the sink. No need to duplicate code.

So, which variant to use?

If you are interested in painting video on QGraphicsView/QML, then qtglvideosink is the best choice of all sinks. And if for any reason the system doesn’t support OpenGL shaders, qtvideosink is the next choice. Now if you intend to paint video on normal QWidgets, it is best to use one of the standard GStreamer sinks for your platform, unless you have a reason not to. QWidgets can be transformed to native system windows by calling their winId() method and therefore any sink that implements the GstXOverlay interface can be embedded in them. On X11 for example, xvimagesink is the best choice. However, if you need to do something more tricky and embedding another window doesn’t suit you very well, you could use qtglvideosink in a QGLWidget (preferrably) or qtvideosink / qwidgetvideosink on a standard QWidget.

Note that qwidgetvideosink is basically the same thing as qtvideosink, with the difference that it takes a QWidget pointer in its “widget” property and handles everything internally for painting on this widget. It has no signals. Other than that, it still does painting in software with QPainter, just like qtvideosink. This is just there to keep compatibility with code that may already be using it, as it already exists in QtGStreamer 0.10.1.

This is actually 0.10 stuff… What about GStreamer 0.11/1.0?

Well, if you are interested in 0.11, you will be happy to hear that there is already a partial 0.11 port around. Two weeks ago I was at the GStreamer 1.0 hackfest at Malaga, Spain, and one of the things I did there was porting qtvideosink to 0.11. I must say the port was quite easy to do. However, last week I added some more stuff in the 0.10 version that I haven’t ported yet to 0.11. I’ll get to that soon, it shouldn’t take long.

Try it out

The code lives in the qt-gstreamer repository. The actual video sinks are independent from the qt-gstreamer bindings, but qt-gstreamer itself has some helper classes for using them. Firstly there is QGst::Ui::VideoWidget, a QWidget subclass which will accept qtvideosink, qtglvideosink and qwidgetvideosink just like any other video sink and will transparently do all the required work to paint the video in it. Secondly, there is QGst::Ui::GraphicsVideoWidget and QGst::Ui::GraphicsVideoSurface. Those two are meant to be used together to paint video on a QGraphicsView or QML. You can find more about them at the documentation in graphicsvideosurface.h (this will soon be on the documentation website). Finally, there is a QtGStreamer QML plugin, which exports a “VideoItem” element if you “import QtGStreamer 0.10″. This is also documented in the GraphicsVideoSurface header. All of this will soon be released in the upcoming qt-gstreamer 0.10.2.

Just letting you know that I merged the Plasma Hard Disk Monitor/IO applet a few days ago into master. So it'll appear in KDE 4.9.

I also accidentally had a bug that was leftover from some debugging, that resulted in 100% cpu usage. Fixed a few minutes after I was informed -- so if you're running it, be sure to update to today's commit ;-)

Funny how it's hard to notice such things when you have so many cores these days.

It'll fix some other bugs soon enough, like the fact that tooltips don't even display units. Actually, I correct myself..that affects all applets. So yeah. I'll fix that.

A lot of interest was shown for a desktop client that synchronises data between the local machine and ownCloud. Talking about synchronising means that the software tries to keep the content of a local directory on the same current state as one on ownCloud. Whenever a file becomes more recent on one of the both sides its its going to be updated on the other quickly.

As I am currently working on the syncing I thought I could share the plan.

Where we come from

I am working on a desktop client based on a program called mirall. Mirall was started by Duncan Mac Vicar (github) and I joined the development (github) a couple of month ago. Mirall is witten in C++, currently Qt based.

Mirall uses csync, a universal file syncronizer written by Andreas Schneider as a backend. That works great for local and ftp attached storages, but as ownCloud is webDAV based, and csync was not supporting webDAV, we had to further investigate. In an SUSE sponsored hackweek I did some experiments with an external tool called sitecopy and implemented a sitecopy based backend for mirall.

That works nice for a one-way usecase of syncing - whenever something on your local disk changes, it gets automatically pushed to the ownCloud. Together with a fetch functionality which gets all content from the ownCloud that already covers a lot.

But of course the target is to get a fully functional two way syncing.

Improve csync

The decision now is to improve csync and fade off the sitecopy backend, for this
reasons:

• Mirall already utilizes csync with good results for local directories and
  ftp servers. csync has proofed to implement the syncing algorithm very well.
• csync comes with a shared library to link from applications in opposite to the
  sitecopy solution which means calling an external script.
• the csync library offers a natural interface for people who want to write an
  additional client, for example based on a different gui toolkit.
• csync offers a command line client! That means that syncing ownCloud from command line comes for free.
• csync has a clean modular plugin system for the backends.

So as a result the idea is to create a WebDAV backend plugin for csync. To manage
the WebDAV communication, libneon is used. This is work in progress, currently
happing in a dev branch in csync upstream.

Mirall improvements

The work on mirall happens together with miralls upstream. As the ownCloud community is aiming for a specific ownCloud client I will work out options together with Duncan how we can give mirall different names (ownCloud and mirall obviously) and maybe themes and such.

We will target for a system tray tool that allows to manage syncronized folders for the first release, not much more fancy stuff planned now.

Mirall currently is plain Qt, but on the longer run it will get KDE improvements such as KWallet integration to be compiled in optionally on platforms where it makes sense.

Mirall will be available on Linux, Windows and MacOS.

Timeline

We plan for a beta version of the ownCloud client for early march, at least on  Linux. A first stable version will be released with ownCloud4, again at least for Linux, with second priority Windows.

Other Sync Clients

There is work going on on other desktop sync clients. I know its good to combine efforts in FOSS, but I apologise for staying on the mirall path, I already have been on it for too long. On the other hand I don’t  think its a problem to have more than one client driven by community. Diversity is one of the strength of FOSS.

Thanks

Already now, even if there is nothing released yet, a big thanks goes to Duncan Mac Vicar, the initial author of mirall, for beeing very cooperative with mirall as well as to Andreas Schneider, the founder of csync, who actively helps to get webDAV support into csync. Both are very enthusiastic about ownCloud which is great and motivating :-)

Many others send in patches, help compiling on other platforms, test and give suggestions. Many thanks for that, your contribution is very appreciated.

In the last sprint I developed a translation memory server in PHP almost from scratch. Well, it’s not really a server. It’s run inside MediaWiki during client requests. It closely follows the logic of tmserver from translatetoolkit, which uses Python and SQLite.

The logic of how it works is pretty simple: you store all definitions and translations in a database. Then you can query suggestions for a certain text. We use string length and fulltext search to filter the initial list of candidate messages down. After that we use a text similarity algorithm to rank the suggestions and do the final filtering. The logic is explained in more detail in the Translate extension help.

PHP provides a text matching function, but we (Santhosh) had to implement pure PHP fallback for strings longer than 255 bytes or strings containing anything else than ASCII. The pure PHP version is much slower, although that is offset a little because it’s more efficient when there are fewer characters in a string than bytes. But more importantly, it works correctly even when not handling English text. The faster implementation is used when possible. Before we did some optimizations to the matching process, it was the slowest part. After those optimizations the time is now bound by database access. The functions implement the Levenshtein edit distance algorithm.

End users won’t see much difference. Wanting a translation memory on Wikimedia wikis was the original reason for reimplementing translation memory in PHP, and in the coming sprints we are going to enable it on wikis where Translate is enabled (meta-wiki, mediawiki.org, incubator and wikimania2012 currently). It is just over 300 lines of code [1] including comments and in addition there are database table definitions [2].

Now, having explained what was done and why, I can reveal the cool stuff, if you are still reading. There will also be a MediaWiki API module that allows querying the translation memory. There is a simple switch in the configuration to choose whether the memory is public or private. In the future this will allow querying translation memories from other sites, too.

A few days ago Mark Shuttleworth announced the HUD menu, a  Unity dialog that lets you trigger menu actions in the focused application like:

• look for bookmarks,
• change your IM status
• execute an action contained in the menu bar.

This kind of features as well of how they are executed may sound familiar to you dear Plasma Worksapce user… Exactly! I’m referring to our beloved KRunner!

KRunner can do a lot of stuff in both global and active application scope (though it tends to offer more global features) , just to mention a few: Math, Bookmarks, Files, Calendar, Contacts, Emails, Devices, Change IM Status, Recent documents…

I have to say that I’m glad to see Unity going into this direction since it is something that we (KDE Community) have believe in for years, so having Canonical and its designer team walking into the same direction may indicate that we are not wrong or at least we are not the only ones mistaken

Despite KRunner being able to do a lot of things it couldn’t do something the HUD does, execute actions contained in the menu. No less than 7 months ago I did my first attempt on achieve exactly that and of course I blogged about it. I didn’t continue with the effort mainly because: kdelibs was frozen, it worked only for KDE applications, it worked only if the menu bar was shown within the window.

After watching the HUD video I got inspired and motivated to create a Runner which will use the same technology as HUD (and the oxygen-appmenu or the plasma-menubar plasmoid) to look and execute menu bar actions, this is the result:

Direct link

 

There are a few things to work on but I hope to put this in KDE Plasma Worksapce 4.9 if the Plasma teams like it of course.

The code is in:

git://anongit.kde.org/scratch/afiestas/appmenu.git

Kubuntu packages are WIP
Would be nice if somebody can write a manual of how to setup appmenu in Qt and maybe other toolkits.

I am glad to announce the third bugfix release for Muon Suite 1.2. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies.

The third bugfix release fixes several crashes found with previous versions of the Muon Suite, including a rather severe crash in the Muon Software Center caused by default repository changes in Kubuntu. Additionally, hangs experienced during long/large upgrades have been fixed, and issues with the update notifier not always notifying of updates have been fixed. All fixes have been included in the recently-released release candidate of the Muon Suite 1.3.

Packages for Kubuntu 11.10 are from the QApt repository. I will try to get 1.2.3 pushed as an official update for Kubuntu 11.10 over the next week or so using the Ubuntu Stable Release Update process. Since this has a more rigorous testing process than my unofficial PPA, regression testing from users will be required. Stay tuned for more info about that if you’d like to help! This did not happen with the 1.2.2 release due to a severe lack of time on my part due to final exams and work, but I will try to make it happen this time as this release does fix several serious issues.

Further technical information about the release, including source tarball downloads and a detailed changelog, can be found at the project pages here and here.

Yes, I could not resist to associate Blender with "will it blend" my favourite way to use an iPhone (check out this video http://www.youtube.com/watch?v=_S8sxpK4_iA).

Some days ago, I asked some questions to Ton Roosendaal and he, really nicely, found the time to answer. As you all may know, he is the creator of Blender and the head of the Blender Institute. Anyway, for me, the most important idea he developed is the "open movie" project. It introduces a completely new concept of creating an artistic opera, where the public can be an active part during the production and expecially after it, possibly improving the opera itself or creating another version (if it's a movie, you can create your own final). Basically, it's the power of free open source software ported to art, expecially cinematographic art.
Tra l'altro: se siete italiani, potrete leggere una traduzione dell'intervista con presentazione nel prossimo numero di GNU/Linux Magazine Italia.

-So, this will be the first Blender "open movie" with real actors: is there a particular reason for which you decided this or it's just a director's choice?
Each time I've picked a main theme connected to technical targets for Blender. The whole concept of our open movies is to get focus for a longer period on bigger targets, and have these targets well tested and validated immediate. That mimics the process how most (bigger) animation studios work with their in-house software. If there's one thing we stand out among the competition it's Blender's open source nature, which really makes it your own in-house software!
After doing one game project and three animation films, doing a vfx based project was a very obvious choice. Modern film making happens with 3d software you know!

-Can you tell us, briefly, the plot of Mango (obiously without spoilering)?
In the distant future they find out that the nearing destruction of the World has been caused by a break-up in Amsterdam long ago. They then desperately send a fleet of space ships and robots back to the past to prevent this break-up to happen.
(Also see blog post about this on mango.blender.org + Ian's reaction)

-Since the open movie is also a way to let developers improve some Blender features, collaborating with the artists, the Mango team wrote some "development targets". Can you explain us, practically, what those targets are?
Just 2 days ago we posted a very long article on our blog about the development targets. It's actually quite a too long list now, we will need to narrow it down still.
Some techniques are impossible to avoid though; and the main one is camera tracking. That's an artist's tool in Blender that allows you to extract the 3D camera position, orientation and motion from shots. With that info you can then seamlessly merge artificial 3d rendered objects with the real footage. You can even take it steps further and use it to track bodies, faces or even do full motion capture of humans. All in Blender - without need of special equipment.
Basic but good quality camera tracking is Blender already, released last month.

-Now a technical question: do you use GNU/Linux distributions for producing this movie? Which free open source programs do you use, mainly, for the production?
In the studio we use Ubuntu for the workstations and Debian for the render farm nodes. Exclusively free/open source tools are being used for the complete visual pipeline here. Apart from Blender that's of course the GIMP, MyPaint, Krita and Inkscape.
An exception is for example the camera data itself - files from Red Epic cartridges require closed software to convert to regular readable image files. Also the sound editing and mix we don't do ourselves, we just accept the best offer from a composer or sound studio.

-Italy has been, from the beginning of the 20th century, a very active country in cinematographic art, and the public is really interested in new movie ideas. Do you think to present Mango also in Italy, for example at the Venice festival (september 2012, it's about when you plan to complete your movie)?
Yep, I'm a big fan of Italian cinema! But we make a humble short low-budget film, just 5-7 minutes, I don't think that would be a big event for the Venice festival. For sure I'll try to get it in of course :) We have two Italian artists working here on Mango, they would love to see this happen!

-Which features would you like to see in a future version of Blender?
For next year and later? I don't think we need so much new features specifically, what we need mostly is quality and good maintenance of features. With Blender being compared to the big commercial programs, we somehow have to organize our developer community to keep improving too. The only way to keep growing is to organize small/medium studios to get involved with development as well; to hire people to work on Blender and together work on a tool we all can use far more efficiently than any closed program.
Once that's done we obviously have to make a big feature film together. And then add loads of new features again!

Post Scriptum: If you don't know what camera tracking is, watch this:
Digital Makeup in Blender from Sebastian König on Vimeo.

Edit: Ton suggested me to put here some pictures from mango authors, so I have choosen these (click to see them  bigger):

I meant to release a new version of Notably on Friday, but I got sidetracked with some stuff. Plus, I've been spending a lot of time on designing the UI for this release, which I think isn't a good idea. Notably is still not quite mature, and I think right now features are more important than polish.

Last week, I showcased some tagging UIs. They aren't yet ready to be deployed in KDE, as they need to be polished quite a bit. Plus, there is a lot scope for collaboration when designing UIs.

Changes Revamped UI

I've gotten rid of most of the custom KWin code. I'd initially wanted my application to look quite different, with a blurred background and fixed size. But that would be locking the user into a fixed interface.

Notably now looks and behaves more like a KDE application. (No more blurred background)

Better Sidebar

Most of the code improvements have been in the sidebar, which now acts as a proper menu and allows navigation.

Experimental Widgets

Some brand new widgets;

Tag Widget

I showcased the new Tag Widget I was working on a couple of days ago. Since then, I've improved the code to make it more maintainable, unfortunately it still needs a lot of work.

Tag Cloud

Creating a Tag Cloud turned out to be a greater challenge than I expected. Right now it's implement with some basic HTML in a QTextBrowser. I'm still experimenting with some custom layout code. Lets see how it goes.

Tag Browsing

You can browse your notes based on the tags they have been given. This will eventually have to be expanded to allow multiple facets - like tags, dates and so on. Implementing it on the Nepomuk side is fairly simple, but I'm not sure about the interface.

After a couple of more releases when I've gotten most of the main features down, I'll start on polishing it up and moving it to extragear :)

Source Code: kde:notably

Today Phoronix published (again) test results comparing the Game Rendering Performance on various desktop environments. As it “seems” like the performance of Game Rendering under KWin got worse in comparison to last year I want to point out a few things.

First of all: keep in mind that this is a test of Game Rendering Performance and doesn’t tell anything about the performance of tasks that matter. The development focus of KWin is clearly not on being great for games. We want to be (and are) the best composited window manager for desktop systems. That is what matters that is what we fine tune the system for.

Another important fact to know is that last years test was seriously flawed and I think this years test is flawed in a similar way. Last year KWin used by default unredirection of fullscreen windows while no other composited window manager in the test did that. With 4.7 we adjusted the default and turned unredirection off. But at the same time Mutter received to my knowledge unredirection of fullscreen windows. In case it is enabled in Mutter we have the explanation for last years bad results and this years good results.

If I would perform such a test, I would not benchmark KWin once but once for OpenGL 2.x backend, once for OpenGL ES 2.0 backend, once for OpenGL 1.x backend, once for XRender backend, the same set with unredirection of fullscreen windows turned on and once without compositing at all. We see there are so many things that would influence the game rendering performance that just one run of the benchmark is not enough.

But still we would recommend to turn compositing off when playing games. At least that is what I would do. A window manager is mostly just in the way of games and that is one of the reasons why gaming on desktop is by far not as good as playing on a gaming console. So if you want to game with KWin use the feature to specify a window specific rule to block compositing as long as the game is running. This will yield the best game rendering performance.

This was my first FOSDEM without a predefined tight agenda, so I could enjoy more than ever the event. I had a lot of fun and could talk to many people with no stress.

I attended to several talks. I must say that I didn't like many of them. I'll mention the best ones, for different reasons:

• Wayland
• MER
• Qt5
• LibrePlan
• OpenAdvice
• OpenMoko Freerunner 
• Why the community should welcome Average Jane and Joe 

Obviously I didn't attend to most of the talks. There were more than 400 in one and a half day.

I spent most of the late Saturday and Sunday around KDE stand. Many KDE members where there and I could talk to most of them. I would like to mention Jonathan Riddell's work, specially in these hard times for him, Jonathan, you rock!

It was very cold in Brussels. We reached -14ºC the first night. Simply too much for a Canary Island guy. The beer was warmer than the weather. That was weird. Thanks to the Kolab guys, Paul and Georg, I could drink some very good beer and visit cool bars I've never been before.

As you know, we are having a hard time in Spain, specially if we talk about unemployment. Free Software sector is doing quiet good though. On our recent history, one of our structural problems have been exportation. Last two years, due to the internal the economic crisis, we have raised them by 30% and FLOSS companies are no exception. Many Spanish companies had presence in FOSDEM 2012.

On Sunday night I organized a networking dinner with some Spanish FLOSS companies and a representative of the Commercial Office of the Spanish Embassy in Brussels. KDE Spain, Zentyal, Gestiweb, Igalia, Carlos Sánchez and others (up to 24) were there.

The goal was that these representatives could know some entrepreneurs and how the FLOSS sector is doing in Spain. Next year, the day before FOSDEM 2013, we plan to organize in the Spanish Embassy in Brussels some networking activities between Spanish FLOSS companies and foreign corporations attending to the event.

FOSDEM has a great program, but networking is as relevant as talks. So don't don't miss it next year. See you there, hopefully, with better weather.

Agustin Benito Bethencourt (Toscalix) Spanish Blog: http://abenitobethencourt.blogspot.com Linkedin profile: http://es.linkedin.com/in/toscalix

Probably you know Chakra Project ! the one of most popular linux distros based on Arch Linux which come with latest KDE desktop. anyway… (more informations)

after more than 1 year, after Neda artwork set, in next release of chakra (will released 12 february 2012) you can see a big change in artwork section. our new artwork set called Ronak (a kurdish name for girls that means “Light”) which includes wallpaper, Plasma Theme, KDM, Ksplash. best news in this release is we have 2 version for Ronak Artwork, a Light version that comes with colorful artwork set and a Dark version for users who love dark desktop that the dark one is default after installation and also users can change that to light theme with accessible tools in “System Settings”.

 

Ronak is in Testing repository! you can install and use it before Chakra Archimedes (2012.2) release and report probably bugs.

In Artwork section of Chakra now we have 2 artist and 1 maintainer (me). special thanks to my best friend “Shahrzad” who design both of wallpapers in dark and light version and “David” who design Plasma Theme for Ronak. and it’s my proud to introduce Chakra Artwork Team with these guys. im glad to work with this team and we promise to you and users that we will be more active in next releases

P.S : We, me and Shahrzad present this package to all users who love Chakra and we present it to our people in Iran that love the world and wish the peace for all around the world…

Dear all digiKam fans and users!

digiKam team is proud to announce the 1st digiKam Software Collection 2.6.0 beta release!

With this release, digiKam include a lots of bugs fixes and new features introduced to last Coding Sprint from Genoa.

read more

Yesterday I woke up to the news that Canonical are no longer going to fund Riddell to work on Kubuntu. I've trying to figure out what that means for KDE and for community Linux generally.

Disclaimer: I work in the same role as Jonathan at SUSE, a competing Linux company that sponsors the openSUSE project. This is my personal opinion, not that of the openSUSE Board or SUSE Linux GmbH.

I'm sad for Jonathan personally. He has put a lot of his lifeblood into Kubuntu over the years, at no little cost to himself, and to be pulled off one's favourite project hurts. The same thing could happen to me if the powers that be decide, so I can easily empathise with him.

In the bigger picture, I have to say that this doesn't surprise me at all. For Canonical, Kubuntu fulfilled its purpose a few years ago already. Kubuntu, and the other official Ubuntu derivatives, have always been a spoiler move to tie up community contributors who believed in the early community-centric image of Ubuntu, but who didn't agree with the main Ubuntu's direction. Otherwise, there was the risk that Ubuntu design decisions would polarize the Linux community and send people towards Ubuntu's competitors. With the derivatives, they are safely occupied under the big tent of the Ubuntu brand.

If we look back at the Ubuntu game plan as history neatly lays it out for us, we have

1) Establish the Ubuntu brand amongst early adopters (check, by about 2005)
2) Expand it to the wider Linux user base (check, by about 2007)
3) Make Ubuntu the default Linux for non-technical users (2009)
4) Tie up a paying market. Initial targets have been enterprise desktop Linux (maybe next year ;)) or consumers in the massmarket netbook segment (but that was squashed by tablets and Microsoft rounding up the manufacturer back to the XP prison), and now they are aiming at embedding into consumer electronics (TVs) and will probably snare a tablet OEM as a cloud OS (hell, if KDE can do it...) or a bookseller or someone who wants a platform to digitally sell something else off of.
5) Profit
6) Buy more spaceflight (Probably. For some, 5) is enough)

Somewhere after 1), the massive demand for KDE on Ubuntu in KDE's main territories (Germany, via the ubuntu.de forums, which IIRC threatened an unofficial fork) caused Canonical to realise that it was better to control a large dissenting minority with some token gestures than to have them really doing their own thing. So Jonathan, at that point a KDE packager at Debian, was hired, and Mark Shuttleworth did his salesman job at a couple of KDE events making some insubstantial promises (If I had a dollar for every KDE eV board member at the time who told me "But Mark has promised to install and use Kubuntu on his workstation" multiplied by every Ubuntu developer overheard chuckling that "But they don't know that Mark *never* uses his workstation, he's always on a notebook"...), a few community people got flights to events, and Kubuntu was born, and legitimised by the then-leaders of the KDE community.

Once 2) was consolidated, Kubuntu was redundant to Canonical, but on the average professional Linux hacker's salary, Jonathan was an affordable luxury. Now, I suspect that with the trend at Canonical to develop more and more in-house to chase 4) rather than just distribute what the FLOSS community provides, putting paid man-hours on a mature product is no longer a good way to spend engineering budget.

By cheaply tying up competitors' resources, Kubuntu has hindered KDE's overall growth via other distributions and balkanized the KDE community. It can be argued that Kubuntu has brought users and contributors to KDE as part of the rapid initial growth of Ubuntu, and Kubuntu has been a success in focussing their developers on improving KDE, but this came at the price of cementing KDE in the role of a second class environment in the eyes of everyone who came to Linux via Ubuntu. I suspect that the GNOME community, which previously surfed the wave of Ubuntu's growth, will feel the pinch of necessity as Canonical moves towards its endgame, and having already been displaced as the default desktop for an inhouse development, will move further towards just being an anonymous organ donor to Unity and subsequent productisable UIs.

Why am I writing this? I don't want to be so crass as to just say 'come to my project instead'. I'd like to take this opportunity to suggest that you should have no illusions about what your community Linux distribution means to the businesses that sponsor it.

For openSUSE, it's some engineering contribution to and testing of SUSE enterprise products' codebase, and supporting the enterprise brand via a halo effect from the community brand. In setting up the openSUSE project, SUSE has been militant in giving the community complete control of the project and the distribution that comes out of it. Call it an insurance policy or a lifeboat, but by opening and freeing all the tools that create openSUSE (as well as the source code), we assure that the results of 20 years of work are indefinitely available. SUSE is secure enough in its business and believes strongly enough in free software to do this with the rootstock of its enterprise products, because the modular, federated Open Build Service allows SUSE to derive enterprise products from openSUSE without having to steer it.

Last weekend was FOSDEM and it was a blast! Camila's first and I get that she didn't look forward to it that much - we had some trouble on the way there. As I'm now just on the way to the airport to pick her up (she had a meet-up with some KolabSys people) I dunno if she changed her mind but I bet she did. If only because she got some Brazilian beans from Izabel Valverde ;-)

For me it was the usual - there was little visiting of talks for me. Seriously, 200 hours of talks in 2 days? Attempting to visit the interesting ones just leads to frustration so I've given up on that. There are just too many people to talk to, too much beer to drink and sell and little catch-ups to have. FOSDEM needs to become a week-long event. Seriously.

A cool highlight of FOSDEM was of course the release of Lydia's awesome Open Advice project. It's a book for people who want to participate and make a difference in Free Software, explaining our culture and drawing upon some bright minds for real-world experiences. It is quite a read - I only got as far as the introduction by ex-FSFE Dude Georg Greve and some first paragraphs of a few chapters. But it's worth it if what I've read is any indication. Of course, in true Free fashion, it's open and even ready to edit and improve if you want!

There was a lot of fun around the openSUSE crowd as usual. The crew did a great job selling t-shirts, hats, beer and other stuff all for the benefit of FOSDEM (we donated the proceeds of the sales as usual). The awesome 'Old Toad' beer was as popular as ever - it is indeed a great beer and a good way to keep the fun alive. The Greek(o)s really drove this part as they must've drunk at least half our supply ;-)

Oh and after being pressed Frank promised that he'll ensure ownCloud has a good booth next year. So, ownCloudies (can't think of a better name atm) - you guys & girls really have to take that dive in 2013!!! Don't let Frank pull it alone. Not that His Baldiness can't do that, it's just that he'd look lonely. We can't have that.

And at night the usual great dinners - Thai food one night, Japanese Tepan Yaki or something (fiery, dang) another. Finishing it off properly with a few beers.

By the way, I've set up the LinuxTag wiki page for the openSUSE gang, sign up!

hugs,
Jos

Sometimes the decision of how a program should behave is not right or wrong technically but based on the user expectation.

In Okular we are asking ourselves what should happen when you have two lines with the following text

This is an ex-
ample

and copy it. Should it return "This is an ex-\nample" or "This is an ex-ample" or "This is an example"?

Head over to the KDE forums and vote!

At the end of a long day here are some photos from KDE at FOSDEM 2012. Pradeepto says "3.24 AM here, am in office, those pictures made my day/night/whatever itis now".

KDE Love as Claudia sells t-shirts

Paul demos KDE Software on every form factor: mobile, tablet, desktop, Windows, cloud and server.

Corridor chat with Frank

Cross-Desktop room group photo (missing lots of people who were at other talks)

KDE dinner - had to turn away quite a lot of people who were too late to get a seat. I may be concussed but I'm still able to herd KDE cats better than anyone else did.

A business man pose from Paul

Lydia Launches the Open Advice book on which I am a contributing author

FOSDEM reminded me why I love KDE, great people and friends working on great technology.

There appears to be some confusion regarding the meaning of yesterday’s announcement that Kubuntu 11.10 is going to be the last release Canonical is offering commercial support for.

For those who have not yet read about it, let me quickly recap the situation. Up until now Kubuntu was a Canonical supported flavor of Ubuntu. This essentially means that you can buy a support contract from Canonical to help you with your Kubuntu infrastructure. Every once in a while Canonical would stamp ‘LTS’ on a Kubuntu release to indicate that they would support this release for 3 or 5 of years to come (delivering security and major bug fixes primarily). The 11.10 release is the last release for which Canonical offers these services. As a direct consequence Jonathan Riddell, a good friend of mine and fearless leader of Kubuntu, will work on other technology during work hours.

You might have noticed that I was writing a lot about Canonical just now, and the reason for this is that the change mostly is about Canonical and not Kubuntu.
Kubuntu is and always has been a mostly community driven project. To give you an idea what mostly means in this case: out of the 25 people who notably contributed in the past year, 1 person was employed by Canonical to do so (i.e. 4% of general Kubuntu work was financed by Canonical). Please do not get me wrong though. Jonathan is a great developer and does a considerable amount of work, particularly in those areas where the community currently lacks motivation, hence some workflow revision is in order to make the ‘new’ Kubuntu equally efficient.

So what changes for real?

• No commercial support from Canonical for future releases.
• Jonathan Riddell will work on non-Kubuntu stuff during work hours.
• Alignment of Kubuntu with other siblings like Edubuntu, Lubuntu and Xubuntu.
  For those who care: on a technical level this means that a considerable amount of Kubuntu maintained software will be moved from the main to the universe archive.
• Probably some workflow changes that are yet to be discussed.

Is this bad?
It probably is if you wanted to adopt Kubuntu in your company and were counting on a Canonical support contract. However this is probably more of Canonical’s loss than your’s. As noted earlier there is a pool of more than 25 people one could employ directly to get the same result, perhaps even better. It is certainly sad that Jonathan will not be able to continue getting payed for working on his baby though.

Is this good?
Moving to universe bares a great deal of opportunities for Kubuntu. Primarily it gives the community yet bigger control over what the distribution looks like as we do not need to get software approved to be worthy of Canonical’s support. At the same time it also reduces the policy overhead (main inclusion for those who have heared of it). The detanglement allows us to move even closer to KDE without having to worry about conflicting interests, as what is good for KDE is not necessarily what is good for Canonical.
All in all I expect Kubuntu to become more agile and continue to regularly deliver an easy to use Linux distribution featuring the latest and greatest KDE software.

There is an occasional and not very amusing urban myth that Kubuntu is a stepchild of Ubuntu based on the idea that Canonical is not giving the same amount of care to Kubuntu as other flavors of Ubuntu. It’s not true because Canonical has given much more care to Kubuntu than many other flavours. But all those who believe in this myth may now rejoice as the stepchild is moving out and going to share a flat with its much loved siblings \o/

&amp;lt;p&amp;gt;&amp;amp;lt;a href="http://www.formspring.me/deepsky28"&amp;amp;gt;http://www.formspring.me/deepsky28&amp;amp;lt;/a&amp;amp;gt;&amp;lt;/p&amp;gt;