Bobulate

Home [ade] cookies

0 is ambiguous

October 21st, 2010

Since Qt 4.7, the QString class has gained a constructor. It used to have QString(const char *), QString(const QChar *, int) and a bunch of others. Now it has QString(const QChar *) as well. This constructor works with 0-terminated QChar sequences, like char * does. A useful addition, except that it makes certain other code constructions newly ambiguous.

Consider code that uses 0 as a pointer; this is now ambiguous because that might be a const char * or a const QChar *. There’s code in KDE where 0 is used in places for QStrings, and this used to work, like class A { public: A() : a(0) {} ; QString a; } ; You don’t always see it that obviously; for instance, there’s arrays of structs with a terminating null struct — a real C-ism. It becomes ambiguous with a QString member: struct { int, int, QString } foo[] = { …, { 0,0,0 } } . For some reason we hit these more clearly in Solaris (OpenIndiana, that is), and we’ve started to fix them. The simple fix is to use QString() to mean an empty string (QString::null? damn I’m oldschool).

One more reason to look forward to nullptr (didn’t mpyne or MarcM mention that recently?).

Link Dump / N900

October 20th, 2010

Lots of links and interesting tidbits come my way. Most are KDE related, sometimes computer science. I thought I’d clear up my backlog of items for once.

Some folks have asked me what I think of the Nokia N900. Blog posts like that by Dinesh or Ben prodded me, but what worked best was spotting an N900 in the wild. See, I know KDE and Qt developers have this device. Nokia kindly ensures that we have access. But does it get used by anyone else? The Register (a UK IT publication I like to read) is ferociously anti-Nokia, so I rarely read any good news. Combine that with decidedly poor availability of the N900 in the Netherlands — none of the telco’s carried it — and it’s felt rather lonely with one. The device I’m using is one of those handed out at the Maemo summit in Amsterdam. I didn’t attend, but someone who did passed the device on to me.

Now, I’m not necessarily a smartphone user. I tend to move from home to office by train, don’t have lots of "road warrior" in me, and I can stand being offline for, say, an hour while moving between one location and another. I love the Nokia 6300 form factor. Small, sturdy, makes phone calls and is a nice mp3 player as well. In a pinch it can even load up buienradar.nl or another website. That said, I may as well start with what I perceive to be the downsides of the device — which should be no surprise here. Size and battery life. The thing is heavy, which makes longer phone calls a drag. it lasts two, maybe three days on a charge if it sees little use and doesn’t hook up to a wifi hotspot — the latter is a real drain. Compare to the week I get with the 6300 or three weeks with a 2310 (again, I’m not a heavy phone user, so standby time is actually most important to me).

Software-wise there are a few annoyances (setting a ringtone is much harder than it needs to be) but I really appreciate the openness of the platform. Debian packages? Pre-built VM for development? SSH out of the box? An XTerm? Ticks all the boxes for me. IRC over SSH to irssi running on a server is just what I always do — hasn’t anyone built Quassel for this device yet? Software updates are a little slow, but I appreciate it that it also flags updates for third-party apps. I have an early release of KDEPIM-Mobile installed, which needs an update, and there’s Marble too.

The keyboard is nice as long as you’re not using emacs. All in all I’d say the N900 is the smallest laptop I’ve ever owned — and it makes calls, too.

Coming out for Pink

October 15th, 2010

Thanks to lots of comments on my previous blog post about color schemes, I’ve made things Moar Pink. If you’re not yet ready to destroy that color, here’s the start of the (pink) art.

Icons have been pinkified — where you can see that some are resistant like the battery and SELinux — a little more harmony has been created between the colors. Notice that the icons do become a little monochrome like this (or is it bichrome?) because the color nuances are smashed flat with a pink hammer. I’ve also added a custom Konqueror stylesheet to keep things pink when visited websites don’t have anything set. There’s still some uncomfortable blue in links (also in Blogilo) and message counts (KMail). And of course KMail still has the blue swoosh while switching folders — I can’t see that that is configurable anywhere.

