Archive for the ‘Linux’ Category

gnome-shell: first impressions

I’ve been trying out gnome-shell for the last week. My impression so far:

* As to be expected it feels very rough
* It needs more keyboard bindings (e.g. in the Activities tab)
* Why is the clock the only interface element in the middle of the top-bar? Put that space to use, for Darwin’s sake! What about putting the applications menu bar up there? 😀
* Unusable without proprietary drivers, at least on NVidia hardware. Didn’t try it on AMD or Intel hardware

Now, that all sounds terrible negative. But in the end I’m quite optimistic. By being willing to break with the traditional desktop paradigm, the gnome-shell people are able to experiment with a plethora of new ideas. Finally workspaces are being put to use as a central metaphor not only as an afterthought. I also think that by using workspaces, MDI applications finally could get useful. I’m also looking forward to the integration of application notification and communication (through telepathy). The design document was very promising, I wonder how it all works out.

Advertisements

Five years of Ubuntu

Whoa, what a time. It seems like yesterday that the first release of Ubuntu (4.10, “Warty Warthog”) escaped into the wild. There was quite some buzz about that first release of the ‘Desktop Debian’ and I remember being very sceptical. Similar projects – Corel Linux OS, Lindows/Linspire – never lived up to the expectations and were quickly forgotten. But Ubuntu promised to be different. Ubuntu promised to be about Community and Participation, about End-Users and The Desktop.  No closed-door development like with Redhat Linux or SuSE Linux, no, a real community distribution. Five years late, Ubuntu has lived up to that probmise.

Yeah, right. It’s still not perfect. Yeah, Bug#1 is still open. And yeah, there are still a lot of lose ends to be tied up and some warts to be removed. Ubuntu is getting there. We are getting there.

As I wrote last year; 2008 was the Year of the Linux Desktop. And this was – to a big part – thanks to Ubuntu (and therefore Debian).

What an amazing five years. And what amazing times to come.

Here is to another five years!

The tanner’s ugly daughter – or – Musings about a modern GTK+ theming

GTK+ may be called many things. I would call it ‘simple’ and sometimes even ‘elegant’, referring to it’s foundation of pure, elegant C. But not everyone is compelled to use those terms, using terms like ‘clumsy’ and ‘unwieldy’ instead. Yes, there is a lot disagreement. But there’s one thing almost everyone would agree to: that GTK+ isn’t pretty.

Well, it is true. But why? Well, it seems that programmers and hackers don’t make good designers. But that’s not the whole story. Another reason is the current GTK+ theming. There are some things which just are not possible.
From a ‘old school’ programmer’s point of view GTK+ works nicely. It has all the widgets one needs to create decent and functional application. You can stick them together and the GUI you’ll get will work nicely. But the look of GTK+ has never been breathtaking and, to be honest, GKT+ is not as flexible as it could be. Animation is difficult and the layout of GTK+ applications tends to be very static.
In the last few years this weakness has gotten more apparent as other toolkits advanced more and more in the terms of eye-candyness: HTML/JS is highly flexible for creating innovative GUIs as the plethora of usable and unusable websites demonstrate. Qt provides a broad and deep platform which demonstrated its capabilities with KDE 4. If GTK+ wants to stay competitive, it needs to catch up. In other words; GTK+ theming is stuck and needs serious overhaul.

To understand the reasons, let’s first take a look at the current architecture of the GTK+ theming.

Focus lines are not possible in GTK+

Focus lines are not possible in GTK+

GTK+ theming as of now

The look of GTK+, just as with all modern graphic tool kits, is defined by themes. Theming in GTK+ consist of three parts: Engines, Styles and Configuration. All in all it can be summarised as: “Themes provide styles, which can be configured and assigned to widgets”. But let’s start at the beginning.

GTK+ provides a set of drawing primitives: lines, boxes, arrows, and so on. Whenever a widget is drawn, these drawing primitives are used. The implementation provided by GTK+ is very basic and not very sophisticated, but it can be overridden.

That is where the theming engines come into the picture. The theming engines provide their own implementation of those primitives. You can even add additional configuration parameters. These are called ‘Styles’. Say, you don’t just want a foreground and background colour for your widget. Say you want a gradient? Easy, just add a configuration parameter for that style and tell the engine where to use gradients. This happens in the ‘.gtkrc’ file where every widget is provided with a set of configuration parameters.

But that only allows you to style the individual primitives. It is not possible to change the geometry of a widget. Say, for example, you want round edges for your buttons?  Well, the only way to do that is to hardcode this into the theming engine; whenever a button is drawn, just handle this in a special case. Query the widget ancestry and draw your round-edged button whenever needed. Problem fixed!

The drawbacks

… as long as you don’t want custom widgets. Drawing custom widgets can be a major pain with GTK+. You can draw custom widgets, GTK+ is perfectly capable of doing that. There are some major GKT+ application which provide their own widget implementations because the default GTK+ implementation didn’t suite their needs. The problem arises as soon as you want to mimic the look a certain kind of widget. Then you’ll run into problems.

You see; styles are hierarchical. You cannot draw a ‘button’ style if you don’t derive from GtkButton. You have no way to tell the theming engine to draw your widget like a button.  So the only thing you could do is to use the drawing primitives to draw something that at least resembles a button in most themes. But as you may have guessed; this is a very difficult task and not very funny.

Knowing about this problem, some theme engine developers have taken special care that some of the more popular applications get drawn as intended; they include special clauses to check for some known custom widgets.  But that only makes matters worse, for you cannot know every custom widgets. So user interface design with GTK+ in the last few years has effectively been a choice between using only GTK+ widgets or having custom widgets look either crappy or out of place.

GTK+ also makes it particularly difficult for themes to draw widgets spatial dependant. Suppose you want three buttons to be drawn, side by side with the outer edges of the first and third buttons lightly rounded? Well, currently it is not possible; the theme engines are lacking spatial information and the application developers have no way to tell a theming engine when and how to treat a widget in a special manner. Well, that’s not completly true; there is a way to pass ‘details’ to theming engines. But the nature and definition of those details has apparently never been documented and got lost in space and time.

To make matters worse, theming isn’t isolated. It touches many other issues, like animation, layouting of widgets (which is nowadays fixed for most applications) and also platform integration.

The silver lining on the horizon

These drawbacks of the GTK+ theming architecture, the basic design, goes back to the very beginnings of GTK+. There were some changes to the theming system during the last major version bump (1.2 to 2.0), but it has stayed always stayed the same, more or less. And people noticed. Now some  GTK+ developers organised a meeting about the future theming of GTK+, lovingly called ‘Hackfest’. And their plans are impressive; to provide the basic architecture of a future GTK+ theming and rendering infrastructure. This wouldn’t be half as spectacular if only GTK+ developers were invited. But if you take a look at the schedule, you’ll see that Qt and Mozilla developers are also participating. If this results in an easier integration of third party applications into GTK+ and thus the GNOME desktop will remain to be seen, but it certainly looks promising. Having Mozilla/Firefox and Qt applications look /exacly/ the same as GTK+ applications might finally be possible.

The ‘hackfest’ has been going on since Monday and the first results are already spilling out. The new theming API, it seems, will focus on Cairo and and CSS. Now Qt has had CSS-style theming for quite a while and interoperability on that layer suddenly seems possible. Maybe we’ll even get a unified theming configuration language for GTK+ and Qt! I’m quite curious how they bring all these pieces together; theming, layout, animation, integration and odd-shaped widgets. But let’s wait and see.

References:

Aaron Bockover’s complaint about theming in GTK+
Thomas Wood’s comments to GTK+ theming
Documentation of GTK+ theming on http://live.gnome.org
New theming API entry on http://live.gnome.org
GTK+ Theming hackfest announcement
First feedback from the GTK+ Theming Hackfest

Application development with Vala – First Steps: Getting the Vala feeling

Thanks to undeconstructed from #vala at irc.gimp.net

In the last few weeks I’ve been playing around with Vala, and enjoying it. “What the heck is Vala”, you might ask, and of course you will get an explanation. Not only because Vala, though still in its infancy, hasn’t gotten the attention it deserves.

Vala is, in some sense, a new programming language. It’s syntax and structure leans heavily towards C#. As Jürg Billeter, the mastermind behind Vala, likes to put it; Vala is an amalgam of different C inspired languages, mostly C++ and C#. An though there is no mercury in this mixture, you’ll find many a gold nugget in Vala.

“Why another programming language? Aren’t there enough out there yet?” might be your next question. And of course this also deserves an explanation. Yes, there is an awful lot of programming languages out there. But what makes Vala special is it’s unique combination of high-level programming and low-level interface. You see; even though Vala supports modern programming language features like objects, foreach-loops, generics, annotations, memory management and exception handling, Vala is very slim. It doesn’t require a virtual machine. Indeed; Vala compiles are binary compatible to C. You can use C libraries from within Vala, you can even use Vala libraries from C. That’s because Vala, at it’s core, still builds upon the foundations of C. But more on that later. First, let’s take a look at a piece of Vala code.

int main (string[] argv) {
        stdout.printf ("Hello, World!\n");
        return (0);
}

