Planet KDE

Aaron Seigo (aseigo): re: re: ramblings on 6 month cycles and Plasma

Fri, 09 May 2008 18:15:00 +0000

Toma took the time to reply to my blog entry on the six month cycle. He raised some ambiguities that I could probably clarify on a bit.

"First point is the very complex reasoning of the available time to do new features with a six months release cycle, which according to Aarons calculation means that half of the year we are in non-feature development. I don't understand that. "

As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:

Catching my breath a bit (let's call that a day or three, so not significant)

Responding to bug and wishlist reports; these tend to pick up right after a release and I like to spend the start of each cycle working on the x.1 release that is going to come out soon after the x.0 release. This is usually a significant time sink in the first couple weeks.

Surveying the landscape, revisiting the feature plan and figuring out exactly what will be done in this next cycle. This is impacted by the results of the last cycle as well as the ever evolving needs and desires for the product. This too takes time and prevents immediately diving in to new feature development

It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.

That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.

"I hear you scream that svn branches suck."

No arguments from me there ;)

"moving it to git repositories will give you a lot more overhead and merging that all back at intervals to KDE's svn will frustrate you as well."

Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.

"With git you usually merge a completed feature, making the diff too large for people to check on the mailinglists. At least I prefer ten smaller commits to review than one big one."

We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.

This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.

That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.

Ugh.

"After the period merge back, people using KDE's svn will make build fixes, etc. That will need to sync back to the git repository."

The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.

Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.

It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.

"I'm sorry, but if you want more hacking time, this is not the way to go in my opinion."

Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.

So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).

It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.

I also disagree with the general remark that a 'six month cycle' does not work for you in this project. How on earth is it possible to judge that, when the very first cycle is not even completed.

Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.

It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.

"I always learned from my mother (hi mam!) that I need to give it a try for a couple of times before deciding it does not work."

That's good advice from your mother. I'm sure she'd also tell you to learn from the mistakes and successes of others, to not repeat errors you've made in the past and to repeat your successes whenever possible. It's not like creation cycles are a new science.

It may be the first time KDE's tried to stick consistently to such a short cycle period, but it's not my first time around.

"The schedule is not set in stone and if you have reasons to change things, mail the release-team."

If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.

If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.

It's really hard to argue with the pace of KDE3 development.

So, I've no concrete solutions for the problems mentioned in Aarons blog,

Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)

I can understand that a new project requires a lot of setup for the infratructure, but when that's done things will get easier.

This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.

I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.

Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.

Johan Thelin: Kubuntu upgrade issues

Fri, 09 May 2008 17:15:00 +0000

I just used the Kubuntu upgrade tool to get the latest goodies from Hardy (wobbly windows here I come). However, this resulted in a strange looking system. I've found three symptoms:

#1 Klipper and friends start in windows in the top left corner before finding their way down to the kicker dock.

#2 Selecting "logout" or pressing ctrl-alt-backspace results in a blank screen, a hard reset is required to get back to business.

#3 Window decorations are messed up. For instance, Firefox gets some old-style KDE 2-ish look and RMB clicking on the title bar results in what looks like an unthemed menu. However, the desktop menu looks alright.

Desktop menu

Window menu

If anyone knows of a good way to resolve these issues, do let me know.

Tom Albers: re: ramblings on 6 month cycles and Plasma

Fri, 09 May 2008 16:42:06 +0000

After reading one of Aaron Seigo's lasts blogs, I feel the need to respond to it.

Cyrille Berger: Libre Graphics Meeting 2008 : Day 1

Fri, 09 May 2008 14:19:27 +0000

I arrived in Poland two days ago for the Libre Graphics Meeting 2008. It's an interesting conference where developers and users of graphics applications open source application meet and discuss.

The afternoon before the start of the conference, I had some time to do a little tour of the city:

The first talk on the first day was about Hugin, the panorama creation tool. Then there was one about Phatch, it's a batch processing tools which is very similar to Workflow, except that Phatch is dedicated to image manipulation, and was released.

Then the afternoon started by a talk by some Bruxelles designers who use open source software to do their job. Then there was a presentation about Font and Free Software: the tool to create fonts and how the best way to propagate your work.

Then there was the yearly gegl presentation which was much more technical than previous years, and concentrating on some internal of gegl, it's quiet interesting to see how different and similar are the core of Krita and gegl (the future core of the Gimp). Then I went to a presentation on the upcoming SVG 1.2, and new cool features like movies as background of a text.

Simon Hausmann (tronical): QtWebKit Development Update