Olaf points out that there was work done on system-color-settings compatible color schemes for some applications. That’s definitely something to keep in mind.

Now, this exercise isn’t just about being horrifyingly pink. I came up with a few usage scenarios where easy-to-do global appearance updates are interesting:

  • Distribution branding. I know, most ditro’s do this by hand already. But having a good checklist of where to look and what to modify would make it easier on them. Plus, you could then publish, say, the Fedora look and make it easy to install onto any KDE desktop installation.
  • "Hey, your desktop is cool, can I have that?"
  • Quick user switching.
  • Activity customization.
  • Environment-aware computing. When you move your laptop outside, the color scheme changes and everything becomes higher-contrast and more sharply defined. Like the n900’s keyboard lights up in the dark, but now for wallpapers and color schemes.
  • Pretending that your video cable is damaged so that one color drops out.

I so need to start a TechBase article on colorizing and global appearance customization.

It’s Colorized

October 15th, 2010

Alas, Frederik’s master plan has not seen a whole lot of progress. I wanted to go down that path a little as well — that has everything to do with sitting next to Lydia for a day of not-always-exciting meetings. She challenged me to make my desktop as horrifyingly pink as possible. That would be useful if I had to plug in my laptop to give a presentation: the color scheme would shock everyone awake.

So, clear challenge. Now how do you make your desktop as pink as possible. KDE is terrifically configurable, but that doesn’t mean it’s simple to configure it. Here are my notes in KDE 4.4.5 (Fedora 13). To some extent it’s intended to show where additional polishing might be applied to make KDE more consistent. And overall it will show that for an overall appearance manager we need something more — or something else — than we have right now.

Wallpaper: right click the background of the desktop, pick Desktop Activity Settings. That’s the only configuration item there. It opens a Desktop Settings – Plasma Workspace dialog. Pick Wallpaper. Click Get New Wallpapers. There’s a search bar in the resulting dialog. I tried searching for unicorns first, but the right search term is "Sugarcoma Bunny". Click install and then select that wallpaper, click OK. The dialog goes away and the first step (over one million pixels) in pinkness has been made.

Colors: start System Settings, pick the Appearance module. The title now changes to Style (because that’s the selected item on the left). Go down one item, to Colors. Pick the tab Scheme. Click Get New Schemes. (This Hot New Stuff is really darn useful). Once again there’s a search bar, use "pink". You could pick either Ruphy’s "So pink that it hurts my teeth" or Fregl’s "Fluffy." I think the "hurts my teeth" theme is a little better, but it still needs a little tweaking.

This is where futzing with color schemes gets a little complicated. There is a tremendous number of settings to deal with, and I’m not really sure what all of them do. (Here’s a bit of history related to color display in the scheme list).

Switch to the Colors tab (in the Colors item). From the drop-down box, select Window. Click the button next to Normal Background. Pick a better color. I used #FBBCFF. OK the color dialog, then click apply. For reference, we’re in System Settings – Appearance – Colors – Colors – Window. Five selection levels deep. You might want to Save Scheme to keep these custom settings around, too.

Icons: there doesn’t seem to be a very pink icon set. I skipped this bit for now.

Windows: if you stick with the Oxygen window decoration, there are some additional colors to set. The window shadows are colored as well, and in a pink desktop, you should have pink shadows. I changed the windowdrop-down shadow to use #FBBCFF; the active window glow uses #FF37C7 and outer color #FFC0FF.

Other appearance items: to be truly pervasively pink, we would need a pink splash screen and emoticon set as well. Switch to the Splash Screen item. Click Get New Themes. For some reason this dialog is different from the ones used earlier. It’s titled Get Hot New Stuff and labeled internally with System Settings Add-On Installer. There’s probably some string not being passed to a constructor there to make the labels more meaningful. Note to self: check same dialogs in KDE 4.5.2, then file a bug report if necessary. Searching for "pink", "bunny" and "fluffy" didn’t yield anything, so we’ll have to leave the splash for now; same for emoticons.

