Bobulate

Ivan has been on a tear with his “stripes” series of wallpapers. They remind me of crinkly potato chips, too. In some random browsing I ended up on the Blue Mint, with 15 more cool wallpapers. The latter page shows that “K Desktop Environment” is a rather persistent term. Like mildew, it’s hard to get rid of.
It’d be nice to have a KDE4-OpenSolaris wallpaper, something nice for the 4.6.0 release when it rolls around (4.6.0 of Plasma Desktop plus the KDE Platform 4.6.0 and the KDE Applications Collection — which even on OpenSolaris is more than just what’s found in the core KDE SVN modules). Of course, the OpenSolaris term is one that needs eradication as well, now that Oracle has definitely killed it (last week in Linux Journal, but really old news to anyone watching the official face of OSOL). Anyway, Ivan, here’s a chance at fame in an insanely niche environment.
I’ve been looking through things on kde-look.org a bit, trying to find one or two nice wallpapers and themes to put into the default KDE consolidation, if only to give a teensy bit more spice to the OSOL packages. It’s really hard to choose — because of the sheer volume of material on there. Themes as well: possibly I just don’t understand what “Beryl Emeral Theme” or “Aurorae Theme” means; I assume they’re not applicable in a stock KDE installation. That doesn’t leave much to choose from, anyway.
Of course, for your needs in art, Lukas’s work is to be recommended. The advances made over in Krita are one reason I really should get down to updating the Krita packagers, so’s I can see for myself what’s going on.

I’ve been using VirtualBox (the Open Source Edition) a fair bit recently. My desktop machine fairly hefty: an i7 860, 4 core HT and 8GB RAM. I leave it running Kubuntu and VirtualBox on top of that. Then I have a workable, if by now slightly dated, desktop and all the KDE applications that I need. In VirtualBox I run the machines I’m interested in for development. That’s an OpenSolaris instance and a FreeBSD one (just resurrecting that interest now and I haven’t even gotten around to checking out area51 yet). I also keep a Fedora and a Kubuntu VBox around for comparison purposes. So plenty of ways of using up the CPU power. Next to the desktop machine (also under my desk) is my spare box, which is an amd64 6250e, dual core, 6GB RAM.

The guest additions make the applications running in the VBox interact with the host machine without mouse or keyboard grabs; then the KDE application running inside GNOME in OpenSolaris is very nearly just another window on my desktop.

I use the OpenSolaris VBox to compile KDE packages. In a very simple test — building QScintilla — I find that the virtual machine outperforms the physical machine sitting next to it. Compile goes from 3 minutes to two, running the same software stack. I’m very much surprised, because the clock speed difference isn’t that great and I’d expect there to be some non-trivial virtualization overhead.

The fact I can share a folder between the host OS and the VBoxes is quite useful, since it means I only need a single checkout of KDE SVN. I can patch from inside each virtual machine, experiment and eventually push things back out. FreeBSD doesn’t support directly shared folders, but I can still network-mount everything. This then means that it’s become much easier for me to test changes across OSsen. No longer will I horribly break Linux builds with a little Solaris patch (er .. I don’t think I’ve done that before, or maybe I just don’t remember).

What would be really keen is appliances: a VBox image that is an instant FreeBSD / OpenSolaris / OpenSUSE development environment. That would work for FreeBSD and OpenSUSE, I think, but the license terms of Sun Studio presumably preclude redistribution. That’s unfortunate, because it makes it harder to get development done (although, come to think of it, a system which has everything installed except for the one tarball of Studio might not be encumbered). It would serve a different purpose than the SuSE build service which does builds for many many different OSsen — desktop development in a separate environment.

One thing I intend to add to the stable is a Linux VBox with Sun Studio for Linux installed on it, so I can try some stuff related to the compiler. I recently finished up packages for KDE-PIM and there were many patches needed; there’s some template magic that the Sun compiler just doesn’t understand, leading to dozens of KCalCore::Incidence::Ptr() cast constructors being patched into code that’s otherwise a model of tidyness. Only once I’ve got something sensible set up will it be possible to apply power machinery (in casu KDAB Marc, C++ template guru) to the problem. In any case, we have packages for all the parts tagged as KDE 4.5.68 (snapshot from trunk) for OSOL except for bindings, edu, kmix and plasma-addons. The problem in kde-edu is actually a bug with Boost and Sun Studio, so that’s going to take a little more work to fix.

