Slashdot Mirror

Actually, in the GNOME software map (under Miscellaneous) there's a piece of software called Finder, which is just the Mac menu bar for GNOME. I've played with it before, and it seemed rather functional. Of course, not being a Mac user, I don't know how it shapes up to the Mac bar.

C:\DOS\CRASH>

The FAQ states:

GNOME stands for "GNU Network Object Model Environment". GNU stands for "GNU's Not Unix", and
has always been officially pronounced "guh-NEW" to minimize confusion. Since GNU is GNOME's first
name, GNOME is officially pronounced "guh-NOME".

What would you recommend as the best-of-the-best open source tools currently existing for creating portable, modern documentation? And what tools are needed that don't exist?

Please be specific. What would you tell a complete newbie to set up on their machine in order to start writing portable, extensible docs?

Thanks!
W
-------------------

GNOME has the (more and more) nice control-center, where other apps may put their config stuff as well (just like Sawmill does)

Also worth mentioning is the GConf configuration library. Although not very visible to the user, it makes storing, retrieving and last, but not least monitoring configuration settings easy.

A quick look at Google pulled up about 6,000 articles, mostly old. Have a look around, you're bound to find someone who knows something at these sites:

Here's an old slashdot article about Solaris8. From this article, I don't see Solaris8 on x86 becoming a hot development platform, but judge for yourself.

Here's an older looking page about sound on x86 hardware with Solaris.

Here's one from Gnome. This is one of the slickest desktops around. If it don't do sound yet, try KDE.

Look for atricles with your specific hardware and linux. I found out that MediaGX had some Linux sound support that way. It's just some hardware that I had. That sound was supported was luck of the draw. I'll bet you want better assurances than that. Sun has a forum for questions like this, here.

Hopefully, someone who knows something will answer your post. I'd like to know what you find, please post back if you learn anything useful.

Don't commit to this module without asking me, Havoc Pennington . Thanks :-)

The filename?

README.REALLY.I.MEAN.IT

Perhaps we should ask him whether this has helped in the fight against third-parties attempting to rewrite his prose :)

I don't quite see this "unanimous standardization" that you are referring to. Redhat and TurboLinux both offer Gnome as the default desktop. Mandrake, OpenLinux, and Corel Linux offer KDE as the default. Most distributions offer both as desktop choices.

Like it or not, while the Linux community is doing the parallel development thing, in the Linux industry, the race is pretty much over.

Far from it. I can name 3 companies devoting many manhours and cash to Gnome development: RHAD Labs, Eazel, and Helix Code. Companies such as MandrakeSoft and Corel are funding KDE development. The race, if anything, is just beginning to get interesting...

Yeah, I know about Eazel. Judging by the amount of hype they've generated, all I can say about them is: show me the code.

okay:

here is some of it.
----

As always, Matrox has excellent linux support. G400 runs fast and steady under XFree86 SVGA server. You can overclock the board with gMGAclock, a GNOME-based overclocking utility for Matrox G400 cards.

It's nowhere near ready for use yet. In fact, it's so early in development that it doesn't really have much of a homepage. You can't download it, except from GNOME CVS, and few people know about it.

But it exists.

It's called GNOME Basic.

Basically, it's an offshoot of Gnumeric, which is the default GNOME spreadsheet. Since Gnumeric is intended to be feature-for-feature compatible with Microsoft Excel, one of those features is the built-in scripting language, VBA.

So, they decided to do a VBA clone, and it is turning into something that can run VB code.

Note that it is very early, under development, and does not yet have an IDE (just a compiler). Its homepage (as such) is here.

Enjoy!

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

It's nowhere near ready for use yet. In fact, it's so early in development that it doesn't really have much of a homepage. You can't download it, except from GNOME CVS, and few people know about it.

But it exists.

It's called GNOME Basic.

Basically, it's an offshoot of Gnumeric, which is the default GNOME spreadsheet. Since Gnumeric is intended to be feature-for-feature compatible with Microsoft Excel, one of those features is the built-in scripting language, VBA.

So, they decided to do a VBA clone, and it is turning into something that can run VB code.

Note that it is very early, under development, and does not yet have an IDE (just a compiler). Its homepage (as such) is here.

Enjoy!

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

I see, I should have stated myself more clearly. I am not talking of glibc (i.e. libc.a), but of GLib (i.e. libg.a). Take a look at the reference manual to get a feeling of what it provides. As I said before, it is a most useful tool.

The combination of autoconf and automake is definitely the way to go.

