Slashdot Mirror

http://l10n-status.gnome.org/ [gnome.org]
http://l10n-status.gnome.org/HEAD/index.html
[gnome.org] Translation stats for Gnome/Gtk+.

http://i18n.kde.org/stats.php [kde.org]
http://i18n.kde.org/stats/gui/stable/index.php
[kde.org] Translation stats for KDE.

There are a plethora of bugs plaguing Linux-on-the-desktop. I know, because I've moved our sales department to a Linux desktop. Let me tell you: there are serious problems.

- Nautilus doesn't correctly check permissions of files it's deleting, and gives incorrect 'permission denied' errors. This bug is 5 years old! It prevents people from ... wait for it ... being able to delete files with their file manager. Did I mention that it's 5 years old? http://bugzilla.gnome.org/show_bug.cgi?id=40990

- Multiple, crippling bugs in gtk+ prevent any serious application development:
http://bugzilla.gnome.org/show_bug.cgi?id=317387
http://bugzilla.gnome.org/show_bug.cgi?id=156017
http://bugzilla.gnome.org/show_bug.cgi?id=308474
http://bugzilla.gnome.org/show_bug.cgi?id=161837

Most of the above bugs are over 1 year old, and have basically never been touched by a gtk+ developer. Of course, over the period of the past year, there have been numerous major gtk+ releases, as well as numerous major gnome releases. The problem is that fixing critical bugs doesn't "scratch anyone's itch", so nothing gets done.

I imagine people would recommend that I try out QT instead of gtk+, but the licensing doesn't really suit me ( have to pay big dollars for a commercial license ), and I'm not convinced that the situation would be any different anyway.

After watching the 'progress' of the above bugs for over a year, I can tell you now why people aren't developing any applications for Linux-on-the-desktop: because the desktop is too fucking bug-ridden, and that doesn't appear to be about to change.

There are a plethora of bugs plaguing Linux-on-the-desktop. I know, because I've moved our sales department to a Linux desktop. Let me tell you: there are serious problems.

- Nautilus doesn't correctly check permissions of files it's deleting, and gives incorrect 'permission denied' errors. This bug is 5 years old! It prevents people from ... wait for it ... being able to delete files with their file manager. Did I mention that it's 5 years old? http://bugzilla.gnome.org/show_bug.cgi?id=40990

- Multiple, crippling bugs in gtk+ prevent any serious application development:
http://bugzilla.gnome.org/show_bug.cgi?id=317387
http://bugzilla.gnome.org/show_bug.cgi?id=156017
http://bugzilla.gnome.org/show_bug.cgi?id=308474
http://bugzilla.gnome.org/show_bug.cgi?id=161837

Most of the above bugs are over 1 year old, and have basically never been touched by a gtk+ developer. Of course, over the period of the past year, there have been numerous major gtk+ releases, as well as numerous major gnome releases. The problem is that fixing critical bugs doesn't "scratch anyone's itch", so nothing gets done.

I imagine people would recommend that I try out QT instead of gtk+, but the licensing doesn't really suit me ( have to pay big dollars for a commercial license ), and I'm not convinced that the situation would be any different anyway.

After watching the 'progress' of the above bugs for over a year, I can tell you now why people aren't developing any applications for Linux-on-the-desktop: because the desktop is too fucking bug-ridden, and that doesn't appear to be about to change.

There are a plethora of bugs plaguing Linux-on-the-desktop. I know, because I've moved our sales department to a Linux desktop. Let me tell you: there are serious problems.

- Nautilus doesn't correctly check permissions of files it's deleting, and gives incorrect 'permission denied' errors. This bug is 5 years old! It prevents people from ... wait for it ... being able to delete files with their file manager. Did I mention that it's 5 years old? http://bugzilla.gnome.org/show_bug.cgi?id=40990

- Multiple, crippling bugs in gtk+ prevent any serious application development:
http://bugzilla.gnome.org/show_bug.cgi?id=317387
http://bugzilla.gnome.org/show_bug.cgi?id=156017
http://bugzilla.gnome.org/show_bug.cgi?id=308474
http://bugzilla.gnome.org/show_bug.cgi?id=161837

Most of the above bugs are over 1 year old, and have basically never been touched by a gtk+ developer. Of course, over the period of the past year, there have been numerous major gtk+ releases, as well as numerous major gnome releases. The problem is that fixing critical bugs doesn't "scratch anyone's itch", so nothing gets done.

I imagine people would recommend that I try out QT instead of gtk+, but the licensing doesn't really suit me ( have to pay big dollars for a commercial license ), and I'm not convinced that the situation would be any different anyway.

After watching the 'progress' of the above bugs for over a year, I can tell you now why people aren't developing any applications for Linux-on-the-desktop: because the desktop is too fucking bug-ridden, and that doesn't appear to be about to change.

There are a plethora of bugs plaguing Linux-on-the-desktop. I know, because I've moved our sales department to a Linux desktop. Let me tell you: there are serious problems.

