...

First, we have historically striven to avoid adding dependencies that are not common on a wide range of platforms. Of course, this means that we often cannot make use of the latest and greatest enhancements available, but on the other hand it makes life much easier for our users. What is the GNOME Office's stance on the issues of dependencies and portability?

Dependencies will be limited to goffice libraries like libgda and libgoffice, which afaik are developed with portability in mind.

GnomeOffice applications will also use:

GnomePrint for printing LibGSF for file handling LibXML2 for XML parsing

GnomeOffice apps should be designed with portability in mind. We best serve our user base by being flexible and nible. It is also important that we do not overly restrain ourselves feature-wise simply for portability's sake. Libraries built with portability and extensibility in mind, like LibGSF (discussed later), are strongly encouraged.

Inkscape works well on Win32 already. My only gripe is that the 0.37 release ships its own Glib and GTK instead of using the "system" ones. It annoys me that I and others have put so much time into getting GTK+ working and theming pixel-perfectly (GtkWimp) on Win32 and then have apps deploy their own copies of same. I understand that there are real problems that you guys are trying to conquer by doing so, but I contend that there are better alternatives.

...

Do you have a listing of the currently available reusable components from these other projects, that we could review?

libgda, libgnomedb: www.gnome-db.org libgsf: http://www.advogato.org/proj/libgsf/ libgoffice: currently part of Gnumeric afaik

libgnomeprint, libgnomeprintui.

...

Third, is GNOME Office working with the freedesktop organization? How is it tying in with them? Are there other standards bodies that GO will be working with?

Afaik there is non-strict adherence to the HIG. I am unaware of any major collaboration with fd.o, although I'm uncertain whether fd.o is covering anything pertinent to GO at the moment.

Adherence to the HIG is an eventual goal except in limited situations.

I have at least 2 pertinent FD.O projects at the moment:

1) Use of Enchant (or some library that wraps Enchant, such as GnomeSpell or GtkSpell) for any application that does spell-checking 2) Use of mime-type based atoms on the clipboard. For example, "image/svg+xml" and "image/png" might make sense for Inkscape. "text/html" makes sense for Abi, Evo, Gnumeric, ...

...

Finally, how do you view Open Office and KOffice in the context of GNOME Office, and in terms of interoperability, competition, augmentation, etc.?

Concretely, KDE plans on using Enchant at some future date. I'm fairly certain that I can get KOffice to follow my upcoming mime-type clipboard RFC. OpenOffice and Mozilla will likely follow in this regard.

Interoperability: I believe it is a definite goal to support the various OASIS office formats. I think Gnumeric is closest to this goal, as nobody has stepped up to really work on it for AbiWord. It's more a question of manpower whilst the lead developers are concentrating on more important aspects.

Will Lachance and I have written OOo Writer filters. They're not 5* quality, but show substance and promise.

...

We have been looking at libgsf. It would be interesting to learn more about the benefits these other capabilities could provide for Inkscape.

Jody would be best placed to answer this.

I'll field this one.

LibGSF is a few things:

1) A powerful, value-add, portable, flexible wrapper around FILE* types of operations 2) A compound document library. For example, MS OLE2, JAR/ZIP that OOo uses as their file format, etc... 3) A set of utility functions to make #1 and #2 better for the programmer

WRT point #1, LibGSF makes many fundamentally different (but similar) things look like FILE* handles. More correctly, Input and Output handles. These types of handles include:

} FILE* handles } GnomeVFSHandles } In-memory buffers } GIOChannels } COM IStreams } Bonobo Streams } COM ADODB::Streams (soon) ...

Further, seamless GZip/BZip compression/decompression are supported over any of the above handles.

What does this mean? It means that (at least):

1) Copying to the clipboard is the same as writing to disk. Just use an in-memory sink. Ditto for reading from a clipboard. 2) You can read/write data out of an embedded object (BonoboStream, IStream) 3) You can read/write data out of a database (ADODB::Stream) 4) You can read/write data over Samba, HTTP, WebDAV, FTP, SSH, ... (GnomeVfs) 5) You can GZip your XML stream that's going to a remote WebDAV server with only 1 more line of code.

Further, these types of operations don't look any different to you, the API consumer. It allows you to add in tweaks and extensions transparently for any Win32 port, Gnome port, etc... that you might have. You could use the new GtkFileSelector with its GnomeVFS backend on GNOME builds. Or just the "normal" FILE backend on non-GNOME builds. As a GSF API consumer, you won't have to change more than a line or two of code to handle these tremendously different cases.

GSF adds value by adding a layer of sanity-checking on top of their wrapped Handles. For example, I've seen fwrite return a short count but !ferror() (take that, ANSI C!). This takes care of that potential problem. The FILE* Output will create a temporary file and not overwrite any existing file until your saving operation is entirely successful. It also has some smart symlink handling. All sorts of things that are easy to screw up and hard to get right.

In short, GSF "just works" for just about any and every definition of "just works".

Cheers, Dom

_________________________________________________________________ Say �good-bye� to spam, viruses and pop-ups with MSN Premium -- free trial offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/