For years — perhaps since KDE e.V. was formed — there has been a mailing list kde-ev-vorstand. A perfectly sensible name if you happen to speak German and know something about eingetragene Vereine. For the rest of the world, perhaps not so much. The list has now been renamed to kde-ev-board. Unfortunately, during the changeover, mail sent to one list or the other has gotten lost. So if you tried to communicate with the board of KDE e.V. on the weekend or monday or tuesday morning, september 18-21 2010, your mail may have silently vanished. Please be extra alert for replies and don’t be shy to re-send.

So, what’s KDE e.V. you might ask? It is the non-profit association which was set up to support KDE development. An association is a convenient legal form in Germany (and elsewhere). It has members — the membership of KDE e.V. are those people who want to help the association achieve its goals. It’s a little like a tennis club: the members want to be able to play tennis and so set up a club that ensures that there’s infrastructure so that everyone can play. The association doesn’t play tennis itself, even when the members do; its purpose is there to make things possible. KDE e.V. makes it possible to channel money into developer sprints and helps organize the yearly Akademy conference — this year that will be a Desktop Summit once again in cooperation with the GNOME Foundation. You can find out what the association has been doing in the Quarterly Reports. The latest one is for 2010Q2; Q3 is just about to close so we’ll be looking for volunteers to help write it up and we’ll be soliciting items from the various working groups and teams in the KDE community.

The board list is the right place to ask about travel reimbursements (ask before you book!) or to suggest sprint topics, offer hardware support and instigate new projects which have funding requirements. Just remember that kde-ev-board@ is now the best address to use (although -ev-vorstand continues to function).

A bit of a belated thanks to Albert and Frederik for providing information about updates in dependencies needed for KDE4 — even trunk things as it works towards the 4.6.0 release of Plasma Desktop and the KDE applications.That kind of "heads up!" makes it much easier to keep the whole software stack up-to-date. Shortly after reading their blog entries, I updated (attica) or added (ebook-tools) specfiles to the specfile repository for 4.6.0. ebook-tools needed libzip, which as far as I could tell wasn’t available yet either (caveat: Oracle basically stopped updating all the package repositories and the SourceJuicer efforts, so the past four months have seen total stagnation on the official front for software packages, so it’s possible that someone else has already packaged the stuff elsewhere). Anyway, it’s appreciated, and those packages will affect the next package release on OpenSolaris.

We’ve just bumped the build to KDE 4.5.68 snapshot (in the -460 repository; the -450 one remains at 4.5.1). The builds haven’t finished shaking out yet, though. We’ve rolled a Phonon 4.4.3 tarball (apropos tarballs, I really enjoy reading Valorie Zimmerman’s blog for a reminder of what it’s like to start out in developerland) from git for internal use. QScintilla and the Python bindings for it have been added. Those aren’t directly useful in KDE, but they’re nice to have. I have tried a bunch more PyQt applications and they all seem to work ok, so I’m declaring those bindings "good enough."

Bug reports and patches can go into KDE’s bugzilla bugs.kde.org, with the OS set to Solaris.

Sun Studio has been renamed Solaris Studio, to reflect its target OS — or maybe just to say that Sun has been consumed by the boa constrictor that is Oracle. Of course, Studio works on Linux as well, so the name is now a misnomer in other ways.

Solaris Studio 12.2 is out, a minor upgrade over 12.1. The KDE4 on OpenSolaris project is one of the biggest public consumers of the C++ compiler — I suppose VirtualBox is as well, although that project never led to much C++ technology being updated in Solaris. Pavel was active during the beta phase of this product, and was the first person to report a regression in the C++ compiler: the -Y flag (in particular, -YP, which is documented to prepend directories to the linker’s search path) changed behavior. Now, historically the -YP flag has been different between the C and C++ compilers (duh?), and code consolidation pushed the C behavior into C++.

Unfortunately, the documentation hasn’t been updated to reflect this change. Neither has the regression been fixed. In other words, a bug reported pretty much on day 1 of the beta, shipped unchanged three months later.