Fri, 09 May 2008 13:44:01 +0000

As part of Qt 4.4 we have now made our very first release!

Shortly before the release we finished merging all our changes back to the Subversion trunk branch, where we are working directly now. We will continue to maintain and bugfix the code in the Qt 4.4.x release series, but we try to make the changes in trunk first and then backport changes as they fit.

Our current goal is to catch up with the architectural changes that happened in trunk and maintain the layout tests. Holger for example fixed the HTML Canvas after some internal API changes. Ariya started working on Netscape plugins for Windows and Tor Arne I heard is polishing a secret feature he’s been semi-secretly working on for a while now in not-so-secret trunk. I heard rumors that he’s going to secretly blog about the secret feature soon, so stay tuned.

Big props also to Marc and the guys at Collabora for landing the initial support for Netscape plugins for the X11 Qt and Gtk ports in WebKit trunk! Great job!

On the application side Urs Wolfer’s Google Summer of Code project for integrating QtWebKit into KDE has been accepted. Congrats Urs! Feel free to stop by in #webkit and bug us if you have questions

Jeremy Whiting (jpwhiting): KNewStuff with Goya

Fri, 09 May 2008 06:59:00 +0000

KHotNewstuff2 is going to be using Goya (once it moves out of kdereview and into kdeui on the 19th). So I thought publicly thank Raphael(ereslibre) and Kevin(ervin) for the great work on such a nice framework. I also wanted to let everyone see the new ui a bit and get some feedback.

This is 'khotnewstuff4 plasma-themes.knsrc' Currently the name, one line of description, author, and downloads are visible. I'll try to get rating shown, and a way to see more information about an entry. Also, notice the tooltip shows the complete description for each entry, it can be a bit big at times, not sure what the best way to show that would be, suggestions anyone?

Aaron Seigo (aseigo): ramblings on scripting

Thu, 08 May 2008 22:50:00 +0000

Today I may have stumbled upon why the people working on scripting for Plasma tend not to grok at first the point and purpose of ScriptEngines or any of the other mechanisms we have put in place for this:

In most cases, the API is defined by the host and the language binding is just a mapping of that API into the runtime environment the code will be run in.

With Plasma it's really the other way around. The language support (not necessarily bindings!) define the API while libplasma simply provides the canvas and management of the components. The language support defines the API, which could be a 1:1 mapping to the libplasma API but really doesn't need to be.

So the language people have been looking at Plasma asking, "So... how do I bind to this API?" and see ScriptEngine which is totally unsuited for that and scratching their head. Meanwhile, I get to explain for the Nth time (where N == number of languages people are working on ;), probably rather clumsily, that binding isn't the point of those classes. =)

Now that I finally understand this difference in perspective, perhaps I'll be able to articulate it more accurately in future.

Michael Pyne (mpyne): How infuriating

Thu, 08 May 2008 22:48:33 +0000

So Mario Kart Wii came out the other day. Given that every Mario Kart ever has been at least a great game, we picked it up immediately.

