I'll respond as best I can, although I'm hoping that somebody with a more development acumen wrt GO will pipe up to officially clarify things. I should be right(ish) though.
On Wed, 2004-02-18 at 18:33, Bryce Harrington wrote:
There's has been talk of GNOME Office applications requiring a quality SVG canvas. Your roadmap suggests that, at some point, you intend to separate out an SVG canvas from the Inkscape codebase.
Yes, this is something we think many other projects would derive value from. There's several major refactoring steps that need to be done before we can feasibly approach it, so this may be rather 'blue sky' for a good while.
It's not 'blue sky' though; it needs to be outlined early just how this will eventually happen so that when it becomes a viable tool then the GO applications will be in a position to take advantage of it.
Agreed. Note though that while we hope to encourage and assist in generation and collection of clipart, our specific objective is simply to define a way to "plug in" clipart to Inkscape. In this way, other projects besides us could organize and generate their own clipart packages, without having to go through the Inkscape project.
I believe it's the "plug in" bit that would be of interest to GO applications. Jody is already working hard with the Gnumeric codebase to factor out libgoffice which will provide, among other things, a common plugin framework for GO applications. If the clipart plugin were to be a potential goffice plugin... this is how the benefits of collaboration would start to be realised.
Things like the clipart media come with time; I don't believe this will be a concern to anybody at the moment. What use is clipart if we can not yet use it? ;)
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.
AbiWord is already well-ported to Windows, MacOS, QNX, and even BeOS.
Gnumeric will become portable in it's next version; I recently read an update from Jody where he outlined the last remaining GNOME-specific dependencies.
I'm not sure of the Gnome-DB portability status.
Summary: GO is aiming to be fully portable.
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
The best guys to liase with on this are Jody Goldberg and Rodrigo Moya.
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.
Obviously with Cairo, fd.o is probably more relevant to Inkscape.
However, that's only what I know (which is limited) and I'm sure any of the GO projects would be eager to work with fd.o if it were to be of any benefit to them.
Will there be a set of standards or guidelines that all GO apps will strive to follow?
Is there? Not yet. Will there be? I would have thought so.
I'm just beginning to stir up a fuss; GO has been slumbering for far too long and it's time to galvanise the effort. Only recently have the core GO projects (AbiWord, Gnumeric and Gnome-DB) aligned development goals.
I'm hoping that the lead developers will start to put their heads together on issues like this to form an official roadmap and guidelines for the GO applications to aspire to. Your input on this could be crucial given your projects potential importance through providing the graphical canvas.
Finally, how do you view Open Office and KOffice in the context of GNOME Office, and in terms of interoperability, competition, augmentation, etc.?
This is my 'birds eye view' take:-
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.
Competition: I believe the goal of every GO application is to be the best of it's breed. Cloning is not on the agenda.
Augmentation: This is a tricky one to answer. With no formal process or documentation in place, this is something that really needs to be defined. The GNOME Office 1.0 release was achieved by years of quiet dedicated hard work by the AbiWord, Gnumeric, and Gnome-DB teams. It was a case of actions speaking louder than words.
I believe that GO is not looking to envelope applications like Inkscape or Conglomerate. Instead, I think GO is looking for input on collaborating to the distinct advantage of the current and prospective member projects.
For GO to make good progress towards a greater goal over the coming years, greater efforts do need to be made to define process to allow the collaborating GO applications and projects to grow closer together.
Rodrigo told me he to go step by step, and I agree this is the best way to make progress. It is now a case of gathering the projects of potential for GO together to start moving step by step towards a common path, towards a greater goal.
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.
Thanks, Bryce
Thank you for your time and consideration.