We (as in the KDE4 on OpenSolaris crew) are creative enough to adapt to this situation: instead of using -YP to prepend paths, we can set the whole search path (like we would in C) like so: -YP,/opt/kde4/lib:/usr/lib . There’s one big gotcha, though: the C++ runtime and standard libraries live in the compiler installation directory, which must be searched for them. So we end up with a situation like this: if it’s Studio 12.1, use -YP,/opt/kde4/lib (nothing else, since the compiler libraries and /usr/lib are searched already) and if it’s Studio 12.2, first find out where the compiler libraries are installed (typically, but not necessarily, /opt/solstudio12.2) and then use -YP,/opt/kde4/lib:/usr/lib:/opt/solstudio12.2/lib . And don’t forget to adjust for different architectures (x86 vs amd64 vs SPARC).

In short: Solaris Studio 12.2, don’t bother.

Of course, a compiler isn’t the most important thing for Oracle. That’s just enabling technology and I imagine that it just needs to be good enough to push their in-house code to production. ISVs apparently don’t contribute enough to the bottom line to give them the tools to use the OS as well.

Do you get this as well? A PDF delivered along with a message that you can use Adobe Acrobat Reader (r) to open that file?

PDF is a (relatively) open standard. It is an ISO standard (19005-1), for one thing. This also means that there are alternate implementations of the standard. And you might have good reasons to avoid the Adobe implementation. For instance the number of exploits against their implementation, or because it doesn’t run on your hardware / software platform. Most of the time I’m at a computer which is perfectly capable of dealing with PDF files through a Free (both as in speech and in beer) PDF reader, and the "download Reader" just strikes me as weird. I get these PDF files from travel agencies, hosting providers, financial advisors and local governments. I often reply asking them to update the text accompanying the file to say something like "You need a PDF reader to view this file. Get a free one or use something else." The PDF Readers (.org) site is a good place to point people and organizations. The site points out the available options and how to get a Free PDF reader.

The Free Software Foundation Europe (FSFE) has started a campaign to promote the use of Free PDF readers by local governments. The idea is to point out where your local government is pointing only to the proprietary software solution and to get them to adapt the text to offer more choice. There’s a contest involved, as well.

As far as the PDF readers site goes, it points to muPDF; that’s one I would personally avoid for semi-technical reasons: the code is terrible and utterly undocumented. Maybe the application works — but it’s not something that satisfies my code-readability test. Not one of the files has a license header, although the thing as a whole is licensed under the GPL version 3 or a commercial license.

Turning to the more popular — or rather, the recommended readers on Free Software operating systems — selections, there’s Okular and Evince. I use both of them fairly regularly — Evince is my fallback on OpenSolaris during those times that I’m compiling KDE. Following the links from PDF Readers to the two web pages for Okular and Evince shows a pretty big difference: the latter is focused on packages and contains a link to a how-to-compile page, while the former is all about building the software from scratch with a comment that there’s probably packages available. Neither of these strike me as a particularly good user experience. I wonder if there’s any feasible (technically and privacy-preserving) way to detect the OS so as to improve the download suggestions.

The past few months I’ve been a little quiet about KDE4 on OpenSolaris, but that’s not to say that nothing happens. Pavel Heimlich and Jan Hnatek have pushed the packages and dependencies forward. For instance, the 4.5.1 release of Plasma Desktop for OpenSolaris along with KDE Applications happened entirely because of their efforts. Pavel is now part of the kde-packagers group, so we should see a slight improvement in release timing — that is, KDE4 on OpenSolaris should release packages on release day alongside SuSE, Fedora, Ubuntu and PC-BSD.

The Korona distribution of OpenSolaris — that is OSOL plus a Plasma Desktop and KDE applications by default — is also a result of their work. There hasn’t been a recent update of it (not with 4.5.1 that I know of) but there will be, once the dust settles a little around OSOL.

Ah yes, the dust. Einsturtzende Betriebssystemen or something like that. Oracle has managed to collect epic amounts of ill-will from Sun fans, ex-Sun employees, Free Software enthusiasts, Open Source folks, software packagers and whoever else I’ve left out. Examples of annoyance and exasperation can be found on most of the OSOL forums. Here and here are two examples (mirrored from the OSOL forum site, though).

So, what’s up for us? Well, various dependencies are being updated — like testing Sun Studio 12.2, upcoming Qt 4.7 — for KDE 4.6 releases. The breadth of available software in our tree is increasing — see the inclusion of PyQt and QScintilla as of this week — and our coverage of KDE Applications including the office suite is getting better. I don’t think we have a full KOffice available yet, but it’ll get there eventually.

As always, our software development happens in the open and patches get pushed upstream as much as is feasible. Communications happens on #kde4-solaris on Freenode and on the kde-discuss@opensolaris.org mailing list. Join us. OSOL is still more popular than Plan 9, after all.