I’ve only played it in versus mode, both competitively and cooperatively with my wife, in racing and both battle modes, and I can definitely say that this is the least pleased I’ve been with a Mario Kart title ever. I’ve actually thrown the Wiimote (luckily a mattress was in the way) :(

My major gripes? Well, let’s list:

I’m actually not upset at the Wiimote-as-steering-wheel controls. They take getting used to and I don’t think they’re as precise as normal analog stick controls (I haven’t tried yet however) but as long as you recognize that about 350 degrees full left to full right is the complete range of motion you’ll adapt. Try to push more and you’ll simply confuse the game into steering the wrong way. This is something that could be improved by a stand or something that has a mechanical stop, at least you’d know when you hit the full range of motion. But again, you’ll at least get used to this.
The first major concern for me (and this is huge) is that they seem to have drastically changed power sliding. In Mario Kart 64 and Mario Kart Double Dash when you power slide you can kind of adjust the direction you slide. They seem to have significantly reduced this in Mario Kart Wii. This significantly ramps up the difficulty. Turn too early and you are pretty much guaranteed to go over an edge or run into the wall. Turn too late and you are pretty much guaranteed to go over an edge or run into a wall. Even if you don’t spill out you’re likely not going to be pointed in the right direction once the turn is done. Probably the safest bet is to never power slide (or leave it in Auto) but then you will slow down a lot through every turn.
Oh, and when you do run into a wall (and it will be frequent), you are practically guaranteed to lose 2-3 places each time. This would have been OK as a difficulty-enhancer had they not combined it with the penalty on power sliding.
One thing that I hoped they would fix at some point is the rubber-band logic that allows the CPU to basically completely annihilate you just for doing well in a race. Do too well and all of a sudden you will have disasters rained down upon you as if from on high (and then you will no longer be in the first half of the leaderboard). In previous Mario Karts it would go from happening randomly to conveniently happening on the second or third lap. Now it just seems to happen all the time instead.
Also cool is when you get hit by an item, and then get hit by a passing kart, and then get hit by another item (or two, you’re already hosed at this point). This happens in every Mario Kart game. But I think I’m already up to about half the number of times that it happened to me in Mario Kart 64 and Double Dash combined.

It’s not all bad news. I watched my wife play one-player and even though she made a lot of mistakes playing through her first time, she rather easily took first in all 4 races she played. Apparently my strategy will have to be trying to stay in 12th the whole time and hoping for good items. In addition the stages are inspired, both for racing and battle modes. I’m going to stay away from online play because that merely leads to me getting my face stepped on by someone I can’t so much as throw my soda at, but it’s nice that it has the option.

I’m going to go try playing it one-player and seeing if I can at least get some entertainment out of it in solo mode. It’s not like I can return it and get my money back. :-/

Aaron Seigo (aseigo): ramblings on 6 month cycles and Plasma

Thu, 08 May 2008 22:18:00 +0000

.. continuing my "I'm feeling ill, so am soaking in a bath" rambling thoughts:

Most of the plasmoids I personally wanted to work into 4.1 are getting punted to 4.2. WoC and a few other things sapped my time. Thankfully others have been working on plasmoids so we'll have some great new stuff there, I just wish I could've been able to play in Plasmoid land more (it strikes me as more fun than the infrastructure issues I deal with ;)

This is one aspect of the 6 month release cycle that I really don't like for Plasma: the punt rate increases. For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things. The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing. What this means is that we spend half the year in non-feature development; over 3 years time a 9 month cycle (with 3 months of stabilization) gives me 20 months of feature dev while 6 months gives me 18 months. That sounds similar enough, but the windows are tiny in the 6 month cycle, meaning more punting which in turn means that many features will be delivered in 12 months time to the user rather than 9.

It's also pretty obvious to me that for other projects, a 4 month cycle is probably even more useful than a 6 month cycle. Web based CMS projects come to mind as a good example where 4 month cycles would be the "Goldilocks" (aka "just right!") cycle.

In fact, I suspect 4 months might the Golidlocks number for Plasma: 2-3 months of features, 1-2 months of stabilization and exercising those new features via plugins. Unfortunately, 6 is not very evenly divisible by 4 ;) so this wouldn't work for the current release cycle.

I know that 6 months is all the craze right now, mostly IMHO for the wrong reasons like "marketing" or "downstream synchronization", but also partly for the right reasons such as quick cycles with a known clock rate for better iterative development patterns. I really dislike the marketing and downstream control issues because the former is complete BS (I want to smack someone with a marketing textbook every time I hear them opine on how six month cycles are better for promo) and the latter is misplaced priorities (accommodating downstream by hobbling upstream is remarkably short sighted). Really it comes down to finding a way to satisfy different sets of priorities.

I spent some time today thinking about what it would mean if mainline Plasma development moved to a git repository outside of KDE's svn, syncing at "known good revision points" back to svn except during KDE feature freeze periods so that we can have development windows that make sense for Plasma without breaking KDE's release cycles. Downstream gets what they want (a tarball every 6 months) and Goldilocks gets what she wants. We could stabilize the Plasma code base wheneverit would make sense for Plasma and downstream can simply get whatever the last "good point" was when a KDE release happens. This effectively decouples release schedules from development schedules, not unlike what the Linux kernel has managed to do.

I don't think this will work if our merge cycle is longer than 6 months however: testers and new developers will likely work against what is in svn and I don't want to require people to have to use another repository just to get at Plasma. So the merge cycle would have to be shorter than 6 months to keep the illusion of "development done in svn".

Perhaps there's another answer, but something needs to shift because one development window size does not fit all. At the same time the road of "hundreds of individual repositories and tarballs released whenever they want" is not really an option either as that'd just be integration hell for everyone.

So there you go: ramblings with no real concrete answers .. yet. =)

Aaron Seigo (aseigo): ramblings on 4.2

Thu, 08 May 2008 21:30:00 +0000