Well, that does look familiar, doesn’t it? All control structures (for-loop, while-loop, switch/case, if/else, …) behave like their C counterparts. Vala is very much like C, although there are some peculiarities. Like that string-datatype, and that stdout-whatsit.

Having stored this piece of code in a file called hello0.vala, it can be compiled:

valac hello0.vala

No rocket science thus far. The resulting binary can be executed and will result in following output:

$./hello0
Hello, World!

Now that we have made ourselves a little bit comfortable with the Vala tool chain, let’s take a look at some of the more interesting features Vala has to offer. That string data type, for example.
In our main function, we’ve defined a single input parameter. string[] argv; an array of strings. But other than simple C arrays, this is not only a block of continuous memory. It’s an object by itself and thus has properties we can inspect. It’s length, for example.

int main (string[] argv) {
	stdout.printf ("Argument vector length: %i\n", argv.length);
	return (0);
}

There is more. Using the foreach-loop we can even iterate over this array.

int main (string[] argv) {
	foreach (string arg in argv) {
		stdout.printf ("Argument: %s", arg);
	}
	return (0);
}

Neat, isn’t it? But Vala has even more to offer. Like Classes. Everyone likes classes, so let’s make some! Animals are always good for examples, so I’ll use them as well.

public class Animal {
	public string name;
	public bool can_fly;
	public bool can_swim;
	public bool can_walk;
	public string noise;

	public string make_noise () {
		return (this.noise);
	}
}

int main (string[] argv) {
	Animal dog0 = new Animal ();
	dog0.can_fly = false;
	dog0.can_walk = true;
	dog0.can_swim = true;
	dog0.noise = "Whuff";

	dog1.can_fly = false;
	dog1.can_walk = true;
	dog1.can_swim = true;
	dog1.noise = "Whuff";

	stdout.printf ("dog0: %s", dog1.make_noise ());
	stdout.printf ("dog1: %s", dog1.make_noise ());
}

This little example already shows some features of Vala. Obviously there are classes, with members and methods. But this example isn’t very sophisticated. Let’s try something more interesting. For example, let’s replace those booleans with a bitmap, bring in some generics and inheritance.

public enum Locomotion {
	NONE =  0,
	WALK =  1,
	SWIM =  2,
	FLY  =  4,
	EVERYTHING = Locomotion.WALK | Locomotion.SWIM | Locomotion.FLY
}

public abstract class Animal : Object {
	public string noise		{ public get; construct; }
	public Locomotion locomotion	{ public get; construct; }
	public string make_noise () {
		return this.noise;
	}
	construct {
		this.locomotion = Locomotion.NONE;
		this.noise = "";
	}
	public abstract string introduce ();
}

public class Dog : Animal {
	public string name { private get; construct; }
	Dog (string name) {
		this.name = name;
	}
	construct {
		this.locomotion = Locomotion.WALK | Locomotion.SWIM;
		this.noise = "Whuff";
	}

	public override string introduce () {
		return ("My name is " + this.name);
	}
}

public class Finch : Animal {
	construct {
		this.locomotion = Locomotion.WALK | Locomotion.FLY;
		this.noise = "Tchirp";
	}
	public override string introduce () {
		return ("Buggeroff");
	}
}
public class Fish : Animal {
	construct {
		this.locomotion = Locomotion.SWIM;
		this.noise = "Blubb";
	}
	public override string introduce () {
		return (this.noise);
	}
}
public class Bass : Fish {
	public string name { public get; construct; }

	Bass (string name) {
		this.name = name;
	}
	public override string introduce () {
		return ("I am " + this.name);
	}
} 

int main (string[] argv) {
	List<Animal> a_list = new List<Animal> ();
	Dog wulfie = new Dog ("Wulfie");
	Finch bert = new Finch ();
	Bass bob = new Bass("Bob");
	a_list.append (wulfie);
	a_list.append (bert);
	a_list.append (bob);

	foreach (Animal a in a_list) {
		string loc = "i can";
		if ((a.locomotion & Locomotion.FLY) == Locomotion.FLY )
			loc = loc + " fly";
		else
			loc = loc + "'t fly";
		stdout.printf ("(%s)\t%s: %s, %s \n", a.get_type ().name (),  a.make_noise (),  a.introduce (), loc);
	}
	return (0);
}

As you can see, Vala supports all features you’d expect from a modern programming language. Classes, abstract classes, inheritance, generics, method overloading and so on. And still there are many features I didn’t touch in this essay, like interfaces, signals, exceptions, namespaces, access level modifiers, lambda functions and packages. And most important; Vala provides memory management, freeing the developers of most the hassles usually associated with low-level application programming.