- Nautilus doesn't correctly check permissions of files it's deleting, and gives incorrect 'permission denied' errors. This bug is 5 years old! It prevents people from ... wait for it ... being able to delete files with their file manager. Did I mention that it's 5 years old? http://bugzilla.gnome.org/show_bug.cgi?id=40990

- Multiple, crippling bugs in gtk+ prevent any serious application development:
http://bugzilla.gnome.org/show_bug.cgi?id=317387
http://bugzilla.gnome.org/show_bug.cgi?id=156017
http://bugzilla.gnome.org/show_bug.cgi?id=308474
http://bugzilla.gnome.org/show_bug.cgi?id=161837

Most of the above bugs are over 1 year old, and have basically never been touched by a gtk+ developer. Of course, over the period of the past year, there have been numerous major gtk+ releases, as well as numerous major gnome releases. The problem is that fixing critical bugs doesn't "scratch anyone's itch", so nothing gets done.

I imagine people would recommend that I try out QT instead of gtk+, but the licensing doesn't really suit me ( have to pay big dollars for a commercial license ), and I'm not convinced that the situation would be any different anyway.

After watching the 'progress' of the above bugs for over a year, I can tell you now why people aren't developing any applications for Linux-on-the-desktop: because the desktop is too fucking bug-ridden, and that doesn't appear to be about to change.

There are a plethora of bugs plaguing Linux-on-the-desktop. I know, because I've moved our sales department to a Linux desktop. Let me tell you: there are serious problems.

- Nautilus doesn't correctly check permissions of files it's deleting, and gives incorrect 'permission denied' errors. This bug is 5 years old! It prevents people from ... wait for it ... being able to delete files with their file manager. Did I mention that it's 5 years old? http://bugzilla.gnome.org/show_bug.cgi?id=40990

- Multiple, crippling bugs in gtk+ prevent any serious application development:
http://bugzilla.gnome.org/show_bug.cgi?id=317387
http://bugzilla.gnome.org/show_bug.cgi?id=156017
http://bugzilla.gnome.org/show_bug.cgi?id=308474
http://bugzilla.gnome.org/show_bug.cgi?id=161837

Most of the above bugs are over 1 year old, and have basically never been touched by a gtk+ developer. Of course, over the period of the past year, there have been numerous major gtk+ releases, as well as numerous major gnome releases. The problem is that fixing critical bugs doesn't "scratch anyone's itch", so nothing gets done.

I imagine people would recommend that I try out QT instead of gtk+, but the licensing doesn't really suit me ( have to pay big dollars for a commercial license ), and I'm not convinced that the situation would be any different anyway.

After watching the 'progress' of the above bugs for over a year, I can tell you now why people aren't developing any applications for Linux-on-the-desktop: because the desktop is too fucking bug-ridden, and that doesn't appear to be about to change.

Your 100% right. All I hear is cringely this, cringely that.

The guy does not make innovative statements, and its more just repeated well known information. He doesn't even offer decent solutions.

If you look around, Gnome for instance develops new ideas and starts bounties for them.. http://www.gnome.org/bounties/

If you want new technology ideas, Auzy has his own set (which actually covers this) http://auzy.blogspot.com/2006/02/auzys-technology- predictionswishlist.html

Now if you look at Cringely's, its already well known information, and his solutions are lacking. His not even trying to solve the issues. How this got into Slashdot and concepts by gnome or Auzy didn't is quite saddening.. its gotten to the point that every week its Cringely said this. The authors obviously dont know what people want.

I think I hate to say this, but I dont think I'll be hanging out at slashdot much anymore. Its turned into quite a sad state.

- Resistant Memory

Hark! I hear the sound of somebody who hasn't use Linux in years.

Support for most printers is there out of the box. Both my HP Laser and my Epson Printer/Scanner were supported out of the box on the current and previous versions of Ubuntu. That's printing *and* scanning.

Again, on the latest version of Ubuntu, there's an option in the main menu, under Graphics, called gtkam which you might notice because it has a little picture of a digital camera next to it. Click it and you can interface with most digital cameras. No driver installation necessary. Alternatively, just plug your memory card into your card reader and an icon for the card will appear on your desktop. I'm having a hard time imagining how they could make it any simpler.

Several of the Linux audio players have in-built support for the iPod. The default media player for Kubuntu, amaroK, does, as does the default media player for Ubuntu, Rhythmbox.

OK, this one is supported but you're going to have to install an application to deal with it. Luckily, Ubuntu comes with a graphical utility to install programmes. All you have to do is tell it to install Kino and you're sorted.

So please, when you're going to diss Linux, at least have the decency to try it first.

$ find /etc/|grep gnome|wc
    158 158 10424

Did you miss the Gnome 2.14 announcement?

Cairo integration?

Cairo Snippets

Go down on this page to the section labelled "Sharp Dressed Man".

Cairo Introduction