I'm not feeling very well today; been having a bit of a hard time sleeping the last few nights and now I think I know why: my stomach was churning most of the day up until mid-afternoon. Feeling better now, but it seems I was probably fighting off some sort of bug. I don't tend to get really ill, I just get dragged down when I catch something. Anyways .. not very exciting nor what you probably care to read about. ;) It did mean that I spent most of the day being unproductive coding-wise; instead I soaked in the bath a bit and thought about various things. Here are some ramblings from that down time thinking.

Part of the 4.2 roadmap for Plasma is already taking shape in my head. Yesterday while talking with Chani and J.P. on irc, I realized something that is pretty obvious in retrospect (hindsight, 20/20, yadda yadda): containments have become the place to do both functionality customization (layouting, toolboxing, applet addition/removal controls ..) as well as background painting. These things are pretty orthogonal, however, and what you really want to do is mix and match between these two sets of functionalities as a developer.

There will be some odd ducklings that do everything themself: a MacOS X style dock, for instance, would want to control both the background painting as well as the layouting and applet selection. Fair enough.

But many will want to have a given style of functionality, but use the same background painting that exists elsewhere. Or vice versa.

So in 4.2 I'm going to explore adding some add-on functionality for containments: backgrounds and context menus. The latter was already planned, but the backgrounds as separate add-ons is a new idea driven by the understanding that to avoid lots of duplicated code we really need to have a way to share background painting.

This won't affect the "any applet can be a containment" situation at all, nor will it force containments to use these new add on categories. The containmnet will remain in full control, this will just provide a painless way to access work done by others.

Additionally, I'll need to go back and do some KConfig hacking again for 4.2. In particular, besides doing the API review for KConfigBackend so that we can confidently export that interface for 3rd party use in plugins, I need to make KConfigSkeleton aware of KConfigBase so that we can use KConfigGroup with it. Plasma uses KConfigGroup extensively in its config system, but KConfigSkeleton is unaware of it. This is due to KConfigSkeleton coming about before KConfigBase was really interesting or useful to write against; it was more a "behind the scenes class" versus the useful base class it is now. The problem for Plasma here is that this means we can't use KConfigSkeleton really anywhere, which sucks since it's a very convenient way to both define and document configuration systems. It also makes driving the configuration user interface simple (e.g. one line of code). We already have support for plasmoids from packages (e.g. scripted plasmoids) to have code-less configurations, but it doesn't actually work when it comes time to save the config due to this issue. It's too late for 4.1, so this gets moved to 4.2.

(edit: i completely forgot the following in the first run at this.. doh!)

4.2 will also be when we go for concrete binary compat, move libplasma into a libs module (perhaps even kdelibs?) and either split out the Package classes into KNewStuff2 or make KNewStuff2 use libplasma.

At least we'll have a happy Plasma for 4.1.

Michael Pyne (mpyne): Victory Again

Thu, 08 May 2008 21:06:10 +0000

So before I went underway our car had developed a trouble causing the Check Engine light to come in continuously. No abnormal sounds but being nuclear-trained has taught me not to live with “locked-in” alarms or warnings. I wasn’t able to troubleshoot it in the limited time I had before deploying so I asked my wife to make sure it got investigated when she had free time.

She took the car to the dealership. She actually had to make two trips; apparently there were two separate faults that would have caused the light to come in by this time. Nothing mechanical luckily, but apparently at some point while the dealership was troubleshooting the issue they had to unhook the battery. Doing this activated the anti-theft feature of my radio; it would not play music unless I typed in the anti-theft code. This code was included on a card which I was supposed to remove from the car and keep in a safe place. Needless to say, I had removed it from the car, and it is still in some safe place, nowhere to be found.

So my car radio has been silent for about a month and a half now. I finally got the time to really dig into this issue since the dealership apparently is completely unable to figure out what the unlock code should be. A little browsing on the Internet and apparently many people have had the same issue, and the unlock codes are few enough to list in one paragraph.

So I went and wrote them down and typed them in one by one. After about a dozen tries the radio started working again. Yay! I will record the code in my KWallet this time; it is the only thing which I reliably can count on being there. In case anyone else develops this issue with a Chevy Aveo, I found these posts helpful: automotive forums and Yahoo! Answers.

Patrick Spendrin (SaroEngels): One step beyond(*)

Thu, 08 May 2008 20:46:51 +0000