So with all those fancy features, how can Vala still be compatible to C? It’s because valac, the Vala compiler, uses the GLib type system for its underlying framework; Vala code is translated to plain C code with hooks to GLib and (if one uses GLib.Object as superclass) GObject. This generated code in turn is compiled by GCC. Vala applications thus are native binaries, requiring neither an interpreter nor a virtual machine.

Vala provides (very) complete mappings to many important Unix C libraries, such as stdlib, D-Bus, Cairo, SDL, Poppler. And of course, with its roots deep in GLib, Vala also supports the Gtk+ framework and all related libraries. The excellent libgee, also developed in Vala, provides array lists, hashes, sets and collections. Use of the pkg-config system makes using libraries very easy. And as soon as GObject introspection is in place, bindings to all kinds of scripting languages come with the package for free.

Vala, now at version 0.3.4, is still under heavy development. My first experiments have already uncovered some bugs, which got fixed immediately. Vala might still need some time to come of age, but already it is picking up momentum, as the first projects start to use it. Especially developers with an aversion towards C++ might find Vala interesting, for it links the solid GLib type and event system with an elegant syntax, providing all the necessary tools for rapid application development on a stable foundation.

Links:

Vala (Project site)

Why 2008 Will Be The Year Of The GNU/Linux Desktop – seriously. I mean it. Really.

Don’t take this article too serious. I had a lot of fun writing it. I do believe that GNU/Linux is coming to the desktop in 2008, however.

When I first started to work with GNU/Linux, now almost eleven years ago, I’d never would have guessed that it would become such a large part of my life one day.  I liked the idea; communal developed software. Collaboration on a whole new level. Software not developed by a company, but by enthusiasts. It had something rebellious and subversive. I just fell in love with it.

Back than, GNU/Linux (and the BSDs also) was merely a toy for me. Something fresh, something new. Something completely different. But after I had set up my first servers, had started using October Gnome as my desktop environment, I started digging deeper. Into the internals of the system. Into the Source.

I always considered myself to be a fairly good coder. Not excelling, but competent. And because of that I recognised the quality of that code. I realized that that those little pieces of code were the works of mad genious artists. Pure, elegant C, honed to perfection.

I was convinced that it would – one time – rule the world.

Yet I always fooled myself about GNU/Linux’ problems. Back then, getting X to run was a task of days, at least on the hardware at my disposal. The desktop environments were clumsy and counter-intuitive, the applications limited and ugly, for they were written with either CDE or Tcl/Tk. Most didn’t even have a graphical user interface and were limited to the console. XMMS was okay for playing MP3 files, but even watching a move was a daunting task. Those were the dark ages, when the Knights of the Light only had started their quest for freedom and equality.

Even back then there have always been Prophets of The Dawn. Reiterating the old prophecy that this, yes, this very year would come to be known as the Year Of The Linux Desktop. I always used to simile at them and give ’em cookies. They were cute, somehow. Breaking the Mighty Power of the Forces Of Evil would be the task of a generations. The desktop market was fixed in the hands of Microsoft, a convicted monopolist. An unpleasant necessity. Breaking that power would be a task for giants.

While I was promoting GNU/Linux in my surroundings, providing installation setup, first private, than commercial, the Amazing Power Coders were out there. Doing good wherever they could. And one by one, Linux’ weaknesses were being addressed, scrutinized, judged and attacked with the fury befitting a wildcat.

Things have changed. GNU/Linux has changed. X.org, KDE, GNOME, Linux and all the other pieces of software composing the free software desktop have ripen well. It’s functional software, mostly slim and elegant, sometimes even beautiful.

Today I saw an advertisement for the Asus EEE PC, printed by a large consumer electronic store (Mediamarkt). This is the first time, that a GNU/Linux product has been advertised by that company. A company that has no ideology whatsoever. Besides making money. In the last few month no week passed by without the announcement of yet another GNU/Linux desktop/consumer product. Mostly ultra-lowcost ultraportable. Because these are the areas where GNU/Linux shines like a twinkling star.

And there is more. In two weeks there will be an anniversary. The anniversary of “GNU/Linux preinstalled on the desktop machines of a major hardware vendor”. It’s almost been a year since Dell announced to ship desktop and consumer products with Ubuntu pre-installed. HP followed shortly thereafter. And although neither Dell nor HP are making huge profits by selling GNU/Linux machines, both still provide the option. Even after a year.

With the rise of those consumer machines GNU/Linux got a lot of advertisement. And suddenly people I never talked to before about GNU/Linux start asking questions. They ask for support, for guidance and help. Some even offer to pay. Finally.

And the disbeliever, the skeptic inside, is falling silent.

So, now hear my prophecy, as I am joining the ranks of the Enlightened; The GNU/Linux desktop is coming. 2007 saw the end of the beginning. 2008 will feel the torrent.

VMware Server, Ubuntu “Hardy Heron” 8.04 and Linux 2.6.24

Yesterday I updated my work laptop to Ubuntu 8.04.  Of course it’s silly to abuse a productive machine as a testing ground for a unstable release, but I did it, nonetheless.

My impression so far is very good! Even “Hibernate” and “Suspend” seem to work now, very nice. The only problem I had was with VMware Server, the only piece of proprietary software I use on my machine. For business reasons. However; the problems I had were fast to fix.

  1. Patch the VMware modules.
    VMware does not yet support Linux 2.6.24, so the modules have to be patched. The VMware community forums helps with that: http://communities.vmware.com/thread/121847?tstart=-1
    Don’t forget to edit …/source/vmmon-only/include/vcpuset.h, you need to change line 74 from “asm/bitops.h” to “linux/bitops.h”. (Thanks to luyseyal for that.)
  2. Re-compile the modules.
  3. Just use sudo vmware-configure.pl to recompile the modules.

  4. Copy the libraries
    The VMWare Server Console was compiled with an older version of the GCC than Hardy is compiled. If you get the following error, you need to copy some libraries:

    /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)

    Use following commands to copy the libraries to the VMware directory:

    cp /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/cp /usr/lib/libpng12.so.0 /usr/lib/vmware/lib/libpng12.so.0/

That should to the trick!

The end of proprietary software?

Steve Ballmer, the CEO of Microsoft, called it a “cancer”. Other have outfitted it with “viral” attributes, destroying the software business as it was formerly known. And while Free Software advocates are very fast to dismiss these accusations as FUD (Fear, Uncertainty, Doubt), there is a grain of truth in them.

If we take a look at the Free/Open Source Software landscape, its advantages become quite evident; wherever there is a need for a certain tool, users gather, start to plan and develop a piece of software to satisfy that need. This works surprisingly good, as any Linux user can tell you; the Linux desktop has been a viable alternative to proprietary operating systems for quite a while now and I dare to say that the rate of progress is equal (if not higher) to that of any competitor. Indeed; this is not only limited to the desktop, but is true for almost every corner of the software landscape. However; there are to very distinct exceptions to that rule; games and specialist software.

The community based development approach of Free/OpenSource software has some very impressive advantages. First of all, the burden of the cost of the development is (ideally) not shouldered by one entity, but by a legion of contributors, be it enthusiast developers or hired programmers. Second; while the cost is divided, the advantages of the software is not. And third; abandoned software projects can be picked up again. For proprietary software, this is a no-go if you don’t own the copyrights.

However; since the development process is so utterly dependent on the community, Free/OpenSource software will only prevail where there are enough enthusiasts with the right skills. And this, unfortunately, does neither include specialist software nor games.

It is my expectation that Free/OpenSource software will increasingly dominate the software landscape. Utility software, office software, multimedia and productivity suites; these are categories that attract a huge crowd of people, some of them apt enough to contribute, in code, in documentation, in testing. I doubt that proprietary piece of software stands a chance against an Free/OpenSource product, at least in the long run, say; 10 to 15 years.

Games and specialist software however are something different. Their target audience is limited, the fields require a huge amount of expertise and thus the number of experts is limited. Creating a community in this kind of environment is a very difficult task. I expect proprietary software to flourish in this parts of the software landscape for quite some time to come.

Project Ammonite

Being rather unhappy with the state of Nautlius, I’m going to revive my old “Filecentral” (http://home.zhwin.ch/~bosshrap/projects/filecentral/) project. Project Ammonite will be a prototype of an minimal yet extensible file manager for the GNOME desktop. Since Filecentral 2/Ammonite will be based on GVFS instead of gnome-vfs, and the first stable GVFS release is expected for Gnome 2.20, I still have some time to draw up a proper concept.

I guess there will be a lot of people that will tell me to work on improving Nautilus instead of wasting my time on a new project and divert effort this way. But anyone who has ever taken a look at the Nautilus source code knows what complexity lies in those depths. It’s not without reason that Nautius has been in maintainance mode for the last few years.

The first project phase will be an evaluation phase; priorities, possible starting points, project to evaluate. Thunar as a starting point is also something to consider, although that would inevitably lead to a fork; Benedikt Meurer will probably never agree to incorporate GNOME libraries into Thunar.

One way or the other, these are some of the priorities I consider:
– extensive metadata integration
– plugin system
– speed

If I ponder about it, may be that there arise some new ones.

Any suggestions?