[[ By now the desktop is pretty darn pink. But let’s start two applications to see how far the colors go. ]]

Konsole: start Konsole, go to Settings -> Edit Current Profile. Select the Appearance tab. Notice the extremely cool way color schemes slide in, but there’s no quick way to import a color scheme. The New button gives you basically a bunch of color selectors; there’s no Hot New Stuff here, nor a quick way to import settings. It’s not clear to me how to export the settings either — I’ll file a wishlist item there.

It’s straightforward to set up light and dark pink (or purple) as foreground and background colors, but the other available colors are a bit problematic. I use irssi in screen a lot, and the blue and yellow that it uses was a bit jarring. Since I don’t use any other colors in konsole, I just picked a bunch of settings to colorize things in a nice way for my specific use. KDE 4.5 note: seems that the menus have changed a little, and you need to go through the settings dialog.

Kate: the other application I use a lot is Kate, and it uses its own color schemes. Go to Settings->Configure Kate and then under Editor Component / Fonts & Colors you can mess with the colors. Again, no clear way to export a scheme or use Hot New Stuff to get new ones. Here again there’s a huge number of colors to set up (which might explain why there’s only two color schemes by default). I took a quick route to setting up a pink scheme and changed only the four text background colors: normal, selected, current and bookmark = ( #FFBBFD, #FF7DCB, #F8E0F4, #FF39F9). The current line is perhaps a bit greyish, but that does make it easy to spot. I haven’t touched any of the syntax highlighting.

Other UI elements: text input and some other backgrounds still aren’t pinkish, but white. I may have missed something in the color scheme control module. Similarly alternating colors in lists aren’t pink and pink, but still while and blueish.

Plasma Theme: many Plasma themes are dark-ish. For this color scheme, you really want the desktop background to shine through. I tried the Glassified theme but struggled to get it to be transparent. I suspect XRender problems on this laptop. In any case, to change this: System Settings -> Appearance -> Style. Select tab "Workspace". Here you can pick themes. The obvious theme would be the original Fluffy Bunny, but it has gone missing again. I ended up with the Atelier theme — click Get New Themes, then search for that name. Install, apply, done.

After all this configuration, the desktop looks like the screenshot here. There’s still some disconcerting bits of white there — the open documents list in Kate in particular. But let’s take a step back and summarize where changes needed to be made to achieve the goal of "make it pink".

Wallpaper, system color scheme, icon set, emoticons, window deco settings and colors, konsole color scheme, kate color scheme, plasma theme. Less than half of these support Hot New Stuff. They are in several different locations, different KCM’s, require manual configuration in applications.

Now suppose that one of my new friends from Ljubljana were to come over and ask if they can make their desktop look like mine (o horrors!). It strikes me that it would be useful to have a new collection (or meta-HNS) setting that is called "Overall Appearance" or something like that that would apply a theme, wallpaper, color scheme, etc. etc. in one go — including Konsole and Kate’s default schemes. Then the idea of "share my desktop look" can come to fruition. Or have I just missed something obvious to do that already?

4.5.2 on OSOL and OI for real

October 9th, 2010

I recently mentioned that Plasma Desktop and KDE applications 4.5.2 was building. It’s done now and the repository has been put up on solaris.bionicmutton.org. This uses a Linux port of pkg.depotd, rather crudely hacked together by myself. That should ease up some package downloading issues.

So, users of KDE4 on OpenSolaris and OpenIndiana, it’s time to update. Remember to file bugs at bugs.kde.org with the OS set to Solaris, and drop by #kde4-solaris on Freenode.

PS. There was an article up on a Dutch website with “5 best things Oracle did for Open Source” and one of them was “Kill OpenSolaris”. Hm. PPS. Konqueror does crash on Flash games sites, somewhere in kjs. On the plus side, DrKonqui now produces nice stack traces with dbx.

Plasma Desktop and KDE Applications 4.5.2 on OpenSolaris

October 7th, 2010

Now that the october updates for all the software shipped by the KDE community — that is, Plasma Desktop and the applications — has been released, it’s time to bump versions, etc. and kick off a bunch of builds. This follows the tried-and-true approach of replacing the version number (i.e. it now reads ‘%define kde_src_ver 4.5.2’), running make, waiting for the pkgbuild tool to report failures, fix, rinse, repeat. Usually the things we fix are just new or removed files. In this release, for instance, KHelpCenter has a new documentationnotfound/ directory and some files there.

During this period, our so-called stable (-450) repository is not stable. Fixes to the packages get pushed as and when they are found. Once the builds are stable (i.e. a few of us have managed to get everything to build), then Hajma kicks off a clean build on our build server, waits about six hours for that to finish, then uploads the whole darn thing to the actual binary IPS package server. And then people can update as they like.

I won’t vouch for the stability of updating. We usually take the ‘pkg uninstall -r hier-kde4-deps ; pkg install KDEconsolidation’ route, which is also known as ‘log into JDS, rip out all of KDE, install a new one’. One day we hope to look at that more closely.

Our IPS package server runs in OpenSolaris in a VirtualBox on an OpenSuSE machine. There’s issues with networking in that setup; I’m a little hazy on the details but it means that downloads often crap out. There’s 1226 TCP connections in FIN_WAIT2 state right now. That’s also a sign that people are actually using Plasma desktop and KDE applications on OpenSolaris and OpenIndiana. Apparently folks are overrunning the OI IRC channel asking what’s wrong with our package server — ask in #kde4-solaris, folks.

Since the server setup has been giving us some problems, I cloned the pkg source code repository from Oracle and now have a copy available in our Mercurial repository. The purpose of the clone is to hammer the system into shape so it can run on Linux. It seems Onno M. has done something similar, to the point of producing packages of same via the OpenSuSE build service. In any case, the idea is to drop the VM and additional OS from the equation and make pkg.depotd serve packages directly from Linux. This needs some testing, but I imagine we will be switching over for serving up 4.5.2.

Finally Michael will be able to install KDE software without a week’s worth of disconnects.

[[ While I typed this story, I built the KDEsdk, KDEtoys and KDEutils packages; changes here reflect the renaming of kdesvn-build to kdesrc-build. KDEtoys has no changes, and KDEutils incorporated one of our patches from 4.5.1, so there was a patch to remove. ]]

Two last tidbits: I managed to utterly break my OSOL VBox, so I now do builds on OpenIndiana virtually and on physical hardware running OSOL. Packages are produced in OSOL b.134 and work unmodified on OI b.147 and later. The -460 repository is in the throes of a massive cleanup since the range of supported platforms has shrunk recently: it’s either Solaris10 (untested except by the hardiest of souls) or OSOL b.134 or OpenIndiana, pkgtool 1.3.102 or later. That means cleaning up tons of cruft and special-cases. Once that’s done, there looks to be a bump to Boost (to 1.44) and some Qt mucking about.

Qt 4.7.0 on OpenSolaris

September 29th, 2010

Even though OpenSolaris is no more, and I should be writing about “Qt 4.7.0 on OpenIndiana” instead (OpenIndiana is a distribution made by the people of the Illumos Project, which is intended as a Free Software community development effort based on the existing OpenSolaris codebase), I’m going to continue saying “OpenSolaris” for now. That’s partly because I haven’t actually tried any of the newer versions available through OpenIndiana — I’m still stuck on build nv134, the last one to come out officially from the maw — belly? — of the beast. Hajma says OI is fine with our existing KDE packages.
Stuff carries on in the KDE4-OpenSolaris repositories. The active repo is -460 which advances towards the eventual release of KDE 4.6.0. That Mercurial repo now has two branches. The default branch is Qt 4.6.3-based, with the KDE 4.5.68 snapshot. There’s a separate branch (hg up qt-4.7.0) in which I’ve been pushing the new Qt 4.7.0 release. In that branch:

  • Grantlee 0.1.6, prompted by Steve.
  • Qt 4.7.0, obviously.
  • Qt 4.7.0 examples and demos. This is new for 4.7.0, because previously we didn’t have any packages building the examples. After a great deal of digging around, it turned out that qglobal.h was overly pessimistic about the compiler, which in turn caused compile errors in the examples, which is why we had them switched off. Install FOSSqt-examples.
  • Full(er) QtConcurrent support, related to the previous fix. This is one thing that I really enjoy in packaging (or at least, it dulls the pain): something doesn’t package right, so I need to figure out why, so I read lots of code and documentation and in the blink of an eye I’ve spent half a day writing Qt Concurrent test programs. It’s good practice as a programmer.
  • QML. At least the QML minesweeper demo runs, I haven’t tried anything else.
  • hgview. This is a Mercurial log viewer, written in PyQt. I’ve added it because it is a useful tool and because it demonstrates the power of PyQt reasonably well. To run it, you’ll need a newer Mercurial than the one bundled with OSOL, so I banged together a Mercurial 1.6 package as well.
  • KDEPIM 4.5.68. That’s Kontact, updated with all the previous, so you now have KNotes with fancy templates and the mobile version of all the Kontact apps, too. This snapshot brings Akonadi into the mix, about which I’ll write some other time.
  • Qt Creator. I grabbed 2.0.1, the latest, which is just as well because I see there’s a security warning about 2.0.0. I still need to figure out one more RPATH fix for it to go really well.
  • Lots of crashes

For grantlee, I ran the test suite and got 34 seconds on the benchmark (test 9). No idea if that’s good or bad. In general Qt apps seem a little sluggish to me, which means that we’ll have to look at the locking performance again and check out how debug output is handled.

The “lots of crashes” thing is worrying though. eAlex79 reported on IRC that he was having trouble with gcc-based builds of Qt 4.7.0 on OSOL as well, so it might be something more fundamental. He says it’s got to do with threading and glib, which fills me with dread. I just know the symptoms for now: Konqueror crashes. The Qt browser demo crashes while loading the default page. Blogilo crashes when starting the settings page. That kind of stuff, and it will take us some time to sort out what’s what. As always, this reflects more on the unusual platform and compiler and flags choices than anything else.

On the other hand, the important bits (konsole and kate) do work.

Bits of Artwork

September 28th, 2010

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.

Pirates!

September 22nd, 2010

Even if Talk Like a Pirate Day (developer idea: implement tlapd, a proxy LDAP server that mangles replies to be more piratey or which intercepts http requests) passed quiety for me this year, I’m still partial to the (ahem) romantic ideals of the pirate. So when Something Positive pointed to a Steve Jackson floortop game Evil Stevie’s Pirate Game which combines Pirates, Lego ships and large group gaming. Whee!

Recent kitchen projects have included a totally failed meringue pie and chocolate ice cream — neither of which the kids liked, but which nonetheless disappeared so quickly no photos are available. And I think I’m getting the hang of white bread now, too. Need to work on getting the crust just right.

GUUG’s Linux Kongress is on right now, if you’re near Nuremberg. NLUUG’s Fall Conference, with Security and Privacy as topics, is coming up at the beginning of November.

Lastly, I’m happy to hear tales of people (like Frederik) Joining the Game. Coincidence that he describes what KDE e.V. does the same day I write a rather dry item on the same topic? Mystery! At least he can spell “e.V.” properly, which I couldn’t.

VirtualBox in use

September 21st, 2010

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.