Ok, after roughly one week out in the countryside again I came home yesterday and today I started my efforts again to bring KDE to compile with the brand new mingw-gcc 4.3 alpha version. Even though it has been feared that mingw-gcc might lag even further behind, the new maintainer Aaron William LaFramboise brought out a rather new release. As Aaron is a GSoC-student as I am, we can work together even better.
But now towards the facts that might interest the KDE on Windows Community:
I could build Qt with two patches and I had to disable webkit.
This first patch was due to a missing extern declaration in one sourcefile, the second one was a bit strange since it required using uint instead of quint32. The errors with webkit were not easily solveable so I will investigate them further especially as strigi fails on a similar error too. Currently I think that this is a more a mingw error but I might be wrong in the end.

To give you a more general outline:
I plan to work on mingw4 from time to time so that I will have a running KDE from mingw4 by the time KDE 4.1 gets released. KDE 4.2 should be buildable with mingw4 too and probably for KDE 4.3 we will switch completely away from mingw 3.*.

Right now I will start my GSoC project on marble so most of my time will be coding again.

So long for now, new posts will probably come in more regularly.

(*) 'One step beyond' is a song by the british ska formation Madness and just came to my mind after I got Qt building.

Derek Kite (dkite): Change

Thu, 08 May 2008 20:32:50 +0000

No, not a political slogan The headings in the menu are changed. Multimedia is now Sound & Video, Development is Programming, Accessories, System Tools. We now have a cashew or whatever it's called taking up space on the limited and valuable real estate that makes up the panel. Cookies and KWallet work again with Konqueror. Konqueror is getting better and better. A few crashes last week seem

Casper Boemann: Reworked scale dialog in Krita

Thu, 08 May 2008 19:06:52 +0000

I've worked a bit on the scale dialog for Krita. Neither the old one from the 1.x series nor the new one in current KOffice2 alpha releases were good enough. I've mailed a bit with Ellen which only confirmed that it is indeed a difficult dialog to get right.

In the end I reordered some items, so I hope it's a bit easier to figure out how to use it. I think it has become quite good, but judge for yourself. So much cool stuff coming in KOffice 2.0

Andreas Hartmetz: A new gold standard

Thu, 08 May 2008 18:34:08 +0000

Welcome to the third installment of the gold linker series on this blog!
Today Ian Lance Taylor, author and maintainer of gold, fixed the last known bug relevant to KDE 4. That means that you can grab gold off the official CVS server, compile it, and use it to compile KDE like with ld - only faster. Three cheers to Ian, you kick ass!
As all the relevant bugs are fixed now today's menu does not contain any important patches but some nifty tweaks.
The first one helps reduce the size of the gold executable (you still need to strip it to make it smaller, though). Here it goes:

--- Makefile    2008-05-06 06:21:28.000000000 +0200
+++ Makefile    2008-05-06 06:21:16.000000000 +0200
@@ -163,7 +163,7 @@
 CATOBJEXT = .gmo
 CC = gcc
 CCDEPMODE = depmode=gcc3
-CFLAGS = -g -O2
+CFLAGS = -g -O2 -fvisibility=hidden -fno-exceptions -fomit-frame-pointer
 CONSTRUCTOR_PRIORITY_FALSE = #
 CONSTRUCTOR_PRIORITY_TRUE =
 CPP = gcc -E
@@ -171,7 +171,7 @@
 CXX = g++
 CXXCPP = g++ -E
 CXXDEPMODE = depmode=gcc3
-CXXFLAGS = -g -O2
+CXXFLAGS = -g -O2 -fvisibility=hidden -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -fomit-frame-pointer
 CYGPATH_W = echo
 DATADIRNAME = share
 DEFS = -DHAVE_CONFIG_H

Download Makefile.diff

I also whipped up a utility called ldswitch to replace /usr/bin/ld. Rename the old /usr/bin/ld to ld-old and copy gold to /usr/bin/ld-new. Then copy ldswitch to /usr/bin/ld and you can easily switch between the old linker and gold by setting the environment variable USE_GOLD_LINKER to something nonempty whenever you want to use gold. I changed my own little compile script to set USE_GOLD_LINKER by default.

