You two are talking past one another. He said that the speed of Nautilus was comparable to Windows Explorer for GNOME2. You are noting that Nautilus lacks some speed for GNOME 1.4. It's quite possible that you both are correct.
Having lots of different modules makes compiling GNOME a real pain but gives developers more fine-grained control on the libraries they include in their applications. The GNOMErs made a decision to favor developers in this regard, figuring end-users would depend upon their distributions or upon Ximian's Red Carpet to handle the rest.
That said, have you tried GARNOME? It makes compiling GNOME very easy, to the happiness of beta-testers everywhere. Cheers!
If you're looking to manage a bunch of terminal windows and a webbrowser, you probably shouldn't be using KDE either. You would be better off using Blackbox window manager with some xterms and Mozilla (launched from the command line). That configuration would be one of the most efficient graphical solutions to the terminal-webbrowser needs described above.
KDE (and GNOME) are trying to be full-featured desktop environments such as the ones that Apple and Microsoft provide. If you don't want all the extra features provided by the full desktops, you're just using up memory for no good reason.
I'm sure that the Anjuta folks would be quite happy to accept your "tweaks" to have Anjuta run on PPC architecture. They want Anjuta to be used as widely as possible: it's a matter of where the patches come from, not of platform arrogance.
You said: "3) It encourages open standards, because you don't have to pay for Connector if you convert your servers to use some open standard that's supported by Evolution by default. "
Doesn't it seem strange that their business model depends upon people using proprietary software; yet, your point is that their business model would encourage them not to buy the service?
I think you're on to something here. If there is a pre-existing open-sourced application out there (like Apache), the company can relatively cheaply add some value to it and sell services. On the other hand, if you are creating an application from scratch (like what theKompany is doing with Kivio or Ximian with Evolution), you are spending too much time and money making something from which you'll never see direct return. You sweat and bleed to make the application, and *anyone* can use it or charge for services. It's economic suicide. If you don't care about the money, it's all good, though.
You say: "Sometimes, it's just better to start over from scratch. Look at how fast Konqueror is improving and compare that to Mozilla. While Mozilla is quite a nice browser today, consider how long it took to get there due to the mess that was Netscape Navigator code. "
The poor Mozilla guys! They're criticized around the block for abandoning the Netscape 4.x base and starting from scratch, and this guy says that they took too long because they had to deal with the Netscape codebase.
It is true that generic terms do not get trademark protection. However, I don't think the term "Windows" is generic in this context. We don't call all GUIs "windows" as a general term (even non-tech people only call GUIs "windows" under the assumption that MS software is involved). I also don't think that "windows" was the generic term for computer GUIs before MS put out its first version of Windows (correct me if I'm wrong).
On the other hand, I do think that the term "windows" is descriptive of the GUIs found with the MacIntosh, MSWindows, the X-Window System, etc. "Windows" is a way of describing the frames that the programs inhabit and through which users graphically interact with their software.
It is also true that one cannot get a trademark on a mark which is "merely descriptive." See 15 U.S.C.A. sec. 1052(e)(1). However, if MS's continuous use of the term in connection with its software (for 5 years to be safe) makes "windows" become distinctive (read: most people associate "windows" in a software context with MSWindows), then MS can trademark the term "windows" anyway. See 15 U.S.C.A. sec. 1052(f). Such is the case here, IMHO. Feel free to disagree.
Your friend is referring either to the Full Faith and Credit Clause (Article IV, section 1): "Full Faith and Credit shall be given in each State to the public Acts, Records, and judicial Proceedings of every other State." or to the Privileges and Immunities Clause (Article IV, section 2): "The Citizens of each State shall be entitled to all Privileges and Immunities of Citizens of the several States."
I'm not sure that either apply here, though. Microsoft is not a citizen of any state, and we're not talking about any of its privileges or immunities anyway. Secondly, the nine dissenting states are not failing to recognize the settlements offered to the other states. Rather, they are demanding different remedies for their own citizens (if I'm understanding the whole thing correctly-- I haven't followed it that closely).
Perhaps Microsoft is claiming that by insisting on harsher rememdies, the dissenting states are putting an undue burden on interstate commerce, which is the sole domain of Congress (see Article I, section 8, clause 3). Just a thought...
Etc. Almost half of the past 30 news posts on GNOME involve a political controversy. Is this news-site bias or simply GNOME's ability to stir controversy?
You're right that GNOME1 applications don't work *on* GNOME2, but they do work *with* GNOME2, since the GNOME1 libraries are fully parallel installable with the GNOME2 libraries. In other words, you can have your new desktop environment, the applications that make use of the new and better libraries, and still use your favorite applications that haven't been ported yet. It's a beautiful world.
I can't really comment on comparisons with KDE, as I'm not familiar with KDE's accessibility. However, accessibility has been a driving force in GNOME2 development. Sun, in particular, has been very active in this area. See, for example, their work on the Accessibility Toolkit (ATK) or the GNOME on-screen keyboard or the screen-magnifier (see here). You can find more about the GNOME Accessibility Project (GAP) here. All this is being designed for GNOME2; so, we'll see more of the implementation of the accessibility stuff with this release onward.
As for the question of who is using GNOME2, well, the developers are using it mostly -- which you might expect since GNOME2 beta just came out!;-)
dude, the spirit of the whole RMS post is *COOPERATION*. I don't think your post is getting with the program, so to speak.;-) By the way, I'm a GNOME supporter.
I don't know how feasible your idea is, though it sounds attractive. Without wanting to starting a language flamewar here, though, I'll say that it would probably be easier to write the interface library in C rather than in C++. Why? Creating language bindings for C is easier than for C++ (at least, that is the conventional wisdom). Also, since C++ is mostly a superset of C, then C++ can use C libraries whereas C cannot use C++ libraries. Anyhoodle, your idea is attractive, but I wonder whether it's technologically feasible no matter which language one uses. Anyone care to comment?
I can't speak for KDE (though I believe they have a Usability team), but look here for the GNOME Usability Project (aka GUP). I know that Sun has done user testing on GNOME.
"Sometimes, you just need one or two in the packages, and you are forced to install the whole jumbo packages. "
Interesting. Often, GNOME is criticized for having too many small packages, which make compiling that much more difficult. The same may also be true for KDE. I just know that GNOME gets the opposite complaint frequently.
The patent issue could be a problem, but there are a few things to lessen the worry:
1)Mono is being conservative and only trying to implement things that are already in existence. See this quotation: "We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques." from MSDN.
2) You say: "My worst fear is everything would go incredibly well with mono: diverse compilers, robust libraries, etc. and we would all start to build code around it, and then about 5 years down the line Microsoft whips out a patent and demands royalties for all the labor that we have done under the illusion that it would be free." It is unlikely that a surprise patent is going to bite you 5 years down the line. It is true that until a patent application is finally accepted or rejected, the patent claims are secret. See 35 U.S.C.A. sec. 122(a). However, this period of secrecy is fairly short. MS submitted the API specs to the ECMA at least a year ago. Those specs are what the Mono libraries are being built on. Those specs will likely be described as "described in a printed publication." If MS wants to patent any of the API's, it has only 1 year in which to do so. See 35 U.S.C.A. sec. 102(b). Otherwise, there is a statutory bar on patentability, and the specs are in the public domain. See id. If MS has applied for those patents by now, there is a maximum 3-year time span for those claims to be reviewed and accepted or rejected by the PTO. See 35 U.S.C.A. sec. 154(b)(1)(B). Generally, however, MS would have to prosecute its patent within 6 months of the filing date. See 35 U.S.C.A. sec. 133. Therefore, "secret" patents are likely to be in hiding for less than 3 years.
I hope this allays some of your fears. Cheers!
P.S. IANAL (but I hope to be one some day), and anyone construing what I have said here as legal advice to their specific situation is an idiot.
You are making at least two assumptions here:
1) MS can force Ximian and other developers to pay for using the.NET framework.
>>Since Ximian is only using information submitted to a standards body, I guess we're saying that MS would use software patents and not copyright to force these payments. Patents, by their very nature, are supposed to be out in the open, right? What patents are we talking about here? Even if there are some patents being applied for (and thus not in the open), is there anything that Ximian is doing that hasn't already been done by Sun with Java? Here is a brief excerpt from Miguel's interview on MSDN that may go toward answering the but-is-it-patented? question:
"Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern.NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on.NET if they turn out to be restrictive?
Miguel de Icaza: Well, for one we are writing everything from scratch.
We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques."
2) Next assumption: the main purpose of Mono is to be compatible with.NET.
>>I believe that Miguel stated (Question 28) that while compatibility would be great, the Mono platform would be a real bonus in its own right, compatibility be damned. You could call it a fork of.NET, if you like. Is this horrible?
GNOME is composed of many thousands (or millions?) of lines of C code. Converting GNOME to C# is a gargantuan task and not likely to happen for a very long time, if ever. Sun doesn't have much to worry about in this respect.
Should GNOME have skipped directly to 2.0? I don't think so. GNOME 1.4 was very instructive, as it gave the developers a prototype of many of their new technologies/applications (e.g. Bonobo, GConf, Orbit, Nautilus). The feedback from 1.4, especially the observations of the problems, will make GNOME 2.0 a much better environment. Because the developers were going to ditch API compatibility after GNOME 1.4 anyway, they were free to experiment with the new stuff. They fixed the new stuff, so that it worked "right" for GNOME 2.0, and they did not have to worry about staying true to the APIs. GNOME 1.4 might have been painful, but it will bear good things in the GNOME2.x series. Cheers!
I'm not so sure you're right on this one. I don't keep up with KDE so much, so I can't speak fo them, but KDE comes up not infrequently on the GNOME lists. Sometimes, the comments are, "hey, KDE does it this way, which is kind of neat! Maybe we should think about this." Sometimes, the comments are "hey, KDE does it this way, which kind of sucks. We should avoid this." Having a point of comparison on Unix/BSD/Linux desktops is a good thing. The GNOMErs do care about KDE, believe it or not. From what I gather, KDE cares about GNOME too.
Yes, the close-button-discussion was a bit silly, but the GUP people *are* putting a lot of thought into making the interface better. You should applaud their efforts rather than criticize them. Now, I'm not sure what you mean by "major, sweeping changes." Some think those changes are already occurring; others think that the interface shouldn't be too different from Windows* or OSX under the strategy of embrace and extend. In any case, I think you'll find that GUP will bear fruit in the upcoming GNOME2 and the applications that use its framework. Cheers!
It is obvious to me that you haven't spent much time around the GNOME Usability Project (aka GUP) or the Usability Lists. First, the GUP folks tend to head in a more Mac-like direction than in a Windows one (e.g. instant-apply preference dialogues, menu-bar at top of screen). Secondly, these guys think *a lot* (some say too much;-) about what makes a usable, intuitive desktop. Just check out the lengthy debate about whether to include a close button in an instant-apply dialogue, if you want to see an extreme example. In short, the GUP people are doing lots of work (including a Human Interface Guideline) to make the desktop a more usable experience for the end user, and GUP is not blindly following anyone (though they tend agree more with the Mac people). Check out GUP. It's pretty interesting (and exciting).
um...it's a DEVELOPMENT PLATFORM release, i.e. we're talking about the libraries upon which the desktop environment is built. In a few weeks, after they've killed lots of the bugs hiding in the libraries and after the developers have had more time to port the key desktop applications, then the DESKTOP beta will roll out too. Some of the applications, like Abiword, may not be ported by the time GNOME 2.0 goes gold; however, all GNOME 1.4 applications will work great in the GNOME 2.0 desktop until the apps have been ported. In the meantime, the apps just won't be taking advantage of the goodies in the GNOME 2.0 libraries, that's all. So, relax! The future looks rosy.:-)
"Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. "
GNOME *is* sticking to its guns with CORBA and Bonobo. The developers are actively working on the Bonobo component model and Orbit2, and they plan on using them for the forseeable future. They're actually quite excited at the possibilities these tools are bringing to them and their desktop environment. From what I've seen on the lists, the developers have been hard at work ironing out wrinkles in the inproc/out-of-proc components and are happy with the speed of Orbit.
Now, I will concede that you're right in that *Miguel* has moved on. Even before Bonobo had fully matured (that's happening with GNOME2 development after the GNOME 1.4 experimentation), Miguel decided that the.NET framework is the way to go. I say, good for him! If Miguel and Ximian can make MONO into a beautiful development platform that is better than Bonobo, that's great! If that does happen (and it's going to be at least year before we can tell how it's doing), GNOME will probably be happy to start using MONO and employ Bonobo as a bridge to the new platform. Until then, GNOME is quite happy with Bonobo.
Jonathan Ingram posted in a thread that if Orbit really proves great, KDE would be happy to use it. In the meantime, KDE is using their own solution (which they like quite well) and will let GNOME do the Orbit development. You can compare GNOME's stance with MONO in the same way: wait and see.
Remember Miguel != GNOME and even Ximian != GNOME. Both are big players in GNOME, but GNOME is larger than them. Cheers!
Slashdot Mirror
You two are talking past one another. He said that the speed of Nautilus was comparable to Windows Explorer for GNOME2. You are noting that Nautilus lacks some speed for GNOME 1.4. It's quite possible that you both are correct.
Having lots of different modules makes compiling GNOME a real pain but gives developers more fine-grained control on the libraries they include in their applications. The GNOMErs made a decision to favor developers in this regard, figuring end-users would depend upon their distributions or upon Ximian's Red Carpet to handle the rest.
That said, have you tried GARNOME? It makes compiling GNOME very easy, to the happiness of beta-testers everywhere. Cheers!
If you're looking to manage a bunch of terminal windows and a webbrowser, you probably shouldn't be using KDE either. You would be better off using Blackbox window manager with some xterms and Mozilla (launched from the command line). That configuration would be one of the most efficient graphical solutions to the terminal-webbrowser needs described above.
KDE (and GNOME) are trying to be full-featured desktop environments such as the ones that Apple and Microsoft provide. If you don't want all the extra features provided by the full desktops, you're just using up memory for no good reason.
I'm sure that the Anjuta folks would be quite happy to accept your "tweaks" to have Anjuta run on PPC architecture. They want Anjuta to be used as widely as possible: it's a matter of where the patches come from, not of platform arrogance.
You said: "3) It encourages open standards, because you don't have to pay for Connector if you convert your servers to use some open standard that's supported by Evolution by default.
"
Doesn't it seem strange that their business model depends upon people using proprietary software; yet, your point is that their business model would encourage them not to buy the service?
I think you're on to something here. If there is a pre-existing open-sourced application out there (like Apache), the company can relatively cheaply add some value to it and sell services. On the other hand, if you are creating an application from scratch (like what theKompany is doing with Kivio or Ximian with Evolution), you are spending too much time and money making something from which you'll never see direct return. You sweat and bleed to make the application, and *anyone* can use it or charge for services. It's economic suicide. If you don't care about the money, it's all good, though.
You say: "Sometimes, it's just better to start over from scratch. Look at how fast Konqueror is improving and compare that to Mozilla. While Mozilla is quite a nice browser today, consider how long it took to get there due to the mess that was Netscape Navigator code. "
The poor Mozilla guys! They're criticized around the block for abandoning the Netscape 4.x base and starting from scratch, and this guy says that they took too long because they had to deal with the Netscape codebase.
You can't have it both ways.
It is true that generic terms do not get trademark protection. However, I don't think the term "Windows" is generic in this context. We don't call all GUIs "windows" as a general term (even non-tech people only call GUIs "windows" under the assumption that MS software is involved). I also don't think that "windows" was the generic term for computer GUIs before MS put out its first version of Windows (correct me if I'm wrong).
On the other hand, I do think that the term "windows" is descriptive of the GUIs found with the MacIntosh, MSWindows, the X-Window System, etc. "Windows" is a way of describing the frames that the programs inhabit and through which users graphically interact with their software.
It is also true that one cannot get a trademark on a mark which is "merely descriptive." See 15 U.S.C.A. sec. 1052(e)(1). However, if MS's continuous use of the term in connection with its software (for 5 years to be safe) makes "windows" become distinctive (read: most people associate "windows" in a software context with MSWindows), then MS can trademark the term "windows" anyway. See 15 U.S.C.A. sec. 1052(f). Such is the case here, IMHO. Feel free to disagree.
Your friend is referring either to the Full Faith and Credit Clause (Article IV, section 1): "Full Faith and Credit shall be given in each State to the public Acts, Records, and judicial Proceedings of every other State." or to the Privileges and Immunities Clause (Article IV, section 2): "The Citizens of each State shall be entitled to all Privileges and Immunities of Citizens of the several States."
I'm not sure that either apply here, though. Microsoft is not a citizen of any state, and we're not talking about any of its privileges or immunities anyway. Secondly, the nine dissenting states are not failing to recognize the settlements offered to the other states. Rather, they are demanding different remedies for their own citizens (if I'm understanding the whole thing correctly-- I haven't followed it that closely).
Perhaps Microsoft is claiming that by insisting on harsher rememdies, the dissenting states are putting an undue burden on interstate commerce, which is the sole domain of Congress (see Article I, section 8, clause 3). Just a thought...
The Mono controversy (with some RMS thrown in):
- The present story
-
RMS comment
-
Miguel responds
-
Miguel talks about Mono at *gasp* MSDN
RMS controversy (apart from Mono):-
RMS not elected
-
RMS says why he should be elected
-
RMS IS running for election
-
Breaking News! RMS running for a seat on the GNOME foundation
GNOME is behind or dying or a slave of corporate masters (see also Mono controversy):Etc. Almost half of the past 30 news posts on GNOME involve a political controversy. Is this news-site bias or simply GNOME's ability to stir controversy?
You're right that GNOME1 applications don't work *on* GNOME2, but they do work *with* GNOME2, since the GNOME1 libraries are fully parallel installable with the GNOME2 libraries. In other words, you can have your new desktop environment, the applications that make use of the new and better libraries, and still use your favorite applications that haven't been ported yet. It's a beautiful world.
;-)
I can't really comment on comparisons with KDE, as I'm not familiar with KDE's accessibility. However, accessibility has been a driving force in GNOME2 development. Sun, in particular, has been very active in this area. See, for example, their work on the Accessibility Toolkit (ATK) or the GNOME on-screen keyboard or the screen-magnifier (see here). You can find more about the GNOME Accessibility Project (GAP) here. All this is being designed for GNOME2; so, we'll see more of the implementation of the accessibility stuff with this release onward.
As for the question of who is using GNOME2, well, the developers are using it mostly -- which you might expect since GNOME2 beta just came out!
Cheers!
dude, the spirit of the whole RMS post is *COOPERATION*. I don't think your post is getting with the program, so to speak. ;-) By the way, I'm a GNOME supporter.
I don't know how feasible your idea is, though it sounds attractive. Without wanting to starting a language flamewar here, though, I'll say that it would probably be easier to write the interface library in C rather than in C++. Why? Creating language bindings for C is easier than for C++ (at least, that is the conventional wisdom). Also, since C++ is mostly a superset of C, then C++ can use C libraries whereas C cannot use C++ libraries. Anyhoodle, your idea is attractive, but I wonder whether it's technologically feasible no matter which language one uses. Anyone care to comment?
I can't speak for KDE (though I believe they have a Usability team), but look here for the GNOME Usability Project (aka GUP). I know that Sun has done user testing on GNOME.
"Sometimes, you just need one or two in the packages, and you are forced to install the whole jumbo packages. "
Interesting. Often, GNOME is criticized for having too many small packages, which make compiling that much more difficult. The same may also be true for KDE. I just know that GNOME gets the opposite complaint frequently.
The patent issue could be a problem, but there are a few things to lessen the worry:
1)Mono is being conservative and only trying to implement things that are already in existence. See this quotation: "We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques." from MSDN.
2) You say: "My worst fear is everything would go incredibly well with mono: diverse compilers, robust libraries, etc. and we would all start to build code around it, and then about 5 years down the line Microsoft whips out a patent and demands royalties for all the labor that we have done under the illusion that it would be free." It is unlikely that a surprise patent is going to bite you 5 years down the line. It is true that until a patent application is finally accepted or rejected, the patent claims are secret. See 35 U.S.C.A. sec. 122(a). However, this period of secrecy is fairly short. MS submitted the API specs to the ECMA at least a year ago. Those specs are what the Mono libraries are being built on. Those specs will likely be described as "described in a printed publication." If MS wants to patent any of the API's, it has only 1 year in which to do so. See 35 U.S.C.A. sec. 102(b). Otherwise, there is a statutory bar on patentability, and the specs are in the public domain. See id. If MS has applied for those patents by now, there is a maximum 3-year time span for those claims to be reviewed and accepted or rejected by the PTO. See 35 U.S.C.A. sec. 154(b)(1)(B). Generally, however, MS would have to prosecute its patent within 6 months of the filing date. See 35 U.S.C.A. sec. 133. Therefore, "secret" patents are likely to be in hiding for less than 3 years.
I hope this allays some of your fears. Cheers!
P.S. IANAL (but I hope to be one some day), and anyone construing what I have said here as legal advice to their specific situation is an idiot.
You are making at least two assumptions here: .NET framework.
.NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?
.NET.
.NET, if you like. Is this horrible?
1) MS can force Ximian and other developers to pay for using the
>>Since Ximian is only using information submitted to a standards body, I guess we're saying that MS would use software patents and not copyright to force these payments. Patents, by their very nature, are supposed to be out in the open, right? What patents are we talking about here? Even if there are some patents being applied for (and thus not in the open), is there anything that Ximian is doing that hasn't already been done by Sun with Java? Here is a brief excerpt from Miguel's interview on MSDN that may go toward answering the but-is-it-patented? question:
"Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern
Miguel de Icaza: Well, for one we are writing everything from scratch.
We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques."
2) Next assumption: the main purpose of Mono is to be compatible with
>>I believe that Miguel stated (Question 28) that while compatibility would be great, the Mono platform would be a real bonus in its own right, compatibility be damned. You could call it a fork of
Just some things to think about...
GNOME is composed of many thousands (or millions?) of lines of C code. Converting GNOME to C# is a gargantuan task and not likely to happen for a very long time, if ever. Sun doesn't have much to worry about in this respect.
Should GNOME have skipped directly to 2.0? I don't think so. GNOME 1.4 was very instructive, as it gave the developers a prototype of many of their new technologies/applications (e.g. Bonobo, GConf, Orbit, Nautilus). The feedback from 1.4, especially the observations of the problems, will make GNOME 2.0 a much better environment. Because the developers were going to ditch API compatibility after GNOME 1.4 anyway, they were free to experiment with the new stuff. They fixed the new stuff, so that it worked "right" for GNOME 2.0, and they did not have to worry about staying true to the APIs. GNOME 1.4 might have been painful, but it will bear good things in the GNOME2.x series. Cheers!
I'm not so sure you're right on this one. I don't keep up with KDE so much, so I can't speak fo them, but KDE comes up not infrequently on the GNOME lists. Sometimes, the comments are, "hey, KDE does it this way, which is kind of neat! Maybe we should think about this." Sometimes, the comments are "hey, KDE does it this way, which kind of sucks. We should avoid this." Having a point of comparison on Unix/BSD/Linux desktops is a good thing. The GNOMErs do care about KDE, believe it or not. From what I gather, KDE cares about GNOME too.
Does Mono have any equivalent to Java's sandbox? It would be nice to have the extra security protection.
Yes, the close-button-discussion was a bit silly, but the GUP people *are* putting a lot of thought into making the interface better. You should applaud their efforts rather than criticize them. Now, I'm not sure what you mean by "major, sweeping changes." Some think those changes are already occurring; others think that the interface shouldn't be too different from Windows* or OSX under the strategy of embrace and extend. In any case, I think you'll find that GUP will bear fruit in the upcoming GNOME2 and the applications that use its framework. Cheers!
It is obvious to me that you haven't spent much time around the GNOME Usability Project (aka GUP) or the Usability Lists. First, the GUP folks tend to head in a more Mac-like direction than in a Windows one (e.g. instant-apply preference dialogues, menu-bar at top of screen). Secondly, these guys think *a lot* (some say too much ;-) about what makes a usable, intuitive desktop. Just check out the lengthy debate about whether to include a close button in an instant-apply dialogue, if you want to see an extreme example. In short, the GUP people are doing lots of work (including a Human Interface Guideline) to make the desktop a more usable experience for the end user, and GUP is not blindly following anyone (though they tend agree more with the Mac people). Check out GUP. It's pretty interesting (and exciting).
um...it's a DEVELOPMENT PLATFORM release, i.e. we're talking about the libraries upon which the desktop environment is built. In a few weeks, after they've killed lots of the bugs hiding in the libraries and after the developers have had more time to port the key desktop applications, then the DESKTOP beta will roll out too. Some of the applications, like Abiword, may not be ported by the time GNOME 2.0 goes gold; however, all GNOME 1.4 applications will work great in the GNOME 2.0 desktop until the apps have been ported. In the meantime, the apps just won't be taking advantage of the goodies in the GNOME 2.0 libraries, that's all. So, relax! The future looks rosy. :-)
"Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. "
.NET framework is the way to go. I say, good for him! If Miguel and Ximian can make MONO into a beautiful development platform that is better than Bonobo, that's great! If that does happen (and it's going to be at least year before we can tell how it's doing), GNOME will probably be happy to start using MONO and employ Bonobo as a bridge to the new platform. Until then, GNOME is quite happy with Bonobo.
GNOME *is* sticking to its guns with CORBA and Bonobo. The developers are actively working on the Bonobo component model and Orbit2, and they plan on using them for the forseeable future. They're actually quite excited at the possibilities these tools are bringing to them and their desktop environment. From what I've seen on the lists, the developers have been hard at work ironing out wrinkles in the inproc/out-of-proc components and are happy with the speed of Orbit.
Now, I will concede that you're right in that *Miguel* has moved on. Even before Bonobo had fully matured (that's happening with GNOME2 development after the GNOME 1.4 experimentation), Miguel decided that the
Jonathan Ingram posted in a thread that if Orbit really proves great, KDE would be happy to use it. In the meantime, KDE is using their own solution (which they like quite well) and will let GNOME do the Orbit development. You can compare GNOME's stance with MONO in the same way: wait and see.
Remember Miguel != GNOME and even Ximian != GNOME. Both are big players in GNOME, but GNOME is larger than them. Cheers!