The ideas can be broken down into several distinct categories: Standards, drawing element collections, format converters, and code libraries. Each of these needs can be handled independently of each other, and I think even if only a few could be achieved, it would enhance the current situation considerably.
In addition, there have been several ideas around the theme of "shared identity", by which I mean the discussions about suites, merging, etc. While I think many of these ideas are a bit too optimistically ambitious to be realized in the near future, I think they hint at a desire among the community for a "teammanship" approach between these projects. Perhaps we can achieve this desire without having to undertake radical changes to how the projects work.
Standards and Guidelines
The Open Source community thrives on standards. In Inkscape, we've found the SVG spec to excel at helping us figure out interoperability problems with other applications; we simply compare behaviors of the two apps against the spec, and file a bug on whichever app isn't following it. Similarly, the GNOME HIG has been instrumental in settling arguments over how the interface should look. We may disagree with the standard, but hey, those are the rules. Processes exist to change the rules, but until that happens we abide by them.
One idea for improving the interoperability and integration between Open Source graphics applications is to establish some new standards and guidelines. For example, a "guideline for artistic application keyboard accelerators" could help address a huge number of the discrepancies between the applications that users are noticing today, especially if it also details the rationale for each binding. Path, text, and gradient editing may be other areas where new guidelines could help.
It would be wise for any such standardization efforts be kept at a desktop-system-neutral level. I.e., they should not be appended to the GNOME or KDE interface guidelines, but kept independent of either. This way, the work will be applicable to a wider range of projects, and thus will help all of the Open Source applications we use.
freedesktop.org has been working on a wide number of guidelines and standards that are highly applicable to our projects. Perhaps as a starting point, we can work on attaining and/or validating compliance to these specs between the three programs.
- Drag-and-Drop Protocol for the X Window System
- X Clipboard Explanation
- X Settings Spec (DRAFT)
- Icon Theme Spec (DRAFT)
- Recent Files Spec (DRAFT)
- Cursor conventions specification (DRAFT)
These are just a handful of examples of freedesktop.org's work, so this could be a very rich vein to tap. In addition, if there are areas we need standards that have not yet been covered, perhaps we can encourage investigation into those areas as well.
Drawing Element Collections
Probably the most powerful and effective ways of instilling a sense of interoperability between open source graphics applications would be to establish some shared collections of the low level elements they all use for creating drawings:
Presently, each Open Source drawing application essentially does its own thing with its palettes, and with the exception of fonts and clipart there is little sharing between them.
The Open Clip Art Library project may be a good model for how things could work. OCAL was started by several Inkscape developers, but was kept independent of Inkscape so other applications could benefit from its work. The clipart is installed into a general location so it is clearly considered a system resource like fonts. This project has also included gradients and symbols, and possibly could be a good forum for maintaining additional collections of drawing elements. They are associated with freedesktop.org, put out routine monthly releases, and are already included in several Linux distros. If a few more of us volunteer to help them with the technical side of things, I think OCAL could be expanded to cover the range of items needed.
The next step would be to improve installation of these items. I.e., gradients should probably be located in /usr/share/gradients, rather than as a subdir of the clipart package. I imagine some file hierarchy standards could be beneficial to scope out where these items should be installed on a Linux system, and how applications should access them. Indexing is probably worth thinking about, since conceivably these collections could get rather large.
From there would follow the work of both incorporating the palettes from existing programs into shared collections, and implementing support for these collections into programs that currently lack palette support.
For colors, there is a challenge in the fact that Pantone colors (the colors that everyone wants) have strict IP restrictions on them. Inkscape and Scribus have discussed this, but without a good solution. I'm sure the GIMP folks have likewise mulled it over. It would be wonderful if someone could figure out a system that would allow users to be able to incorporate Pantone, without incurring the IP challenges onto the applications themselves.
- "OSS consistency, Page 1/2"
- "OSS consistency, Page 2/2"