ldswitch.c:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    // invoke either /usr/bin/ld-new or /usr/bin/ld-old depending on the
    // environment variable USE_GOLD_LINKER
    const char *ld_env_var = getenv("USE_GOLD_LINKER"); // "USE_GOLD_LINKER" kids, mmmkay?
    const char *linker_name = 0;
    if (ld_env_var && ld_env_var[0] != '\0') {
        // OK, the environment variable exists and it has nonzero length...
        argv[0] = "/usr/bin/ld-new";
        linker_name = "gold";
    } else {
        argv[0] = "/usr/bin/ld-old";
        linker_name = "GNU ld";
    }

    if (execvp(*argv, argv) < 0) {
        fprintf(stderr, "** exec failed. Probably the %s executable %s was not found.\n", linker_name, argv[0]);
        return -1;
    }

    //unreachable
    fprintf(stderr, "Gamma ray burst registered.\n");
    return -1;
}

Download ldswitch.c

If you don't know yet (or have forgotten) how to get gold, here it is again:

cvs -d :pserver:anoncvs@sourceware.org:/cvs/src login
cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co -d binutils src
cd binutils
./configure --enable-gold
make

After having compiled the whole thing once you can go on to run make only in the gold subdirectory for recompiles.

That's it, have fun with gold! It's ready.

Nikolaj Hald Nielsen: Magnatune memberships launched, Amarok 2 offers full support

Thu, 08 May 2008 18:06:25 +0000

Finally, after hacking on it on and off for over 6 months, Magnatune has officially unveiled the 2 new membership options "stream" and "download". So as not to sound like a bad commercial, I will let John tell the story about these services.

What I would like to spend a little time on, even though I have touched on it before, is the cool way in which Amarok 2 already offers full integration for these 2 new memberships.

With a stream membership, all of the preview streams from the Magnatune service become available in high quality ( 160kbs ) ogg with no nagging speaker announcement at the end of each. ( if configured to use oggs, the mp3 files are also nag free but the same quality as the non member version ). This makes all the Magnatune service content almost indistinguishable from local content. Configured with a download membership, not only are all the streams high quality and nag-free, but the "purchase" option turns into "download" and lets you download as many albums as they like for free ( basically just skips the credit card screen and goes straight to the download dialog ). With a download membership, Amarok 2 essentially turns into the world's first music player with an integrated, unlimited, DRM free music download subscription service ( as far as I can tell ).

Another, slightly more obscure way these memberships affects Amarok 2 is that it can automatically convert Magnatune streaming urls from other sources into membership streams ( if configured to use a membership ). So, for instance, a stored playlist of non-membership mp3 streams can automatically be transformed into high quality membership oggs by Amarok. This makes it possible to do a cool Magnatune service front page in Amarok 2 that just links to "normal" mp3 streams and still ensure that the members get to hear the nag free streams.

Ok, so I am excited ( can you tell? ), but I have been working on these memberships for a long time and has taken great care to ensure that Amarok 2 would be ready to use them when they were launched. So now we just need to get Amarok 2.0 out the door...

Roland Wolters (liquidat): Areca: Linux desktop backups made easy

Thu, 08 May 2008 14:47:19 +0000

There are some desktop backup tools available for Linux, but most of them are not developed anymore. Areca however is under constant development and also provides a user friendly GUI.

Backups and Linux are a twofold thing: if you have hundreds or thousands of computers backups are not a problem at all: Amanda, Bacula, Restore and others are your friends. Also, if you want to create backups on single machines, there are many tools available: rsync, tar, and many, many more.
However, all these solutions are not suitable for the average user.

In the last years several projects were started to provide user friendly solutions for the backup of Linux desktop machines. A year ago I already reported about SBackup. Also, the Ubuntu team developed the solution TimeVault and last but not least there is flyback which I used for several months to keep a backup of my thesis. But despite their advantages they all suffer from stalled development: all mentioned projects are effectively dead at the moment.

There is only one exception: the little known Areca. This in Java programmed backup solution provides a user friendly GUI and is even suited for desktop users who have a quite complex idea of backup systems.

Despite some current bugs (it chokes on large numbers of files, you have to use several backup rules in such cases) and some shortcomings (the file choose dialog only allows to mark one single file each time) the program has matured over the time and can easily be used in a productive environment. Besides the usual backup/restore it also features statistics, the ability of merging backups, different backup profiles, encryption and other gimmicks. But be sure to quickly read through the documentation so that you understand what backup groups and backup targets are before you start!

The only problem I now have is that it is not packed for Fedora - or any other bigger distribution besides Ubuntu. The download section provides pre-compiled tar.gz packages, however I would prefer a rpm I could automatically fetch with yum.

Seb Ruiz (sebr): Google Treasure Hunt

Thu, 08 May 2008 11:59:49 +0000

The Google-AU blog reports that Google is going to be holding another one of it’s brain busting adventures soon. The post is ended with the following text/clue:

Arrrrrrrr you ready? Onward to the first puzzle, matey! And good luck!

aHR0cDovL3RyZWFzdXJlaHVudC5hcHBzcG90LmNvbS8=

Soon :). 1210550400

Warning: links below contain spoilers.

Shouldn’t take long to figure out. The 10 digits of the final number is a dead giveaway that it’s a unix timestamp, and maps to a particular time. That’s soon.

The seemingly random string is a base64 encoding of a particular website.

Sebastian Kuegler: Hideous GTK themes in KDE4 sessions.

Thu, 08 May 2008 10:58:09 +0000

For some time, GTK apps running inside my KDE4 session would not pick up their theme properly, making them look hideous in their default theme. I'm using a small wrapper script (/usr/local/bin/startkde4) to get my KDE4 desktop up and running. Since I've put the "unset GTK2*" line into the script, GTK apps pick their theme again:

#!/bin/sh

export LD_LIBRARY_PATH=/home/kdedev/kde/lib
export KDEDIR=/home/kdedev/kde
export PATH=$KDEDIR/bin/:$PATH
export KDEHOME=~/.kde4

unset GTK2_RC_FILES

. /home/kdedev/kde/bin/startkde

If you're still living under the "I use a GTK1 app" stone, put another line for GTK(1) apps in there.

Hope this tip keeps someone from tearing out hair. :)

Kent Hansen: Code Less, Create The Same ™

Thu, 08 May 2008 08:50:43 +0000

For reasons of extreme bias, I mostly like the Qt Script C++ API. However, if I had to choose one thing I really dislike, it would be the form of the QScriptValue constructors. They all take an engine pointer as their first argument. This means you have to write code like

QScriptEngine engine;
QScriptValue object = engine.newObject();
object.setProperty("redundancyLevel", QScriptValue(&engine, “Unnecessarily high”));
object.setProperty(”QT_VERSION”, QScriptValue(&engine, 0×040500));

It sure would be a lot nicer if you could do it like this instead:

object.setProperty("redundancyLevel", "Comparatively low");
object.setProperty("QT_VERSION", 0x040500);

Well, with the latest Qt 4.5 snapshots, you can! The old-style constructors have been obsoleted (but continue to work as before, of course). The documentation and examples have been updated to use the new-style constructors, and it’s looking a whole lot nicer.

Nuno Pinheiro (pinheiro): Black fan number 1.

Wed, 07 May 2008 20:34:00 +0000

I promised to Urs Wolfer, several months ago to work with him on a new KDM theme that matched the work we were doing a bit all over.
To do the KDM theme I needed a new wallpaper.
Here it is in 2 versions.

This one works beter as an walppaper IMO.

This one is being used for the KDM.

Any way the Svg link.

Hope you will like it.
Now i need to think about a new logo for a cool project. Wish me luck :)

Celeste Paul (seele): KDE User Research Profiles (May 7 2008)

Wed, 07 May 2008 19:54:49 +0000

Updates on current KDE User Research Profiles:

Plasma User Research Profile: A lot of good stuff came out of the Plasma Interviews and the work from Tokamak. I’d like to see more of this written up and discussed in public.

Both the Okular User Research Profile and Gwenview User Research Profile have some good stuff in their profiles. Remember that these profiles grow with the project, and as you expand your scope or add/change functionality, the profiles must be updated to remain useful.

This week, I would like to call on Kopete to begin working on their User Research Profile.

Instant messaging is an activity that nearly every type of user participates in and Kopete is one of the best instant messenger applications out there. But because Kopete has such a broad audience, it makes it that much more important to get all of the user types and use cases/scenarios documented. As always, ping me if you need help getting started.

Stephan Binner (Beineri): KDE 4.0.4, Codenamed Out-Of-Stuff-To-Tell

Wed, 07 May 2008 16:57:29 +0000

The usual monthly game: a new KDE bugfix release, openSUSE packages and a new Live-CD which as already said looks more and more less like KDE 4.0 but like our openSUSE 11.0 KDE4 desktop (while still being based on openSUSE 10.3):

Mike Arthur (mikearthur): Mendeley

Wed, 07 May 2008 11:14:22 +0000

I’ve recently left BT and joined a start-up called Mendeley. I’m now writing Qt code for a living which will hopefully benefit my KDE contribution’s quality and hopefully my work on KDE will benefit Mendeley. I’ve moved to London for the job, hence the decreased number of blog posts lately and my vanishing from the internet. I hope to get back to blogging and doing KDE work when the dust settles but let’s hear some more about what I’m doing.

