LWN.net Logo

GNOME's Project Ridley

From:  Jonathan Blandford <jrb-AT-redhat.com>
To:  gtk-devel-list-AT-gnome.org, desktop-devel-list-AT-gnome.org
Subject:  Announcing: Project Ridley
Date:  21 Aug 2005 00:50:24 -0400
Archive-link:  Article, Thread


Now that GTK+-2.8.0 is out, the GTK+ team would like to announce Project
Ridley.

GOALS:

The primary goal of Project Ridley is to cut down on the number of
problem libraries that are part of the GNOME platform.  We propose to do
this by moving functionality into GTK+, wherever it makes sense.  These
libraries are generally small, undermaintained, and buggy.  They have an
unclear purpose (such as libgnome and libgnomeui), are copied-and-pasted
around (such as libegg) or would benefit by being in GTK+ (libgnomeprint
and libgnomeprintui.)

We have been sending confusing messages to ISVs, free software and
otherwise, as to what they should be using to develop applications.  By
cleaning up these widgets and deprecating the libraries, we can make it
much simpler for developers.  To emphasize the 'consolidated platform'
message, we are considering to call the GTK+ version incorporating the
results of Project Ridley GTK+-3.0.

The secondary goal is to bring people currently working on the platform
together in a coordinated effort.  We would love to bring more people
into the GTK+ team and get people working on the platform again.

WHO SHOULD GET INVOLVED:

Anyone who's currently writing code for platform tasks.  As we're
targeting GTK+ for this work, it has to be written in C.

HOW TO GET INVOLVED:

We put up a a wiki page detailing the tasks we'd like to accomplish at:

http://live.gnome.org/ProjectRidley

A few of the widgets have people actively looking at them, though all
could use help.  There are tasks of all sizes, ranging from simple
cleanup and renaming of an existing widget to designing a cross-platform
printing api to writing a kick-ass, fully-functioning cairo-based
canvas.

We don't want to create a new list for this effort, and would like
followup mail to be sent to gtk-devel-list@gnome.org.


(Log in to post comments)

GNOME's Project Ridley

