Coding The Future Linux Desktop [updated]

the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere." Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).

Comments

Next week I will be coding the Linux desktop:

[Realistic_Dragon]

[] in C
[] in scheme
[] in mono
[] in asm
[X] in a penguin suit
[] whilst eating a banana
[] upside down
[] badly
[] perfectly
[] in an easy to use fashion
[] as a placeholder for my terminal windows
[] to look just like Windows

How about still using C

[Xargle]

We'd actually get a performance gain without a 4 way Xeon and gigs of memory, and apps would even downscale acceptably to mobile devices?

Re:How about still using C

[IamTheRealMike]

You've clearly never spent hours tracking malloc arena corruption, insidious thread safety bugs, or enjoyed the benefits of a clean OO syntax.

No. C has its place for sure, but for writing desktop apps it's the wrong tool for the job.

Still, I have to admit, this is something that could go so many ways. Right now Mono has the mindshare in terms of Gnome/GTK# apps, people are playing with it, liking it, there are actually unique interesting apps (like Muine) written in it etc. Where are the interesting GTK/Java apps?

On the other hand, the GNU java toolchain is nicer than Monos. GCJ is a really nice, easy to use compiler that's pretty fast and it creates ELF binaries. It fits in with the existing infrastructure, reuses our investment in ELF and the resultant apps don't have strange EXE and DLL extensions.

Java-GTK is apparently also quite a mature set of bindings, though I haven't used them so I can't say for sure.

I'm not convinced the patents thing is really valid. If Microsoft have patents on their class libs I think it massively unlikely Sun don't have patents on theirs. Worse, I suspect that even if there was a completely open source, newly designed framework that was similar to Java/.NET it would fall under those same patents.

We probably just have to ride them out.

I think Havoc is off base with the XAML comments. XAML will only be usable with the arrival of Longhorn which is in, what, 2008 now? It looks a lot like XUL, and yet where are all the XUL apps? Firebird is still the flagship XUL app, even after all this time. I certainly cannot see XAML taking over HTML anytime this century, there's simply too much investment in HTML and XAML isn't compelling enough from what I've seen to offset that.

Re:How about still using C

[NonSequor]

Here's my philosophy: the computer is here to do my work not the other way around. When I write a program I want to expend my effort only on explaining how it should work and not worrying about things like memory allocation.

What's worse is that C forces you into a certain way of thinking. Other languages make it easier to work in other styles so you can actually implement the algorithm in the way that you come up with it.

I've got a nice computer and I want to take advantage of it. I don't write much software, but anything that could make it easier would be welcomed.

Re:How about still using C

[RailGunner]

I don't think it's a question of time invested as far as poor UI design goes, I think it's more of a problem that most engineers don't really know how to put together a User Friendly UI, because let's face it - we think the CLI is pretty user friendly.

UI's could get much easier to use if developers would just select the right widget for the job. For example: Have a two state switch? Whether some feature is enabled or disabled? Please, just use a check box. The goofy group box with the two radio buttons (one labeled "Enable" and the other "Disable") is just clutter.

Another tip? Ask a graphic designer to layout your UI, then go and implement it. Graphic Designers study the best way to graphically communicate an idea, so (speaking from experience, my wife is a graphic designer) they can be a terrific resource in laying out a UI.

Finally, if you're using any kind of graphical UI editor like MSVC, Glade, Qt Designer, etc.. it just takes a second, but line up your widgets for crying out loud. Nothing screams amateur loser like controls that don't line up correctly.

And remember - your average customer doesn't see the elegant code you wrote under the hood - they see your UI. Especially remember this when writing Linux UI's - one thing MS is fairly good at is putting together a consistent UI. Might be ugly as sin like WinXP's default, but it's consistent.

Re:How about still using C

[ichimunki]

What I don't understand is why so much attention is on Java or C#. Is it only because with runtimes these are the languages out there that compile down to some form of byte-code? Don't we then perpetuate the problem of having to match binaries and runtimes just as we now have to match binaries and platforms (thinking x86 vs. PPC and the like).

I should think we'd all be better off if more and more end-user apps were being written in interpreted languages like Ruby, Python, or Perl, using the appropriate GUI bindings (my personal favorite is Ruby-GNOME2, especially just the GTK bits, since those are supported on Windows for an added portability bonus). Porting scripts from one GUI toolkit to another is often quite possible as well since the differences are often minimal (just don't get distracted by that ever-sought Holy Grail of the Meta-Toolkit). Not only that, there appears to be some promise for the idea of using libraries written in any C-based scripting languages from any of the other C-based scripting languages (just as they have excellent capabilities for using C libraries).

Re:How about still using C

[Moraelin]

I don't know about him, but I've spent time debuging malloc/free bugs. I also earn a living with Java right now. So I have at least some clue of its advantages.

And, sorry, I think there's a reason why Java is popular on the server side, and why you don't see any killer desktop apps written in Java. And why I'd actually like it to stay that way.

Off the top of my head:

1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.

2. The garbage collector does _not_ play well with the swap file. It causes each page belonging to the Java heap to be regularly paged in. Often. Several times per garbage collection pass, in fact.

So whereas a system which stuck to C or C++ will still run at full speed when I load 550 MB of programs in a 512 MB of RAM, a 100% Java system would trash to death at that point. (In fact, see point 2: much sooner than that.)

Or if only 300k out of that is Java stuff, it will act all elbows to the other apps. It will keep bringing its own pages in, and forcing everyone else to do with less memory.

And no, this problem isn't solved by compiling to ELF. As long as you have a garbage collector, it happens anyway.

3. Java RAM usage is ludicrious, especially for a system based on small utilities, like *nix is. I've actually had to write once the exact same small GUI utility in both C and Java. The C version ran in under 1 MB. The Java version allocated 16 MB right upon startup.

It gets worse from there. Even minimal string manipulation or use of trees will easily use 2-3 times more memory than in C. Stuff which in C/C++ goes on the stack, or is allocated together as part of a single struct, in Java ends up a twisty little maze of individually allocated objects, each with its own memory overhead, above the size of the data in it. A simple String is two objects for example.

4. It also has horrible startup time. No, sorry, I don't want to wait a couple of seconds just for the JVM itself to initialize, each time I launch an application. And I think that both Gnome and KDE are already proverbially slow to start as it is; they don't need to add half a minute to their startup time just because the gazillion apps they run on startup are Java.

5. Swing is slow. It insists on painting every single pixel in the window personally. Basically if you have one form in a swing window, the whole window is one big canvas, on which the individual buttons/fields/toolbars/menus/etc are rendered in software, pixel by pixel. If that's your idea of a fun desktop, may I humbly suggest setting your X to use the VESA framebuffer instead of whatever accelerated driver you're using?

6. It also requires quite a bit of clue to use well. See for example the listener leaks I've mentioned before. Or it's very easy to write GUI code that's dead slow, if you don't know what you're doing. E.g., code which takes several seconds just to fill in the values in a combo box.

Etc.

Basically, I'm all for Java and all, but I sure as heck don't want it on my desktop, if I have a choice. When I run a web browser or an IRC client program, I very much like them to be well behaved applications which don't play hardball with the paging. I also appreciate if they don't allocate 3 times more memory than they really need.

So, sure, the Gnome team is free to switch to whatever language they please. But the day they release a desktop based on Java, it'll very likely be the day when I kick Gnome as whole off my hard drive.

Visual development environment

[nycsubway]

Having development environments like KDevelop and Glade are very important to the linux desktop. If these programs had more point-and-click UI design features, it would allow anyone with basic programming experience to put together a program. It's both good and bad to have this in linux though; it allows almost anyone to point and click an application together, and this will help corporations utilize a linux desktop. It also allows for the same problems that windows development has: lack of granularity in visual basic and really bad, unoriginal programs.

I think improving the visual part of KDevelop and Glade is very important. I also think leaving C/C++ and possibly Java as the languages in which the applications are written is preferable. C# is simply Java by Microsoft.

It would also be nice to have a development environment that allowed any language to drive the UI.

And now, the rest of the story

[Anonymous Coward]

Your point is well taken, but it is rather surprising that you seem to have forgotten invention also drives economies. "They" want this waste/consumption of resources to force people to buy the Next Big Thing.

This isn't American and it isn't even Capitalist; it's Human, and probably vexed Pharoah as much as it vexes you or the lower income individual on the upgrade treadmill (MS/Software/_or_ Hardware.)

Regards,

A. C.