It's good stuff, and exactly what you are asking for, I think.

"XGL is a different X server. This is a more incremental change which is slated to become part of Xorg. We don't believe that replacing the entire X server is the right path, and that improving it incrementally is a better way to modernize it. After talking to people at xdevconf, it felt like much of the upstream Xorg community shares this view. You can search Adam Jackson's notes for "large work for Xgl" to get the blow-by-blow or NVidia's presentation from XDevConf 2006 on using the existing model.

We've been working on the AIGLX code for a some time with the community, which is in direct contrast with the way that XGL was developed. XGL spent the last few months of its development behind closed doors and was dropped on the community as a finished solution. Unfortunately, it wasn't peer reviewed during its development process, and its architecture doesn't sit well with a lot of people.

The other question is Wait, can I use compiz? The answer there is a theoretical yes, although no one has actually gotten it to work. We love compiz and we think it's great stuff and is well polished, but it's often confused with the underlying architecture of XGL. Much like the code that we've added to metacity, compiz is a composite manager. With a bit of work, it should be possible to get compiz working on this X server. There's an excellent post from Soren on the topic of compiz vs. metacity."

How can they talk about graphics advances without screenshots? I believe the term used these days is "TTIWWP".

They can get away with not giving you screen shots because they give you movies

How can they talk about graphics advances without screenshots? I believe the term used these days is "TTIWWP".

They can get away with not giving you screen shots because they give you movies

How can they talk about graphics advances without screenshots? I believe the term used these days is "TTIWWP".

They can get away with not giving you screen shots because they give you movies

My GNOME browser has a File menu too; whilst arguably a web page is a file, IMO it would make more sense to the user to have a Page menu instead - Page->Open, Save, Print, View Source etc.

In fact everything seems to have a File menu, even my Terminal. I guess stuff like a Quit menu item should go in a Program or App menu.

For a group like GNOME, with their Human Interface Guidelines I'd have thought they would sort out the menus sensibly and intuitively, not design them for refugees of other UIs.

http://developer.gnome.org/projects/gup/hig/1.0/me nus.html#the-file-menu

But anyway, 2.14 seems like they've focussed on good goals like improving performance, and even added a feature to Metacity, window edge resistance! Rejoice!

[...] if you're making a user-oriented app like a windows environment in OSS, why would you choose to regress to naming binaries after development names?

There is nothing wrong with that. Giving binaries a short name (project name or codename) means that they are easier to type. Advanced users who invoke GUI programs from the command line instead of using the menus are likely to know the project name anyway. If I use the command line, it is easier to type "gimp" than "Image Editor" or "GNU Image Manipulation Program" (note that auto-completion would not help much if you also have "Image Viewer", "Image Search", etc.).

The command line is supposed to be efficient, not descriptive. It would be impractical for the frequently used commands such as "cd", "ls", "cp" and others to have descriptive names. So it makes sense to use short names for the command line (even if they may be a bit obscure for those who do not know their origin) and use longer, more descriptive names for the desktop menus.

By the way, OSS is not the only environment that uses different names for the command line and for the menus. For example, look at the names of control panel components in Windows: descriptive names in the menus, cryptic names for the command line.

For your information, here is a direct link to the chapter of the GNOME HIG dealing with menu item names. It contains good examples of descriptive names. This was published two years ago, so any application that still uses cryptic names in the menus is violating these guidelines and should be fixed.

they write software.

Give me a break. "According to developers".. bullshit. You didn't ask them.

From the gnome-screensaver FAQ:

Why doesn't the screensaver preferences tool allow me to change the settings for the theme?

We are trying to take a different approach. We would prefer for the themes to simply work.

From Bug 316654 - no ability to configure the different screensavers, which is resolved and marked WONTFIX:

I don't have any plans to support this. My view is that any screensaver theme that requires configuration is inherently broken.

From Bug 316655 - no ability to full screen preview individual screensavers, which is also resolved and marked WONTFIX:

There are no plans to implement this feature. I don't think this feature solves any real problems.

Res ipsa loquitur.

Give me a break. "According to developers".. bullshit. You didn't ask them.

From the gnome-screensaver FAQ:

Why doesn't the screensaver preferences tool allow me to change the settings for the theme?

We are trying to take a different approach. We would prefer for the themes to simply work.

From Bug 316654 - no ability to configure the different screensavers, which is resolved and marked WONTFIX:

I don't have any plans to support this. My view is that any screensaver theme that requires configuration is inherently broken.

From Bug 316655 - no ability to full screen preview individual screensavers, which is also resolved and marked WONTFIX:

There are no plans to implement this feature. I don't think this feature solves any real problems.

Res ipsa loquitur.

Give me a break. "According to developers".. bullshit. You didn't ask them.

From the gnome-screensaver FAQ:

Why doesn't the screensaver preferences tool allow me to change the settings for the theme?

We are trying to take a different approach. We would prefer for the themes to simply work.