The autoconf and automake docs can be a bit obscure; most people seem to learn how to use them by studying the configure.in and Makefile.am files from other projects.

There is also a brief discussion of autoconf and automake in Havoc Pennington's Gtk+/Gnome Application Development that might help you get started. This fine book is available on-line: here is the relevant section.

The combination of autoconf and automake is definitely the way to go.

The autoconf and automake docs can be a bit obscure; most people seem to learn how to use them by studying the configure.in and Makefile.am files from other projects.

There is also a brief discussion of autoconf and automake in Havoc Pennington's Gtk+/Gnome Application Development that might help you get started. This fine book is available on-line: here is the relevant section.

The GNOME math tools here show promise, but I still tend to derive interpolation functions by hand, just because it's often easier, even if you've got Maple handy.

Broccolist

From what information is available, what do you think of Eazel? Is this necessary, or are Gnome and KDE too geek-driven to ever meet consumer preference/demand? Do you think that Gnome or KDE could be modified to create a consumer-level GUI, or will it take a project like Eazel to start from scratch? How essential is all this to the success of Linux?

There is an extensive article concerning the replacement of imlib by gdkPixbuf on the Gnome Website
http://developer.gn ome.org/feature/current/html/gdk-pixbuf.html

I'd also like to encourage the Gnome hackers to seriously consider working on an IDE similar to KDevlop. That is simply an amazing piece of work. You have all the documentation and tools necessary to rapidly create KDE applications...and it's very easy to use and intuitive. I know that Gnome has Glade and gIDE and there has been talk of integrating the two, but somehow that doesn't seem like the answer. I think Glade should be integrated into an IDE, but gIDE is no KDevelop, no offense to the author(s). A very functional IDE that even new hackers could use, would go a long way to getting further involvment int the gnome project.
----

I'd also like to encourage the Gnome hackers to seriously consider working on an IDE similar to KDevlop. That is simply an amazing piece of work. You have all the documentation and tools necessary to rapidly create KDE applications...and it's very easy to use and intuitive. I know that Gnome has Glade and gIDE and there has been talk of integrating the two, but somehow that doesn't seem like the answer. I think Glade should be integrated into an IDE, but gIDE is no KDevelop, no offense to the author(s). A very functional IDE that even new hackers could use, would go a long way to getting further involvment int the gnome project.
----

I'd also like to encourage the Gnome hackers to seriously consider working on an IDE similar to KDevlop. That is simply an amazing piece of work. You have all the documentation and tools necessary to rapidly create KDE applications...and it's very easy to use and intuitive. I know that Gnome has Glade and gIDE and there has been talk of integrating the two, but somehow that doesn't seem like the answer. I think Glade should be integrated into an IDE, but gIDE is no KDevelop, no offense to the author(s). A very functional IDE that even new hackers could use, would go a long way to getting further involvment int the gnome project.
----

This link is the screenshot.
Here

But there are others, if you feel like browsing.

What about gnome-midnight commander? I believe that is included as part of the default gnome set of apps, if you install the default that is...

Anyways, it does a lot of things well, it is a graphical file manager. Its just as good the windows file manager, of course there is all that security involved that isn't an issue in windows.

If you're interested.

http://www.gnome.org/mc/


Also, since the screeshot section is a bit lacking, but there is a shot of it in the my desktop shot.

What I hate is all the unnatural dependencies on GNOME on RedHat systems. For instance, last night I upgraded my RH5.2 system to RH6.1. I have a lot of complaints about how this worked (like, why can't I cancel or at least unmount my drive? and why can't password-less users login or at least have root change their passwords), but the relevant complaint is the GNOME deps.

Ummm, no. I think your problem is RedHat. I use Gnome on Debian, and have never once had any problem with it. If you're a package manager kind of person, dpkg has never caused any dependency problems with me, and if you prefer tar.gz sources, just go to www.gnome.org and download the lot from their website.

If you're using RPMs and you've got dependency problems with Gnome, then RedHat is your problem.

You have probably received 400 emails about this already, but just in case - here goes. Both Gnome and KDE already have graphical file managers, contrary to the article which said neither has a graphical file manager. Here is a screenshot of the Gnome file manager and here is one of KDE's.

Please issue a retraction so people are not misled. It is very important to the Linux community that people in the more general computing public become aware that Linux is becoming easier to use. Thank you for your attention to this matter.

Although Linux already has a pair of evolving GUIs -- KDE and Gnome -- neither has a graphical file manager. Instead of clicking on icons or menus to open and save documents, users must type file names into a command-line interface.

