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

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?

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.

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.

Language Evolution

[nonmaskable]

I've been professionally developing using C/C++ since 1985 on everything from device drivers to GUIs on every platform imaginable and I love C++.

BUT I've also been doing Java and C# the last three years, and they are a *huge* win in developer efficiency. Watching people working on my projects, I can see marginal developers immediately become much more productive (2x in some cases) - and I've been measuring this using several objective metrics (modules/week, LOC, PR #, time/PR).

I would rather see Java "win", but unless Sun blinks on the free/open issue _very_ quickly, I think C# will win by default.

GNOME is GNU. Mono is hostile to GNU.

[bizcoach]

I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.

Re:I didn't read all of it but...

[Hard_Code]

Maybe because people don't want to keep constant track of memory allocation semantics. Maybe because developers don't want to have to learn a new platform library (e.g. Boost) every time they look at a new project. Maybe because the legions of programmers we expect to build tomorrow's applications will justifiable not give a damn about solving the same old problems we have been solving for decades, and instead want a consistent platform and set of APIs to get their work done safely and with minimal hassle.

"Our guys" are gonna have to fight their guys. And if "their guys" are armed with cheap CLR/VB.net/C# runtimes (meaning there will by about 10x more), we are going to freaking lose even though we have big and complicated C/C++ howitzers.