Miguel de Icaza Tells All!

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?

Miguel:

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.

Miguel:

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?

Miguel:

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 (http://www.gnome.org/gnome-office/dia.shtml).

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...

Miguel:

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 gnome.org 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?

Miguel:

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?

Miguel:

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 ....

Miguel:

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?

Miguel:

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)?

Miguel:

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.

Miguel:

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?

Miguel:

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

Miguel:

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?

Miguel:

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.

Miguel:

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.

GNOME is GNU all over again.

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.
------------------

Getting rid of Exchange servers...

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 (www.openone.com).

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.
--

Gnome is phat

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.

Re:interesting, but not everything

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.

Printing stuff

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?

GNOME/KDE and speed

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.

Where have you been?

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!)

Obligatory

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. :-)

Re:GNOME/KDE and speed

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.