Mendeley is providing a tool for managing academic and research knowledge, allowing people to be able to better find and manage academic papers and use a network of others to avoid mundane tasks when trying to seek academic knowledge. There will also be interesting benefits for those producing papers as well.

This consists of a desktop Qt application (for Windows/Mac/Linux and maybe other Qt supported platforms) which can plug into your Mendeley.com account and allows metadata to be gathered and shared. The desktop application and web application usage will remain free-as-in-beer but the desktop client will be (at least initially) proprietary.

We’re also looking for a talented PHP/Javascript developer with database experience (preferably MySQL) to join the team based in Central London. You will have a lot of responsibility from the beginning and must be passionate about the problems Mendeley are trying to solve and using social networks to solve them (*cough* Web 2.0! *cough*). You can read the full job advert on Mendeley’s site.

Although this may look like a blatant plug it’s also because I believe the sort of people that read a fairly technical blog like this may be more suitable for the position than on a random jobs board.

I’m enjoying Mendeley a lot so far. I’ve been able to make a real difference in my first two days and the other guys are great fun to work with and I look forward to learning more about academic research and Qt in the coming months!

Wade Olson: ars comparison: will better tools mean better results?

Wed, 07 May 2008 01:49:55 +0000

It’s hard not to notice a comparison between two articles currently on ars technica. On one hand, Peter Bright writes about Microsoft’s troubled attempts at modernizing code bases and standardizing tool kits. At the same time, Ryan Paul delves into the new features of the freshly released Qt 4.4.

$COMPANY has had good opportunities to do something about this, but they have been systematically squandered through a combination of ineptitude, mismanagement, and slavish adherence to backwards compatibility. The disillusionment I feel is incredible.

$TOOLKIT has a lot to offer on Windows CE and is well suited for creating graphically rich touchscreen user interfaces. Developers say that it offers good performance and strong support for the native look and feel of the platform. $COMPANY’s tools support tight integration with Visual Studio, which means that it will be easy for existing Windows CE developers to adopt the framework.

Can you guess which quote is about a small Norwegian company trying to compete against well-known international software behemoths and which quote is about Microsoft (that actually owns Windows CE and Visual Studio)?

Congratulations to the Trolltech team: Now stop celebrating and get 4.5 out the door.

Jonathan Riddell (riddell): Qt 4.4, Regular KDE builds from Neon, Cuteness!

Wed, 07 May 2008 00:11:44 +0000

Qt 4.4 brings lots of goodness. Packages are now entering hardy-backports.

If you want the latest unstable trunk Qt, kdelibs, kdebase and amarok on a regular basis without the hassle of compiling it yourself, project Neon has a Launchpad Personal Package Archive with regular builds.

Lastly, these were left on our doorstep today, free to a good home. Cuteness.

Celeste Paul (seele): UDS Travel Page

Tue, 06 May 2008 23:23:24 +0000

Corey was nice enough to start an Attendees page to collect travel information for the upcoming UDS on May 19th. Add your info so you can coordinate taxis or whatever with other travelers.

Ariya Hidayat: quattro quattro zero

Tue, 06 May 2008 21:55:39 +0000

In case you live under the rock and miss Thiago's latest blog post, Qt 4.4.0 is just released. This latest release packs a lot of exciting new features such as Phonon for multimedia stuff, integration of WebKit (open-source web rendering engine), powerful XML processing with XQuery and XPath, the famous Widgets on Canvas and Alien Widget, concurrent programming support for multithreaded processing, Qt for Windows CE, and tons of other enhancements.

Surely you wouldn't want to miss this one!

Ellen Reitmayr (el): Talk at BeLUG (Berlin - May 7)

Tue, 06 May 2008 20:39:01 +0000

On May 7, I will give a presentation about the impact of usability at the Berlin Linux User Group (BeLUG). Along examples from KDE and Gnome, I will illustrate the effects of a project vision and user research.

What: Usability in Open Source Projekten

Where: BeLUG e.V., Lehrter Str. 53, 12557 Berlin

When: Wednesday, May 7. 18.00.

Albert Astals Cid (TSDgeos): KUbuntu KDE 3.5.9 kded lock fixed

Tue, 06 May 2008 20:36:56 +0000

So this is the great thing of Free Software, people care about their programs/distributions/wathever and we got a relatively quick fix for the ugly problem about kde locking on Kubuntu. Cheers to Jonathan for fixing it.