Please create an account to participate in the Slashdot moderation system


Forgot your password?

Miguel de Icaza Tells All! 82

In his responses to the Slashdot interview, Miguel shares the deadly truth about GNOME, the shocking story of the future of Bonobo and CORBA, and the titillating tale of adventure and intrigue that lies deep within the bowels of popular Free Software development projects. Okay, so it's not all that shocking, but Miguel has brought us some really great news and answers from his neck of the open source woods.

Printing and GNOME
by datazone

Printing and printer support is a major issue with the Linux desktop. How do you plan to address this in GNOME in the future? Or do you believe that it should be addressed in a lower level than at the desktop?


This is a very interesting question.

We have been working on the GNOME printing architecture, which so far consists of an imaging model, and some user interface elements for applications to use.

The GNOME printing architecture is interesting as it provides:

1. A postscript imaging model for programmers to use.

2. On top of the Postscript imaging model we added alpha transparency (and as an added bonus we also added anti-aliasing).

3. Native drivers (no need to generate Postscript first and manually process with Ghostscript a file for your printer, which has many problems from the user perspective, from the efficiency point of view, and from the quality point of views).

Currently the GNOME printing architecture includes a Postscript driver, an on-screen preview driver, a generic RGB driver (that can be used to generate images), a meta-file driver, and a black-and-white HP PCL driver (which needs work, and yes, we could use some help making more native drivers ;-).

Now, GNOME Print alone is not enough, it needs to be tied with the spooling system as well and have access to the features of a particular printer. So the GNOME printing system needs to integrate with these systems. We have been talking to the various people working on these projects, and GNOME print will integrate with a variety of spooling systems.

For example, GNOME print and the VA, and TurboLinux efforts for a printing architecture are complementary, so there is a good chance it will be our first spooling back-end.

So just to re-iterate, the printing problem can be divided in:

1. Application API for rendering data.

2. A spooling system: a way to query the printer queue, control the printer queue.

3. A printer capability system: which would let applications and users use the various features available in their printer.

4. User interface elements for enabling programmers to make the most out of the above features.

GNOME print is only attacking (1) and (4), and we are working with other people to provide a complete solution to the printing problems in Free systems.

Okay, alright....answer this HONESTLY
by SgtPepper

Just how well do you and the KDE guys REALLY get along....don't you GNOME people ever just want to get together all the Nerf gear you can and stage an all out war?

Seriously though, how much communication really does go on between the two camps? I would imagine at least some must if you and the KDE camp are to maintain interoperatability.


We talk in various mailing lists about these issues. For example, the wm-spec-list is very close to releasing a joint specification for window manager features that both GNOME and KDE can use.

On the other hand, I do personally like a lot some of the KDE developers like Kalle, Torben and Matthias. I have had the chance of meeting Kalle more times than any other of the KDE developer.

Also, recently an effort has been started to share widgets across Gtk+ and Qt. Both projects will announce the details when there is a more concrete plan about it.

But all in all, it is important that we agree on file formats for documents, which is what end users are exposed to.

User interface importance?
by zhobson

First off, I'd like to say that I love GNOME, it's been my primary environment since 1.0 was released.

