Inkscape developers!
I'm in the process of developing the new GNOME Office portal.
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.
I also notice your plans for a clip art extension. This would also be an excellent tool for other GNOME Office applications.
GO already contains arguably the best available spreadsheet application in Gnumeric, one of the leading word processors in AbiWord, and an excellent data(base)-agnostic backend in the Gnome-DB project that is a unique facet to GO. We are looking to include Conglomerate (advanced XML editor), Mergeant (database management), and Planner (project management) as well as Inkscape. The increased collaboration and code re-use could produce an office suite to be reckoned with.
Inkscape is becoming the leading SVG editor. I am in a position of ignorance (not a coder or a projcet lead) but I firmly believe there is a desire from the GO team to include Inkscape among GO or, at the very least, make use of some of the excellent functionality provided by Inkscape.
Perhaps Inkscape could make use of the advanced editing capabilities of Conglomerate or other facets of GO? There is libgsf, libgda, libgnomedb and the planned libgoffice (emerging from Gnumeric).
I know not the details nor how any of this would be accomplished and indeed parts of it is mere speculation by myself. I can only humbly invite some (or all!) of you to join the GO mailing list in order to begin discussions with the more technical members of GO with regards to what GO and Inkscape can do for each other:
http://lists.gnome.org/mailman/listinfo/gnome-office-list
In the potential GO application list, we have a distinct selection of potentially (if not arguably) best-of-breed applications. If they were to collaborate then who knows what exciting prospects the future might hold! But first the respective project leads must be prepared to look months or even years ahead in terms of planning and setting goals.
Thank you for your time and I hope to hear from you soon!
On Wed, 18 Feb 2004, Charles Goodwin wrote:
Inkscape developers!
I'm in the process of developing the new GNOME Office portal.
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.
I also notice your plans for a clip art extension. This would also be an excellent tool for other GNOME Office applications.
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.
We haven't defined what that process will be precisely, but hope to keep it straightforward and easy for folks to implement. It could be as simple as "create a symlink to your clipart package in /usr/share/inkscape/clipart/".
GO already contains arguably the best available spreadsheet application in Gnumeric, one of the leading word processors in AbiWord, and an excellent data(base)-agnostic backend in the Gnome-DB project that is a unique facet to GO. We are looking to include Conglomerate (advanced XML editor), Mergeant (database management), and Planner (project management) as well as Inkscape. The increased collaboration and code re-use could produce an office suite to be reckoned with.
Inkscape is becoming the leading SVG editor. I am in a position of ignorance (not a coder or a projcet lead) but I firmly believe there is a desire from the GO team to include Inkscape among GO or, at the very least, make use of some of the excellent functionality provided by Inkscape.
It's an honor to be considered joining with this. We'd certainly like to learn more about this. And of course we'll need some time to discuss this as a team before reaching a decision. However a few questions spring to mind:
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?
Do you have a listing of the currently available reusable components from these other projects, that we could review?
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?
Will there be a set of standards or guidelines that all GO apps will strive to follow?
Finally, how do you view Open Office and KOffice in the context of GNOME Office, and in terms of interoperability, competition, augmentation, etc.?
Perhaps Inkscape could make use of the advanced editing capabilities of Conglomerate or other facets of GO? There is libgsf, libgda, libgnomedb and the planned libgoffice (emerging from Gnumeric).
We have been looking at libgsf. It would be interesting to learn more about the benefits these other capabilities could provide for Inkscape.
In the potential GO application list, we have a distinct selection of potentially (if not arguably) best-of-breed applications. If they were to collaborate then who knows what exciting prospects the future might hold! But first the respective project leads must be prepared to look months or even years ahead in terms of planning and setting goals.
Thank you for your time and I hope to hear from you soon!
Thanks, Bryce
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.
On Wed, 2004-02-18 at 21:37 +0000, Charles Goodwin wrote:
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.
libgda has been compiling on windows for years. Not sure if it works or not, since I have never tried, but it shouldn't be any problem in making it work on windows. On MacOS X, since it's unix, it should just work.
libgnomedb is the sdame case, we have even stuff for making it compile only the GTK-only parts, thus not having all the GNOME-dependant bits. That GTK-only part should also work on windows with no problems.
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
there is also some libgoffice code in the gnome-office module, in GNOME CVS.
cheers
On Wed, 18 Feb 2004, Charles Goodwin wrote:
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.
*Nod* We've been quite interested in finding ways to better collaborate with other projects. For example, we've been in frequent contact with the Scribus DTP folks for SVG-level compatibility so docs can be shared between the two apps. We've also been interested in developing better interrelationship with the Mozilla SVG plugin group, as well as Cairo and librsvg, for obvious reasons. :-)
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.
Ah, interesting, I can definitely see how having a common mission could help all the projects - have the development goals that have been aligned between these projects been formally written up?
Bryce
On Thu, 2004-02-19 at 00:17, Bryce Harrington wrote:
Ah, interesting, I can definitely see how having a common mission could help all the projects - have the development goals that have been aligned between these projects been formally written up?
I think it would definitely be worthwhile for some of the lead developers, yourself included, to hack some thoughts up on a suitable wiki - nice and easy.
And what about the Gnome wiki at gnomesupport.org: http://gnomesupport.org/wiki/index.php/GnomeOffice
I just created that as a starting point. If the developers can add some information with regards to their intentions and aspirations then I can eventually convert that wiki page into a nice html page for the GO website as it develops.
On Wed, 18 Feb 2004, Charles Goodwin wrote:
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.
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.
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.
I had a chance to talk with a few of the Inkscape developers, and I think you're right that going step by step will be the best way to go. Inkscape is still a young project, especially compared with AbiWord and Gnumeric, so we're still feeling our way around, and getting a handle on our own internal roadmap and development goals. So moving step by step will give us time to gain some self-definition.
Particularly, it would be of use to have some clearer explanation of the specific and tangible benefits of being part of a suite, as opposed to simply using similar underlying libraries and following similar guidelines.
One area I hope Gnome Office establishes a solid, well researched strategy is with Open Office (and perhaps also with KOffice). Despite the various things people dislike about OOo, it has a definite lead in many areas, which means that there is non-trivial risk to projects that seek to compete head-to-head with it.
Taking off my Inkscape hat and putting on my OSDL hat, a piece of advice I can share - From what I've been seeing and hearing in relation to OSDL's Desktop Initiative efforts, 2004 is likely going to see some strong pressures towards consolodation at the desktop level. It sounds like Freedesktop is going to play a key role in this, which is why I'd strongly suggest building a very good relationship with them.
Bryce
On Thu, 2004-02-19 at 06:37, Bryce Harrington wrote:
Particularly, it would be of use to have some clearer explanation of the specific and tangible benefits of being part of a suite, as opposed to simply using similar underlying libraries and following similar guidelines.
The guidelines are still fairly basic: - being gtk2-based - half-adherence to the HIG - being a good, solid application
Inkscape already fulfills this criteria.
The benefits start mainly with the use of common libraries: - libgsf which you are already looking at - libgoffice for plugins
These are things that would definitely benefit Inkscape (why reinvent the wheel etc etc) in the short term.
Then longer term goals: - exporting your SVG canvas to a library - combining facets of Inkscape/Inkview with that of AbiWord to create a presentation application (somebody is already working on a framework) - continual review of shared libraries and ongoing documentation efforts - extra cross-platform compatability review and resources - shared translation resources
Then there are the non-development-related benefits: - extra publicity as being part of a suite - larger community that can be a valuable resource - shared resources to help cope with any sf.net inadequacies
The people to pay attention to in order to really get a feel for how some of the above is achievable are Dom, Jody, and Rodrigo. Dom's excellent mail on libgsf show's just how well-thought-out libgsf is.
One area I hope Gnome Office establishes a solid, well researched strategy is with Open Office (and perhaps also with KOffice). Despite the various things people dislike about OOo, it has a definite lead in many areas, which means that there is non-trivial risk to projects that seek to compete head-to-head with it.
KOffice are looking to use Enchant, which was born out of AbiWord.
I think it's a case of 'if we can work with them we will and if they can work with us then encourage it.' Not being a developer, I cannot assess with an certainty the pheasibility of any aspect of this.
Taking off my Inkscape hat and putting on my OSDL hat, a piece of advice I can share - From what I've been seeing and hearing in relation to OSDL's Desktop Initiative efforts, 2004 is likely going to see some strong pressures towards consolodation at the desktop level. It sounds like Freedesktop is going to play a key role in this, which is why I'd strongly suggest building a very good relationship with them.
Dom answered this well already:
"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, ..."
I encourage you to respond to emails from Dom, Jody, and Rodrigo before you respond to mine. Mine contain more hope than substance. ;)
I believe it would be easier for GNOME Office to establish ways in which it could benefit from working with fd.o (and the other open source offices) once GO has consolidated itself as a chosen suite of applications and set out it's goals as a platform; it's difficult to ascertain where we can work with these bodies on a broad level when we're not yet fully certain of the direction we are GOing in.
On Thu, 2004-02-19 at 12:47, J.M. Maurer wrote:
presentation application (somebody is already working on a framework)
Noone is working on this afaik.
I have it on good advice that somebody is, privately, working on this. And even if nothing comes of that, as GO applications collaborate on sharing features it will become an increasingly realistic process to access the required components of AbiWord and Inkscape to achieve this.
Anyway, regardless, there is already Inkview which, although rudimentry, is a nice start and could become much more if somebody is developing it "step by step".
One area I hope Gnome Office establishes a solid, well researched strategy is with Open Office (and perhaps also with KOffice). Despite the various things people dislike about OOo, it has a definite lead in many areas, which means that there is non-trivial risk to projects that seek to compete head-to-head with it.
Well we're betting we can overtake OOo in quite a few areas over the next year as they struggle with their cumbersome code-base. Certainly AbiWord-2.2 and Gnumeric-2.0 will establish significant leads in a number of key features, in addition to the leads we already have.
Taking off my Inkscape hat and putting on my OSDL hat, a piece of advice I can share - From what I've been seeing and hearing in relation to OSDL's Desktop Initiative efforts, 2004 is likely going to see some strong pressures towards consolodation at the desktop level. It sounds like Freedesktop is going to play a key role in this, which is why I'd strongly suggest building a very good relationship with them.
What does this mean? If it means what I think it means I can't see how more pressure could be applied than I already feel to "join the winning team".
Frankly the pressure just motivates me to work harder om AbiWord and Gnome Office.
OO.o falls way short of my vision of a Productivity Suite could be.
I, and I suspect we all in Gnome Office, have nothing against working with F.D.O. We've benefitted greatly already from their work. (Particularly fontconfig and XFT2).
Cheers,
Martin
Bryce
gnome-office-list mailing list gnome-office-list@...45... http://mail.gnome.org/mailman/listinfo/gnome-office-list
On Thu, 2004-02-19 at 13:03, msevior@...79... wrote:
What does this mean? If it means what I think it means I can't see how more pressure could be applied than I already feel to "join the winning team".
Frankly the pressure just motivates me to work harder om AbiWord and Gnome Office.
OO.o falls way short of my vision of a Productivity Suite could be.
I think Bryce was referring more to fd.o than OOo.
Also, GO and OOo are two very different beasts with different architectures and different goals. The GO approach is to aim to be the best and collaborate to help that happen. The OOo approach, from my perspective, is a fully integrated office suite that is a drop-in replacement for MSO.
Taking into account the tools used as well as the end goal, again from my perspective only, Inkscape squarely drops into the GO bracket but is really quite unaligned with OOo.
But we are grossly digressing from the matter at hand:
o Is it pheasible for Inkscape and other GO applications to share features and libraries in a reasonable time frame?
Yes. Inkscape is already looking to do this (libgsf) and could collaborate on other aspects (eg libgoffice/clipart)
o Would Inkscape be a valuable addition to GO?
Yes. Incredibly; GO needs an SVG canvas of high quality and Inkscape is well placed to deliver this.
o Do GO and Inkscape have similar philosophies?
Yes. Both are seeking standards compliance to some degree such as reasonable HIG compliance and cooperating with standards bodies such as fd.o on several levels.
o What are the ways in which Inkscape and GO applications could collaborate in both the short and long term?
The developers need to put their heads together to identify these areas.
By whatever means a formal plan needs to evolve. I think the informal collaboration between AbiWord, Gnumeric, and Gnome-DB was ideal for that phase of GO development. But if more projects are going to come into the fold then surely it needs to be formalised on how they can align themselves with and contribute to GO.
On Thu, 19 Feb 2004, Charles Goodwin wrote:
On Thu, 2004-02-19 at 13:03, msevior@...79... wrote:
What does this mean? If it means what I think it means I can't see how more pressure could be applied than I already feel to "join the winning team".
Frankly the pressure just motivates me to work harder om AbiWord and Gnome Office.
OO.o falls way short of my vision of a Productivity Suite could be.
I think Bryce was referring more to fd.o than OOo.
Right. I think to be able to compete effectively against OOo, strong allies are needed.
Obviously if I thought time would be better spent working on OOo, well I'd probably be working on OO Draw. ;-) I did look into working on OO Draw a while back but it just didn't "click" for me. I don't know if the other OOo app codebases are the same way, but if so, they could run into long term problems if they lack enough developers to keep up.
But more importantly I wanted to emphasize that a _strategy_ is needed. For example, with Inkscape our strategy for competing effectively with OO Draw is pretty straightforward. First, we shoot for gaining really good SVG compatibility (OO Draw is weak here, and it seems like SVG is growing to become an extremely important file format in the open source community). Second, we try to make the project very enjoyable to work in; happy developers are productive developers. Third, we try to encourage experimentation and don't dismiss new ideas just because they're oddball ("patch first, discuss later"); if Inkscape can gain some strange but really handy new feature that no other application has, it could be that killer advantage that opens up huge new possibilities. And finally, we focus more on trying to put out a great product for certain users, than trying to gain a huge userbase; this way we enjoy having a small and fun user community that team with us in finding how to make the app better, rather than just an endless stream of anonymous bug reports. ;-)
Also, GO and OOo are two very different beasts with different architectures and different goals. The GO approach is to aim to be the best and collaborate to help that happen. The OOo approach, from my perspective, is a fully integrated office suite that is a drop-in replacement for MSO.
Very true. File format compatibility appears to be a large part of this. It has made me wonder if one could extract the document format parsing bits from OOo and turn them into reusable libraries.
By whatever means a formal plan needs to evolve. I think the informal collaboration between AbiWord, Gnumeric, and Gnome-DB was ideal for that phase of GO development. But if more projects are going to come into the fold then surely it needs to be formalised on how they can align themselves with and contribute to GO.
Agreed. Having a specific mission, with exciting goals, and a clear strategy for achieving them could help a great deal.
Bryce
On Wed, Feb 18, 2004 at 10:37:18PM -0800, Bryce Harrington wrote:
Particularly, it would be of use to have some clearer explanation of the specific and tangible benefits of being part of a suite, as opposed to simply using similar underlying libraries and following similar guidelines.
I see benefits on several levels.
1) Mind share. Like it or not people have been conditioned to believe that office/document apps are part of a suite. An informal literature search at the local bookstore a few years ago turned up 10 references to Star-Office (before OO) 8 references to KOffice, 5 to abi and 2 to gnumeric. The authors just didn't consider stand alone apps worth mentioning.
2) Shared code. Many tasks associated with document centric applications are common across applications boundaries. - Managing plugins - Handling multiple import/export types - Simple widgets like undo/redo and colour selectors - reading/writing various file formats ...
None of there are inherently impossible, or even terribly difficult to create a functional implementation for. However, resources are required, which is not something any of our projects want to waste. Doing high quality implementations, with a reasonable amount of polish for the user takes alot of time. Sharing this effort to get a best of breed implementation would seem like our only chance of moving on.
On Wed, Feb 18, 2004 at 10:33:54AM -0800, Bryce Harrington wrote:
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?
At present there are two libraries associated with gnome-office, and one more is on the way.
- gnome-db/gda : glib, libxml2, libxslt - libgsf : glib, libxml2, bzip2, zlib
All of these are available on all relevant platforms. The new libgoffice that is under development currently pulls gtk and libgnomeprint into the stack. libgnomeprint is purely glib, and should not be a problem, although it could use some platform specific printing backends. gtk will likely cause some consternation depending on your cross platform strategy.
Do you have a listing of the currently available reusable components from these other projects, that we could review?
At present gnome-db and libgsf are the only stand alone portions. libgoffice was developed as an appendage to gnumeric, and will bud off into a stand alone library after it has absorbed a bit more from it's parent.
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?
There are no relevant freedesktop initiatives directly relating to office applications as far as I know. If some are created we'll be involved. We are monitoring the OASIS file format effort, and have joined the FSG printing initiatives.
Will there be a set of standards or guidelines that all GO apps will strive to follow?
Eventually there may be. At the inception our goals are focused on creation, than long term visions. For now it is sufficient to be a well maintained application that uses glib, and would like to be part of the gnome-office project. We need to work on integration at many levels. Let's pick the easy bits, such as cut-n-paste, first.
Finally, how do you view Open Office and KOffice in the context of GNOME Office, and in terms of interoperability, competition, augmentation, etc.
There is only one competitor of interest, Microsoft.
OO and KO are both interesting projects that we should collaborate with when possible. Gnumeric has exchanged test suites with OO, and KO uses libgsf and libwv. We'll continue to improve support for the OOo implementation of the OASIS file formats. It may even make sense to adopt their structured file format. Of course it is difficult to have much interaction with OO, its quite difficult for them to break their code into pieces others can use.
On Thu, 2004-02-19 at 14:47, Jody Goldberg wrote:
There are no relevant freedesktop initiatives directly relating to office applications as far as I know.
Dom will not be happy that you forgot that Enchant has become a fd.o standard. ;) In fact, I'll quote him again:
"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, ..."
Eventually there may be. At the inception our goals are focused on creation, than long term visions. For now it is sufficient to be a well maintained application that uses glib, and would like to be part of the gnome-office project. We need to work on integration at many levels. Let's pick the easy bits, such as cut-n-paste, first.
+1 to step by step, but at the same time we shouldn't just put everything off until later. Perhaps we should also step by step be setting out the roadmap and standards for GO and it's applications.
On Thu, 2004-02-19 at 09:47 -0500, Jody Goldberg wrote:
On Wed, Feb 18, 2004 at 10:33:54AM -0800, Bryce Harrington wrote:
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?
At present there are two libraries associated with gnome-office, and one more is on the way.
- gnome-db/gda : glib, libxml2, libxslt - libgsf : glib, libxml2, bzip2, zlibAll of these are available on all relevant platforms. The new libgoffice that is under development currently pulls gtk and libgnomeprint into the stack. libgnomeprint is purely glib, and should not be a problem, although it could use some platform specific printing backends. gtk will likely cause some consternation depending on your cross platform strategy.
libgnomedb adds a libgnomeui dependency. It could probably be removed, if there is concern about it. I don't remember right now exactly what things are pulled from libgnome/ui, but most could probably be replaced with GTK.
cheers
On Wed, 2004-02-18 at 18:33, Bryce Harrington wrote:
On Wed, 18 Feb 2004, Charles Goodwin wrote:
Inkscape developers!
I'm in the process of developing the new GNOME Office portal.
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.
I also notice your plans for a clip art extension. This would also be an excellent tool for other GNOME Office applications.
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.
We haven't defined what that process will be precisely, but hope to keep it straightforward and easy for folks to implement. It could be as simple as "create a symlink to your clipart package in /usr/share/inkscape/clipart/".
GO already contains arguably the best available spreadsheet application in Gnumeric, one of the leading word processors in AbiWord, and an excellent data(base)-agnostic backend in the Gnome-DB project that is a unique facet to GO. We are looking to include Conglomerate (advanced XML editor), Mergeant (database management), and Planner (project management) as well as Inkscape. The increased collaboration and code re-use could produce an office suite to be reckoned with.
Inkscape is becoming the leading SVG editor. I am in a position of ignorance (not a coder or a projcet lead) but I firmly believe there is a desire from the GO team to include Inkscape among GO or, at the very least, make use of some of the excellent functionality provided by Inkscape.
It's an honor to be considered joining with this. We'd certainly like to learn more about this. And of course we'll need some time to discuss this as a team before reaching a decision. However a few questions spring to mind:
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?
Do you have a listing of the currently available reusable components from these other projects, that we could review?
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?
Will there be a set of standards or guidelines that all GO apps will strive to follow?
Finally, how do you view Open Office and KOffice in the context of GNOME Office, and in terms of interoperability, competition, augmentation, etc.?
Perhaps Inkscape could make use of the advanced editing capabilities of Conglomerate or other facets of GO? There is libgsf, libgda, libgnomedb and the planned libgoffice (emerging from Gnumeric).
We have been looking at libgsf. It would be interesting to learn more about the benefits these other capabilities could provide for Inkscape.
Re. Conglomerate: we're building a general purpose XML editor aimed at end-users for "document style" DTDs, focussing initially on DocBook. So we'd love to be able to embed Inkscape for editing SVG subtrees within our users documents. I'm not sure how much we'd be able to offer you in return, though! (This is rather blue-sky right now, though)
In the potential GO application list, we have a distinct selection of potentially (if not arguably) best-of-breed applications. If they were to collaborate then who knows what exciting prospects the future might hold! But first the respective project leads must be prepared to look months or even years ahead in terms of planning and setting goals.
Thank you for your time and I hope to hear from you soon!
Thanks, Bryce
gnome-office-list mailing list gnome-office-list@...45... http://mail.gnome.org/mailman/listinfo/gnome-office-list
On Thu, 2004-02-19 at 22:09, Dave Malcolm wrote:
I'm not sure how much [Conglomerate would] be able to offer [Inkscape]
I'm sure the Inkscape team would rather be focusing on developing their SVG editor than the XML editor... wait, isn't Conglomerate an XML editor? ;)
At 02:09 PM 2/19/2004, Dave Malcolm wrote:
We have been looking at libgsf. It would be interesting to learn more about the benefits these other capabilities could provide for Inkscape.
Re. Conglomerate: we're building a general purpose XML editor aimed at end-users for "document style" DTDs, focussing initially on DocBook. So we'd love to be able to embed Inkscape for editing SVG subtrees within our users documents. I'm not sure how much we'd be able to offer you in return, though! (This is rather blue-sky right now, though)
One could easily argue that that the added value of being able to use Inkscape thusly is enough.
On Thu, 2004-02-19 at 17:09, Dave Malcolm wrote:
Re. Conglomerate: we're building a general purpose XML editor aimed at end-users for "document style" DTDs, focussing initially on DocBook. So we'd love to be able to embed Inkscape for editing SVG subtrees within our users documents. I'm not sure how much we'd be able to offer you in return, though! (This is rather blue-sky right now, though)
Well, I'd imagine the relationship could be reciprocal.
While I do plan on implementing a (bare-bones) internal XML editor, being able to use conglomerate if present would rock, too.
One obstacle we'd need to think about would be dealing with the differing internal document representations.
Inkscape is basically aiming in-memory hierarchical database, including transactions, which I think kind of precludes using libxml structures. Also, the eventual plan for Inkscape is to also store CSS parse trees in the same document tree as the XML document itself.
-mental
On Fri, 2004-02-20 at 05:23, MenTaLguY wrote:
One obstacle we'd need to think about would be dealing with the differing internal document representations.
Inkscape is basically aiming in-memory hierarchical database, including transactions, which I think kind of precludes using libxml structures. Also, the eventual plan for Inkscape is to also store CSS parse trees in the same document tree as the XML document itself.
I'm unsure of the feasibility, but have you looked at Gnome-DB for doing this rather than implementing it over again?
On Fri, 2004-02-20 at 05:41, Charles Goodwin wrote:
Inkscape is basically aiming in-memory hierarchical database, including transactions, which I think kind of precludes using libxml structures. Also, the eventual plan for Inkscape is to also store CSS parse trees in the same document tree as the XML document itself.
I'm unsure of the feasibility, but have you looked at Gnome-DB for doing this rather than implementing it over again?
Well, the goal for right now is a lot more modest than a general database architecture -- I'm just using database terminology with our parse tree representation because treating it as a (hierarchical) database turned out to have some conceptual benefits.
Conceivably, we might do some real database-y things down the road to support things like distributed editing, but that's a long way away yet...
Even then, I'm not sure GnomeDB would be a good fit, since GnomeDB is designed for relational rather than hierarchical data.
Also, there are some special requirements, like a commit operation that returns a log fragment which later can be rewound/replayed to undo or redo the transaction (this is used for undo/redo of operations that affect the parse tree), and fine-grained constraints and change notifications.
-mental
On Fri, 2004-02-20 at 22:01 -0500, MenTaLguY wrote:
On Fri, 2004-02-20 at 05:41, Charles Goodwin wrote:
Inkscape is basically aiming in-memory hierarchical database, including transactions, which I think kind of precludes using libxml structures. Also, the eventual plan for Inkscape is to also store CSS parse trees in the same document tree as the XML document itself.
I'm unsure of the feasibility, but have you looked at Gnome-DB for doing this rather than implementing it over again?
Well, the goal for right now is a lot more modest than a general database architecture -- I'm just using database terminology with our parse tree representation because treating it as a (hierarchical) database turned out to have some conceptual benefits.
Conceivably, we might do some real database-y things down the road to support things like distributed editing, but that's a long way away yet...
Even then, I'm not sure GnomeDB would be a good fit, since GnomeDB is designed for relational rather than hierarchical data.
it is designed to cope with any data source, even with hierarchical data. There might be some stuff missing, but data models (recordsets) can contain fields of type 'list', which contain lists of values, and those values can in turn be more lists, and so on. So it should cope with hierarchical data also.
I'm not sure though if libgda is the correct solution for inkscape XML parsing.
Also, there are some special requirements, like a commit operation that returns a log fragment which later can be rewound/replayed to undo or redo the transaction (this is used for undo/redo of operations that affect the parse tree), and fine-grained constraints and change notifications.
this is already available in libgda in the form of transactions. A XML provider (= plugin) could be implemented, and have it implement the transactions internally. In fact, we already have a XML-based provider, although it is supposed to only support libgda's export/import XML format (a DTD we've got to describe a full database).
cheers
On Mon, 2004-03-01 at 05:11, Rodrigo Moya wrote:
it is designed to cope with any data source, even with hierarchical data. There might be some stuff missing, but data models (recordsets) can contain fields of type 'list', which contain lists of values, and those values can in turn be more lists, and so on. So it should cope with hierarchical data also.
Hmm.. that does sound interesting.
I'm not sure though if libgda is the correct solution for inkscape XML parsing.
Probably not -- since really it's more a question of storing XML in the database, than storing the database in XML. I'd want to work very directly with libxml2 (and for CSS, libcroco) for parsing.
Also, there are some special requirements, like a commit operation that returns a log fragment which later can be rewound/replayed to undo or redo the transaction (this is used for undo/redo of operations that affect the parse tree), and fine-grained constraints and change notifications.
this is already available in libgda in the form of transactions. A XML provider (= plugin) could be implemented, and have it implement the transactions internally.
It sounds like we'd need a very specialized provider; unless I misunderstand, most existing providers would not give you multiple levels of "undo", or in general the ability to reverse (and replay) an already comitted transaction.
In fact, we already have a XML-based provider, although it is supposed to only support libgda's export/import XML format (a DTD we've got to describe a full database).
I'm not sure that helps much -- in our case, we want to store the XML (and other grammars too, in the same tree, as one unified AST) in a database; the form of the backend doesn't matter quite so much.
Here's a concrete example of what I have in mind. Take the following SVG fragment:
<g> <rect x="0" y="0" width="100" height="100" style="fill:red;stroke:black"/> <use xlink:href="#foo" /> </g>
The AST would look something like this:
Key: [1] - numbered continuation points so the diagram won't wrap (ClassName) - a mutable node of a given class "blah" - an immutable string node ( "axis", "name" ) - a branch name (a branch can hold one or more children) {SVG}g - shorthand for an expanded name in the SVG namespace
(XMLElement)--+-- ( "name", NULL ) -- "{SVG}g" | +-- ( "child", NULL ) -- [1] [2]
[1](XMLElement)--+-- ( "name", NULL ) -- "{SVG}rect" | +-- ( "attribute", "x" ) -- "0 | +-- ( "attribute", "y" ) -- "0" | +-- ( "attribute", "width" ) -- "100" | +-- ( "attribute", "height" ) -- "100" | +-- ( "attribute", "style" ) -- [3]
[2](XMLElement)--+-- ( "name", NULL ) -- "{SVG}use" | +-- ( "attribute", "{XLINK}href" ) -- "#foo"
[3](CSSDeclList)--+-- ( "child", NULL ) -- [4] [5]
[4](CSSProperty)--+-- ( "name", NULL ) -- "fill" | +-- ( "value", NULL ) -- "red"
[5](CSSProperty)--+-- ( "name", NULL ) -- "stroke" | +-- ( "value", NULL ) -- "black"
The leaf nodes are immutable strings, so all mutations of the tree are accomplished by adding/reordering/exchanging/removing nodes on branches.
Depending on the class of a node (and on higher-level objects which have attached themselves to it), various constraints may be applied as to which mutations are valid and permitted. Every mutation also results in a notification to any interested listeners, on a per-node basis.
[ For example, XML elements have only one "name", which cannot be changed, "attribute"s, and "child"ren -- no other branches are valid. Their "child" axis will only accept other XMLElements, and branches on the "attribute" axis will only accept one child. This permits the actual representation for XMLElements to be very compact and specialized. ]
Every node is capable of serializing itself as a UTF-8 string, and every class has an associated parser (here generally implemented using libxml or libcroco) that can be used to build nodes of that class from such a string.
At least that's the design I'm looking at right now.
(yes, I am utterly insane)
It sounds like libgda might be general enough to expose a useful interface to this kind of setup, but it seems like it'd require a very custom backend and probably not all the functionality could be made available through libgda's generic interface?
-mental
On Mon, 2004-03-01 at 20:29 -0500, MenTaLguY wrote:
Also, there are some special requirements, like a commit operation that returns a log fragment which later can be rewound/replayed to undo or redo the transaction (this is used for undo/redo of operations that affect the parse tree), and fine-grained constraints and change notifications.
this is already available in libgda in the form of transactions. A XML provider (= plugin) could be implemented, and have it implement the transactions internally.
It sounds like we'd need a very specialized provider; unless I misunderstand, most existing providers would not give you multiple levels of "undo", or in general the ability to reverse (and replay) an already comitted transaction.
some providers already support that, in the form of nested transactions. Others would have to simulate it in some way. For the XML provider, if done, it would just mean keeping track of the changes, and of the undo levels, to be able to rollback a set of transactions.
In fact, we already have a XML-based provider, although it is supposed to only support libgda's export/import XML format (a DTD we've got to describe a full database).
I'm not sure that helps much -- in our case, we want to store the XML (and other grammars too, in the same tree, as one unified AST) in a database; the form of the backend doesn't matter quite so much.
Here's a concrete example of what I have in mind. Take the following SVG fragment:
<g> <rect x="0" y="0" width="100" height="100" style="fill:red;stroke:black"/> <use xlink:href="#foo" /> </g>
The AST would look something like this:
Key: [1] - numbered continuation points so the diagram won't wrap (ClassName) - a mutable node of a given class "blah" - an immutable string node ( "axis", "name" ) - a branch name (a branch can hold one or more children) {SVG}g - shorthand for an expanded name in the SVG namespace
(XMLElement)--+-- ( "name", NULL ) -- "{SVG}g" | +-- ( "child", NULL ) -- [1] [2]
[1](XMLElement)--+-- ( "name", NULL ) -- "{SVG}rect" | +-- ( "attribute", "x" ) -- "0 | +-- ( "attribute", "y" ) -- "0" | +-- ( "attribute", "width" ) -- "100" | +-- ( "attribute", "height" ) -- "100" | +-- ( "attribute", "style" ) -- [3]
[2](XMLElement)--+-- ( "name", NULL ) -- "{SVG}use" | +-- ( "attribute", "{XLINK}href" ) -- "#foo"
[3](CSSDeclList)--+-- ( "child", NULL ) -- [4] [5]
[4](CSSProperty)--+-- ( "name", NULL ) -- "fill" | +-- ( "value", NULL ) -- "red"
[5](CSSProperty)--+-- ( "name", NULL ) -- "stroke" | +-- ( "value", NULL ) -- "black"
The leaf nodes are immutable strings, so all mutations of the tree are accomplished by adding/reordering/exchanging/removing nodes on branches.
Depending on the class of a node (and on higher-level objects which have attached themselves to it), various constraints may be applied as to which mutations are valid and permitted. Every mutation also results in a notification to any interested listeners, on a per-node basis.
[ For example, XML elements have only one "name", which cannot be changed, "attribute"s, and "child"ren -- no other branches are valid. Their "child" axis will only accept other XMLElements, and branches on the "attribute" axis will only accept one child. This permits the actual representation for XMLElements to be very compact and specialized. ]
Every node is capable of serializing itself as a UTF-8 string, and every class has an associated parser (here generally implemented using libxml or libcroco) that can be used to build nodes of that class from such a string.
At least that's the design I'm looking at right now.
(yes, I am utterly insane)
It sounds like libgda might be general enough to expose a useful interface to this kind of setup, but it seems like it'd require a very custom backend and probably not all the functionality could be made available through libgda's generic interface?
well, libgda could help in the storing and reading of the data from the database. Not sure if it fits here. If you just want to parse the XML in a specific way, using libxml2 directly might be better.
What I don't understand here is why you'd want to store all that in a "database", don't the XML just come from the .SVG files?
cheers
On Tue, 2004-03-02 at 03:19, Rodrigo Moya wrote:
well, libgda could help in the storing and reading of the data from the database. Not sure if it fits here. If you just want to parse the XML in a specific way, using libxml2 directly might be better.
What I don't understand here is why you'd want to store all that in a "database", don't the XML just come from the .SVG files?
Yeah... I'm not sure I did such a good job of communicating what I was going for originally.
The "database" idea isn't so much for storage as for manipulating the document in memory -- the current and planned representations are just databases in mostly the same sense that a GHashTable might be -- it's just that I found that applying database concepts and terminology improved the design.
However, using a "real" database of some kind to implement a "shared workspace" is something I want to keep an eye on; we'll need something like that when we broach some of the collaborative editing functionality we've discussed in the past.
If we can use libgda for that rather than rolling our own API, that'd be really cool (and would potentially make it easier for e.g. external scripts in languages with just a libgda binding to participate in an editing session).
What I've learned from this conversation is that it's at least possible in principle with libgda, which is good to know.
-mental
On Tue, 2004-03-02 at 21:30 -0500, MenTaLguY wrote:
On Tue, 2004-03-02 at 03:19, Rodrigo Moya wrote:
well, libgda could help in the storing and reading of the data from the database. Not sure if it fits here. If you just want to parse the XML in a specific way, using libxml2 directly might be better.
What I don't understand here is why you'd want to store all that in a "database", don't the XML just come from the .SVG files?
Yeah... I'm not sure I did such a good job of communicating what I was going for originally.
The "database" idea isn't so much for storage as for manipulating the document in memory -- the current and planned representations are just databases in mostly the same sense that a GHashTable might be -- it's just that I found that applying database concepts and terminology improved the design.
However, using a "real" database of some kind to implement a "shared workspace" is something I want to keep an eye on; we'll need something like that when we broach some of the collaborative editing functionality we've discussed in the past.
hmm, then it makes sense. libgda can help you in the retrieval and (basic) management of the data, from wherever it comes from.
If we can use libgda for that rather than rolling our own API, that'd be really cool (and would potentially make it easier for e.g. external scripts in languages with just a libgda binding to participate in an editing session).
right. I guess you could look at build your custom stuff on top of libgda, and while you're on it, we could see, one thing at a time, the stuff that are generic enough to be in libgda. If you want to have access to databases for shared workspaces, I guess this makes sense.
cheers
On Mon, 2004-03-01 at 20:29 -0500, MenTaLguY wrote:
this is already available in libgda in the form of transactions. A XML provider (= plugin) could be implemented, and have it implement the transactions internally.
It sounds like we'd need a very specialized provider; unless I misunderstand, most existing providers would not give you multiple levels of "undo", or in general the ability to reverse (and replay) an already comitted transaction.
it depends on the provider. Some RDBMS allow nested transactions, so you can commit and rollback transactions inside transactions. Some libgda providers simulate this in some way, and could be extended to simulate it better, but I guess you'll still probably want your specialized transaction manager. Not sure though.
cheers
participants (9)
-
unknown＠example.com -
Bryce Harrington -
Charles Goodwin -
Dave Malcolm -
David Bolack -
J.M. Maurer -
Jody Goldberg -
MenTaLguY -
Rodrigo Moya