Not to mention: "We've never used either desktop, and if we have, then we didn't really know what we were doing! We're just talking out of our collective asses ... in an attempt to make this seem like bigger, more important news."

WHY?! Because they BOTH have graphical file managers and they BOTH offer cute little icons to click on, AND shortcuts, and much more...

However, there is some good stuff missing. First of all, it's not easy to do half of the stuff when it comes to icons and junk. In KDE, it's very difficult to chose an icon unless it's in one of the specified directories, and it also only supports XPM; GNOME supports a little more than that. So, yes, there is still work to be done.

Well first of, let me say that I have to use MS Word for school all the time and it sucks big time. Now since I got that out of the way I can continue.

Bussiness wise, it only makes sense for people to start looking at a free operatoring system to use- if it saves money, I think it is a advantage. There recently has been a huge influx of X/Linux office procucts because it is unchartered or un-dominated ground. Both Corel and Sun have office software for linux. KDE is developing a office suite and most interestingly I have heard rumors that Helix Code formed more to develope a office product than to extend gnome (though they do that too). The Gnome/Helix Code office product seems the most intriguing to me because it seems they are looking to copy MS Office. Even the fine goofy details like Visual Basic in Word they are working on (check it out at www.gnome.org/gb)!! Way back in the golden days, MS was slow to the word-processing game (which became the office software game) but they stole and cheated as always.

In summary, if you haven't already got October Gnome, get that. Then get gdk-pixbuf and install it. Then gnome-core and gnome-applets. It's easier with the rpms because rpm -e is a godsend if things go wrong.

I have been running the 1.1.x gnome-core/applets and haven't crashed them effectively yet. The old bugbear of the crashed panel is now gone, because it has started itself back up after I crashed it (I was trying to: I was curious) without that wretched "You already have a panel running" message.

There should be some reasonably up to date information in the FAQ: if it doesn't work, tell the FAQ folks so they can _fix_ it!

Finally, don't confuse "latest release" with CVS. The stable CVS stuff is stable. Parts of the HEAD branch, notoriously, are not, and this frequently includes gnome-libs, which is a fairly fundamental part :) If you just want to try the new bits, forget CVS and go for the 1.1.x releases, and throw in as many bugs as possible into the bug-tracker. I've had a lot of mine getting fixed very fast recently. (Thanks guys, I do notice it)

I think that you have a good point BUT I do have to point out KOffice and the GNOME-Office suites. Now, they're not perfect by far and maybe they don't offer all of the features of MS-Office (yet) but they have the *ability* to do so via the OpenSource development model that they use. Not only are they nearly as functional, but in some cases they actually work *better* than their MS-equivalents.

Example: PowerPoint only creates presentations that will work correctly with IE4.x or higher; KPresenter creates (albeit static) presentations you can even view with G!zilla and/or KFM, Konqueror, mozilla, IEx.x, NSx.x... any web browser that supports images, basically. I like that.

Also, when was the last time that you saw Explorer embed a Word document? In a frame? How about PostScript or PDF? Spreadsheets? Microsoft is going to have to worry about people wanting these cool features- I already show them to my friends and they drool, because they want a desktop that can do what mine can.

Unix design philosophy makes use of small tools linked together not large software programs doing everything at once.

I.e., components, such as Nautilus and, I think, the KDE 2.0 file manager will use?

There are other ways to link tools together than to build shell scripts, pipelines, and the like.

I completely agree, but why is this? Why do all X themes look butt ugly?

We've all seen these before, but compare them and think, "What is Aqua doing that GNOME is not?" Nothing! Both screenshots are simple desktop+explorer shots. Yet somehow the Aqua screen looks like da bomb and GNOME looks like shite.

• GNOME screen shot
• MacOS X screen shot

There's no particular reason for this to represent a "duplication of effort," at least from the standpoint of the GNOME project. After all, they needed a better file manager. GMC has not been all that satisfactory.

What their application amounts to is one that unifies files and remote objects (via HTTP/FTP) together, and lets methods be invoked on them.

By using the Bonobo interface, they can pull in all sorts of GNOME objects. That's certainly not duplication.

It may be duplicative if you're a developer working on the Kconq file manager for KDE that has similar scope; it's not duplicative within the context of GNOME.

I'd say that this is the most important component to have some serious HCI people take a look at; that's the only hope of it being usable to the "Bubba" users. (No offense intended to other than Presidents of the United States :-) ...)

It's important that this get HCI attention in that if it succeeds, Nautilus would become the front-end for a whole lot of users to get at "system stuff."

Also, if this leads to a better wm-spec, the world will be a kinder, happier place. Where all programs and windowmanagers can get along and share their bells and whistles, creating a joyous cacophonic r(o)ar.

But, I think some of upper management is still trying to shake this Linux thing off. I can't wait to show them this, just to make them lose sleep. Oh and now open source projects with $10 mil. in VC off the bat... that's what I'm talkin' about.

It seems like the author feels that most of the people flame him because they're in some kind of Total World Domination frame of mind. Are there other Linux fans out there who are happy just to have a product they enjoy using? People who don't care about world domination don't have to talk about what Windows apps will run on WINE and such and such. We're happy with the apps we have, and in my experience, people are willing to learn new apps as long as they're intuitive (like the MacOS products). From my experience I've seen new computer users do quite well on pre-installed Linux machines or Computer Lab UNIX machines as long as the applications make themselves fast and intuitive. My friend in Santa Cruz bought a pre-installed system from Penguin and she installed Applix by herself and figured out how to use it (I believe on the Gnome desktop). She had a copy of Windows on-hand just in case Linux was too intimidating but never had to put it in the CD-ROM. Maybe if Linux is intuitive in this way and becomes even more intuitive and easy (pre-installs, and easy to learn applications/desktops) nobody needs to sell Linux or bash Microsoft and Linux can stand on its own.

Justin

These filesystems are not as simple to interface in as the "Amiga filesystem" or other such stuff, as these FSes have expectations to be able to control somewhat how the kernel manages caches. They're not merely "drop in a patch and all will be well."

As a result, while I agree that it's good to have some diversity now to allow some experimentation, I am far less sure that it will be wise to have four (or more, if rumors of Compaq contribution of AdvFS code turn out to be true...) filesystems integrated in to the "official" kernel stream. There may be merit to having a couple of them, but not likely all of them.

So while I agree that it's quite OK for there to be 5 of them (and that ignores GFS, NTFS, and other stranger options that may be of less direct relevance), I think that there will be, ultimately, a need for several of the "integration projects" to fail.

Otherwise, Linus and others won't have time to fix up NFS3, improve memory management, implement ACLs, implement capabilities, implement IA-64 support, and all the other sorts of things that need to occupy some of their time.

The GUI comparison was pretty good; I agree with Per that it is a Good Thing that we have GNOME and KDE, as this is sufficient diversity to ensure that there is some competition whilst not being so much as to be completely fragmenting. It is unfortunate that this leaves some potentially good toolkits like FLTK or Tk or Amulet or Garnet or InterViews "out in the cold."

The point is that variety is useful at the point in time at which you're not sure what the results should look like.

But after that point, variety comes at the cost of having to support additional "development streams," and while there is logic to "letting the best man win," this has the side effect that if you agree with this, you have to also agree with the notion that the "not quite best men" need to be able to lose.

GTK is under active development, which means it can be fixed. GTK could easily be made to use the X Resource Manager as its basis for reading and storing preferences information. This could be done without breaking any existing apps: it could be a binary-compatible change.