From Bug 316654 - no ability to configure the different screensavers, which is resolved and marked WONTFIX:

I don't have any plans to support this. My view is that any screensaver theme that requires configuration is inherently broken.

From Bug 316655 - no ability to full screen preview individual screensavers, which is also resolved and marked WONTFIX:

There are no plans to implement this feature. I don't think this feature solves any real problems.

Res ipsa loquitur.

both the links are /.ed here are some pics: http://www.gnome.org/~davyd/gnome-2-14/

Boooooorrriiiiiiiing...

Perhaps this is because it is designed to look rather generic/clean/sterile out of the box so that it fits in nicely in any home or buisness environment. If you want something more exciting or personalized, there is absolutely no one stopping you from taking five minutes and visiting places like art.gnome.org or www.gnome-look.org

Personally, I don't care for the default look, but some of the fun was in customizing the appearance and making it my own.

That being said, it would be interesting to see something like Tango! gain more widespread use.

If it only offered "Yes" and "No", what would you click when you didn't want to exit at all?

The button in my mail reader that sends a message - in particular, a message to the "report a bug/deficiency here" address for the application in question - or the button in my mail browser to submit such a bug; if it only offered "Yes" and "No", that'd be a deficiency.

"Yes", "No", and "Cancel" might be an improvement, but the human interface guidelines for the desktop I referred to suggest that "Button names should correspond to the action the user performs when pressing the button--for example, Erase, Save, or Delete", so "Don't Save", "Cancel", and "Save" are even more of an improvement.

The GNOME Human Interface Guidelines make a similar suggestion:

Write button labels as imperative verbs, for example Save, Print. This allows users to select an action with less hesitation. An active phrase also fits best with the button's role in initiating actions, as contrasted with a more passive phrase. For example Find and Log In are better buttons than than Yes and OK.

so "Yes" and "No" aren't the labels that should be used in most GNOME alert boxes. I'd say they aren't the labels that should be used in most alert boxes in any GUI; the KDE User Interface Guidelines make that suggestion:

Although Yes-No questions have an appealing simplicity, they do have a downside. While the implications of the Yes answer are usually very clear, the implications of the No answer are often not clear at all. The question "Do you want to save your changes?" serves as a good example. Pressing "Yes" will get the changes saved, but what happens when the user presses the "No" button? Rephrasing the question as an Either-Or question will help make this more clear: "Do you want to save or discard your changes?". Now there can be buttons labeled "Save" and "Discard", and the consequences of both are equally clear.

One could debate which of the Macintosh/GNOME convention of "affirmative button on the right" and the Windows convention of "OK as the default button and default button on the left" is better (and perhaps the Windows convention is "better" by virtue of being the one familiar to more people), but neither of them are something done by "NO ONE ELSE ON THE PLANET".

If it only offered "Yes" and "No", what would you click when you didn't want to exit at all?

The button in my mail reader that sends a message - in particular, a message to the "report a bug/deficiency here" address for the application in question - or the button in my mail browser to submit such a bug; if it only offered "Yes" and "No", that'd be a deficiency.

"Yes", "No", and "Cancel" might be an improvement, but the human interface guidelines for the desktop I referred to suggest that "Button names should correspond to the action the user performs when pressing the button--for example, Erase, Save, or Delete", so "Don't Save", "Cancel", and "Save" are even more of an improvement.

The GNOME Human Interface Guidelines make a similar suggestion:

Write button labels as imperative verbs, for example Save, Print. This allows users to select an action with less hesitation. An active phrase also fits best with the button's role in initiating actions, as contrasted with a more passive phrase. For example Find and Log In are better buttons than than Yes and OK.

so "Yes" and "No" aren't the labels that should be used in most GNOME alert boxes. I'd say they aren't the labels that should be used in most alert boxes in any GUI; the KDE User Interface Guidelines make that suggestion:

Although Yes-No questions have an appealing simplicity, they do have a downside. While the implications of the Yes answer are usually very clear, the implications of the No answer are often not clear at all. The question "Do you want to save your changes?" serves as a good example. Pressing "Yes" will get the changes saved, but what happens when the user presses the "No" button? Rephrasing the question as an Either-Or question will help make this more clear: "Do you want to save or discard your changes?". Now there can be buttons labeled "Save" and "Discard", and the consequences of both are equally clear.

One could debate which of the Macintosh/GNOME convention of "affirmative button on the right" and the Windows convention of "OK as the default button and default button on the left" is better (and perhaps the Windows convention is "better" by virtue of being the one familiar to more people), but neither of them are something done by "NO ONE ELSE ON THE PLANET".

http://developer.gnome.org/doc/API/2.0/glib/glib-M emory-Slices.html
http://developer.gnome.org/doc/API/2.0/glib/glib-S tring-Chunks.html
http://developer.gnome.org/doc/API/2.0/glib/glib-C aches.html

They're just specialist memory allocations, however, since they have a particular purpose they can be optimised more than a few calls to malloc would be, and easier to use from an API point of view too.

http://developer.gnome.org/doc/API/2.0/glib/glib-M emory-Slices.html
http://developer.gnome.org/doc/API/2.0/glib/glib-S tring-Chunks.html
http://developer.gnome.org/doc/API/2.0/glib/glib-C aches.html

They're just specialist memory allocations, however, since they have a particular purpose they can be optimised more than a few calls to malloc would be, and easier to use from an API point of view too.

http://developer.gnome.org/doc/API/2.0/glib/glib-M emory-Slices.html
http://developer.gnome.org/doc/API/2.0/glib/glib-S tring-Chunks.html
http://developer.gnome.org/doc/API/2.0/glib/glib-C aches.html

They're just specialist memory allocations, however, since they have a particular purpose they can be optimised more than a few calls to malloc would be, and easier to use from an API point of view too.

That's not Network Manager, that's network-admin. This is Network Manager. The main-page screenshot doesn't show it, but you can right click on the notification area icon and select "Connection information" to get all the TCP/IP config (the old network monitor applet had like 4 steps to get this info and was a major complaint for it's UI).

Memory chunks provide an space-efficient way to allocate equal-sized pieces of memory, called atoms. However, due to the administrative overhead (in particular for G_ALLOC_AND_FREE, and when used from multiple threads), they are in practise often slower than direct use of g_malloc(). Therefore, memory chunks have been deprecated in favor of the slice allocator, which has been added in 2.10. All internal uses of memory chunks in GLib have been converted to the g_slice API.

GStreamer, the official audio backend for GNOME, will include DRM plugins developed by a company called Fluendo, which hopes to make money by restricting the users' rights and turning GNOME/Linux/"the Free Desktop System" into a Vista-like nightmare controlled by the entertainment cartel. Why? Because Fluendo is on the GNOME Foundation's Advisory Board. I can't believe I've been so stupid to actually give them money, so that they can turn around and stab Free Software in the back! Never again will I trust the GNOME Foundation after they sold out the community like this.

I hope KDE is smart enough to avoid DRM by choosing a multimedia backend that is GPL. This will ensure that users can change the code of any plugin, remove the DRM, and be left with a functional product. Xine would be an excellent choice for a multimedia backend, since it is light-weight, works with more codecs that Gstreamer (not to mention better) and can be included as a library in any program, like Kaffeine and Amarok have already done.

GStreamer, the official audio backend for GNOME, will include DRM plugins developed by a company called Fluendo, which hopes to make money by restricting the users' rights and turning GNOME/Linux/"the Free Desktop System" into a Vista-like nightmare controlled by the entertainment cartel. Why? Because Fluendo is on the GNOME Foundation's Advisory Board. I can't believe I've been so stupid to actually give them money, so that they can turn around and stab Free Software in the back! Never again will I trust the GNOME Foundation after they sold out the community like this.

I hope KDE is smart enough to avoid DRM by choosing a multimedia backend that is GPL. This will ensure that users can change the code of any plugin, remove the DRM, and be left with a functional product. Xine would be an excellent choice for a multimedia backend, since it is light-weight, works with more codecs that Gstreamer (not to mention better) and can be included as a library in any program, like Kaffeine and Amarok have already done.

I'm running Mandriva 2005, and although I've found the PalmPilot integration to be quite functional, Evolution is only hot-synching one of my task categories, which is a known bug.

Also, Evince will read both PDF and PostScript documents, and of course OpenOffice can export documents as PDFs.

How about Fedora Core 5:
1. Linux with SELinux enabled
2. Firefox 1.5 and Konqueror with Opera as an option
3. How about making it look the way you want?
4. With Mono, you have Beagle
5. yum for command line, yumex or pup for GUI
6. Gstreamer, xine, mplayer: all installable through yum(ex)/pup
7. Non root accounts plus lockdown
8. All sorts of backup scripts
9. Wiki, CVS, etc.
10. Anaconda or a live CD

I'm aware of abiword (that covers Word, what about Excel?)

Gnumeric.

Note that it requires GTK+ to be installed, but if you already have the GIMP or Gaim or whatever, you should already have that.

I've been using DIA for some serious work and created quite a few UML, ERD and network topology diagrams with it for my employer, but, with experience, I never came to actually like it.

There are some things I like about DIA.

• The compatibility between the Windows and the Un*x versions has been a real enhancer when I had to have flowcharts made and modified between my brother who was on Windows through TurtoiseSVN and myself and another project member who are both (mostly) on Linux.
• It's open source.
• It works very transparantly and its file format is easy enough to parse and understand.

The things I dislike about DIA are more numerous, though. Just a few:

• Connection points on most, if not all, objects are too few.
• Not enough shapes.
• I can't count the number of times I've deleted an object while trying to delete a character, because I forgat to press Right-Arrow, Backspace instead of Delete.
• There's no way to indicate that two lines cross without touching, and it's also impossible to indicate the opposite.
• There's a lot of inconsistency in editing the shapes between shapesets.

All in all, DIA has made my live easier though. And also, I'm not exactly a fan of some of the Windows alternatives such as Smartdraw.

I've been using DIA for some serious work and created quite a few UML, ERD and network topology diagrams with it for my employer, but, with experience, I never came to actually like it.

There are some things I like about DIA.

• The compatibility between the Windows and the Un*x versions has been a real enhancer when I had to have flowcharts made and modified between my brother who was on Windows through TurtoiseSVN and myself and another project member who are both (mostly) on Linux.
• It's open source.
• It works very transparantly and its file format is easy enough to parse and understand.

The things I dislike about DIA are more numerous, though. Just a few:

• Connection points on most, if not all, objects are too few.
• Not enough shapes.
• I can't count the number of times I've deleted an object while trying to delete a character, because I forgat to press Right-Arrow, Backspace instead of Delete.
• There's no way to indicate that two lines cross without touching, and it's also impossible to indicate the opposite.
• There's a lot of inconsistency in editing the shapes between shapesets.

All in all, DIA has made my live easier though. And also, I'm not exactly a fan of some of the Windows alternatives such as Smartdraw.

In my case it's not the file manager, but the file chooser. Gnome developers decided to develop the GTK file chooser. That's nice, but gnome has many other needs that gtk doesn't. Using the file chooser is PAINFUL. You just have the name, and the "modified" field and a list of favourite locations. You can't even order things by SIZE.

You don't have different "views" at all in fact. You can't get a view where all the images are show a small thumbnail instead of a meaningless icon.

I agree about the lack of columns and icon view. However, there are some bugs open about them, and none of them has been WONTFIXed or anything like that, so the design isn't fixed in stone and good implementations would no doubt be welcome, and will probably end up there sooner or later.

And the image formats that will be previewed are the ones supported by the pixbuf GTK plugins: only the formats in in /usr/lib/gtk-2.0/2.x.0/loaders/*. Forget about things that have sense, for example video thumbnails, something that has a LOT of sense if you're going to open a video file in a video editing program.

This, on the other hand is pure unadulterated bullshit. You're obviously not very familiar with the preview API of GtkFileChooser, there is nothing that limits it to the pixbuf loaders. If a video editing program or player wants video thumbnails there, it can easily be done.

Compare it with the KDE file selector, where I even can watch the video.

I took ten minutes to write a small proof of concept: http://www.cc.puv.fi/~e0000274/fsvideo.png, and yes, although I didn't bother to add the controls to throw-away piece of code, it's live video, not snapshot.

In my case it's not the file manager, but the file chooser. Gnome developers decided to develop the GTK file chooser. That's nice, but gnome has many other needs that gtk doesn't. Using the file chooser is PAINFUL. You just have the name, and the "modified" field and a list of favourite locations. You can't even order things by SIZE.

You don't have different "views" at all in fact. You can't get a view where all the images are show a small thumbnail instead of a meaningless icon.

I agree about the lack of columns and icon view. However, there are some bugs open about them, and none of them has been WONTFIXed or anything like that, so the design isn't fixed in stone and good implementations would no doubt be welcome, and will probably end up there sooner or later.

And the image formats that will be previewed are the ones supported by the pixbuf GTK plugins: only the formats in in /usr/lib/gtk-2.0/2.x.0/loaders/*. Forget about things that have sense, for example video thumbnails, something that has a LOT of sense if you're going to open a video file in a video editing program.

This, on the other hand is pure unadulterated bullshit. You're obviously not very familiar with the preview API of GtkFileChooser, there is nothing that limits it to the pixbuf loaders. If a video editing program or player wants video thumbnails there, it can easily be done.

Compare it with the KDE file selector, where I even can watch the video.

I took ten minutes to write a small proof of concept: http://www.cc.puv.fi/~e0000274/fsvideo.png, and yes, although I didn't bother to add the controls to throw-away piece of code, it's live video, not snapshot.

In my case it's not the file manager, but the file chooser. Gnome developers decided to develop the GTK file chooser. That's nice, but gnome has many other needs that gtk doesn't. Using the file chooser is PAINFUL. You just have the name, and the "modified" field and a list of favourite locations. You can't even order things by SIZE.

You don't have different "views" at all in fact. You can't get a view where all the images are show a small thumbnail instead of a meaningless icon.

I agree about the lack of columns and icon view. However, there are some bugs open about them, and none of them has been WONTFIXed or anything like that, so the design isn't fixed in stone and good implementations would no doubt be welcome, and will probably end up there sooner or later.

And the image formats that will be previewed are the ones supported by the pixbuf GTK plugins: only the formats in in /usr/lib/gtk-2.0/2.x.0/loaders/*. Forget about things that have sense, for example video thumbnails, something that has a LOT of sense if you're going to open a video file in a video editing program.

This, on the other hand is pure unadulterated bullshit. You're obviously not very familiar with the preview API of GtkFileChooser, there is nothing that limits it to the pixbuf loaders. If a video editing program or player wants video thumbnails there, it can easily be done.

Compare it with the KDE file selector, where I even can watch the video.

I took ten minutes to write a small proof of concept: http://www.cc.puv.fi/~e0000274/fsvideo.png, and yes, although I didn't bother to add the controls to throw-away piece of code, it's live video, not snapshot.

The real problem is it's slow ... even in comparison to Gnome.

I just don't believe that anymore. Gnome has become a memory and CPU pig: There're reasons why gnome 2.13 has so many performance improvements. KDE used to be a memory pig, but then gnome catched up and their memory usage went trough the roof. By the way, porting applications to QT4 (no functionality) improves the memory usage percentages with double-digit numbers, so there's a chance that KDE 4 eats less memory

The top post also asked "I don't know what the Gnome guys are up to". I wish to know that aswell. KDE is actively developing KDE 4 but Gnome 3 doesn't exist at all today. Some Gnome developers seem to think that gnome 3 shouldn't be developed because gnome 2 is already feature complete and that doing small improvements which don't break compatibility it's a beter option. That sounds good, but I'd say it looks scary: KDE people is actively developing a KDE version which will rock in many ways and Gnome doesn't seem to have nothing to compete against it, except that Fedora now includes mono and more C# apps can be developed. Noveel seem to be the one place where cool things are being done with gnome.

Platform: Console Edition, Desktop Light Edition, Desktop Edition
One Platform: $1780, $1990, $3300
Two Platforms: $2670, $2990, $4950
Three Platforms: $3560, $3980, $6600

After all Aero Glass is mostly based on developments seen quite a while ago in OS X.

Repeating this again and again doesn't make it true. In fact, there are no significant features in Aqua that weren't known and used previously in UIs. In particular, Apple invented neither animation, nor hardware acceleration, nor transparency as part of the UI.

If anything, Apple deserves a good deal of criticism for misrepresenting the Aqua style of GUI as the result of Apple research.

if ya gotta buy a new box to run Vista, then why not just simply make the switch

Indeed, why not make the switch? After all, if it is cutting edge GUI features you desire, Gnome has both Vista and Aqua beat.

Funny thing--due to a small change in a header location in a recent release of a package, it won't build on Ubuntu out of the box; if fixed and compiled, it then crashes on startup. This isn't Mandrake 7.2, or Slackware Version Ancient--this is a fully updated version of one of the three most popular desktop distributions out there. I'm a bit disappointed.

So it's a bit less monumental for us Ubuntu users, alas...

Funny thing--due to a small change in a header location in a recent release of a package, it won't build on Ubuntu out of the box; if fixed and compiled, it then crashes on startup. This isn't Mandrake 7.2, or Slackware Version Ancient--this is a fully updated version of one of the three most popular desktop distributions out there. I'm a bit disappointed.

So it's a bit less monumental for us Ubuntu users, alas...

Well, GnuCash is a GTK app, not a GNOME app.

But all of GTK2 and most of GNOME has already been ported to windows anyway. You can get prebuilt binaries for most of the libraries at: ftp://ftp.gnome.org/pub/gnome/platform/2.12/2.12.0 /win32/dependencies/

I'm not sure how many extraneous libraries GnuCash 1.9 relies on... but if all the libraries already have windows ports, it's really easy. As an example, the last GTK2 app I ported to windows took about 30 minutes of time.

And the native MacOSX GTK2 port seems to be coming along as well.

Since it is slashdotted, here are some excerpts from the site:

The GnuCash development team proudly announces GnuCash 1.9.0 aka "We're gonna make it!", the first of several unstable 1.9.x releases of the GnuCash Open Source Accounting Software which will eventually lead to the stable version 2.0.0. This release is the very first of the gtk2-based GnuCash series, and is intended for developers and adventurous testers who want to help tracking down all those bugs that are still in there.

What's New in GnuCash 1.9.0?
o Welcome to GnuCash 1.9.0 aka "We're gonna make it!" the first of several unstable releases of the GnuCash Open Source Accounting Software which will eventually lead to the stable version 2.0.0. This release is the very first of the gtk2-based GnuCash series and is intended for developers and adventurous testers who want to help tracking down bugs.
o WARNING WARNING WARNING - Make sure you make backups of any files used in testing versions of GnuCash in the 1.9.x series. Although the developers go to great lengths to ensure that no data will be lost we cannot guarentee that your data will not be affected if for some reason GnuCash crashes in testing these releases.
o PLEASE TEST TEST AND TEST SOME MORE any and all features important to you. Then post any bugs you find to bugzilla http://bugzilla.gnome.org/enter_bug.cgi?product=Gn uCash
o If you have the urge to help beyond testing please get involved in the discussions on the GnuCash mailing lists which you will find at http://www.gnucash.org./ We especially need people to help with updating the documentation as all texts refer currently to the 1.8.x series. Please see http://wiki.gnucash.org/wiki/Development on how to get involved.
o PS I'm not going to list the many features changed or updated in this release because obviously there is so much that has changed.
Caveats

Caveats for testers:

* Any 1.9.x version might crash unexpectedly at any point during runtime. If you test some serious work in a 1.9.x release, make sure you hit "Save" after ever non-trivial workstep.
* Keep in mind that features which are not used in everyday work might crash unexpectedly at all times. This includes but is not limited to: graphical reports, scheduled transaction editor, price editor, financial calculator, OFX/QIF/HBCI import.
* Especially all the new features might crash instantly on testing. This applies in particular to any of the budget-related features. We may always decide to disable such new features for the initial 2.0.0 release, and re-enable them in a later release.
* The documentation is completely outdated. All help texts usually only refer to the 1.8.x series; please expect all descriptions in the help texts to be totally wrong when applied to the upcoming 1.9.x series. Everyone is invited to help improve the documentation; see http://wiki.gnucash.org/wiki/Development on how to get involved.

How can you help?

* Testing: Test it and help us discover all bugs that might show up in there. Please enter each and every bug into bugzilla at http://bugzilla.gnome.org/enter_bug.cgi?product=Gn uCash
* Translating: The new release comes with plenty of new translation strings. If you consider contributing a translation, we invite you to test this release already, but please keep in mind that we are not yet in our string freeze phase. Please check http://wiki.gnucash.org/wiki/Translation_Status for updates on this, as we recommend to wait for the string

Since it is slashdotted, here are some excerpts from the site:

The GnuCash development team proudly announces GnuCash 1.9.0 aka "We're gonna make it!", the first of several unstable 1.9.x releases of the GnuCash Open Source Accounting Software which will eventually lead to the stable version 2.0.0. This release is the very first of the gtk2-based GnuCash series, and is intended for developers and adventurous testers who want to help tracking down all those bugs that are still in there.

What's New in GnuCash 1.9.0?
o Welcome to GnuCash 1.9.0 aka "We're gonna make it!" the first of several unstable releases of the GnuCash Open Source Accounting Software which will eventually lead to the stable version 2.0.0. This release is the very first of the gtk2-based GnuCash series and is intended for developers and adventurous testers who want to help tracking down bugs.
o WARNING WARNING WARNING - Make sure you make backups of any files used in testing versions of GnuCash in the 1.9.x series. Although the developers go to great lengths to ensure that no data will be lost we cannot guarentee that your data will not be affected if for some reason GnuCash crashes in testing these releases.
o PLEASE TEST TEST AND TEST SOME MORE any and all features important to you. Then post any bugs you find to bugzilla http://bugzilla.gnome.org/enter_bug.cgi?product=Gn uCash
o If you have the urge to help beyond testing please get involved in the discussions on the GnuCash mailing lists which you will find at http://www.gnucash.org./ We especially need people to help with updating the documentation as all texts refer currently to the 1.8.x series. Please see http://wiki.gnucash.org/wiki/Development on how to get involved.
o PS I'm not going to list the many features changed or updated in this release because obviously there is so much that has changed.
Caveats

Caveats for testers:

* Any 1.9.x version might crash unexpectedly at any point during runtime. If you test some serious work in a 1.9.x release, make sure you hit "Save" after ever non-trivial workstep.
* Keep in mind that features which are not used in everyday work might crash unexpectedly at all times. This includes but is not limited to: graphical reports, scheduled transaction editor, price editor, financial calculator, OFX/QIF/HBCI import.
* Especially all the new features might crash instantly on testing. This applies in particular to any of the budget-related features. We may always decide to disable such new features for the initial 2.0.0 release, and re-enable them in a later release.
* The documentation is completely outdated. All help texts usually only refer to the 1.8.x series; please expect all descriptions in the help texts to be totally wrong when applied to the upcoming 1.9.x series. Everyone is invited to help improve the documentation; see http://wiki.gnucash.org/wiki/Development on how to get involved.

How can you help?

* Testing: Test it and help us discover all bugs that might show up in there. Please enter each and every bug into bugzilla at http://bugzilla.gnome.org/enter_bug.cgi?product=Gn uCash
* Translating: The new release comes with plenty of new translation strings. If you consider contributing a translation, we invite you to test this release already, but please keep in mind that we are not yet in our string freeze phase. Please check http://wiki.gnucash.org/wiki/Translation_Status for updates on this, as we recommend to wait for the string

They could have never kept the source closed because it would have to be checked into the Xorg tree eventually. These conspiracy stories are just created by people in certain communities who are scared of Novell. Novell is doing things unconventionally and is actually making some progess. Read more on how Novell is doing things...

Yes, it's about time. Two years ago Sun tried this, then RedHat tried it and from what I can tell both quit. Novell deserves credit for getting it done.