Now then, how do you think GNOME will evolve in terms of usability? GNOME has certainly conquered the stability mountain (anyone who argues otherwise probably isn't using release versions), which is almost certainly a side-effect of the Free Software development model. However, while Free Software is generally powerful and easy to use for experienced users, it's not generally the kind of thing a novice can operate easily.

I remember hearing about a "usability group" or something like that for GNOME, to concentrate on interface issues. This is a great idea, but I haven't heard much about this group since then. Are modern user-interface issues a concern for GNOME,or is it mainly trying to match the interface conventions of other popular GUIs (like NeXT, MacOS and Windows)?

We started the GNOME User Interface improvements projects last year.

During the initial development of GNOME, we did not have a lot of time to discuss and incorporate ideas that flooded constantly. But later we realized that many genuinely good ideas were dropped because we did not have time to implement them at the pace they were coming (the standard reply in the early days of GNOME was `Want something changed? send a patch'. And we have basically changed this)

So the User Interface Improvements project was started to address this problem. It is coordinated by Jim Cape, and he works with other users and programmers to bring these usability changes into GNOME.

The UI team has been focusing on usability of the GNOME desktop by taking the input from the community. They are assembling and cataloging the suggestions for improving GNOME as well as providing mock-ups of how various GNOME tools could be improved.

As a result, I believe we are a lot more receptive to people's input than we were before, and this is something we want to keep enhancing as time passes.

Now, it is very hard to come up with good user interfaces. So there is definitely an element of copying existing interfaces. User interfaces and paradigms that are known to work and bring them to free software. But this is not stopping anyone from contributing new ideas and new user interface elements that can be incorporated into the system.

Contrast this with the people who want to reinvent computing as we know it (you can identify them at parties because they will start their senteces with `What is computing anyways?'). The GNOME project is not in this realm, but we would gladly take all the good ideas that both research and production communities produce and we will incorporate them. What we have not tried to do is become a user interface research project.

That being said, you have to keep in mind that it is very hard to start innovating user interfaces if you have zero lines of code. With the current GNOME system as it stands you can start from a working application that has already a few thousand lines, and work towards innovation.

It is like trying to design a car trying to ignore all the knowledge on mechanism, thermodynamic and engineering that has been accumulated over the years. It is a simpler task to innovate if you use the existing knowledge. As Isaac Newton said, you can view a lot further away because you are standing on the shoulders of giants.

For example, it is easier to innovate user interfaces for a spreadsheet once you have a fully working product (so that you can just remove the part you think can be removed, and plug your new code there), rather than trying to innovate the user interface and having to build all the infrastructure.

There are various companies that are working together with GNOME now, and they are bringing their expertise from their previous experience, which is very good for improving the general usability of GNOME (Eazel).

Andy is someone I really like for his vision on how computers should work, and his special attention to the end user.

Talking to him has changed a lot my view on what GNOME should be. In the beginning I thought "We need a desktop for free systems", now I think "We need the perfect user interface for end users to use on a free system". Achieving the best user/computer interface is a goal that many of us share.

But this is just a first step, we are of course working and integrating the ideas that will define the desktop computer of the future.

C++/Java/CORBA/Components/Frameworks (Score: 5, Interesting) by PureFiction

Do you see object oriented design and implementation playing any part in GNOME's future?

The architecture of GTK/GNOME is technically somewhat object oriented, however, without all of the benifits of an object-oriented language (at least the parts written in C).

It would seem to me that as the scope and size of the GNOME project increases, it would be increasingly advantageous to use C++ or Java with much more CORBA support and more structured design (UML design models?) for reference by the developers. Standard components and frameworks would also fit well into this type of extension.

Do you see GNOME increasing in complexity and size to the point where these types of development techniques would be required?


Yes, there is a lot of object oriented design going on in GNOME.

On using UML for modeling various components in GNOME:

Recently there has been a boom in creating UML diagrams for various GNOME components (particularly for new applications) as our Diagram application has become mature (

Various GNOME module authors have different preferences on what languages they want to use, and it will be up to each of them to choose the language they want to use for their own modules. I myself want to use Python more and want to use Java more in my own developments.

Although, just because some of our code is written in C, does not mean you are left out of paradise.

Now, a big push right now within the GNOME effort is to use Bonobo components, which are basically reusable components built on top of CORBA, with a set of standard interfaces for component programming.

Outlook Interoperability with Evolution
by Cybersonic

My question actually has to do with Evolution, the upcoming Outlook killer.. :)

Will GNOME serve (Evolution) information to MAPI clients? Would be a nice way to get rid of those Exchange servers sitting in most companies' server rooms...


Evolution is probably the most exciting application that is being developed in the GNOME world right now.

First, Evolution is based entirely on Bonobo components. It is one of GNOME's proving grounds for component-based programming. We have spent over a year developing the Bonobo component model, and in Evolution it's beginning to pay off in a big way. Each component in Evolution (mail, calendar, tasks, notes, contacts) is a Bonobo component, fully CORBA accessible (to enable automation and scripting of applications, and yes, it is secure. We do not feed any unsecured data into components, in case you were wondering).

The component-based pluggable architecture means that we can make Evolution into a universal communicator. So, yes, we have every intention of integrating with Exchange environments. Picture an office populated by Outlook clients and an Exchange server or a Lotus Notes server; we can infiltrate that place from the bottom up by making Evolution talk to those Exchanges or Notes servers. Clients can upgrade to Evolution one by one, without the requirement of a top-down organizational decision to dump Microsoft.

This is how GNU/Linux won. This is how we will win.

But the beauty of Evolution's architecture goes much further. It is the first communications tool designed for modern users like the free software community. The free software community stays in touch thanks to e-mail and as we grow, we need more powerful and efficient tools to handle our communication loads.

For example, I receive about 2500 mails a day. Even with procmail and Gnus, filters, scoring and lots of complex scripts, I still spend about four hours a day on e-mail related tasks. And it is pretty hard to find information on the gigabyte of mail that I have archived over the last few years. Traditional mail tools are not keeping up with the demands of modern Internet citizens like myself.

We believe that the mail loads that most free software developers are handling these days are going to become the norm for normal users in the future as the Internet becomes more ubiquitous and e-mail becomes the tool of choice for communication.

Evolution scales to mammoth mail loads perfectly, though. The hackers in the Evolution team designed the entire system to scale: we avoid copying data wherever possible, we never load the whole message into memory even over IMAP, and we used asynchronous interfaces across the board.

Now, the real beauty is that we index all of the mail as we incorporate it into our mailboxes. Dan Winship wrote this beautiful indexing library called libibex which we use for indexing and Michael Zucchi is working together with him in our vFoldering setup. So you can treat all of your archived mail as a giant database, and perform queries on it (think "Altavista for your mail"). So you will finally be able to find information in your mailbox, and you will finally be able to keep track of things.

And then you can save that query as a "virtual folder" (vFolder). So in fact your folders are actually the results of searches on your mail.

Also every element in evolution can be annotated and annotations can be cross referenced, so you can keep track of your contacts, your tasks and your information flow more easily.

And that's just part of the whole system. We are working on fully networked calendaring and contact management, too. So you can schedule appointments with people over the Internet, and have servers storing address-books. We are going to have a Evolution server with all of the address-book entries for all the GNOME hackers.

The system is still under development, of course, but it's the most fun thing to hack on, and we are applying a lot of the tricks we have learned over the past years and enjoying the result.

Evolution is not only limited to handling the standard Personal Information Management features, but through Bonobo components you can plug any sort of communication system and have it integrated with the rest of the system. So hopefully, your irc conversations will also be fully indexed, as well as any other personal messaging system that ships with Bonobo support.

Think "deep integration" and think "I can find that e-mail".

If you want to learn more about Evolution, I suggest you check its Web page here, and as with every other free software project, we would love to see you join the effort, and help us get this out and deployed.

WM interchange
by Wubby

The arguments over Linux Desktop adoption are well know. IMHO, I agree with the strength in diversity reasoning and WOULDN'T like to see GNOME/KDE/Other merge developement regardless of the benefits.

Despite this, do you think WM developers would work towards a set of interface or API standards (to facilitate interoperability) or would this place to great a restriction on innovation and the developement process?


Definitely. The WM spec list has been working for a few months on getting an inter-operable window manager specification for developers to use (and both KDE and GNOME as well as the various active window manager maintainers are contributing to this effort).

How important is COM-like architecture?
by Pike

It seems that the GNOME effort is throwing an awful lot of resources at a component-ized architecture (Bonobo) which aims to do for *nix what COM and ActiveX/OLE did for Windows. And yet it just doesn't seem necessary. I know it's possible for me to insert an Excel spreadsheet into a Word document, but I haven't used that feature in recent memory. None of the documents I exchange with co-workers do, either. Is Bonobo really very necessary? What does bonobo bring to the Linux desktop that users are crying out for, and how is its heavy consumption of development resources justified?


Bonobo is a mechanism for creating reusable software components as well as enabling users to talk to the components through a standardized programatic interface (CORBA).

As I have mentioned in the past, the GNOME project has focused strongly on building a solid infrastructure for people to use, and component programming is just another part of this equation.

The core idea of software reuse and software components is that you can reuse what other programmers did and there is a very precise contract on what the component provides, and the API it exports that you can use to talk to it (Brad Cox used to talk about Software IC, and I am convinced that Software IC did not come in the shape he expected, but in the shape of components).

Also, by writing components, you can mix and match the components: it does not matter which language you used to implement your component on (currently you can use C, C++, Java and Perl to write your components, it does not matter, as all of them will be able to talk to the others)

For example, we wanted to extend the drawing capabilities of Gnumeric, so instead of writing yet-another-half-cooked-vector-drawing-program on top of Gnumeric, we are working with the Dia guys (and in the future with the Sodipodi hackers) to use their editing engine inside Gnumeric.

This is thanks to the fact that we can have arbitrarily-shaped compound document embedding in GNOME, so when you insert a vector-based drawing into your spreadsheet, this drawing is not going to be even handled by the spreadsheet, it is handled by an actual full-blown application that does nothing but specialize on this specific task.

Reusable software components are not limited to visual components, nor embedding information. You can even have completely GUI-less components.

But your point is a valid point, we believe that it took proprietary companies 20 years to produce a few productivity applications, and they are not that fully featured, and they are not that impressive anyways. Specially, as the result is buggy software that slowly improves.

With the current proprietary tools, the whole world is waiting and depending on a few small teams around the world to provide them with their software solutions.

We are building applications that will go beyond the existing offerings: both in usability, simplicity and power. And to do this, we need to avoid the approach of building monolithic applications but rather have small applications cooperating with each other. This is pretty much like the original Unix spirit: write simple tools that do one thing correctly, and have this tool inter-operate with other tools. We have just taken the small tools to the next level: communication can be N-way and the information you exchange is rich and attribute tagged, rather than being free-text (this is the difference between HTML and XML).

You can learn more about the details of Bonobo in my Bonobo technical description.

Also, you have to keep in mind that component programming really goes hand in hand with the way Free Software is developed. With components you can isolate tasks into a module that can be easily understood and digested by a small team of programmers, instead of forcing your programmers to learn how an entire system works.

Given that free software contributors might not be able to commit to work on a project for a long time nor for a given number of hours a week (because of school, personal obligations, or other activities) it makes sense to isolate the tasks. You can then restructure components without affecting the other applications, or you can rewrite them, or you can upgrade them or you can change its behavior to work in different conditions (scalable service or doing work to simplify the code for mobile purposes).

Bonobo/CORBA fulfills the objective of having reusable software that can be shared across applications. Components go one step beyond the traditional object oriented mechanism for software reuse, as components can be implemented in any language, programmers do not depend on using a specific language or a specific application framework that is tied to a language to use components, they can choose the language and programming environment that better reflects their project needs.

Given the nature of Bonobo/CORBA of being language independent, you get the benefits that object oriented programming was designed to solve in a cross-language form.

So GNOME is developing and deploying the framework to create a component infrastructure for free systems to use, an infrastructure in which we will build the future applications. Remember, we are not in the business of selling the same application every two years, but in the business of solving the problem.

Bonobo is still a work in process project, and although various applications already use it (Gnumeric, Evolution, Glade, Nautilus, libGlade, ggv, eog, and gpdf) we are not yet ready to freeze its API.

GNOME has made a lot of advancements on the "traditional" interface front (I mean all of Xerox-derived WIMP land), both in the "easy (or efficient) to use" and "easy to learn" departments. I find case after case, subtle and not-so-subtle, where GNOME is markedly better with its main competition, Windows and Mac. My favorite example of this is Evolution -- can't wait to try it. Evolution may finally tear me away from textmode mail clients....mmmm, query-able databases :)

My question is, where do you see GNOME as fitting in to more groundbreaking user interface research? Not that anyone expects the GNOME team to start pondering lexicons for 3D interfaces (or are you contemplating such things!?!). But there's lots of crazy stuff that still goes on in traditional, 2D interface design. A lot of recent research has been in terms of PDA interface design. Do you see GNOME, with its obvious advantages of modularity and scalability, as having a role to play in that arena?

And what about fundamental changes to the way we use our desktops? I for one haven't really changed at all since the days when I used fvwm1. Sure, things have gotten much prettier, and more applet-filled :) but I'm doing fundamentally the same things, and none of the various ways of configuring things (GNOME + sawmill = many ways of configuring things) have so far seemed particularly radical or any more efficient.

How 'bout the rest of the folks? Anyone done anything truly funky with sawmill? A Turing-complete wm is a fun place to start ....


I definitely see GNOME playing an important role in innovative user interfaces. As I mentioned before, the GNOME foundation, the GNOME applications and the GNOME tools help users get closer to their final goal. For example, it is a lot easier to write an accounting system if you have the proper database libraries and user interface libraries than rolling your own.

So GNOME is this foundation you can start building from, and it is a foundation you can improve (given its open source/free software nature).

There are now people working on different dimensions with GNOME: from new and innovative user interfaces, to productivity applications, to embedding GNOME into small devices, to building component-based software and more.

I understand that for a seasoned Unix user GNOME might not bring a new paradigm for their way they work, but you have to think differently. You have to think how many people have or will be able to run free software on their desktops because it is easier to use.

We do plan on continuing improving GNOME, and catering to the needs of the people who are just starting to use computers and just starting to use GNU/Linux.

When did it take off?
by Uruk

When was it exactly that you knew (or had the feeling) that GNOME was a project that was going somewhere? Free software projects start with no guarantee of popularity, and for every GNOME, there's 1000 totally unknown applications.

Was there a particular application or library or component of GNOME after which you knew GNOME was going to be successful or in general "something special"? What did the GNOME project do that prevented it from sinking into obscurity like so many other free software projects?


I do not know if I ever thought of it that way. You have to understand that when we started the project, what we had in our minds was defending the freedom of software, and not allowing the future of GNU/Linux to be jeopardized by having its user interface be proprietary. Back when the project started I was working happily with my friend Ralf Baechle on the Linux/MIPS port for SGIs.

There are many other reasons that motivated the various members of the GNOME team to work on it: from freedom concerns, to personal joy, to friendship building, to helping other fellow humans to creating the best possible software out there, to learn how to do things and solve problems. And I bet there are many other reasons to do so.

Avoiding sinking I guess was a matter of a lot of hard work from all the involved parties, I do not think I have taken a lot of breaks from working on free software since the GNOME project started. It has been for me a non-stop effort since we began with perhaps three weeks of vacations total.

Also the Red Hat support back in the original days of the project was also very motivating, as they had the same concerns we had regarding the future of a fully-free system. They assembled a team that to this very day is working on GNOME and making the GNOME infrastructure more reliable, robust and usable: from coordinating GNOME documentation to maintaining the core libraries, to creating the new ultra kick-ass Pango architecture.

The GNOME team is large, and I can not speak for all of them, but I do love each and every contributor to GNOME, and I owe beers to them all. I actually, owe them more, but I don't want to go broke.

I love GNOME, but one thing that I really miss is good integration of sound. Let me be clear... I'm not just talking about blips and burps to coincide with user clicks on the standard window widgets... I want it to be easy for application developer to add in audio aspects to their applications UI presentation.

For example -- if I was developing a word processor, I'd want it to be straightforward for me the developer to add a pleasing click with each word that is highlighted.

I understand there are some technical problems to be solved here, but there are more than enough sharp people working on GNOME to make good sound UI happen -- if it is made a priority. I admit that I'm pretty ignorant as to how GNOME is approaching sound. Could you fill me in (and hopefully reassure me)?


I am not very up to date on the discussions on the sound architecture for GNOME. I know that currently we use ESound, and we provide an API for playing sounds to applications, but as your post suggests, attacking the problem correctly and coming up with a design that addresses the various requirements and needs from various sources is not a trivial problem.

And this is part of the discussions we have had these last few days on the GNOME-devel mailing list. If you have ideas that you want to contribute to, I encourage you to join the list, and help with ideas, code, or time the people who are working on this.

Mexico and OSS
by Vox

Hola, Miguel

As a fellow Mexican I want to know...what do you think is the impact of OSS in our country? I know all about the project of putting a whole bunch of Linux boxes in schools, so that's nice, but...what about developers? I don't really remember more than a couple of names of Mexican developers besides yours, which, in a way, also means that we don't have as much advocacy/knowledge about OSS in Mexico as we should (the MS tax kills easier here than in the U.S., for obvious reasons).

I guess as part of that question...what do you think should be done to "push" more developers into OSS here in Mexico?

Gracias por un excelente trabajo para todos nosotros.


I believe that Free Software will help countries with developing economies (like Mexico) to get a competitive advantage that they have lacked for so long. Most of these countries missed the industrial revolution, and for one reasons or another, they depend on external technology to keep up with the times.

Free Software helps in the fraction on depending on external technologies. For example, countries with developing economies can now avoid depending on proprietary software: they can keep the money they spent on proprietary software to themselves, and use it to either develop themselves, or they can use that money to produce free software that will solve their problems (and hopefully other countries problems).

The case of Mexico is the one I am most familiar with: Mexico does produce very little technology, depends a lot on foreign technology and pretty much our main exports are raw materials. Raw materials are extremely cheap (and in some cases it took nature a few million years to produce). For example, a barrel of petrol costs about $25 these days, and a copy of Microsoft Office and Microsoft Windows 2000 costs around $700. Which means that for each copy of Office+Windows 2000 the country is paying with 24 barrels of petrol.

Of course, it is not very easy to do a transition to free software in these countries (as it is not easy anywhere else), but the people governing the developing countries have the responsibility to their people of making the right decisions, and the right decision when it comes to software is not proprietary software.

In general, I believe that we must become software producers (and also technology and innovation producers), and not just consumers. Becoming free software users is a good first step, the next step is to become software producers.

The beauty of free software and GNOME is that part of the freedoms you receive is the freedom to learn from other people's techniques, strategies, and focus on problem solving. Something that has been unheard of in this industry (although it is a pretty common thing in science). So people have a chance to join the effort, and be part of the team of people that are producing knowledge, culture and as a result wealth.

Many smart people on the educational system realize this and that is why GNOME and free software have been very well received on the educational markets, and we are very happy to help them to provide the applications they need.

People should also know that the multi-million dollar efforts to bring computers into every classroom in Mexico and other countries should be equipped with Free Software/Open Source software. And encourage these people to become creative and become part of the creation process rather than just be users of pre-packaged solutions.

Will GNOME implement an API for installers to use? One thing that helps Windows is a common installer so that most software you put on your system is pretty easy to get on. You just click on the executable and then it installs. With GNOME's goal being to make a user-friendly system do you see this as part of that?


GNOME has a few applications for attacking this problem (the GIP), but the problem these days is not just being able to easily install applications, the problem is the slight, subtle and tricky fragmentation of the GNU/Linux distributions.

For example, Helix Code is shipping a pre-built GNOME for various platforms. Although we would love to just compile the code in a specific system and have it installed on the other distributions, it is not possible.

Hopefully the effort to create a standard GNU/Linux base will in the future get rid of this problem, but for now, you are right, it is a real problem and the one that might hurt more the deployment of free software.

Also Helix Code has an installer and an updater that we hope in the future will be turned into generic installer/updater programs that other people can use.

handicapped accessibility and GNOME (Score:5, Interesting) by esj at harvee

I would be interested to find out what are GNOME project's plans for handicapped accessibility. As it currently stands, GNOME is only usable by people with fully functioning eyes and hands. It would be nice to hear how GNOME will address handicapped accessibility for:

visual impairments
mobility impairments
hearing impairments


I know that we have added patches to a few applications to make them usable for visual impaired people and that there are a few applications for GNOME that do address this problem.

I know that Paolo has an infrastructure for visually-impaired people to use with GNOME, and that it hooks to various GNOME applications, but I have not seen this in action myself.

But we are open to extending and changing GNOME in the ways that are required for handicapped accessibility.

Print / display font unification
by elflord

Hi. As the author of the font HOWTO, one issue I've had to address is the lack of a WYSIWYG font system. It boils down to what I think of as the WYSIWYG Typography Problem -- which is this: show me some code that reliably displays a typeface on the screen, and prints text using the same typeface ( at a printer resolution, of course ).

The problem, of course, is that the printing (usually ) goes through ghostscript, while the screen fonts are handled by X11, which operates independently of ghostscript. However, given a screen ( ie X11 font ), there is no canonical way to get the corresponding outline file (pf[ab]|ttf) or the detailed metric information ( such as kerning ). This problem is quite deep in some sense, because the fact that the X client and X server run on different machines means they may not have the same typefaces available. In short, Linux's right hand does not know what it's left hand is doing when it comes to font management.

Applications such as Star Office and Applixware "solve" this problem by using a text configuration file that basically consists of a catalogue of mappings from screen fonts ( in particular, XFLDs ) and printing fonts ( including outline files, metric files and the printer font name ). While these solutions are all more or less satisfactory in their own right, there are too many of them -- we need one GUI font manager that all apps can share.

It is very unfortunate that there are several incompatible solutions to the problem, because it means that the Linux user needs to install their typefaces once for each WYSIWYG app they need. A standard would be a very good thing. Personally, I like the idea of a well documented XML configuration file that could be used by any app regardless of the GUI API used.

In conclusion, my question is this -- What are GNOMEs plans for attacking the WYSIWYG typography problem? And will the solution be GTK/GNOME specific?


There are many-fold, and it is a bit long to explain, but here I go.

You got all the basic problems right. And this is indeed the problem.

* The solution: the solution we have planned consists of using client-side rendering (there are a bag of tricks for making this efficient, if you are interested in these I can explain, but for the sake of the discussion, assume "efficient").

The basic idea is that we want to reuse the code from GnomePrint to load, parse and render type1 fonts. Add support on top of that for TrueType fonts and use those fonts for rendering on the screen and rendering them on the printer.

The core of the idea is: ignore the X fonts as they are useless anyways, and use the system installed Type1/TrueType fonts. And they are useless for a number of reasons: they are only available as bitmaps, not as outlines, and the font naming scheme is basically useless.

* Rendering outline-based fonts (TrueType/Type1) on the screen: Now, this posses the problem of outline fonts looking very bad at low resolutions (for example 12 pixels), and given the patents surrounding hinting in TrueType, it is not clear that we can just use these font technologies alone.

What needs to happen is that someone needs to implement the Hobby algorithm for coming up with beautiful bitmaps from the outline fonts. It is my understanding that someone from the FreeType team had been working on this

* The current approach: Gnome Print currently only pays attention to Postscript fonts, and uses those fonts. And it contains a setup for "guessing" a good match for the screen presentation, but this is far from optimal and will be replaced.

* The Pango project is attacking a load of other issues when it comes to fine typography and rendering of non-Latin1 characters.

Pango will be a standard component of the GNOME 2.0 development platform, at that point the Gnome Print will use Pango.

When I first started using Linux (about a year ago), what impressed me the most was that you weren't locked into a single, all-encompassing solution. Everything was (and is) so modular. Tools like grep, ls, cat, head, etc. and the use of pipes just seemed so refreshing to me, someone who had been using MS-DOS (including Win95) for as long as I can remember. Even in the GUI, there was the display server, the font server, the window manager...

I see desktop environments as being very contradictory to the traditional UNIX philosophy of "do one thing, but do it very well". We have the two leading desktop environments, Gnome and KDE, which are rapidly expanding to include everything under the sun. Is an office suite really part of a desktop environment? Is an email client? Terminal emulator? Web browser?

Personally, I think the answer is no. I want the freedom to choose my desktop shell, my e-mail client, my Web browser, and my office suite.

To get to the point, my question is this: do you believe that the notion of a "Complete Desktop Environment" contradicts the traditional UNIX philosophy? If so, why do you feel the need to change something that has obviously worked so well for so long?

If you would like to know, I would personally prefer that Gnome consist of the panel and shell ONLY, and then we could have something like Helix which could package the panel and shell with a nice browser (branded mozilla maybe), window manager (sawmill or e), etc. I definitely believe there is a need for an open-source office suite, but I think the development should go on outside of Gnome or KDE core.

The objective of the GNU project was to create a fully free operating system. The definition of operating system that Richard used back when he stated was something like "All the things you need to get your work done", or something like that.


If you want to call that GNOME, or you want to call it GNOME Office, or "The Thing" it is really a naming issue. The objective we have is to enable all users to replace a proprietary system on their desktop with our solution.

The fact that internally GNOME is composed of various modules is something that some users do not care, and seasoned users like you can easily configure, customize, replace and change.

So I do not believe there is a problem in GNOME attacking more problems than just being "a panel".

You have to keep in mind that GNOME is an umbrella project that includes the GNOME development platform, the GNOME desktop, and various GNOME-based applications.

Remember: we are doing components here, and you are free to choose the components that you want for your environment.

Best wishes, Miguel.

This discussion has been archived. No new comments can be posted.

Miguel de Icaza Tells All!

Comments Filter:
  • by Anonymous Coward
    Good for you for being a digital musician. I'm sure you make some phat sounds with your samples and loop CDs. Sure gets around that tedious business of actually playing an instrument, doesn't it?
  • Emmett, why must you emphasize the nationality of a project or its leaders?

    Okay, well, you got moderated down as Flamebait, but I think you deserve a response.

    The truth of the matter is that I'm a really, really big fan of 80's Music, including Wall of Voodoo's 'Mexican Radio.' As I was formatting this interview, I read through the bit where Miguel was talking about Mexico and raw materials, and the song started going through my head. That's why it was the topic.

    This problem goes much beyond Emmett. Whereever I see open source or Free Software mentioned, I invariably see the nationalities of the authors prominently mentioned, as though their native countries were more important than their names.

    I think what you're seeing is not an attempt at racism or prejudice, but rather a celebration of the Free Software movement's globality and willingness to accept hard-working individuals from any nation, any land. I'm sorry that you took my comment as a racist one. I know Miguel probably wouldn't.


  • You seem to be under the impression that Gtk+ lacks classes and inheritance. This is not the case. Gtk+ uses a run-time based object system. This is somewhat similar in concept to what Objective C and python do, and in fact it has been argued that such systems have certain advantages compared to statically typed systems such as C++.
  • > Why does GNOME need a third part window manager?

    The intent was to not have GNOME dictate the look and feel of the desktop--your basic "freedom of choice" thing. As you well noted, this didn't quite work out as planned.

    Sawmill, though, is becoming the unofficial official WM of GNOME, to the point that Helix Code bundles it with its GNOME setup. Sawmill dovetails pretty nicely into GNOME--it really doesn't have any overlapping functionality with GNOME.
  • How will I justify a multihead setup if I only have one powershell with multiple tabs?
    Nothing is finer than having 5-6 gvim/Eterm/browser windows on each screen!
  • Palm synchronization would be a nice bonus!

    What's wrong with the existing gnome-pilot package ? (except that it's ofcourse not updated for evolution yet).

  • >>Emmett, why must you emphasize the nationality of a project or its
    >This problem goes much beyond Emmett. Whereever I see open source or
    >Free Software mentioned, I invariably see the nationalities of the
    >authors prominently mentioned, as though their native countries were
    >more important than their names.
    >Well, they're not. It does not reflect well on GNOME or Free Software
    >to have its name tied to such nationalist, Balkanizing, almost racist
    >sentiments, and I'd like to be the first to call for the immediate
    >cessation of this unfortunate trend.

    I think it's a wonderful trend. It may be something that offends WASPS like yourself, but I think it's important that it should be pointed out that open source or free Software movement isn't being driven by WASPS living in USA or Europe, but rather in fact that it is something that is *International* in scope and that NON-WASPS in fact can and *are* making major contrbutions to it.
  • >Hum. When launching KDE, you don't run an umpty megabyte executable.
    >It seems you were not knowing far about KDE. KDE is built on top of Qt
    >for mere practical reasons: the aim was not to create a desktop
    >environment with non-gpl foundations, but t develop quickly a coherent
    >desktop environment. Qt is, technically speaking, a really great
    >toolkit for component programming.

    Heh. KDE orginally was nothing but a backdoor for the people involved with the Qt libs to try and pull a fast one with the Qt libs and linux. If it wasn't the intent, why did the KDE/Qt lib supports get so bent out of shape when RedHat and Debian expressed doubts about the use of the Qt libs?
  • >Good for you for being a digital musician. I'm sure you make some phat
    >sounds with your samples and loop CDs. Sure gets around that tedious
    >business of actually playing an instrument, doesn't it?

    I wouldn't use the term "musician" to describe these guys.....
  • I agree with him on the X layer issue; it's not GNOME as much as X11. It's probably not even the fact that X11 is a "layer", as much as the fact that it's a bloated piggy piece of junk. I'm sure a windowing system like X11 could be built that runs orders of magnitude faster than X11 does. Really. I only wish something like that could be developed, even better, developed on an older machine so it scales superfast to new machines. Oh well, dreaming is always great when you don't know enough about graphics programming to convert hot steam into code...

  • With older computers its probably not so much the speed of the CPU that is slowing down GNOME, but the speed of the antiquated video card.

    I built myself a linux server for home, a dual p2-350, plenty of CPU horsepower. But all I had for video was a very old 2MB video card. GNOME's pretty sluggish on this system and I'm sure its due to the old video card.


  • It is a lyric from the song Mexican Radio by the band Wall of Voodoo. A quick search turned up the complete lyrics [].

    Of course, I'm not saying whether this is a good thing to say or not, but just adding some more context.

  • Man, talk about being a karma whore. If /. had posted news about Evolution, you'd be right up there saying "this is news for freshmeat, not /." Instead, since they didn't, you get to turn around and complain instead. Sheesh. I mean, is it really that hard to follow links when they post about Helix? It was fairly easy to find tons of Evolution information when /. posted their Helix article. Just follow links past the first page and maybe you'll actually learn something one day...
  • I think you missed the point- Evolution is a client, not a server. As such, it obviously can't replace a server of any type, Exchange or otherwise. What Miguel was trying to explain was that once you transparently switch all your users to Evolution (which you can do, without messing with your Exchange server) then one night while all your users are in bed *poof* away goes the exchange server, replaced by anything else- either yourproduct or someone elses with some other protocol. Since it'll all be transparent to Evolution end users, the transition will be easy for them, and in that sense, Evolution will have made it easier.
    ~luge(take the time to understand before you start advertising next time)
  • A terminal that requires gnome-libs and imlib? For a TERMINAL? I'm ok with the gtk+ requirement, you need that for tabs and whatnot. But damned if I'm going to install the thing on Solaris without pulling half of GNOME and a bloated monstrosity like Imlib with it. Trust me, I have many reasons to want a tabbed notebook interface, since I have to connect to dozens of servers and such, but I don't want something that needs me to install a whole linux subsystem just to use.
  • Would it not be an issue because the libraries exist on the system anyway regardless of the WM you are using? Someone please enlighten me.

    Sure, as long as the libraries are installed , everything works. But there's a problem with printing and font management. If KDE and GNOME have their own font managers, it means that users need to install fonts for GNOME, and then all over, install fonts for KDE. It'd be nice if they all did it one way.

  • You're over-reacting. A lot of people are
    proud of their nationality, and having it
    mentioned highlights the international nature
    of the projects they're involved with.

  • A PCI Matrox Millenium runs about $20 on eBay. That's a super affordable upgrade for any box with bad video. I use one in my P-133, and KDE and Gnome work great. (But I also have SCSI-2 and 112 MB RAM, so who can tell.)
  • There seems to be a bit of confusion on exactly what Evolution [] is. Evolution is the mailer, contact manager, and calendar, and in general it will be able to be used to store and share many types of information; Evolution is much more than just an Outlook-like client. It's also a server, which can indeed replace Exchange. The mailing backend is Camel [], and there is a Calendar backend [] as well.

    In summary, Evolution will be a general solution for information-sharing, first with the mail, calendar, and contact sharing mechanism, but also providing a framework for developing and extending this to other applications. You'll be able to see the Evolution server at work when the Gnome hackers set up the Evolution server which will contain all the gnome hackers' contact information.

  • Emmett, why must you emphasize the nationality of a project or its leaders?

    I know what you're saying, but I think you're missing the point.

    The fact that Miguel is from Mexico isn't particularly interesting, by itself. What's interesting is that so many people involved in this whole free software thing are from so many different countries. The international cooperation that happens in free software projects is a source of pride for many people in the free software "community" (whatever that means).

    It's a world-wide revolution. :)

  • Your plug for PowerTerm worked...I gave it a try and was duly impressed.

    A couple of suggestions, however ... I seem to notice some weird font problems after customizing my environment...although my fonts look fine, anything coloured (like a directory listing) comes up in a slightly larger font. Looks kind of weird. :-)

    Also, this program would rock if it could be integrated with 'screen'. Imagine restarting a screen session with screen -x to split it between multiple screens, and have powerterm manage them all with tabbed windows -- then when powerterm is exited, the session is detached, allowing it to be reattached with a regular screen -r, or with powerterm.
  • Yeah, but don't forget that BeOS is an OS and it uses a different aproach to the file system organization -- it is a database (or database-like). Hence it is very logical for them to organize BeMail's email messages as separate files, tagging various attributes, indexing them in any imaginable way for easy search.

    Now, Linux (and other Unices) are Not running on top of a database. Searching and storing emeil in one HUGE file is really a problem. True, you can archive it, split it into smaller ones, etc, but then searchuing becomes a problem. Yeah, you can grep the whole mail directory, but it is not neccesserily the best and simplest approach.

    So, to sum this up -- it does make sense to do what Miguel is describing as Evolution features. In fact, a nice GUI email client is what GNOME (and not only GNOME) needs. Balsa/Spruce/Mahogany are there, but I somehow keep on preferring mutt to their shaky GUI interfaces.

    What did shock me is Evolution's interface -- this is an MS-freaking-Outlook! Look ath the pane layout, icons on a shortcut bar, etc. That's lame. They seem to build it to very closely resemble Outlook and cc:Mail. But there are many of things in Outlook that make it very clunky at best. For example, I cannot thread messages in an easy-to-see tree form like in mutt or Netscape's Messenger.

    This is what bothers me way more than the fact that all my messages will be separate files (well, just need to make sure that I set a smaller block suze on that partition...), very well indexed and easily searchable. But taking by far not the best email client's appearance... Sad...

  • Let's not forget that it is the _GNU_ Network Object Model Environment (I've never completely figured out what this means in relation to what GNOME actually is). So, looking at it from Miguel's point of view, calling it a GNU/Linux system makes sense. In fact, if you consider that the general populace considers the GUI to be the same as the OS, a lot of people would consider it fair to call the OS Gnome instead (of course, the opinions of most people who would think that don't count since they don't really understand the concepts involved). Gnome is also not exclusive to Linux. It's supposed to be portable to other operating systems or, at least, to other Unixes (Unices? Unii?). It might not run on other OS's right now (I haven't checked, I assume it probably runs on FreeBSD), but, like most free software projects, assuming that it's just a Linux project is a mistake.
    P.S. Please disregard what I just said if it turns out that Miguel has, in fact, stated somewhere that Gnome is an exclusively Linux-based environment. Thankyou.
  • Maybe I'm missing something, too, but it actually seems as though it might be an imitation of LifeStreams [] rather than BeOS or Lotus Notes. If that's the case, the GNOME project should be careful of Mirror Worlds' patent [].

    Regardless, it still something new for Free Software (speech, not beer). Kudos to the Evolution team, and I look forward to seeing it. It might be enough to finally get me off of KDE. One note, though - Palm synchronization would be a nice bonus!

  • I was more concerned with conduits for Evolution than the actual synchronization mechanism. The current conduits for Linux have seemed a little lacking to me. If I weren't trying so hard to graduate, I'd probably help with writing some better ones.

  • Check out

    While you're there, make sure you check out GPr and libppd. I am the lead developer of GPr and would like to get some feedback!
  • It is nice to see that gnome/kde are starting to address printing issues. I like seeing the gnome/kde combine in efforts for some window manager standard features. However, I have never seen any mention of gnome and kde using the same printing api. Shouldn't that be incredibly important? That way when I run my gtk programs inside of kde or vice versa, printing will not be an issue. Am I missing something in the way the individual API's work? Would it not be an issue because the libraries exist on the system anyway regardless of the WM you are using? Someone please enlighten me.
  • Well, as it turns out, you are particularly dense this morning! ;-) Just kidding... Seriously though the difference is the Evolution with leapfrog both of these systems you mentioned in several ways. Here's a few reasons why, IMHO:

    First, Evolution's indexing will not only be more efficient, but it will scale far better than [Lotus] Notes currently does. I have used Notes for quite a while and it is a PIG big time. There is nothing efficient about the indexing capabilities of Notes compared to the tradeoff in performance you need just to get Notes Client running on a system.

    Furthermore, Evolution, will be an open source venture (obviously), that will provide an open foundation for universal messaging of not just email as De Icaza says, but also for Instant Message Sessions [potentially] or IRC sessions, etc, and Evolution will "digest" all this info. It will do this with ease, and be scaleable to the point of not requiring you to have a couple hundred Megs of RAM to handle a couple Gigs of information in your store. I haven't witnessed anything like this in Notes, Groupwise, Exchange, or any other mainsteam messaging offering yet, which are all bloated with features I cannot remove, and not scaleable to handle modern email loads.

    Also, being that Evolution will be componetized, it will make Web access to these evolution databases extremely trivial (or at least it should) which combined with XML can eventually be one of the most robust groupware products in existence.

    It sounds like innovation to me - but it will be a different story if it never materializes...


  • Check out for Corel's Application Printing Services API.

  • I use powershell every day here at work. One bash tab is running ssh, the other is running local programs, etc. I love powershell.
  • Will Powershell be included in the next release of Gnome? I'd like to see it the default Gnome terminal. I've not yet seen another Terminal emulator with multiple tabs. Especially one designed for Gnome with keyboard support. Have you looked at it yet? It's really changed how I work in X. Rather than a multitude of xterms I have one window with multiple tabs. Each one doing a different thing. Even if you're not going to include it, at least have a look. It just might change how you work in X.
  • Well, his argument isn't completely pointless. Although I don't think it necessarily applies to just Gnome/Kde. I have an old machine, one of the first powermac ppcs, and X is just slow. It doesn't matter what Desktop Environment/Window Manager I use.

    That being said, I think its probably best to leave these machines to what they do well and not expect newer software to handicap itself by trying to cater to older hardware as well as newer hardware. After all, you can usually get a 150 - 200 Mhz pentium for around $200 or $300, monitor and all.

  • Another good Exchange replacement is HP OpenMail. It is also fully MAPI compliant, all that good stuff. The guys on my LUG have been raving about it; yet another way of sneaking Linux in there :)

    Here's my [] DeCSS mirror. Where's yours?

  • I'll admit that I don't know much about KDE. I don't like the way the versions I've tried felt so close to Windows. I especially don't see the need for browser integration with the desktop manager or filesystem. GNOME, on the other hand I liked, but I've talked to many people who've liked KDE just as much. IMHO, its a matter of personal preference which one you're going to use, and I don't think that'll ever change. Or at least, I hope it doesn't.

  • I think Miguel made it clear in the interview that GNOME isn't one gargantuan program. Instead, its a bunch of little modules that function together to create something bigger, as opposed to KDE which is (AFAIK) one gargantuan program. Of course, for most of these roles, there's currently only one module available...

  • I have a laptop with Pentium 150 MHz MMX, with a NeoMagic video card and 2 MB of video RAM.
    Originally, it had 16 MB of RAM. With this configuration Linux was OK, but both KDE and GNOME generated lots of swap and where VERY slow ( about 2 minutes from 'startx' command to fully operational with stardard configs ). The third worst was Netscape, which required 1 minute to come up.
    The 'top' command told me that the real 'monster' is probably X itself, which had about 7MB of resident memory ( XFree3.3 with 16bpp and virtual resolution of 1024x768 ).

    I looked for alternative window managers. WindowMaker offered the right (for me) balance of performance, usefulness and attractiveness. The only GNOME piece I was still using was gmc. Firing up my graphical desktop in this configuration only required 15 seconds.

    Later, I bought 64 MB of additional RAM. Now both
    GNOME and KDE start-up in about 20 seconds. WindowMaker only takes three seconds, however, so I still use it for real work, only occasionally firing GNOME ( I do use a few GNOME apps,however ).

    Sorry for this lengty post, but I wanted to add info to my opinion.
  • I don't see why you would write a object toolkit in c... C++ is or very soon will be as portable as C (I use g++ and _it_ seems to be a portable ANSI compliant compiler). Also, c++ is written with objects/types in mind, c is a procedural language. Because gnome is the network 'object' enviroment, it would seem to their advantage to use an object oriented language like c++. At this point, i don't see java being used because it would probably have to be compiled because i don't think it would work out to have a thing like this running in a virtual machine. also with classes and inheritance, it would be really flexable and expandable if gtk was written in c++ instead of having to use gtk-- for a wrapper. as you said, it is a gtk issue but it would be helped a lot if gnome was in c++. i wished Miguel hadn't dodged this point.
  • C doesn't naturally support classes and inheritance. I am saying that it is pointless to try to recreate the features that c++ has by adding in extra bloat to emulate and object oriented framework. I see it as trying to re-create something and being doomed either because they don't understand oop or because they can't do it fully with c--yet I have never used gtk+ (but i use gtk--) so i can't say it that is actually the truth. I don't know much about run-time and compile-time based object systems, but I don't really see how this can make anything better or worse for the situation I described above. I know c++ can use a dynamic_cast<> (and other things) to convert types at runtime, but I don't see that as an essential part of a widget set--yet, again I really don't know enough to argue that.
  • Thanks for the info. I was interested as well. Sorry about the trolling fools who insist on offending everyone.

    Keep up the good work...

  • Ok, so I know this is both somewhat off-topic and a long shot. Anyhow, I missed the oportunity to post a question to Miguel about recommended readings; I wanted to know about this because someone who once was his teacher (I study CS in UNAM) told me he read very good books. I have already ordered "Structure and Interpretation of Computer Programs", which he recommends on his activity log but surely he has read other equally enlightening books (specially but not limite to computer related books). I post this here so it may not be lost amongst the thousands of mails he gets and to get the enlightened guiding of other slashdoters. []
  • All this stuff sounds really great (especially printing and email), but when will it be available for me to get my paws on? I know, Open-source is "it'll be released when it's ready to be released," but could someone give a ballpark estimate?

  • So what you're saying is Evolution allows you to replace Exchange clients... And your non-open-source product allows you to replace Exchange on the server side...

    I don't think you've answered your own question anymore than he did...

    Obviously, you hope that some admins will replace Exchange server with your "drop-in replacement" BUT this is very far from stating that this will happen!
  • the scaleup is more a function of memory and swap space rather than processor speed.

    Not so sure, I saw noticeable differences between NT and Office running on two PC with the CPU speed as the only difference.

    and as pointed out elsewhere, this is due to the extra X layer.

    X is not an extra layer, that's the foundation on which the graphics are build up. The only overhead due to the architecture of X is related to its distributed nature. For exemple, you can run an application A on a machine X and display the interface on a machine Y. However, when X is ran locally, it should use Unix sockets or something similar rather than TCP/IP sockets and it doesn't use the network layer.

    So, the performance problem is really lying in GNOME and its functionnality. Almost like any huge Microsoft product that claims to do everything, except vacuum cleaning my carpet and dishwashing (and that's the reason it sucks!).

    The Window Manager and GNOME are two different things and are not tied together. However, it seems the GNOME guys had made extra effort to integrate with Sawmill and Enlightenment (it means handling messages and hints between both components).

  • Have you try Windows NT and Office 2000 on you 486-33?

    If you are looking at a much lighter and less ressources consuming environment, take a look here [www.freshm...ttargettop]. Go in the appindex searching in the X11 section. There is many thin WM available that should fit better on you machine.

  • I went to the German Green Party page once and they have a comment section. But they have a "Schmuddelecke" for idiots and racists like this Anonymous Coward. Maybe /. should filter the real clowns out.
  • i use icewm on a P100 (admittedly faster than a 486-33). it is very quick.

    <pet peeve>Distributions shouldn't default to running all those daemons. IMHO, that's why the recent DDoS's was possible.</pet peeve> // slashdot is a cigarette break for nonsmokers

  • This, from the KOffice mailing list:

    > I hate to be seen as a troll, but ...
    > I know that the KDE Project and the GNOME
    > Project have co-operated in the past where
    > interoperability has been important.
    > Will this be true for office suites? Has
    > anyone from GNOME Office contacted this
    > list? Has anyone from this list contacted
    > GNOME Office? Should we?
    > I think the real issue is interchangable
    > file-formats, or at least seamless filters.
    > Anyone?

    Filters can't be interchangable because their filter library is not
    LGPL. For file formats they are reinventing an entire filesystem, which
    at least to me seems not quite sane.

    So will there be "official" cooperation on the file-formats, or will we be left swinging?

  • Almost all of MS's apps (Explorer for example)
    are all written with COM applets - this is
    one of their more basic tenets. It's not
    just so you can drag images onto spreadsheets,
    it's so they can write quality apps in 50 percent
    less time than netscape can. I personally
    think GNOME's usage of Corba is an essential
    aspect of Linux's being able to compete
    with Commercial development, despite the
    advantages of OSD.

    How important is COM-like architecture?
    by Pike

    It seems that the GNOME effort is throwing an awful lot of resources at a component-ized
    architecture (Bonobo) which aims to do for *nix what COM and ActiveX/OLE did for
    Windows. And yet it just doesn't seem necessary. I know it's possible for me to insert an
    Excel spreadsheet into a Word document, but I haven't used that feature in recent memory.
    None of the documents I exchange with co-workers do, either. Is Bonobo really very
    necessary? What does bonobo bring to the Linux desktop that users are crying out for, and
    how is its heavy consumption of development resources justified?
  • Why? (BTW, you are are, IMHO, a bigeted, racist pig).
  • Miguel is an example of what the future will look like. He is, of course, not the only under-represented minority (Asians are not under-represented) to be famous for a project such as this, but this is what will continue to happen.
  • > as opposed to KDE which is (AFAIK) one gargantuan program.

    Hum. When launching KDE, you don't run an umpty megabyte executable. It seems you were not knowing far about KDE. KDE is built on top of Qt for mere practical reasons: the aim was not to create a desktop environment with non-gpl foundations, but t develop quickly a coherent desktop environment. Qt is, technically speaking, a really great toolkit for component programming. KFM, KDEHelp, KDevelop and all KDE apps which need to display HTML pages use the same widget in the same shared memory, for example. I, personnaly, use KDevelop, which is a really great tool, and it's not a monolithic app: it embeds already existing KDE apps like kwrite for editing, kiconedit and kpaint for pixmap editing, etc. Most tools relies on other existing tools, not always KDE ones, like SGMLtools, autoconf/automake, etc.

    KDE is not one program, and it's not gargantuan.

    And KOM/OpenParts and DCOP will allow component programming much like Bonobo, only a bit lightier and faster (no flames: that's not because Bononbo is badly coded; but because KDE don't try anymore to have a CORBA approach; they've designed DCOP as the bare minimum for fast inter-process minimum, thus forsaking the OMG CORBA standard. There are edges and flaws in both ways, and I don't mean either one is the best).

    Personaly, I think KDE and GNOME are more complementary than concurrent: KDE look at today, GNOME look at tomorrow.

  • Use vmware,
  • I've not run NT or Office, but as with most Microsoft products, the scaleup is more a function of memory and swap space rather than processor speed. GNOME/KDE is different in that speed scales with the CPU speed, and as pointed out elsewhere, this is due to the extra X layer.

    And right now I am running Sawmill on a 486 with no problems. I could probably use E!, but I'm limited by 256 colors, so not much point there. The WM speed is not in question, but it's everything on top of the WM (the panel, config panels, layout) of the GNOME engine that I question.

  • I am VERY pleased to see that outlook integration is a priority! (actually im throughly pleased you answered my question in great detail :) I would love to assist with the project :)

    I think a decent calendering solution is what Linux needs, more than anything.

    Linux Power!
  • The printing architecture is ready to be used today. You can download it from: OME/stable/sources/gnome-print []

    Various applications include support for it (Gnumeric is the one I maintain that uses it).

    The Evolution code base will be available for a preview test in a few weeks. Keep your eyes open.

    Best wishes,

  • Man, talk about being left in the dark. I had no idea something like Evolution was in the works. Slashdot.. you're supposed to keep me up to date on these kinds of things... I had to wait until *now* to find out about it? *irk* if I had wanted out of date news I'd read Time. :(

    Comeon guys, get with it! News for nerds. Evolution is definately news. Why'd I have to wait this long to hear about it!?

  • Go to the printing HOWTO homepage [] ( the version on the LDP is often out of date ). This HOWTO maintainer ( Grant ) really rocks. The page refers to other projects like LPRNG and PDQ.

  • It's against UNIX nature to try to be one-solves-all instead of doing small things well.

    That's why GNOME ( and for that matter, KDE ) does a lot of small things well. The GNOME project have written several small APIs, each of which does a small thing well.

    GNOME is basically a bunch of applications that use a common set of APIs. No one of those applications "solves all" and not one of the APIs "solves all" either.

    GNOME is not a monolith.

  • For gnome to be usable in our environment, you need to allow the sysadmin to override the default spooling environment.

    For example, we use rlpr and manage printcap files on only a couple of servers (one primary, one backup). The print command should be as easy to override as it is in netscape ("rlpr" instead of "lpr", etc.), and preferably also settable to a default by the system administrator in a central configuration file.

    This feature is IMHO much more important than providing a gui to the end user to manage their own queue (although having both would be ideal). In other words, if providing a GUI queue management interface shoudl require sacrificing this customizability, then the GUI should go.
  • He can't help it. Miguel is a member of GNU/FSF, and as such, probably has no choice of terms. "Linux" deeply offends RMS, and MDI has to work with RMS. If he didn't call it GnuLiX, or whatever else this weeks politically correct term is, he would be out on his ass.
  • > It's a world-wide revolution.

    True. But the nationality of the various "shining lights" of the OSS community may indeed prove to be important.

    For instance, it is not hard to imagine a nation (citizens, businesses, politicians, whatever) being somewhat alarmed at the huge cash drain leaving that nation for IT products from foreign producers.

    Add to that basic level of alarm an observation that one of the competing products is being developed under the leadership of a home-town boy, and what is the likely outcome?

    A regional acceleration of the Open Source Revolution.

  • My read of the question was "will Evolution replace Exchange?". Miguel's answer was "corba is great, gnome is great, etc etc etc, btw, Evolution allows you to replace Exchange"

    My comment is only to mention a product that provides the actual drop-in replacement.
  • BTW, this product is unfortunately not Open Source (yet, anyway--I have the ear of the CEO). However, it IS "open" in the traditional Unix sense: standards compliant, flexible, sciptable (command line interface), etc.
  • I use powershell every day here at work. One bash tab is running ssh, the other is running local programs, etc. I love powershell.

    Hehehe thanks :-) I'm glad to see people like it.

    <plug>Everybody download PowerShell! You won't be disappointed :-)</plug>
  • Remember, we are not in the business of selling the same application every two years, but in the business of solving the problem.

    Thanks. Keep up the good work!

  • Perhaps I:m being particularly dense this morning, but I'm not seeing how Evolution is any different from BeOS or Lotus Notes when it comes to managing mail.

    BeOS already treats the mail as separate files, and the built in OS query system can already generate seperate folders for each query. These queries can also be saved and used as necessary.

    Lotus Notes also treats Mail (and well, everything really) like a databse, and is capable of full text indexing and scripted queries as well.

    So am I missing something, 'cause I'm not seeing the innovation here.

  • Your argument is pointless, GNOME is not integrated with the linux kernel, you are not forced to use it. If you have a 386 or 486, run fvwm.

  • I still end up getting tied to Windows to access my mail and calendaring tools in Lotus Notes.

    Personally, I'd be thrilled just to have enough documentation on the Notes protocol to let me download my mail from a script. As it is, all too often the queue fills up and new messages end up in the bitbucket before I can find a Windows machine to log into.
  • Actually BeOS runs graphics and UI in a seperate server too, and I've never had any speed issues with it (aside form the fact that it makes me cry to go back into windows to do something.)
  • Well, either way, it's slow. Thats why I keep saying network transparency should be at a higher level, but I wasn't around back when X was designed. And XFree 4.0 still isn't nearly as fast as BeOS even though it has supposedly no performance hit on local machines.
  • >Miguel shares the deadly truth about GNOME, the >shocking story of the future of Bonobo and CORBA, >and the titillating tale of adventure and >intrigue that lies deep within the bowels of >popular Free Software development projects.

    Hey man, you've been watching too many of those Sun [] commercials...

    "Gnome, it's the DOT in DOT.ORG"

  • From the standpoint of Win32, MacOS, and Java, there is no difference between rendering to the screen, and rendering to the printer.

    You do not have to write extra code to "render to the printer." You build your GUI, and when
    the time comes to print, you tell the components to print.

    Even though it sounds like they are creating a printer canvas that can be rendered to so that the output goes to a printer, it doesn't sound like they are unifying GTK with an imaging model.

    Which means if I want to print anything, I have
    to use special widgets or special API calls.

  • Oh wow! Oh wow oh wow! A Linux client which will talk to Lotus Notes servers?

    Picture an office populated by Outlook clients and an Exchange server or a Lotus Notes server; we can infiltrate that place from the bottom up by making Evolution talk to those Exchanges or Notes servers.

    Now this really does have me interested. While I do cross-platform development as the rule, I still end up getting tied to Windows to access my mail and calendaring tools in Lotus Notes. And no, I can't escape them totally, although VMWare and Exceed both provide some solution to the problem. As Lotus currently have no plans to produce a Linux client for Lotus Notes, I wonder whether this sort of development will force their hand. Given the market for Lotus Notes style organisation tools, this could be a significant gain for the GNOME project if this comes off.


    Toby Haynes

  • A lot of people seem adverse to the fact that Gnome is trying to do so much - desktopwise (window manager, panel, sessions, etc), toolwise (mail clients and backend, schedulers, etc.), applicationwise (gnome office, etc.) and COM libraries and interfaces (bonobo). It's against UNIX nature to try to be one-solves-all instead of doing small things well.

    However, if you looks at the history of Gnome, you'll see that way back when Gnome was first created, Gnome was just about Bonobo. Hence the name "GNU Network Object Model Environment".And Gnome was apparently going to be "part of KDE". However, because KDE was using a propietory toolkit (QT) for it's core work, Gnome expanded to include the Desktop Interface. Everything else in Gnome comes from these original two - a COM-like architecture and a Desktop Interface.

    The way I see it, GNOME project is really just the GNU project all over again, but one step up. The GNU project's original goal was to make a "Free Operating System" (defining operating system as everything you need to get work done). So far they've achieved the first stage of that goal. They've created the backbone of a free system - an OS kernel (GNU/Linux or GNU/Hurd), compilers, basic libraries, display (XFree), various development utilities and tools, etc. GNOME is taking care of stage two: bring that free system to the generic modern user with easy graphical interfaces and large end-user applications.

  • by FascDot Killed My Pr ( 24021 ) on Tuesday April 04, 2000 @06:21AM (#1152289)
    Disclaimer: I work for the company I'm about to mention.

    I see a question about "Will Evolution replace Exchange Server". After much hand-waving and exposition about how great Evolution is, the answer seems to be "no".

    HOWEVER, for those of you wanting to run a MAPI-capable mail server on Linux (or Tru64 or AIX), I CAN recommend another product. MailOne produced by OpenOne (

    MailOne is the descendent of (and official upgrade path for) DEC MailWorks. It's a really good product--I should know, I did the Linux port. We're shipping Beta 1 this week. Check the website for more information.
  • by Dr. Sp0ng ( 24354 ) <mspong AT gmail DOT com> on Tuesday April 04, 2000 @06:32AM (#1152290) Homepage
    Gnome rules. Of all the desktop environments/toolkits I've programmed under (Win32/MacOS/Qt/Motif/GTK/Gnome/OpenLook), Gnome is definately the most pleasing to work with. It provides a lot of very useful widgets on top of what GTK provides and makes normally difficult GUI programming tasks much easier. Of course, there are definately some areas which I would have done differently, but on the whole, it's pretty damn good.

    I want to thank Miguel and all the other Gnome developers for a job well done, and I hope to see even more cool stuff in the future (Evolution sounds really cool, I'm gonna go hunt for more information on it, or maybe an early version.)

    BTW Damn Slashdot cut off my signature, it's supposed to read: PowerShell: The Terminal of the Future.
  • by abes ( 82351 ) on Tuesday April 04, 2000 @07:44AM (#1152291) Homepage
    Without making any assumptions, I would like to being by making the broad generalization that it seems most often the people who complain about forking developments usually aren't the developers, but rather just the end users

    Personally I dislike KDE (flame-shield). I am not trying to advocate preferences to anyone else, but it stems from QT, and as cited by many individuals, the kludged-preprocessor that must be used for their connections/slot technology. Likewise, I think that the GTK model is perhaps one the best designed models around. This is not saying anything about the implementation, as I am not the most familiar with it, but just simply if I had to create my own widget toolkit, I would probably end up with something like it.

    Yet another problem with KDE is that it is C++ based. I haven't checked, but I'm sure there are plenty of bindings that exist now for other languages, but there is an inherent problem. C is fundementally easier to port to C++ than the other way around simply because it is a subset of C++ (i.e. C++ was built from C). I usually almost always write C++ code, even when I don't use OOP, but if I were to create a widget toolkit, I would most likely use C to allow a greater audience. It is quite easy (and infact, this is one of the reasons C++ was made) to encapsulate C code in C++.

    I should point out that I have been assuming that anyone that uses GTK would be in the GNOME catagory, but this is not necessarily true. Again there is forking of work simply because to different people different methods of developement are better. While I beleive the component methodology is good, I have to admit I am a little skeptical of CORBA. I should also admit I know very little about it. I think one thing that would be nice to see is more effort put on the GTK widgets, with a focus on their efficiency, and perhaps even on splitting a few widgets into smaller components. I would think this would be more of a GTK issue than GNOME.

    My point (somewhat elongated) is simply that there are many views on how developement should be done. It is pointless for people to just blindly write code for a system they don't think works properly. For example, I have had to write MFC code before. I never again want to in my life. I shudder every time someone mentions making an MFC like model under *nix. Not only does it suffer from the same preprocessor problems that QT does (although its better hidden), (not too suprisingly) M$ has no concept what it means to be object oriented! I don't care what language you write code in -- heck, I've written OO ASM code before, but rather that you employ it in a meaningful way in which it helps one write code, not hinder it/confuse everyone. The worst part to MFC is their document/view model. This model works amazingly well for things such as word processors, but I think it flops (from several thousand feet up onto metal spikes in cement) for anything else. Its the usual M$ "our way" approach, which ends up in some of the most disgusting code (not written by me of course :)) I've ever seen.

    Of course, I am more than happy to use any of the applications that come out of KDE, and am drooling for KWord to come out (if its all it is cracked up to be). I just rather not have to deal with the QT toolkit, and know that I'll be that much more efficient with GTK.

  • by Greyfox ( 87712 ) on Tuesday April 04, 2000 @06:40AM (#1152292) Homepage Journal
    I haven't heard anything about the VA spooling solution he mentioned and I'm trying to keep tabs on all the print stuff out there (Printing being one of the biggest UNIX weaknesses at the moment.) Does anyone have any pointers to Linux printing projects (Other than CUPS. I know about them.) out there?
  • by Masem ( 1171 ) on Tuesday April 04, 2000 @06:34AM (#1152293)
    One of the common pros for linux and GNU/OSS stuff when reported in the media is the ability to use it on older machines. I certainly know this to be true; a good-sized and visited website with dynamic content can be done on a 486 with a sufficient amount of memory.

    Even with Windows95, as long as the memory is there, it will run without too much of a noticable speed.

    But when I've tried early versions of GNOME and KDE on a 486, the processor speed plays a very important role; these GUIs are both very CPU intensive, and on a 486 felt more than sluggish.

    Sure, hardware is cheap, and most would argue there's no reason why one can't buy a older pentium system and be ok with that. But the point of Linux is to be as free as possible and to work on as many systems as possible. All those 486s are finding uses as Linux boxen, and with 'slow' GUIs, the speed and stability promise of Linux is lost.

    Obviously I doubt that either GNOME or KDE can go back and reoptimize their code to be less CPU intensive. But what can happen is to make sure that the apps that are written do not require that GNOME or KE to be runnning, only that the appropriate libraries are installed, so that, for example, an optimized WM can be used for GUI purposes.

    For example, their communications package, Evolution, sounds like it will be a great program. But if it requires you to have GNOME running, it's going to be lost on a number of folks.

    There is a tradeoff here : speed verses chrome. And, IMO, speed wins out every time.

  • by DonkPunch ( 30957 ) on Tuesday April 04, 2000 @06:55AM (#1152294) Homepage Journal
    Geez, S11, don't you read Slashdot anymore? :)

    Slashdot will run a story about Evolution when:

    1. Someone tries to censor it.
    2. The DMCA prohibits it.
    3. The CIA/FBI/Congress/Al Gore declares it a prohibited ordinance punishable by fine or imprisonment.
    4. ZDNet benchmarks it against Exchange.
    5. JonKatz is able to compare it to the Nazi Resistance.
    6. Amiga claims that they will build their OS on top of it.

    (DonkPunch -- offending slashdotters since 1999!)
  • by cje ( 33931 ) on Tuesday April 04, 2000 @07:20AM (#1152295) Homepage
    Man, talk about being left in the dark. I had no idea something like Evolution was in the works.

    Evolution has been in the works for billions of years. You must have gone to school in Kansas. :-)
  • by arthurs_sidekick ( 41708 ) on Tuesday April 04, 2000 @07:19AM (#1152296) Homepage
    Yet on Linux the gui is *dog* slow. I suppose it is because my distribution comes with a lot of stuff defaulted in - like Sendmail - which DOS doesn't have

    It's not the various daemons that slow down the gui in linux, or on other *nix-like OS's. Most of us put the "blame" on the X-Window system itself. One of the tradeoffs in having a nice clean separation between the GUI and the kernel (which promotes stability) is a loss in speed; since those who use *nix usually do so because they value stability over speed (to some extent, anyhow), this tradeoff is well worth it.

    Nevertheless, XFree 4.0 is looking pretty nice from where I sit (using it right now) even if it isn't a *huge* difference from the late 3.3.x versions in terms of speed; additionally, although I have no personal experiences with either product, you might try Accelerated-X or Metro-X, both of which are (IIRC) proprietary implementations of the X system.

"If you want to eat hippopatomus, you've got to pay the freight." -- attributed to an IBM guy, about why IBM software uses so much memory