LWN.net Logo

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Linux.com has an editorial look at the Portland project. "The Portland project is an effort to unify the Linux desktop by specifying and implementing a common set of APIs that all applications can use, and by supplying tools to assist application developers. Its primary target is third-party independent software vendors (ISV), a group that the Portland project leaders describe as interested in deploying software on Linux, but held back by the fractious dueling-desktop-environment mess."
(Log in to post comments)

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 28, 2006 18:37 UTC (Mon) by cantsin (guest, #4420) [Link]

From the user's viewpoint, multiple desktop APIs aren't even the problem - Mac OS X has them with Carbon and Cocoa, Windows with MFC, .Net and VCL. Given one standard user interface guideline and a common themeing engine, desktop consistency isn't a silver bullet at all. It's just that such standards don't exist, and aren't implemented by Portland either. One could argue that the diversity of free development works against common standards. On the other hand, most free software has managed standardize on Unix/POSIX as its low-level API. Maybe it will be a matter of one or two decades until GUI design has stabilized on a similar common denominator and allow free software what it does best, develop applications alongside open standards, formats and protocols.

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 29, 2006 7:30 UTC (Tue) by niner (subscriber, #26151) [Link]

I don't think GUI *design* will ever be standardized. It's just too much a matter of taste and competing goals. While the Gnome guys want the desktop to appeal to the most brain-dead "Oh my god there are two buttons in this window, I don't know what to do anymore" type of people, KDE want's to empower it's users and give them any choice they can think of. And there are other kinds of users, like the "I want to program my own desktop in a language called config file" fvwm2 users, and many others.

After all, Windows and Mac desktops are very different either. It's just naturally, that on Linux there is more than one choice.

the article overstates the goals of Portland

Posted Aug 28, 2006 20:27 UTC (Mon) by stevenj (guest, #421) [Link]

The article gives the impression that the Portland project aims to unify all the programming interfaces used for GNU/Linux. For example, reading the article might make you think that Portland wants to unify Qt and Gtk into a single API.

However, if you actually read the Portland web page, it seems that their goals are much more modest and practical. They only want to provide a standard interface for a small set of basic tasks, like sending an email or disabling the screensaver. Even their ambitious "long-term" tasks are things like determining the default printer.

Get a grip.

the article overstates the goals of Portland

Posted Aug 28, 2006 20:41 UTC (Mon) by josh_stern (guest, #4868) [Link]

Yeah, the linked article is even worse than you make it sound.

On the day when the instructor for Prose 101 introduced the idea of the three part essay - intro (tell 'em what you will say), middle (say it), and conclusion (tell 'em you said it) - this guy must have cut class and then made up his own version - intro (introduce a bogus description of your subject), middle (ramble on), and conclusion (complain about usage of the same bogus terminology you just introduced yourself in the intro).

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 28, 2006 20:46 UTC (Mon) by ajross (subscriber, #4563) [Link]

I'd be happy if distros would just start installing both Qt and Gtk+ runtimes by default. Right now, it's essentially impossible to provide a modern GUI binary that will run on an arbitrary linux installation.

Now that the era of ABI instability is behind us, it's possible to generate a binary that will run pretty much anywhere. But that's no use unless there is a core list of libraries on which you can depend.

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 28, 2006 22:59 UTC (Mon) by sfeam (subscriber, #2841) [Link]

"I'd be happy if distros would just start installing both Qt and Gtk+ runtimes by default."

Ugh. Please, no. I already resent the large number of Gtk libraries that get dragged in if I install firefox. So far I've been living with that, but it represents a large bolus of (IMHO) junk that is not used by anything else on the system. I am very close to abandoning firefox for this reason [that and the unusably bad file browser].

Choice is good. As in, "let me choose which I want, and don't force-feed me that one I don't want".

The Portland project: No silver bullet for hairy problem of multiple

Posted Aug 28, 2006 23:41 UTC (Mon) by beoba (guest, #16942) [Link]

What fraction of your harddrive's capacity is occupied by GTK or QT?

The Portland project: No silver bullet for hairy problem of multipledesktops (Linux.com)

Posted Aug 28, 2006 23:48 UTC (Mon) by nix (subscriber, #2304) [Link]

A 'large bolus'? A trivial bit of ldd | ... | bc indicates that firefox's
direct DT_NEEDED shared library dependencies total 12Mb, including some
that are part of firefox itself and libc.

Compare that to the total uncompressed size of firefox itself: 60Mb.

That's not only not bloat, it's not even much of firefox's runtime memory
consumption (and most of those binaries are paged out most of the time
anyway). It's a vanishingly ignorable disk space cost unless you're on an
embedded system or an all-in-flash system like OLPC. Any machine fast
enough and with enough RAM to run Firefox at all will be able to swallow
its shared library load without even blinking.

(By comparison, the same bit of scriptage on the comparatively
runtime-memory-efficient Konqueror shows that it drags in shared libraries
totalling 26Mb, and of course there are dlopen()ed objects on top of
that...)

Gtk itself, hm, 30Mb for the whole thing (installed from source); Qt 3.3.6
totals 55Mb (in both cases including docs; the libraries alone are 18Mb
for Qt versus *4Mb* for Gtk. Sorry, even this hardened KDE fan must admit
that for disk space consumption Gtk wins hands-down. The picture doesn't
change much if you drag in pango, atk, glib and cairo.)

(grumble this is free software why don't people do a trivial bit of
*research* before spouting grumble)

The Portland project: No silver bullet for hairy problem of multipledesktops (Linux.com)

Posted Aug 29, 2006 18:28 UTC (Tue) by oak (subscriber, #2786) [Link]

> Any machine fast enough and with enough RAM to run Firefox at
> all will be able to swallow its shared library load without even
> blinking.

Hm. Sometimes I'm running Epiphany (i.e. using the same HTML rendering
engine as Firefox) on a P166 with 96MB of RAM. I don't know why, but
relatively speaking the switching between the menus is much slower than
the page rendering, the page rendering is of acceptable speed (works as
fast as the 33.6Kbs modem can fetch them). When I tested, the Firefox
menus were as slow as Epiphany's Gtk2 menus. (this was on Breezy)


> (By comparison, the same bit of scriptage on the comparatively
> runtime-memory-efficient Konqueror shows that it drags in shared
> libraries totalling 26Mb, and of course there are dlopen()ed objects
> on top of that...)

Library size is not that bad as it should be all readonly/pagable,
whereas dlopen()ed libs cannot be prelinked. Prelinking would save
a lot in memory usage of C++ code because C++ code has a lot of symbols
that need to be relocated.

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 29, 2006 11:01 UTC (Tue) by Frej (subscriber, #4165) [Link]

Back those arguments up with measurements of lost performance.
Like "amount of disk space lost vs total size of disk." I doubt it really matters....

Or, what about
"how kopete runs slower because of gtk libraries located on disk"
I would love to see that one!

My claim, is that the only reason you think it's bloat is because you see the names of packages that are installed. If you didn't see any names, you wouldn't notice.

Please prove me wrong.

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 29, 2006 18:46 UTC (Tue) by Richard_J_Neill (subscriber, #23093) [Link]

This does actually matter. I just built a silent media PC out of an old thinkpad, replacing the HDD with a 1GB CF card, to make it quiet. The performance is extremely good. However, 1GB is only *just* enough to get
a minimal KDE + Amarok + Firefox + VLC + a few utilities.

I already removed every unncecessary package (without breaking dependencies) - and I had to then go through the system with 'du -sh *' and 'rm -rf' to make more space (eg removed some fonts, all of /usr/share/doc, parts of the X-server). This is Mandriva - and Ubuntu, SuSe, and Fedora wouldn't even do a minimum install < 1 GB !

So, agreed that most desktops should install everything, but please let's make them removable. Example: rpmdrake (the GUI for urpmi) has a requirement on cups, sane, mDNSresponder..)

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 29, 2006 21:52 UTC (Tue) by xtifr (subscriber, #143) [Link]

> I already resent the large number of Gtk libraries that get dragged in

But you already have GTK, so I don't see why you'd complain. Nothing would change for you. Me, I have no Qt whatsoever, and plan to do everything in my power to keep it that way.

The Portland project: No silver bullet for hairy problem of multiple desktops (Linux.com)

Posted Aug 28, 2006 23:18 UTC (Mon) by einstein (subscriber, #2052) [Link]

> I'd be happy if distros would just start installing both Qt and Gtk+ runtimes by default.

Perhaps I've been spoiled all these years running suse. So, you mean to tell me that other distros *don't* ship both by default?

> Right now, it's essentially impossible to provide a modern GUI binary that will run on an arbitrary linux installation.

That's funny, I'd been downloading binaries for years, which ran nicely on slackware, redhat, fedora and suse - e.g. netscape, quake 3 arena, etc

In any case, who cares about "arbitrary linux installations"? that way lies madness, forget it. A realistic target would be "any LSB compliant linux workstation" - which includes the major players - suse, redhat, (debian?) and to the extent that other distros follow the LSB it will work for them as well.

The Portland project: No silver bullet for hairy problem of multiple

Posted Aug 29, 2006 14:11 UTC (Tue) by beoba (guest, #16942) [Link]

In the example of Q3A, it's probably all rendered in opengl, so wouldn't need a GUI lib (outside of the ogl libs). Not sure about Netscape, though. Perhaps some version of GTK?

How binary-compatible are the GTK and Qt API's between versions?

The Portland project: No silver bullet for hairy problem of multiple

Posted Aug 29, 2006 14:42 UTC (Tue) by ajross (subscriber, #4563) [Link]

How binary-compatible are the GTK and Qt API's between versions?
They're both pretty good. Qt, of course, has been hamstrung by the kaleidoscopic g++ ABI which for a few years made pretty much any C++ incompatible with the same library on every other distro. But hopefully those days are behind us now. The core library works very hard to maintain binary compatibility within major versions (although, unfortunately, they just did another one last summer: when KDE 4.x ships it will break compatibility with current code AFAIK).

Gtk+ has been more successful at the compatibility game. This is partly because it's a C library, but also because they picked a more "soft coded" architecture which allows for added functionality without changing linker-visible symbols. They broke compatibility only once, at version 2.0, and no further major version bumps appear to be coming in the near future. If I had to pick just one library that was available on all systems, this would be the one.

The Portland project: No silver bullet for hairy problem of multiple

Posted Aug 28, 2006 21:14 UTC (Mon) by dwheeler (guest, #1216) [Link]

This is a pretty bad article. Start with a fundamental misunderstanding, then complain about the something they aren't doing.

They're simply trying to make sure that users can choose whatever desktop they prefer, and run whatever app they prefer. Much simpler, and more practical. I think they're already succeeding in their aims, which are much more modest - and closer to what real users want anyway.

The Portland project: No silver bullet for hairy problem of multiple

Posted Aug 28, 2006 23:51 UTC (Mon) by nix (subscriber, #2304) [Link]

But having multiple GUIs available confuses people! All the UI gurus (in
MS's pay?) say so!

(bah. I'm happy running KDE atop fvwm with xemacs and a large helping of
GNOME apps, with gtk-qt to merge the look-and-feels a bit.)

Multiple variants of the same old...

Posted Aug 29, 2006 8:12 UTC (Tue) by eru (subscriber, #2753) [Link]

But having multiple GUIs available confuses people! All the UI gurus (in MS's pay?) say so!

Multiple user interface conventions confuse people, and that is not just UI gurus, it is also a personal experience... but otherwise the underlying machinery is irrelevant, as long as it works. Both Gnome, KDE and most other desktop systems nowadays approximate the "Windows conventions". If you configure Gnome and KDE to some similar theme, it can be hard to tell them apart, if you are in a hurry.

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds