Slashdot Mirror

One of the strengths of Firefox for some time has been that right out of the box, the binary just ran on lots of Linux versions. With FF3 (starting with betas) they broke this.

Good. Firefox has a large enough memory footprint without statically compiling all the libraries into it just because someone might want to run it on an outdated distro.

FF3 requires a pretty new library (libpangocairo 1.0). I spent an hour trying to come up with it this afternoon for my 100+ users. No luck so far.

Cairo is available from http://www.cairographics.org/. Pango is available from http://www.pango.org/. What, exactly speaking, is the problem ?

The firefox team really let us down big time. We've been anxiously awaiting this release because it's supposed to solve the memory bloat problems (several of us here have to restart the browser several times a week because it's consumed insane amounts of RAM).

Using the same shared libraries as everything else will reduce memory usage, because that way there will only be a single copy of the code in memory. Statically compiling libraries into programs for distribution was always a stupid, stupid, stupid hack.

Now, maybe the Firefox team should also provide a self-contained Firefox version for people who insist on using it on outdated distros - it's not much work, just a single linker flag if I remember correctly - but that certainly shouldn't be the default.

Ummm, BIDI?

I know the last time I wanted to search for font information, overly sexually active monkey

And, as proof of their brilliant naming schemes, Bonobo has nothing to do with fonts. It's their COM architecture.

For font information, you want the obviously-named Pango.

I mean, of course.

GTK2 is mostly slower because all text layout is now done with pango. Pango does a huge range of language typesetting, and AFAIK, Qt is still behind in this area.

I thought the Pango project, and therefore Gnome 2.x, already supported Devanagari. If that is true, why is this legacy Gnome 1.x project being announced now?

I think this webpage is quite old. The IndiX screenshots are from XFree86 4.0.3. The Netscape screenshots are definitely old, too. How could TDIL have "recently released" this?

I thought the Pango project, and therefore Gnome 2.x, already supported Devanagari. If that is true, why is this legacy Gnome 1.x project being announced now?

I think this webpage is quite old. The IndiX screenshots are from XFree86 4.0.3. The Netscape screenshots are definitely old, too. How could TDIL have "recently released" this?

Simputer from India has support for the complex Indic languages.
However, for Japanese and Arabic (with bidi support), I guess the best option would be to run gtk2 - whose pango text layout engine supports complex scripts.
I don't know what PDA has gtk2 based apps, you'll have to find out for yourself.

• Build is complicated.
  
• Some people were under the *wrong* impression that GNOME was slower than KDE. Later on, we benchmarked both, and noticed that GNOME is faster, and smaller than KDE (GNOME 2.2 vs KDE 3.1). So that is not really an issue, but a bad reputation we had from GNOME 1.4
  
• Integrated file manager/browser. This one is the only thing that people have repeatedly said they find confusing about GNOME.
  

This is a moot point, as the plethora of character encodings will eventually disappear in favor of Unicode. Language tags inside the text will then give the renderer hints which it can use to select a font according to its Unicode coverage tables. Fontconfig for Unix, e.g., can already provide Unicode coverage information and if I'm not completely mistaken, language tag development is happening in Pango, the text renderer.

The mapping of key codes to characters is done by the input driver with a keymap. Modern systems all map their keys to unambiguous Unicode values.

The problem of character encodings is dying a slow and painful death.

The best software example I can give that "makes things right" is Gtk 2. With the right fonts installed, every script supported by Unicode "just works" out of the box and in every aspect of the system.

The problems faced are lack of free opentype fonts(preferred for handling numerous ligatures & glyphs & their substitution), support for opentype fonts at the X-level. No, indix(linked by another user) won't solve the issue atleast in the present form, since it breaks a lot of X-protocols. Pango holds promise, but it is not being adopted by QT & it will take some time for rendering engines of all indic languages for Pango to be developed.

The plus side is serious efforts are being made to resolve the issue. OT Fonts are available for a few indic languages & existing ttf's are being converted into otf's,Gnome & KDE translation work is going on (some like my own mother tongue 'kannada' is being translated on WinXP) for some indic languages like hindi,kannada, tamil(one of the first indic languages to be translated), etc.,

The things that we should be alarmed is Microsoft's is on the upper hand: It has OT font's for all indic languages besides input engines, OTF rendering support & BillG who is making his 3rd visit to India has already signalled the need for localisation. And if i am not wrong the fonts have been developed with the aid of the local govt. And they are not in public domain or atleast freely usable on linux.

For more details, see: Indic computing mailing lists-search the indic_computing_devel mailing list for extensive criticism of indix & also the kde 18n mailing list. indlinux,kannada mailing list

Btw, here's another example of MS cosying upto the karnataka govt. The bhoomi s/w(up for this year's stockholmn tech award) may cost nearly 40 lakhs per taluk. A NGO, I currently am in touch with was successful in persuading the officials to look at the possibility of developing it on linux. And projects like this need indic support urgently.

Arial Unicode was available for download with a click-through licence that basically required you to say "I own a copy of FrontPage 2000". I don't have a down-loaded version to hand to check the exact words. I noticed it had been removed from the MS web site a few weeks ago and I just assumed that they had re-organised their web site -- they have never seemed to care about the persistance of URIs...), but I guess I was wrong and it was a conscious decision to remove it.

The reason why Arial Unicode is (was?) important is that as far as I can make out it's the only way to put several languages on the web (using Unicode), specifically Indic ones, including Punjabi and Gujarati. The site that uses these languages I worked on can be found here.

There is no support for Indic languages in X11 (or OSX AFAIK). Gnome2 and Pango should fix this though :-)

Windows still has the best internationalisation support (most languages), but a default Red Hat install with the latest Mozilla is getting very good -- all the demo languages on the Unicode web site work with no problems and also all the UTF-8 samples on this page work -- this is better then Windows 2000 (I have not tried with later versions).

We know about this. Most users don't notice any problem. Some users have major problems. We acknowledge this and it's another one of our highest priorities for the next version.

The next version will use Pango and FreeType and, on *nix, probably client-side-fonts via xft.
I believe there are still some issues to get printing working properly with these newer *nix font solutions but we welcome any input.

MS Word does do a better job if i18n than us right now but, after tables and footnotes/endnotes, improving i18n is our next highest priority. We have a special metabug right now to track tricky multilinal problems.
Work is already underway to add Pango and FreeType support.

Even without them our Chinese support is very good, our Hebrew support is also very good (make sure you get the bidi-build), and our Arabic support should be good but I'm not sure how much testing it has received.

So try it out with all the languages you want and file some bug reports!

• Myth: KDE is more integrated than GNOME
  
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac.

• Myth: KDE is easier to use
  
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. What about application (see GNOME apps later) installation and removal: GNOME has the excellent RedCarpet by Ximian , which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase... which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post on a zealot-ridden site can reduce the result to a running joke. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system - and indeed, can co-exist except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead. Both Hewlett- Packard and Sun Microsystems have committed to using GNOME as the desktop for their Unix systems. This ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME effort is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror is a fine piece of software - it's authors deserve plently of praise - it is, however, quite unreliable and lax in its support of basic web standards compared to either Mozilla or Opera . It is also extremely slow - slower than the latest incarnations of the GNOME Nautilus filemanager/browser.

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  
  Reality: See also: Qt/TrollTech. Easily the most common wail heard by KDE developers - and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt . KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2. GNOME applications wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet ,X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade , Anjuta . All of these packages ooze quality, far outclass and are, at least, 18 months ahead of their KDE/Qt counterparts. It's not only in the area of user applications that GNOME is lightyears ahead, with the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo ), media (Gstreamer ), internationalisation (pango ). As a developement platform, GNOME 2.x is, frankly, years ahead of KDE. And what's more, it is not tied to a lowest common denominator cross-platform bloat-fest like Qt. Yet despite all this, we are still fed the lie that Qt and C++ makes development easier. Judge for yourself.

• Myth: KDE is faster and/or takes less memory than GNOME
  
  Reality: KDE is written in C++. While this is not necessarily a bad thing, it is when the programmers do not know enough to avoid certain pitfalls that can plague software projects. Stupid use of ++/-- with C++ objects; masses of unnecessary allocations and deallocations of memory, and the most cretinous of all, blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the KDE architecture and basic design.

• Myth: GNOME development is slower. KDE releases faster.
  
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the consequent problems with libraries. It bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version. Occasional releases of the entire GNOME system are done, and that's when the GNOME version number is bumped (currently it is 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  
  Reality: Qt started out as non-Free. KDE developers knew this violated the GPL and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Labyrinthine licensing nightmare.

• Myth: Most good GNOME apps are actually GTK applications.
  
  Reality: Most KDE apps, such as those from The Kompany are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

• Myth: KDE is attractive/GNOME/GTK is ugly
  
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

Yeah, the look is pretty much the same. Probably the coolest is Pango, which is the text layout engine behind GTK+ 2.0. There are some older screenshots at pango.org.

Most of the advantage, though, is at the API level.

Fountain claims that you can't write GTK apps which support multibyte character sets like Japanese needs. Obviously he's never used GNOME in Japanese or Chinese. When Pango is stable, his comments will no longer be merely wrong, they will be laughable.

I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.

I have to ask what people who use Netscape for mail have been doing now that Mozilla is shaping up. I've used Netscape for my mail client for many years now (only for the facts that it is firstly a decent GUI client, as far as Unix clients go, and that it can display HTML mail), but Mozilla just doesn't cut it for me.

The widgets for lists and trees are terrible in Mozilla (at least on Unix), and it really makes me wish that the Moz folks had decided to stay with Gtk+ for the toolkit, rather than rolling their own for the sake of portability.. I'm not sure they knew what they were getting into with a new toolkit, especially since they'll probably have to deal with the same things that the Pango folks are..

Anyway, back to my initial query -- what are people using instead? There have been a number of clients based on toolkits like Tk (blech) and even straight Athena widgets (triple blech). The nicer-looking clients (IMHO) seem to be all glam and no substance.. What's up with that?

If someone can find me a 3-pane Gtk+ or Gnome GUI client that is stable and that can handle PGP/GPG, I'd be forever grateful.
--

I am an English speaker, and thus don't know a whole lot about the ins and outs of many of the world's languages, let alone ones that are written from right to left. But I have been watching the efforts of the Pango project, which seems to be helping bring more exotic character sets to Gtk. It isn't done yet, but seems to have made great progress thus far. Perhaps you just need to hold out a little longer and things will sway in your direction...

There's a screenshot of the right-to-left capabilities of Pango on their web page.

Specifically, Hebrew and Arabic text, right-to-left, appear in the middle of the document.

There's a screenshot of the right-to-left capabilities of Pango on their web page.

Specifically, Hebrew and Arabic text, right-to-left, appear in the middle of the document.

Oops, here's the correct link:

Pango

I am sick about seeing Outlook and Outlook Express clones on Linux that will never get as close to the level of i18n support that Outlook Express has simply because the underlying system (e.g. X Windows or GTK ) do not provide a decent framework to build i18n-enabled applications.

Well the dependency on the X font server is getting less and less in the development code. Take a look at Pango to see what they are up to. They have got some nice screenshots of things like the text widgets being able easily represent languages that move right to left(Arabic etc).

Bidi HTML rendering is of course great, but not enough. I admit i haven't tried running it yet (don't currently have access to a Linux machine :( ), so maybe i'm just talking bullshit and correct me if i'm wrong, but AFAIK:

1. Qt/KDE doesn't yet support true BIDI input and selection.

2. The Hebrew po (translation) files for KDE seem to be visually ordered, which means that stuff like button/widget/dialog labels, window captions etc are not truly reordered.

3. Again, _correct me if i'm wrong_, but it seems that in current KDE beta widget placing in a window is left-to-right and it's hard-coded. In a completely internationalized system the direction of the entire window/dialog/whatever should be localizable. Pango seems to already get it right; compare the screenshots: Pango (look at the end of the page) and KDE (notice the colons at the wrong side of the labels).

Now i don't mean to diss KDE; the opposite is true: i love it, i just wished for a long time that they developed a complete bidi solution. Now that both Qt/KDE and Gnome/Pango are both clean GPL they can easily share code and will really speed things up.

I'm not really concerned about polka-dotted scrollbars either, but there are some other areas where platform widgets tend to fall down (especially current GTK, as it turns out), and some of those are pretty important. Things like variable opacity for input widgets (this whole article is about variable-alpha, right?) and support for mixed font sets in input widgets (key for decent i18n support). The GTK i18n stuff is being improved dramatically by the Pango project, but it's not ready to deploy yet.

Pluggable toolkit support is broken in M16, but will be repaired, and it then might be possible for you to build your own libwidget_darchmare.so that uses all-native stuff. I'm not really expert on the widget-construction code.

Take a look at here!

Szo

Actually, you probably don't need Miguel for that. You might want to check out the Pango, which is a project to incorporate unicode into Gtk. That is being rolled into GNOME as an intrinsic component as of (what is now being projected as) the November GNOME release, which will basically be GNOME 2.0 -- slated to come out November 2000 (hence the name). This is detailed in the O'Reilly Summary of the GUADEC conference.

Keep in mind that I don't follow it very closely, so it's possible that this doesn't actually address your question. In which case I'll shut up now :-)

--
It's a fine line between trolling and karma-whoring... and I think you just crossed it.
- Sean