But even if I'm wrong, and doing so would require incompatible changes, so what? They've done it before (there was a year when everyone had to have two versions of GTK installed because Gimp didn't work with the version of GTK that almost all other apps were written for.) They've had flag days before and they will have flag days again.

Dismissing my criticisms of GTK's design because ``the decision has been made'' or ``that's living in the past'' is ridiculous. If a design mistake was made, even if that mistake is fully entrenched (like most of Unix), that mistake should be acknowleged so that people don't make similar mistakes in the future.

I haven't figured out how to do similar dragging and dropping on the desktop or between applications with KDE or Gnome. I'm pretty sure it's there,

GTK+ 1.2[.x] (the toolkit for Gnome - as well as for many non-GNOME applications) has support for drag-and-drop, using both the Xdnd protocol and the Motif DnD protocol. Qt 2.0 (the toolkit for the under-development KDE 2.0) also supports drag-and-drop using Xdnd (but not, as far as I know, the Motif DnD protocol); I think Qt 1.x supported DnD on UNIX/X11, but not using Xdnd (unless one of the later 1.x's added support for it, which it might have).

Here's Troll Tech's documentation on DnD with Qt (probably for 2.0). There may be additional KDE APIs atop that; try plowing through the KDE developer's site.

Here's the GTK+ reference documentation section on DnD APIs; again, there may be additional GNOME APIs atop it - if you plow through the GNOME developer's site, you may find something.

I'm pretty sure it's there, but it doesn't seem as integrated as it did on Irix.

"Doesn't seem as integrated" in what sense? Presumably not in the API sense, as you haven't yet looked at the API; maybe fewer KDE and/or GNOME applications support DnD, but I'm not going to assume that's the case.

I haven't figured out how to do similar dragging and dropping on the desktop or between applications with KDE or Gnome. I'm pretty sure it's there,

GTK+ 1.2[.x] (the toolkit for Gnome - as well as for many non-GNOME applications) has support for drag-and-drop, using both the Xdnd protocol and the Motif DnD protocol. Qt 2.0 (the toolkit for the under-development KDE 2.0) also supports drag-and-drop using Xdnd (but not, as far as I know, the Motif DnD protocol); I think Qt 1.x supported DnD on UNIX/X11, but not using Xdnd (unless one of the later 1.x's added support for it, which it might have).

Here's Troll Tech's documentation on DnD with Qt (probably for 2.0). There may be additional KDE APIs atop that; try plowing through the KDE developer's site.

Here's the GTK+ reference documentation section on DnD APIs; again, there may be additional GNOME APIs atop it - if you plow through the GNOME developer's site, you may find something.

I'm pretty sure it's there, but it doesn't seem as integrated as it did on Irix.

"Doesn't seem as integrated" in what sense? Presumably not in the API sense, as you haven't yet looked at the API; maybe fewer KDE and/or GNOME applications support DnD, but I'm not going to assume that's the case.

As an early promoter of fvwm, we came across many obstacles in the corporate world
to it - the reason was, usually, that CDE was the standard to which the corporation
had to adhere. However, the inception of KDE (and GNOME) has huge advantages
of the archaic systems that were Motif/CDE. For example, something as simple as
adding an application as a menu item into CDE used to have you looking up the
reference manual (which was not clear on the matter).

KDE and GNOME are a breath of fresh air - they will undoubtedly become the new
"standards" on the desktop for Unix platforms. Developers ignoring these
desktop systems are going to find they've missed the boat - big style.


Having seen some of the developments going on with KDE2 such as the
Neural network window placement policy I'd also stick my neck out and say that
they have a good chance in the next 3 years of making inroads into the NT-on-the-desktop market.

If you're a desktop user, checkout the GNOME User Interface Improvement Project.

One of Mike's key theories seems to be that there is no sense of feedback between the end-user and the coder in Open Source development. I would refute this fairly strongly - often the people I know using Open Source tools have fairly widespread experience of other User Interfaces, ranging often both across multiple platforms and going way, way back to before the days when the Graphical User Interface first raised it's head above the primordial digital soup. Now this experience does not make any of these people a UI expert, nor does it necessarily mean that the programs they write have well designed User Interfaces. It does however give us the possibility of recognising good UI design when we get to experience it, and also the possibility of influencing the design of the User Interface in later releases.

In these days of expanding user-base for Linux, and the push to provide a more newbie-friendly environment to work in (which, by the way, I totally support), good User Interface design is getting to be much more important. There are various resources appearing, from the Gnome UI Improvement project and its mailing list, along with the work that the KDE people are putting together with KDE 2.0, which are testament to the need to try and learn from the many graphical interfaces out there and to innovate as well. Having a well designed UI need not reduce the speed at which the experienced user uses their machine, while allowing the novice some hope of making progress.

Innovation is often overlooked in designing a new UI. As soon as you stray from, say, the way MS Windows does something, people jump up and down worrying that new users will be confused by a different method. I'd disagree - just because it has been done that way before is not, in itself, reason to continue doing it. A good UI *must* be intuitive and logical at some level - simply copying the existing behaviour of other window managers will not end up with a coherent project. At the moment, the graphical user interface is a mess of conflicting ideologies. We all have experienced the frustration of 'Drag-and-drop' when it isn't a universal quality - for example in Windows, you can (sometimes...!) drag a file into a program to load it, but you can't drag that file out to save it or pass it to another application to work on it in a different way. And I don't mean using the clip board either, although that may be the route that would be used to effect such a transfer, it shouldn't be obvious to the user that that is how it happened.

Taking the best paradigms for working with a graphical user interface and making it all stick together in a cohesive fashion is a task of iteration, experience and reiteration between the end-user and the coder. Since in the Open Source world the user may also wear the coders hat, this should be the ideal environment in which to create and refine the most useable graphical interface on any platform, as long as we keep our sights on some central game plan of Useability and not merely on creating a feature-rich tick list of things our programs can do.

Cheers,

Toby Haynes

Jeez, those screenshots are amazing. This one is the best. My question is, since when have you had the capability to have transparent window borders??
That is soooo damned cool.

http://enmasse.penguinpowered.com/

Although I'm a little aprehensive, a buddy of mine has it up and running already and says it is very slow at times, he's still tweaking but not having much luck. However from what he says it's a GIANT leap in the right direction. Very slick.

The FTP links:

ftp://ftp.gnome.org/pub/ GNOME/unstable/sources/gnome-core/
ftp://ftp.gnome.org/p ub/GNOME/unstable/sources/gnome-applets/

Never knock on Death's door:

Although I'm a little aprehensive, a buddy of mine has it up and running already and says it is very slow at times, he's still tweaking but not having much luck. However from what he says it's a GIANT leap in the right direction. Very slick.

The FTP links:

ftp://ftp.gnome.org/pub/ GNOME/unstable/sources/gnome-core/
ftp://ftp.gnome.org/p ub/GNOME/unstable/sources/gnome-applets/

Never knock on Death's door:

Although I'm a little aprehensive, a buddy of mine has it up and running already and says it is very slow at times, he's still tweaking but not having much luck. However from what he says it's a GIANT leap in the right direction. Very slick.

The FTP links:

ftp://ftp.gnome.org/pub/ GNOME/unstable/sources/gnome-core/ ftp://ftp.gnome.org/p ub/GNOME/unstable/sources/gnome-applets/

Never knock on Death's door:

Although I'm a little aprehensive, a buddy of mine has it up and running already and says it is very slow at times, he's still tweaking but not having much luck. However from what he says it's a GIANT leap in the right direction. Very slick.

The FTP links:

ftp://ftp.gnome.org/pub/ GNOME/unstable/sources/gnome-core/ ftp://ftp.gnome.org/p ub/GNOME/unstable/sources/gnome-applets/

Never knock on Death's door:

I think the Open Content License has been shown to work quite well. Take, for example, Havoc Pennington's GTK+/Gnome Application Development, released from New Riders earlier this year.

Havoc has a page online with errata for the book, an online version is available, and there's even a CVS version available. That's the power of an open publication license - I think it's great.
----

I think the Open Content License has been shown to work quite well. Take, for example, Havoc Pennington's GTK+/Gnome Application Development, released from New Riders earlier this year.

Havoc has a page online with errata for the book, an online version is available, and there's even a CVS version available. That's the power of an open publication license - I think it's great.
----

The real URL is at http://developer.gnome.org/gnome-ui.

The great thing about developing interfaces with GNOME is the libglade architecture. Designing an usable interface is easier if you can rapidly design it in such a program and if you can tweak and revise it at runtime.

You're spot on about the uses of autoconf you mention but it has other advantages as well. It encourages the use of very deep packages without having to remember the (nightmarish) rules about recursive Makefiles. Instead of dumping all my source in one directory, I can organise it in a logical fashion and get the flexibility, dependency stuff checking and modularity that goes with it. That's just too much work to do every time with vanilla make I find.
Autoconf also simplifies creating a distribution (make dist), putting in checks into your code (make check), installing and uninstalling correctly no matter where the prefix is, and checking for the correct libraries before compile time.
Not that I don't understand make - in fact I think that using autoconf and scanning its output has helped me get a handle on how make does its magic but doing it by hand? Eeek.
A standardised programming language would work. I think Perl makefiles are already a step towards that idea. But a new one would take time to catch on. Nearly all GNU stuff comes with configure scripts. I get nervous when I download source and it doesn't have a configure because 90% of the time, something is wrong and it needs a bit of makefile hacking.
A front-end for autoconf would be a good idea as proposed by some previous posters. Those who want to learn it before a nice GUI comes out or a replacement is found can check Havoc Pennington's online book which has a chapter on the package.

You can learn more about the various GNOME technologies that make up the component model here: http://developer.gnome.org/arch/componen t/

Bonobo uses ORBit, the GNOME fast and slim CORBA implementation for all its communication needs. Unlike popular belief, Bonobo components can be implemented as shared-library object, another process, or a remote process. Giving programmers the freedom they need

The Bonobo design is inspired by COM, Javabeans, Delphi controls, OLE2 and OpenDoc. The main document embedding interfaces are strongly modeled after OLE2, as this model is well understood, well documented and easy to implement.

Best wishes,
Miguel.