Re: [Inkscape-devel] Joining GNOME Office

["Dom Lachowicz" <cinamod hotmail com>]

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