Posted Aug 22, 2005 16:11 UTC (Mon) by Zarathustra (guest, #26443) [Link]

Have they understood yet the meaning of "cross-platform", and that Gnome and Unix are two completely different platforms?

If so, I'll be the first one to applaud their move.

-- A Unix user that expects Unix behavior when running "cross-platforms" applications in Unix systems.

P.S.: I don't care what GTK does when running under Gnome, Windows, or Plan 9, but I'd guess it should work as the users of each platform expect. (As Plan 9 user, I hope no one ever ports GTK to it, we are much better off without it ;))

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 16:52 UTC (Mon) by elanthis (guest, #6227) [Link]

Have the UNIX users realized that UNIX is not a platform, but that it's a loose collection of disparate software based around low-level design themes and which can be cobbled together in countless different ways with no real cohesion or targetable behavior? GNOME/GTK is a platform. KDE/Qt is a platform. UNIX is an operating system. Windows has both a platform and an operating system component. OS X is a platform, on top of the Darwin/UNIX operating system. Platforms can exist independent of the operating system, as GTK demonstrates; a pure-GTK application can run on Win32 and UNIX and behave the same on both, as a pure-GTK application targets the GTK platform, which is implemented on top of the Win32 and UNIX operating systems.

That is largely my problem with cross-platform GUI systems. There is no such thing. The only way to target the actual Win32 platform with GTK would require you to do things that wouldn't mesh with or work on GNOME+UNIX or OS X. If you want a real cross-platform application, you have to develop for each platform. See Abiword for an excellent example of doing that. Not only does it run on GNOME, Windows, and OS X, but it actaully targets the platforms for each, and looks and acts differently on each of them. The difference between Abiword and, say, Evolution is vital. One is a truly cross-platform app, while the other is a single-platform app that runs on multiple operating systems.

Your UNIX apps can be compiled for Darwin/UNIX, but don't mesh with OS X. They can be compiled for Cygwin/USFW, and they don't mesh with Windows. Just because you compile your apps on your Linux/BSD/Solaris box and they run right next to GTK apps doesn't mean that GTK must bend-over backwards to support your apps any more than Windows or OS X should. UNIX is just an operating system, a collection of low-level services for running an application, or for supporting an actual platform... such as GTK+GNOME.

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 16:57 UTC (Mon) by arcticwolf (guest, #8341) [Link]

You're confusing "GUI" or "desktop environment" with "platform". A platform is a pretty abstract concept - it's not defined in terms of what the programs/libraries/toolkits/kernels that you use, but rather in terms of culture, continuity and the "stuff you expect", so to speak.

In that sense, Unix *is* a platform, simply because things have worked a certain way in Unix (all Unices!) for such a long time that nowadays it's the way everyone does it. You may not like the fact that selecting immediately copies the text to the (imagined) clipboard and that middle-clicking pastes; but that's the way it is, and even though you are free to change your system to better suit your own needs/wants, such a change shouldn't be forced on everyone.

That's not to say things can't change. They can, but the way to go is evolution, not revolution. How can anyone be so naive to think that working against their users rather than with them is a winning strategy?

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 17:37 UTC (Mon) by hp (subscriber, #5220) [Link]

How cut and paste works on UNIX was defined in the ICCCM in the early 90s, and clarified later since the ICCCM is somewhat ambiguous:
http://standards.freedesktop.org/clipboards-spec/clipboar...
With agreement from most every project (GNOME, KDE, Firefox, Emacs, OpenOffice, etc.) though some still don't implement exactly what the guidelines say due to bugs.

Also, as documented in the first point in the GTK+ 2.0 release notes in 2002, there is a config option to turn off the select-text-on-focus behavior and the ctrl+c/ctrl+v keybindings if you like.

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 19:44 UTC (Mon) by brouhaha (subscriber, #1698) [Link]

ICCCM is a spec for how cut and paste should work in X clients, not how they should work in Unix. There isn't any Unix-wide concept of cut-and-paste. Nor should there be, IMNSHO.

UNIX isn't a targetable platform for GUI applications

Posted Aug 23, 2005 11:44 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

"You may not like the fact that selecting immediately copies the text to the (imagined) clipboard and that middle-clicking pastes; but that's the way it is,"

No, that's not the way it is, and people who keep spreading this misinformation do a lot to confuse new users.

Selecting does nothing except change the primary selection, and the middle button pastes the _current selection_. The clipboard is a totally separate selection, and always has been. For example I can _select_ some text, hit Edit/Copy and that puts it onto the _clipboard_ now I select more text, and hit Edit/Paste and that pastes the _clipboard_ over the _selection_ replacing it.

Only some ancient Qt/ KDE versions get this stuff completely wrong, and it took a few years to get them to fix it. That's unfortunate (and doesn't say good things about Trolltech's / KDE project's testing) but it's fixed now and people should concentrate on chasing down the few rogue applications that aren't doing it properly, rather than imagining some entirely different mechanism that's less powerful AND incompatible.

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 17:52 UTC (Mon) by Zarathustra (guest, #26443) [Link]

So you are basically saying that Mozilla is not ported to Unix. Great, then could the Mozilla people please write a Unix port? Thanks.

As for the difference between Abiword and Evolution, I could not care less, Unix already has troff and there are many Unix email clients to chose from.

It's so hard to understand that (real) Unix users don't care for Gnome and want nothing to do with it? (just like Gnome developers never cared for Unix and never wanted to bother understanding it)

GTK has two choices, either can be the Gnome Toolkit, or can be a cross-platform toolkit which happens to work in a Gnome environment as well as in various others, but it can't be both.

And I agree with mbligh's comments, just what GTK needs, more bloat, ugh. talk about not understanding the Unix philosophy.

Note: IMHO in most cases the words "platform" and "environment" can be used interchangeably, it might be argued that "platform" has more development related connotations, but "environment" has been used in that context too for a long time, for example see the Unix Bible: The Unix Programming Environment by Brian Kernighan and Rob Pike.

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 18:31 UTC (Mon) by loening (guest, #174) [Link]

"GTK has two choices, either can be the Gnome Toolkit, or can be a cross-platform toolkit which happens to work in a Gnome environment as well as in various others, but it can't be both."
Have you ever done any programing using gtk+, let alone libgnome or libgnomeui? I don't think you have any idea what you're talking about it, and I'll call you on it.

libgnomeui and libgnome (as well as libgnomecanvas) are libraries of widgets and other low level functionality that were written by the GNOME guys because the associated functionality was not in GTK at the time. This stems from the late 90's, when GTK was literally the toolkit for GIMP, and little else.

Despite their name, these libraries are for the most part NOT specific to GNOME. For instance, libgnomecanvas compiles cleanly under windows, it's really got nothing specifically to do with the GNOME environment and has no dependencies on the rest of the GNOME stuff. As another example, over the past half decade, much of the widget functionality that was originally only in libgnomeui has already migrated into GTK and been deprecated in libgnomeui.

As a developer of an app that uses GTK, this consolidation will be a great benefit to me. It'll help keep the portions of libgnomecanvas and libgnomeui that I've been using from suffering from bitrot, and it'll also greatly simplify the windows port of my application.

"As for the difference between Abiword and Evolution, I could not care less, Unix already has troff and there are many Unix email clients to chose from. "
And apparently I'm not a (real) UNIX user, as I use troff when troff is appropriate, but I'm willing to use Abiword when Abiword is appropriate. Allright, then just call me a Linux user. You can go back to living in 1988, and I'll go back to being productive.

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 19:01 UTC (Mon) by Zarathustra (guest, #26443) [Link]

> Have you ever done any programing using gtk+, let alone libgnome or libgnomeui?
Yes, unfortunately I have done quite a bit of gtk+ programming, but I avoid it as much as I can. And I think you missed my point(which admittedly was somewhat offtopic).

> call me a Linux user. You can go back to living in 1988
I'm sorry, but I think you are confused about who is stuck in the 70's; aside from Unix and it's clones(like Linux), which I only use when I have no other option(and when I have to, I like it to work as expected, which is what this whole rant was about); otherwise I like to use modern operating systems.

No, my terminal windows don't emulate an ASR-33.

Modern OSes

Posted Aug 23, 2005 11:35 UTC (Tue) by bojan (subscriber, #14302) [Link]

> otherwise I like to use modern operating systems.

WOW! You actually have access to all 3 computers in the world that run those. Amazing ;-)

UNIX isn't a targetable platform for GUI applications

Posted Aug 22, 2005 19:58 UTC (Mon) by elanthis (guest, #6227) [Link]

"So you are basically saying that Mozilla is not ported to Unix. Great, then could the Mozilla people please write a Unix port? Thanks. "

It's ported to the UNIX OS. It's not ported to any UNIX platform. Mozilla itself *is* a platform, and is often refered to as such - it provides a GUI system, integrated programming/scripting language, and an rather extensive standard library. You can build and deliver complete applications using Mozilla completely independently of the underlying OS that Mozilla is currently running on.

Mozilla looks, acts, and behaves alien on UNIX compared to any non-Mozilla app you run next to it, and the same is true on Windows and OS X. That being why projects like Camino and Epiphany exist - to take Gecko and integrate it with a native user environment/platform/pick-whatever-term-you-want.

UNIX isn't a targetable platform for GUI applications

Posted Aug 23, 2005 3:06 UTC (Tue) by karath (subscriber, #19025) [Link]

"It's so hard to understand that (real) Unix users don't care for Gnome and want nothing to do with it? (just like Gnome developers never cared for Unix and never wanted to bother understanding it)"

I am sure that it is not what you intend, but this (just one quote selected from among several) comes across as incredibly arrogant. It seems to say that there is a "Religion" of Unix and anyone that does not get it is not worthy.

regards,
Charles

UNIX isn't a targetable platform for GUI applications

Posted Aug 23, 2005 19:03 UTC (Tue) by Zarathustra (guest, #26443) [Link]

Maybe it was intended.

"Those who don't understand UNIX are condemned to reinvent it, poorly." - Henry

UNIX isn't a targetable platform for GUI applications

Posted Aug 23, 2005 11:42 UTC (Tue) by bojan (subscriber, #14302) [Link]

> GTK has two choices, either can be the Gnome Toolkit, or can be a cross-platform toolkit which happens to work in a Gnome environment as well as in various others, but it can't be both.

That's quite clear. It is (primarily and for most purposes) and Gnome Toolkit. Gnome folks (mostly) write and maintain it, so it is only logical that Gnome is its intended purpose.

Have a look at the URL for project Ridley and it will be immediately clear.

GNOME's Project Ridley

Posted Aug 23, 2005 10:33 UTC (Tue) by lacostej (guest, #2760) [Link]

Why do you complain about Gnome & Unix each time you see a Gnome article?

If you don't like gnome don't use it. If you're forced to use it, complain to them, not here (Yes I know you've reported them your issues). But it serves no point doing it here. At least not on each Gnome post.

And I really don't understand how porting an application to your OS would make your life worse. Isn't more choice better?

Porting GNOME to Windows

Posted Aug 22, 2005 16:20 UTC (Mon) by proski (subscriber, #104) [Link]

Since GTK is cross-platform, incorporating GNOME libraries it it would mean porting them to Windows. This could eventually facilitate porting some GNOME applications to Windows. In particular, having Evolution for Windows would be great. Anything that keeps users from Outlook and Outlook Express is a great boon for our networked civilization.

Porting GNOME to Windows

Posted Aug 22, 2005 19:43 UTC (Mon) by mbanck (subscriber, #9035) [Link]

People at Novell (most notably Tor Lillqvist, http://tml-blog.blogspot.com) are doing that, and evolution is their target.

Michael

GNOME's Project Ridley

Posted Aug 22, 2005 17:06 UTC (Mon) by nix (subscriber, #2304) [Link]

In http://live.gnome.org/LibgnomeMustDie, Havoc says:

> my view is that GNOME should drop XSMP entirely

What are session-management-aware window managers going to do, then? You have to ask GNOME apps to save their state somehow, and moving completely away from XSMP means that gnome-session ceases to be able to save the state of non-GNOME apps, and any other session manager ceases to be able to save the state of GNOME apps! Please say this is not what you meant :)

GNOME's Project Ridley

Posted Aug 22, 2005 17:51 UTC (Mon) by hp (subscriber, #5220) [Link]

The point is to just drop session management as defined in xsmp. Users don't use it because it doesn't work reliably, since it's too hard to implement in the apps. In my experience more apps are broken than working (and nobody even bothers to report the bugs)

If apps want to save state, XSMP complexity is all around supporting multiple saved states (multiple sessions), which we don't have exposed in the UI anyhow. So rather than XSMP apps could just remember their state in global settings (or e.g. per-screen-size settings).

Of course most apps won't do this, just like they don't save anything in response to XSMP requests, but ;-)

Add to that a way to say "start these apps on login" and combine that with dbus which manages any behind-the-scenes services to be started.

There are a few ways we could do WMs remembering window sizes on login, depending on desired UI. I proposed a "serialized wm state" property once on wm-spec-list, or startup-notification can maybe be used.

GNOME's Project Ridley

Posted Aug 22, 2005 18:40 UTC (Mon) by jwb (guest, #15467) [Link]

FWIW I completely agree on dumping XSMP. It just doesn't work at all, or nobody implements it properly. When I login to GNOME I get the great window storm of xterms that aren't where they were (and of course aren't doing what they were doing before), a Nautilus window that I didn't have open before which is churning my hard drive like mad, usually 2 or more GAIM login windows, a blank copy of Acroread that is complaining about a file in /tmp that's gone, and all sorts of other chaos. I can't see how this is useful.

At the very least cutting out session support would disabuse developers of the notion that it's supposed to work.

By the way, if I have your ear, does GTK+ 2.8 have treeview multiple-row drag? The last two LWN stories on GTK+ were useless flamefests, so we didn't learn a lot about new features.

GNOME's Project Ridley

Posted Aug 22, 2005 18:47 UTC (Mon) by walters (subscriber, #7396) [Link]

AFAIK 2.8.0 doesn't have multiple drag, but Matthias at least said they want to get the libegg fix for this into the next GTK+. Whether that's 2.8.1 or 2.8.2 or whatever, I don't know.

GNOME's Project Ridley

Posted Aug 22, 2005 19:13 UTC (Mon) by jrb (subscriber, #31610) [Link]

Multiple-row DND for the TreeView has long been planned, and is on the Project Ridley Wiki page. An implementations exist, and it is certainly possible to implement this on your own. It will probably land for GTK+-2.10.

Restoring sessions

Posted Aug 22, 2005 19:27 UTC (Mon) by bronson (subscriber, #4806) [Link]

Now that suspend to disk works reliably I have no need whatsoever for a session manager. Sessions have been no end of headache. Personally, I would not lament the loss of XSMP one bit.

GNOME's Project Ridley

Posted Aug 22, 2005 21:11 UTC (Mon) by nix (subscriber, #2304) [Link]

That's peculiar: I have, oh, no problems here (KDE 3.4.2). The only app that doesn't restore its state is XEmacs, and that's because full state saving for an Emacs would be... rather hard.

(Oh, and I *do* use multiple saved states; I have multiple displays and multiple X servers with different capabilities. Handling that is something else Gtk dropped when it forgot that X resources existed.)

GNOME's Project Ridley

Posted Aug 23, 2005 2:09 UTC (Tue) by rise (guest, #5045) [Link]

I'll second that. Under XFCE almost all apps play nicely with sessions for me - XMMS included - and KDE worked almost as well. When I used Gnome sessions were basically useless. The only place I have trouble is with subset of apps launched from a terminal, everything started from menus or a variety of run dialogs (including program arguments) is launched and placed correctly. I don't know if the XFCE and KDE developers are hacking around the problem, but Gnome has the resources to do it as well... just not the will or mindset. I've seen nothing out of that camp in the last few years to contradict the impression of arrogance, NIH syndrome, and obsession with some mirage-like Right Thing(tm) in place of functionality. It's unfortunate that there are a lot of good developers in the Gnome project, but they're not the ones making the decisions. Anyone up for a deadpool on when or if Gnome hits its own XFree86/X.org-style day of reckoning?

GNOME's Project Ridley

Posted Aug 23, 2005 21:15 UTC (Tue) by job (guest, #670) [Link]

I agree. All KDE apps seems to restore properly, with the right child windows open, the right working directory etc. I haven't tried multiple profiles but I would probably use it if I knew how it works; I could use different setups for work and play for example.

GNOME's Project Ridley

Posted Aug 24, 2005 23:07 UTC (Wed) by nix (subscriber, #2304) [Link]

What I was impressed by was that got restoring of programs <i>running on different hosts</i> working right. It even managed to restore programs running on different hosts with unusual things exported into their environments (although I think fvwm-2.5.12 takes some of the credit for that).

If you want to use anything other than rstart (ick!) to invoke remote stuff, you have to hack gnome-session and recompile it. Doing the same in KDE is a matter of one line in a config file (`xonCommand' in the General section of share/config/ksmserverrc) and one script that runs `ssh -f "$@"'. It's still not documented well enough in KDE, but at least you don't actually need to rebuild things to make it work.

GNOME's Project Ridley

Posted Aug 22, 2005 20:12 UTC (Mon) by ajross (subscriber, #4563) [Link]

> The point is to just drop session management as defined in
> xsmp. Users don't use it because it doesn't work reliably, since
> it's too hard to implement in the apps.

It's worth pointing out that the "restore my desktop to the state it had when I was last using it" problem, which session management was invented to address, is not more generically handled by suspend/hibernate facilities or remote desktop protocols (VNC et. al.).

I'm not sure this is nearly as important as it once seemed. I wouldn't be sad to see it go.

GNOME's Project Ridley

Posted Aug 22, 2005 17:07 UTC (Mon) by mbligh (subscriber, #7720) [Link]

Great. Because what we really need is for the gnome core libs to be even more mind-blowingly bloated than they are already. Obviously a fine plan.

GNOME's Project Ridley

Posted Aug 22, 2005 17:39 UTC (Mon) by hp (subscriber, #5220) [Link]

Did you read the article? The point is to reduce number of libs and allow apps to stop linking to old cruft.

GNOME's Project Ridley

Posted Aug 22, 2005 17:44 UTC (Mon) by iabervon (subscriber, #722) [Link]

It beats being both mind-blowingly bloated and insufficient at the same time. The current scheme breaks out parts of the system into separate libraries, even though they can't be omitted and aren't ever used on their own. Of course, a loftier goal is to migrate more of that stuff to places where it is more widely useful, as is being done with Cairo.

GNOME's Project Ridley

Posted Aug 22, 2005 23:49 UTC (Mon) by njhurst (guest, #6022) [Link]

I think that this is a great opportunity to clean up the fragment libgtk+ related librarys. Some people seem to think that libgnome is a gnome specific library, in reality it is mostly useless cruft that someone thought would be a good idea at some point and should be refactored into useful bits that are kept, and the rest thrown. I even go so far as to suggest that for the next release of gnome these vestigial libraries are removed to provide incentive to clean up code.

I think that with a bit of care much of the useful stuff in these endless extra libraries could actually be merged into libgtk+ by enhancing the APIs for common widgets. The biggest problem with gtk is the incomplete APIs - the original project only implemented what the gimp needed (a good plan if you want to get something finished). Unfortunately, the gtk maintainers have been quite reluctant to add extra functionality, so people go and reimplement the whole thing again (either from scratch, or by copy and paste). It looks like project ridley is moving in the right direction, one thing I suggest is that someone does a complete survey of existing gnome and gtk apps and finds out what stuff people use and want, and then prioritise from that. I'm sure that it could be done with some suitable sed scripts or something.

GNOME's Project Ridley

Posted Aug 23, 2005 7:00 UTC (Tue) by petegn (guest, #847) [Link]

At LAst .

Maybe when all this brohaha has died down you MIGHT end up with a gnome that is usefull , Instead of one that farts and dies at the least provocation it is a freakin lib nightmare at the moment ...

PS kde blows gnoe clean out of existance always had and always will .

:-)...

Pete .

GNOME's Project Ridley

Posted Aug 23, 2005 14:10 UTC (Tue) by coriordan (guest, #7544) [Link]

As a Debian user, I don't know what a lib nightmare is. Maybe you should find a better GNU/Linux distribution.

GNOME's Project Ridley

Posted Aug 23, 2005 16:02 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

Let's explain "lib nightmare" in Debian terms.

A "lib nightmare" is when {apt-get,aptitude,synaptic,insert-apt-frontend-name-here} wakes up one morning and decides that you must remove all 794 of your favorite application packages because some package you've never heard of wants you to upgrade some library you've never heard of.

GNOME's Project Ridley

Posted Aug 23, 2005 20:44 UTC (Tue) by drag (subscriber, #31333) [Link]

Then you select "no", don't do apt-get dist-upgrade, but a regular everyday apt-get upgrade and then upgrade the rest of the packages and go back to work.

Then 2-3 weeks later that obscure package gets upgraded along with everything else because the stuff finished moving out of experimental and into unstable, which is what your using becuase this stuff doesn't happen in stable, or at least very very rarely.

debian, libraries, gnome, etc.

Posted Aug 24, 2005 0:39 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

And then you get an inconsistent Gnome setup, which is half from one release and half from another release, though all dependencies are satisfied, and your desktop malfunctions. That was the case for long periods of time when certain Gnome upgrades were percolating through. This problem would be reduced with fewer libraries.

debian, libraries, gnome, etc.

Posted Aug 24, 2005 15:48 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

KDE has a different solution: make everything depend on exactly one version of kdelibs, so it's impossible to upgrade anything (not even the C++ compiler) without upgrading everything.

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