Re:High level languages

[iapetus]

That's largely down to the platform-independent UI code, though. Replace it with native widgets tied to Gnome and performance should be perfectly respectable.

Commercial Linux Apps

[commander salamander]

The battle for the Linux desktop has really been heating up lately, and with the planned release of several big commercial apps (Macromedia), it's getting even hotter.

As a bit of a GNOME fanboy, I hope GTK+ and friends can lure ISVs to use G-technologies when porting their programs. GNOME currently seems to have a large base of commercial support, although I've heard QT is being used in commercial development more. The integration of commercial apps with a desktop platform could be a make-or-break for said platform, especially as Linux market share grows and more Aunt Tillies and suits move off of Windows.

I've got a bone to pick with the FA though; it states that FOSS needs a new high level language and toolkit pronto if it's going to lure new developers. I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in .NET; what makes HP think that GTKmm or QT isn't good enough? Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.

These languages are all outdated!

[seguso]

How sad: the only alternatives taken into account by Havoc are C#, Java and C++. If only the open source movement decided to embrace Mercury (logical paradigm) or Haskell/Clean (functional paradigm), and build .NET-like infrastructures for them, their productivity would be so increased that that they would surpass Microsoft before longhorn comes out. Instead, you go check and find out that the Mercury and Haskell projects are sponsored by Microsoft. Also ML and Prolog are being ported to .NET. Well, I suppose we (the OS movement) will get what we deserve for our lack of foresight.

Re:Community standards...

[maxwell demon]

I'd love to adopt Linux but am still trying to mount /dev/clue ;-)

Well, that's easy. First, download the latest 2.6 kernel (/dev/clue on 2.4 kernels is still experimental). Use a vanilla kernel, the clue patch is probably not working with the kernel your distro may offer. Then get the clue patch, apply it, recompile (configure the clue as module, building it directly into the kernel is not well tested), don't forget to make modules && make modules_install. Install your new kernel (if you use LILO, dont forget to call /sbin/lilo) and reboot. Type modprobe clue. Then look in the proc filesystem if clue has properly initialized. If not, you might have to create a /etc/clue.conf for your system (see the Clue-device-HOWTO for details, but beware that some instructions there are out of date, so check the CHANGES file of the current release). As soon as everything is running, there should be the clue device in you /dev. Now you need to activate the clue filesystem (installed together with the clue device, just do modprobe cluefs). Now you can just issue the corresponding mount command (the exact options can be found on www.cluefaq.org), and voila. To have your clue activated and mounted automatically, you should adapt your modules.conf and fstab.

You see, it's really not a problem, is it?

Re:So the goal really is to follow Windows?

[tal197]

C# is a good language, but it is a far cry from Python, for example. Little, me-too babysteps is not the way to approach this. You need to be bold. Choose something with big wins and big advantages.

From the blog, Havoc writes:

My view, which will doubtless get me flamed, is that these languages [python, etc ]aren't really the right thing for writing large desktop apps such as GNOME or OO.org

I'd be really interested to hear Havoc's reasons for this comment. I've written quite a lot of (smallish) desktop apps in Python (most of the ROX ones, in fact), and it seems ideal. I've also used Java quite a lot.

Python is in many ways similar to Java:

• Platform-independant bytecode.
• Fully OO.

But it has differences too:

• Python is much faster, both starting and running, and seems to use less resources.
• Python programs seem less prone to runtime errors (NullPointerException), and are generally more solid.
• Python is much quicker to write, easier to understand and easier to debug.

True, you loose static type checking. However:

• You can usually run your unit tests in Python in less time than it takes just to compile your Java. So you actually get more checks in less time!
• pychecker can spot many static errors.
• There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.

Re:GNOME is GNU. Mono is hostile to GNU.

[RdsArts]

It's also of shaky legal standing. Mono has no right to use the patents it does for the APIs other then a gentlemens' agreement that MS, IBM, Intel, and the other patent owners will not start charging for them.

This is important as, if they do charge, the Mono project would no longer be able to release a GPLed CLR or compiler. Even a 1$ license on the patent still means it would be GPL-incompatable.

Personally, I don't see why anyone should move to Mono. I'm perfectly happy coding in Python and Ruby until Parrot hits 1.0, when (in theory at least ;) ) I can start sharing that same code across the board.