The problem with Java right now is that the target platform is Linux, and Linux does not support Java all that well even with proprietary solutions. There is no free version of AWT/Swing at all. This is changing, but it hasn't yet changed.
Many of the GNOME developers really like Java, it's just not practical yet for Linux applications.
Miguel and Nat's Helix Code company is hiring about 16 people (in addition to Nat and Miguel) to write an Outlook clone called Evolution, and they've already been working on it for several months. Since there are so many hackers on it it should certainly end up being finished and be pretty cool.
In an ideal infinite-development-time world I think you are right, but you're not presenting a balanced view of the situation; there are a number of tradeoffs.
Separating the engine from the GUI ("model-view-controller") makes the single-GUI architectural work a good bit harder up-front; we tend to do this religiously in large GNOME apps anyway, (though to save time you usually end up using GtkObject - or QObject in Qt - in order to do it).
Once you separate MVC you still have to write the same GUI multiple times for each platform! Nontrivial.
Another approach is to develop a cross-platform framework for the VC part of MVC, as AbiWord does; but this _significantly_ slows down development, if you look at Mozilla or AbiWord development compared to say Gnumeric you can see this very clearly. Gnumeric moves _at least_ twice as fast, if not more, and with fewer developers. So I'd say factor of four increase in development time.
You encounter a least-common-denominator problem where you can't support nice platform-specific features (for example, AbiWord wants to use Bonobo but can't until they write an OLE/Bonobo abstraction layer, a big barrier to entry; Mozilla has an elaborate XPCOM architecture to solve this problem).
Developers have to learn/understand those additional platforms; and to really make it work the lead developer needs two development environments on at least two platforms.
Anyway as a first cut, GNOME stuff is generally written with MVC in mind, and works on any UNIX running X, regardless of whether you're actually using the GNOME desktop environment (you only have to install the libs, your environment can be KDE or E or whatever).
The next portability step will be to use GTK as a cross-platform kit, as the GIMP does to run on Win32/BeOS; then eventually someone might invest the time to move apps to an AbiWord type of framework. However, doing all this stuff from the start would just be a failure, since we'd have no useful apps for the next 3 or 4 years.
a plethora of so-called open source software licenses, that are almost, but not quite, as free as the GPL
X-style license, LGPL, MPL, etc. are all just as free as the GPL, even according to RMS. These licenses vary along other dimensions than freeness.
On the other hand there are indeed "confusion licenses" such as Sun's Community Source License.
It is a widespread misconception that RMS or anyone else considers non-GPL free licenses "less free." They just consider them "less good at promoting free software."
May seem like a nitpick, but you have to understand this conceptual issue to understand free software licensing. It is important to know that non-GPL licenses are still part of RMS's "GNU system" or the Debian distribution or any other 100%-free system.
GNOME can be used for proprietary software without any fees. However, this is not legal advice and you should read the GNU Library General Public License and understand how its terms apply to you.
The dialog gives you a process ID you can use to attach with gdb/DDD or send an abort signal to the process. This is the most reliable way to implement this feature I think; Gimp had code to attach gdb on segfault for a long time, and it didn't work that well.
Right, the panel menu has problems. It is actually checking for newly-added entries, which appear dynamically. So it's doing a bunch of slow filesystem access. But this feature probably isn't worth the speed hit.
We'll definitely want to look at fixing this code for 2.0.
The control center could use some optimization as well, you're right.
Well, I never maintained any packages. I was working on the Debian Tutorial but John and Ossama's book makes that obsolete. I'm still in principle working on gnome-apt but it is stalled waiting for a better tree widget; that's a really big job, and I don't have a month to work on it in the near future. But I do intend to when I get a chance.
Here is some explanation from Miguel about why Imlib is being replaced: a. refcouting is implemented properly, there is no concept mixing between refcounting and caching which disabled us from activating things like the thumbnail support in the file manager as it would have leaked every single image loaded. b. It keeps the alpha channel in the image and it handles it correctly. This means that we can finally ship an image viewer that shows the alpha channel as well as not breaking the image (the previous ones replaced the alpha above 50% for a magenta color). c. It enables us to use all the power of libart and the image support in the Canvas correctly (because the ArtPixbuf data structure has been there since GNOME 1.0, it is not a recent addition). So, all in all, gdk-pixbuf will actually reuse existing code, while being correct.
I don't know of an ORBit book in the works, though it would certainly be nice. Someone just contributed a nice CORBA tutorial which you can find on developer.gnome.org The GTK+ maintainers are writing a GTK+ book, which should be nice; and the GTK+ reference docs are moving along and will probably be published sooner or later
Keep in mind that one book can't be everything. This is a sort of "intermediate-to-advanced GTK+/Gnome programming manual". An introductory tutorial, complete reference, CORBA book, XML book, etc. would all fill pretty thick books on their own. I already wrote 492 pages instead of the planned 350.:-)
But I think you'll find lots of useful information in my book, and of course you can check it out online at the above URL and decide for yourself.
Slashdot Mirror
The problem with Java right now is that the target platform is Linux, and Linux does not support Java all that well even with proprietary solutions. There is no free version of AWT/Swing at all. This is changing, but it hasn't yet changed.
Many of the GNOME developers really like Java, it's just not practical yet for Linux applications.
Miguel and Nat's Helix Code company is hiring about 16 people (in addition to Nat and Miguel) to write an Outlook clone called Evolution, and they've already been working on it for several months. Since there are so many hackers on it it should certainly end up being finished and be pretty cool.
In an ideal infinite-development-time world I think you are right, but you're not presenting a balanced view of the situation; there are a number of tradeoffs.
Anyway as a first cut, GNOME stuff is generally written with MVC in mind, and works on any UNIX running X, regardless of whether you're actually using the GNOME desktop environment (you only have to install the libs, your environment can be KDE or E or whatever).
The next portability step will be to use GTK as a cross-platform kit, as the GIMP does to run on Win32/BeOS; then eventually someone might invest the time to move apps to an AbiWord type of framework. However, doing all this stuff from the start would just be a failure, since we'd have no useful apps for the next 3 or 4 years.
X-style license, LGPL, MPL, etc. are all just as free as the GPL, even according to RMS. These licenses vary along other dimensions than freeness.
On the other hand there are indeed "confusion licenses" such as Sun's Community Source License.
It is a widespread misconception that RMS or anyone else considers non-GPL free licenses "less free." They just consider them "less good at promoting free software."
May seem like a nitpick, but you have to understand this conceptual issue to understand free software licensing. It is important to know that non-GPL licenses are still part of RMS's "GNU system" or the Debian distribution or any other 100%-free system.
GNOME can be used for proprietary software without any fees. However, this is not legal advice and you should read the GNU Library General Public License and understand how its terms apply to you.
irc.gimp.org
The dialog gives you a process ID you can use to attach with gdb/DDD or send an abort signal to the process. This is the most reliable way to implement this feature I think; Gimp had code to attach gdb on segfault for a long time, and it didn't work that well.
Right, the panel menu has problems. It is actually checking for newly-added entries, which appear dynamically. So it's doing a bunch of slow filesystem access. But this feature probably isn't worth the speed hit.
We'll definitely want to look at fixing this code for 2.0.
The control center could use some optimization as well, you're right.
Well, I never maintained any packages. I was working on the Debian Tutorial but John and Ossama's book makes that obsolete. I'm still in principle working on gnome-apt but it is stalled waiting for a better tree widget; that's a really big job, and I don't have a month to work on it in the near future. But I do intend to when I get a chance.
Here is some explanation from Miguel about why Imlib is being replaced: a. refcouting is implemented properly, there is no concept mixing between refcounting and caching which disabled us from activating things like the thumbnail support in the file manager as it would have leaked every single image loaded. b. It keeps the alpha channel in the image and it handles it correctly. This means that we can finally ship an image viewer that shows the alpha channel as well as not breaking the image (the previous ones replaced the alpha above 50% for a magenta color). c. It enables us to use all the power of libart and the image support in the Canvas correctly (because the ArtPixbuf data structure has been there since GNOME 1.0, it is not a recent addition). So, all in all, gdk-pixbuf will actually reuse existing code, while being correct.
Please keep in mind that I don't speak for Red Hat, these are my personal preferences. I'm talking about the GNOME default anyway, not the RH one.
Nope I answered all the questions I was sent.
People seem to be wondering about GNOME status. Please see this page on the developer site.
What are you smoking?
It's 492 pages long with a small font, I wrote all the example programs, and it was not the first GTK+ book - Eric Harlow's was.
I don't know of an ORBit book in the works, though it would certainly be nice. Someone just contributed a nice CORBA tutorial which you can find on developer.gnome.org The GTK+ maintainers are writing a GTK+ book, which should be nice; and the GTK+ reference docs are moving along and will probably be published sooner or later
Please see http://developer.gnome.org/doc/GGAD for more information about the book.
Keep in mind that one book can't be everything. This is a sort of "intermediate-to-advanced GTK+/Gnome programming manual". An introductory tutorial, complete reference, CORBA book, XML book, etc. would all fill pretty thick books on their own. I already wrote 492 pages instead of the planned 350. :-)
But I think you'll find lots of useful information in my book, and of course you can check it out online at the above URL and decide for yourself.