For the past month I’ve been honing my PyQt skills and greatly enjoyed it. I’ve been saying to people at conferences — for years already — that Python (or some other scripting language) is the Right Approach ™ to a great many end-user applications for its speed on development and ease of prototyping. Now I finally spent a month testing the truth of that statement.

However, all the work I did was on Linux systems, both Ubuntu and Fedora. Today I sat down to package PyQt for OpenSolaris. Riverbank Computing supports Solaris, to the extent that sip lets you do –platform solaris-cc, but there were a few gotcha’s along the way.

• The mkspecs parser in sip expands Windows-style percent-sign variables. This bumps into the Sun Studio flags which includes things like -library=no%CStd. It took me a long time to track that down, and then patch it out.
• Python lives in /usr while our Qt packages live in /opt/kde4 — this just causes packaging headaches and RPATH juggling, nothing spectacular.

But those little gotchas aside, packaging went smoothly. You can get the specfiles from the KDE 4.6.0 preparation repository. Packages are not yet available from our usual KDE4-on-OpenSolaris repositories, though. We might backport into the -450 specfile and package repository if there’s any enthusiasm for it.

One thing I’ve had some trouble with is finding code to test the bindings with. Somehow the examples that are bundled with the PyQt source distribution aren’t mentioned a lot on the web, so it took a while for me to find the obvious testing ground. But from there the whole QtDemo application runs except for the OpenGL parts: it seems I’m missing the bindings for that. So there’s still some polishing left to do with the dependencies, too.

So what’s the future hold now we have Python bindings for Qt in OpenSolaris? Well, the obvious thing to do would be to produce some small applications that help with OpenSolaris-specific features such as ZFS, dtrace or containers. That would give the KDE4-OpenSolaris desktop a boost as well.

Eugene reminds us about the KPresenter template contest. This made me go “hunh? did I miss something?” and yes indeed, there was an announcement on the dot some time ago.

Of course, my artistic skills are limited to Kolourpaint and LaTeX beamer hackery, so I’m not going to enter, but I’d encourage all those with actual talent to submit something. Spice up everyone’s presentations! Do bear in mind that the license on the resulting artwork needs to be liberal enough that it can be redistributed — consult the contest rules for details.

Q: How many guitarists does it take to change a lightbulb? A: Seven. One to change the lightbulb and six to stand around and go "yeah, I can do that."

That’s one of my favorite guitarist jokes — I play badly enough that I know most of the time I can’t do that, but hey. While the crux of the joke is that those saying they can, aren’t really up-to-snuff, I’ve been going "yeah, we can do that" a lot this week. Where "we" is various KDE applications or technologies. Perhaps they need a little more promo?

First there was this Ars Technica article on Terminator, to which the first comment was "yeah, Konsole can do that" (for years already, at that). And of course emacs, screen, and plenty of others. Makes me think of the way I use Konsole tabs, though. I tend to have one tab per thing-I’m-doing open, all in different directories; for programming projects I tend to have a source-editing and a compilation tab open. Editing means vi, unless I know I’m going to be at it all day, then there’s a Konsole tab from which I run Kate.

Oddly, I never use the window splitting feature; instead I rely on quick tab switching with alt-arrows and the activity indicators in the tabs themselves. I wonder if that’s something to add to the Konsole Userbase page, describing different ways of using Konsole efficiently? A collection of best practices, if you will, or suggested possible workflows with Konsole. That’s a useful addition to the handbook, I think.

Later — might have been via Glyn Moody’s endless twitter stream — I ran into Matt Zimmerman’s "Embracing the Web". Another "wait, what? we do that." To some extent, KDE’s project Silk aims to do just that. First-class web-apps on the desktop? Midgard does that, too with its deployment framework thingy (Henri may correct my pronounciation here). OwnCloud might fill the management gap, and GHNS (Get Hot New Stuff) brings things from the web to the desktop. The other direction, I’m not so sure of.

Maybe I’m misunderstanding what Matt is after, though. A bigger ecosystem of interoperable web applications (not just services) on a Free Software model (which implies license choices so that cooperation is fostered)? Sure, sign me up — mind that a combination of Quanta Plus (once ported to KDE4) and Silk is probably an awesome development platform and the pervasive support for HTML markup and Javascript in Plasma makes development of web-like applications locally a piece of cake.