Jozef Mak recently made a noteworthy proposal for achieving better integration of Open Source graphic applications, which has been positively received by the three communities he targeted: GIMP (for photo and image editing), Scribus (for desktop publishing), and Inkscape (for vector graphics editing). This has sparked a bit of discussion in our communities and brought up several ideas for improvement.
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:
- Colors
- Fonts
- Gradients
- Patterns
- Symbols
- Clipart
- Filters
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.
Format Converters
Drawing applications live and die by being able to share files with one
another. In Open Source, different applications have different
feature sets, and sometimes it’s quite handy to be able to shift from app
to app in order to perform all of the needed work. Additionally, for
people converting over from legacy proprietary tools, the ability to
import from proprietary formats is crucial.
As an example, in Inkscape we have a functionality that allows us to
automatically pipe a file through a filter program. We found a script
called ill2svg.pl that is able to take an Adobe Illustrator file on
STDIN, and emits the corresponding SVG to STDOUT. This AI import
feature was a very frequent request by users before we added it, and
being able to reuse an existing Open Source tool saved us a *lot* of
effort. Similarly, we’ve been able to leverage Sketch, dia, and other
programs by running them from the command-line to convert their native
file formats into SVG.
The other way Inkscape handles file formats is through libraries such as
libpng. Formal libraries are generally better than command-line tools,
and so are preferred, but they’re more work to create so are not as
common.
More file format converters (either command-line or libraries) and
improvements to the existing converters, would be an extremely valuable
way to improve interoperability between Open Source drawing
applications. There is a dire need for maintainers of the command-line
converters; many of the scripts out there are essentially unmaintained,
and really need developers to improve them. The ill2svg.pl program
mentioned above, for example, needs a number of improvements in order to
read in a wider variety of AI files. A Visio(VDX)-to-SVG converter
could also be extremely beneficial. Reimplementing the more popular
converters as C libraries would give us even more flexibility and power
as we move forward.
In addition, we need to encourage more drawing applications to support
both input and output of SVG and other standard file formats. OODraw is
a commonly used drawing tool, and it has an SVG output capability, but
cannot import SVG. This tends to close off the benefits of SVG to a
huge segment of the Open Source community’s overall userbase.
Programs with unique primary file formats should also be encouraged to
provide the converter code packaged as libraries and/or command-line
tools where-ever possible. Thankfully, many Open Source applications are
already doing this; users can help a lot here by keeping an eye out for
apps that don’t, and voicing their desire for this feature.
Achievement of document format compatibility could be instrumental in
enabling wide numbers of users to convert to Linux. Corporate users
with large numbers of existing drawing files will be loath to convert to
Linux if it means they will not be able to re-use them. We have already
seen with office documents how big of an enabler that OpenOffice.org’s
compatibility has been; doing the same with drawing formats could really
solidify Linux’s value as a desktop platform.
Code (and Widget) Libraries
Sharing of code seems like a no-brainer for achieving integration
between the various projects. However, while this is certainly worth
doing, the benefits are not always a trivial matter to obtain.
Between GIMP, Scribus, and Inkscape, we have one Gtk+ app, one Qt app,
and one (soon-to-be) Gtkmm app. It would certainly not take much time
to find a fourth, fifth, and sixth Open Source drawing application coded
with completely incompatible interface languages. 😉
I don’t think it’s realistic or productive in the near term to expect
these projects to stop and recode themselves to a different widget set.
It’s a heck of a lot of work! Also keep in mind that Gtk and Qt each
imply a lot more than just a widget set; they each have low level
routines (such as glib in Gtk) that are used throughout the program
codebase.
On the other hand, there’s nothing to stop the projects from each
creating shareable widgets, that are packaged and distributed
independently of the program itself. Even if not all graphics
applications could use those, at least some could, and maybe in the long
term we could see some porting activity.
Drawing applications have needs for widgets such as rulers, canvases,
palette editorss, gradient editors, and so forth. These are often too
application-specific to be included and maintained in the core widget
library, though. In addition, oftentimes applications wish to customize
and go beyond the core default widgets.
An idea that’s been voiced for this could be for the individual drawing
application projects to try to organize and package their more
general-purpose widgets into discrete libraries, that they would offer
for other projects to reuse.
We also have numerous examples of efforts others have done to achieve
code sharing both at low levels (such as some of the work KDE developers
have done to reuse lower level GTK libs) and high level (such as
metatheme, etc.) There are big shoulders we can stand on. 😉
In addition, there are a number of non-widget things that may be worth
sharing. For instance, a really good PDF printing library could help us
all out; Scribus has the reputation for the best PDF export in the
community, so this is something they could provide that we could all
benefit from.
“Shared Identity”
In addition to the above technical issues, it sounds like there is also
a desire from users to see the applications united in spirit, if not in
body. This is often mentioned as establishing a “suite”, however I
think what is desired is more about establishing ourselves as a “team”.
To me, a “suite” conjures up the notion of corporate software giants
bundling applications together to try to kill off the competition. But
we’re not trying to kill off or replace anyone. Unlike proprietary
software, success with Open Source software is not measured by
market-share dominance. GIMP, Scribus, and Inkscape can be quite
successful even if they never have more than a fraction of the total
userbase, so long as they continue to improve the value of the tools to
the users and have fun in doing so.
Adobe and Macromedia provide excellent products that are essentially de
facto standards in the computerized art world, and due to their
resources and depth of experience will almost certainly remain the best
solutions for most users. However, there are still sizeable numbers of
users that will appreciate having an alternative, for a variety of
reasons: Price, availability, openness, freedom, participation… Open
Source operates from a fundamentally different philosophy than
commercial-ware, which gives us a small but distinct edge.
I think one thing we could really use is additional liaisons between our
groups. Peter Linnell has been an excellent example of this between
Scribus and Inkscape, and has helped us build a strong relationship.
Despite being in two completely different widget sets, the relationship
has enabled us to achieve a notable amount of interoperability. Because
Peter contributes to both projects, he provides information and keeps an
eye out for things we can each do to improve integration. On several
situations he’s arranged IRC meet-ups between the groups to discuss long
term plans and to share ideas. One or two people serving in such a role
between GIMP and Inkscape (and perhaps other projects) could do a great
deal of good for all of us.
Blue Sky
The big picture here is to build something that enables designers to do
a wide range of work on Open Source. Regardless of whether they’re
using a GNOME, KDE, OpenOffice, or Mozilla application, the goal is to
make it straightforward for them to do better work than can be done with
non-Open Source products.
This is completely achievable, and can be done without having to limit
choice or impose large amounts of work on the projects in question. We
achieve this by agreeing on standards and guidelines, building up
collections of reusable drawing components, creating and maintaining
powerful file format converters, sharing code and widget libraries,
and establishing a shared “team identity”.
I think it can definitely be done, especially if we can get more people
involved in the various projects and efforts required to make it
succeed. With this success in place, the success of the Linux Desktop
will be certain.
About the Author:
Bryce Harrington is one of the Inkscape project founders and a senior performance engineer at the Open Source Development Labs.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
actually, i prefer the fact that all these tools are
1. separate
2. do their own job, well
2. communincate with each other in no other way than a transparent process – through saved files
i really don’t want the OSS desktop to start getting bogged down with behind-the-scenes inter-process communications and MS-Office style objects linked into documents.
I don’t even want scribus to have a “hot-link” to inkscape to update the graphic as it is changed or saved.
The number of potential bugs would increase and so woukd the possible avenues you’d have to explore when something didn’t work.
This is – beleive it or not – was the reason i first look at redhat 5.0 back in those old days … because windows would be doing something and you didn’t know what? and then it would break (because linking of dynamic content in documents is messy) and you had no where to see where it went wrong.
I think the KDE (DCOP, etc) desktop is fine for those that want this sort of functionality. double click on a spreadsheet inserted into a wordprocessor document and it’ll open up the spreadsheet application. ps – are you sure it removed the temp file it worked on while you edited this nameless object?
perghaps gnome/gtk apps can take the simpler philosophy. simpler, lower resources and less headaches.
i came across a MS support web page detailing how users can add a powerpoitn slide to their MS project files. the world has gone mad.
I don’t think we run a risk of having anything THAT integrated for a very very long time, if at all. The talk on the mailing lists is about a more consistent look and feel between the 3 applications. Besides, integrating them like a Adobes CS or Macromedias MX suit would be hard considering that they use 3 different toolkits.
Inkscape — C++ — GTKMM
Gimp — C — GTK+
Scribus — C++ — QT
The “opendoc” container concept just never really took off, although people seem to want to reinvent it periodically.
I must say Scribus is an A1 piece of software, if it had mail merge features it would be worth over AU$ 10 000 as a commercial product.
It’s funny, the only aspect that for me is missing on OSS graphicals apps is their layer of interoperability.
I really believe that the idea behind interoperability boosts productivity. But your concern is more about the buggy implementation done by MS. But what about the example given in the article?? is the Mozilla projet going to suffer the same problems than MS Office?? As many other concerns about MS products, most of time the problem resides in their poor quality on coding and testing. But, even with their problems, developpers recognizes the advantages of integration. Automation of task is often welcome for doing repetitive tasks concerning user-end applications.
I don’t know your every day needs, but for me, that I must prepare very complex scenarios for mathematical simulations, my job starts with an Excel sheet where a big scenario is established, then detailed scenarios (Excel files) are produced. Then every scenario produce the data for C++ programs, every program leaves the data in easily interpretaded data in Matlab. The data is processed by matlab functions to produce images for better interpretation of results. The images are then inserted in a report contained in a Word document. The whole is controlled by an Excel macro and all aps comuninicate each other using ActiveX. It’s not perfect, but oh my, it does the job extremely well.
I would much rather see stuff go into a graphics subdir as I already have hundreds of folders under /usr/share!
i.e.:
/usr/share/graphics/clipart
/usr/share/graphics/gradients
VDX to SVG :
http://sourceforge.net/projects/vdxtosvg/
plus, if anyone is interresting, some preliminary info on former (binary) Visio format (vsd) is available there :
http://www.redferni.uklinux.net/visio/ (i contacted the author, he said he would update it a bit in the next weeks)
I sort of agree with you. However, there are a lot of things that could be made to make GIMP/Inkscape/Scribus nicer to work with together. E.g. see Jimmacs recent comments: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/7746
It would be nice if keyboard shortcuts were the same — for stuff like scrolling, zooming and other common operations. It would be nice if common GUI stuff like color/font/gradient/etc choosers looked and worked the same way. Now that the GIMP is getting color management, it would be nice if it worked well with the color management in Scribus. To some extent I guess code sharing might me meningful, but rather than integration, I think interoperability is more important.
Scribus, like Inkscape, is a relatively recent project and needs to further mature to make a dent on the market.
What? As far as I know Scribus isn’t that new. It’s stable now and I have been using it for two years and I think it’s been around longer than that.
with respect, your “very complex” setup with excel spreadsheet, macros and links to matlab seems intrinsically broken and inefficent.
as a rule of thumb, any scientist who uses spreadsheets (especially excel) should be viewed with suspicion. further, he/she does not have an understanding of efficient computing if they are using excel macros, hot-links to matlab and the such like.
an old mentor of mine had these wise words:
“if its simple, use a calculator, if its complex, code the solution, never use a spreadsheet”.
furthermore, in the scientific computing community, you will find a great thirst for transparency. when things go wrong, and even in terms of risk management, you want the data formats and interchacge formats are both open and accessible.
and this is an important question in the energy and health seatcors for example – what do you do when ActiveX goes wrong – and people lives depend on you getting as much information from the data as quickly as possilble – even from visual inspection? text files are perfect for this.
t
Geez man, that’s an attitude
Before immediately transposing my problems to your limited vision of scientific problems, just read again my statements before jump in.
First. I never wrote that I was using Excel for solving anything, I said that I used it for establishing scenarios. This is easyly done with a spreadsheet. Scenarios is one of the most used aspects of spreadsheet (Excel or whatever). When you have to test coefficents Alpha from value A to value B, with an step deltaAlpha, you just can use an spreadsheet to establish all the constraints, constant data, etc, everything that is needed for your calculations. Then you can write simple code for preparing the N simulations that you want to do. I wrote that a C++ was executed before calling Matlab. Guess what?? This is the program where the real simulation happens (I’m sorry if you coudn’t figure it out). The whole rest (Excel, Matlab, Word) is used to prepare easily the batch of executions and to produce a more readable report of my results.
Second. In several years of C++/Matlab/VBA coding, even if I know that from a design aspect ActiveX has important flaws, ActiveX never have failed for doing this kind of task. I have wrote ActiveX controls in C++, used them in Matlab, and used ActiveSevers in C++/Matlab/VBA with no problem at all. Sorry if you have bad experiences, but you can’t impose them to the rest of the world.
Third: “any scientist who uses spreadsheets (especially excel) should be viewed with suspicion…” That’s is the most stupid assumption that I have read in my scientific life. You have wiped out most of statistical analysys done in thousands of scientific papers during the last 15 years or even more (PLZ, I’m talking about REAL scientific journals such as those from IEEE, ACM, Science, Elsevier, etc, etc, etc). I guess that based on your opinion, the elite of scientific community are morons and you are the guy who has the light of true in his/her hand.
Four: Sorry if your mentor never thought about preparing 20000 simulations or analyzed the correlation between 120 experiments with several variables. I guess that he would write every data in the stack of the calculator and then write a program that do something that in Excel or matlab or anywhere is already written and tested. Go ahead, multiply the chances of doing something wrong.
Five: Go ahead also man for inspecting a text file with some 150 Mb of 3D data (and 150 MB can be ridiculous small for problems such as earth simulations). When you have finished, I think I should be in faculty talking about new approaches for non linear sound propagation, and that for preparing the simulations, they can use an spreadsheet or whatever they considered correct. Non, let me think about it a second time. I think that I won’t say anything about that, I would suppose that they are enough smarts for choosing the right tools.
I must say Scribus is an A1 piece of software, if it had mail merge features it would be worth over AU$ 10 000 as a commercial product.
Look on the Scribus mailing list. I think Craig Ringer wrote a Python script that does mail merge.
What about getting Quanta, Bluefish and Nvu to work with SVG as well as OO.o Draw. It seems like SVG is a great format, for many things, from webpages, to text documents, to vector drawings.
AFAIK mozilla is getting SVG viewers(in beta?) so you could make web pages with them, better and faster than now
Even if this is a stupid pipe dream, exchanging documents between these apps, and importing legacy ones is a great idea.
Also, unifying shortcuts for things like zoooming sounds good too.
Transcode is an open source project used to convert from one video format to another. It works in a very elegant matter. It has 2 types of content plugins and a filter plugin system.
A system like this for still image graphics formats would be great. It works like this:
1) It uses the import plugin to take the data and put it into a standard raw format in memory/disk.
2) It then CAN but doesnt have to, use filter plugins on it.
3) Last it uses the output plugin of your choice to turn its raw data into the format you want.
Like this:
transcode-still -i some.jpg -o some.png
I would think some of the code from the already existing project for video could possibly be used on the still image side, as I know it has the posibility to use still image output plugins it spit out a lot of still images from a video.
An approach like this (be it a commandline tool or a library with these features) would allow anyone to write new plugins for input and output and also filters (such as watermarking filters or branding filters that put your text on the image.)
What? As far as I know Scribus isn’t that new. It’s stable now and I have been using it for two years and I think it’s been around longer than that.
Stable and mature are two different things. Scribus 1.2 is very stable, and its PDF output options and quality are excellent, but its a bit much to expect it to go head-to-head with QuarkXPress or InDesign.
The good news is that development really has been picking up over the last year or so. More people are contributing, and version 2.0 promises to kick ass!
As far as integration goes, I think it would be a good idea for a company like Red Hat or Novell to step in and sponsor a port/fork of Scribus to Gnome. Some really interesting things could be done when Inkscape, the Gimp and Scribus are native Gnome apps.
It seems Bryce have totally missed the point. He focuses on sharing code (and the problems with and effort need for that). That is just something that might help the developers in the long term, but the users don’t care at all if the developers reused or recoded. The users (only) care about the look and feel. “Just” make the apps look/feel the same.
See ImageMagick.
Requirements:
– Unix or Linux or Cygwin on Windows
– ImageMagick
man convert for much much more info
This is how you can convert a jpg to a 16×16 pixel favicon (the small icon that shows up in the URL addrerss bar in the web browser).
$ wget http://www.somewebsite.com/somelogo.jpg
$ convert -sharpen 2×2 somelogo.jpg logo.jpg
$ convert logo.jpg logo.bmp
$ convert -sample 16×16 logo.bmp logo_small.bmp
$ convert logo_small.bmp logo.ico
I can live with UIs that look inconsistent and have some differences in feel. I have to deal with that in Windows and Mac OS; even if I just use apps from one company they aren’t always totally consistent. But when I’m creating documents, having to save files in one app and import them into another is a real pain.
I’ve hardly ever had any trouble with copy and paste between Windows/Mac apps. But it’s still a total mess in Linux, I can never predict what will happen when I try to transfer data between apps. Consistent copy and paste of data between different applications would make me much happier to use Linux for work rather than just for play.
Lately I have been trying to use Inkscape, and I love it. But I would like to know if there is a program (or if Inkscape actually does it) that would make SVG animations in the same way as Macromedia Flash.
You should work in an environment condusive to your work. The way things are not are condusive for my work, which has nothing to do with graphics.
I think you guys are making this more exciting than it is. This is just trying to look and feel the same. Which I could care less about, I can figure out how to use gimp and I know nothing about image work. I can figure out inkscape (very cool program btw).
As long as they do any interprocess communications using compatible means, meaning that I could write a replacement for say The Gimp and make it intercommunicate with inkscape without getting into hacks or way to much work; if they do that, then it’s ok.
Most of the “duh” changes needed are being addressed both internally in the projects themselves and by freedesktop.org
The real benifits from colaboration are in common rendering engines, common color management standards, and a common library for custom widgets.
One of the way to allow a system to leverage the work of others is to use web services (or other types of services) for the functionality which can stand-alone.
For example, for gradients, create http://localhost/services/graphic/GradientManager
to convert back and forth between formats
http://localhost/services/graphic/Convert
Call that server to search/edit/store gradients. Make the XML API stable then you can have multiple implementations in the background. For convert, that service will inform Scribus or whatever app what it accepts as an input and what it can generate as an output. As new formats get added, scribus can automagically support them. No new build, no recompile.
The idea is that the best way for any software to leverage funcationality from another is to seperate itself from the implementation of the other software. WebServices (ran over tcp/ip or http or whatever) allow you to be language and implementation agnostic (C++, C#, perl, python, etc.)
It’s not because a graphical application has a GUI that it can’t leverage a multi-tier approach which can seperate the components inside different services. A service oriented architecture can help more than server applications.
Let me know what you think.
I would try to get the Krita people involved with this, there was talk about redoing parts of the GUI last month and they want to introduce natural paint capabilities to their app. I think they could fit nicely and would probably cooperate.
Take a look here;
http://www.lfp.uba.ar/moreno/TErrores2004/MSExcel/statproc.pdf
You can check the formulas yourself. FWIW: I use Excel myself.
I always wanted to see a shared datatypes system that I originally saw on AmigaOS. BeOS apparently had an improved version of the same idea.
Of course given current requirements I believe the datatypes system was far too limited. Currently we’d require vector import/export as well as bitmap import/export for images alone. Sound, video, animation, documents etc. would a whole other ballgame.
The big advantage was that there was only one library for import/export and pluggable modules did the rest. Add a new module and potentially all relevant applications could use the supported formats.
The big downside was that the internals of these systems was never ideal when exporting various formats. There was rarely enough control over the conversion processes for serious productivity apps producing high quality output. However I never used BeOS enough to see where they had taken the idea.
There are probably several libraries that do part of this already. However the pluggble nature of datatypes at runtime was the key benefit.
One of the ideas that MRDOCS (Peter Linnell from SCRIBUS) and myself have bounced around is developing an Open Color Standards as part of this group of graphics/creative applications. If anyone is interested, hop onto the open clip art list and help us push that one.
Pantone has a complete monopoly over professional color. Everything you are wearing from commercial shops is matched to Pantones. It is really crazy!
Please join Open Clip Art Library and help us change some things…
I don’t think Bryce meant for this to be an exclusive party for Inkscape, Scribus, and Gimp. John Lein, you should make contact with the Inkscape mailing list to discuss this further. We have also been thinking about trying to move this discussion to a neutral space like freedesktop.org. I personally would like to see this happen and also create a planet RSS aggregation of creative application developers in OSS. You may also contact us through the Open Clip Art Library list. Thanks!
This is a topic that has been long overlooked. The author only discusses the problem with 3 apps and getting these apps to work together in a way that Adobe’s and Macromedias creativity suites accomplish that. In that the author is wrong. You have 3 projects being done by 3 entirely different groups. That is just not going to work. The best thing is to fork each of these 3 apps(Gimp, Inkscape, and Scribus) into 3 new apps that are apart of the new integrated Creativity suite. The next problem is that we are really 3 apps short of a true Web and Print Creativity suite.
You need the following;
Image Manipulation(raster-based)
Illustration(vector-based)
Print Publishing
Web Publishing
Web Graphics
Animation
As of now the first 3 apps listed are out and ready to be forked, the 4th one(Web Publishing) is incomplete since there is no really good WYSIWYG based app out there(NVU fall short in many ways). Forking Bluefish and adding a WYSIWYG interface may work thou. As for a Web Graphics app and a Animation app (i.e. apps based on Fireworks and Flash) there is nothing out there to my knowledge in Open Source.
If a truly integrated suite is to exist it needs to be cared for by 1 development group (use OpenOffice as a sample model), using 1 DevKit(say GTK), 1 language(say C++), plus a unified/fully integrated interface and module system. Then let the suite of applications compete side by side against less integrated existing apps and let the end user decide what they want to use.
A Integrated project like this however would not work without a corperate sponser(like Sun is to OpenOffice)
As a professional graphic and web designer who uses Adobe products every day, I have been stopped cold every time I’ve tried to use Gimp and other Open Source graphics tools by the complete incompatibility of keyboard shortcuts.
Suggestion: Look the key commands that Photoshop and Illustrator use for zoom in, switching tools, dragging, etc. Offer a compatability mode (by default?) that would allow a designer to be able to consider switching. Make it easy and consistent and I believe you will be able to switch experienced users much more easily.
I don’t understand why everything should be pprted to Gnome? What’s wrong with Scribus as a Qt application? Rather, Inkscape and Gimp should be ported to use Qt and the KDE libs, as these give you so much more of the apparently needed interoperability. Please, keep the fanboy stuff out of this discussion…
Sounds like a wonderful idea as long as it isn’t too limiting.
There was a project called “ScaVeGra Animator”, that the purpose was to become a kind of Macromedia Flash (but in the Open Source way). Now, this project is lost I think… I know there’s an “Inkview” interface for Inkscape.
Do you know if we can dream about a “Free Open Source Flash”
(an equivalent), for the future? 😉
I use Gimp, Scribus and Inkscape for the comics newspaper Hybride that includes Free Sories.
http://ldreammachine.free.fr
http://www.socallinuxexpo.org/speakers/speakers_gould.php“>Ted (Inkscape Developer) will be speaking at http://www.socallinuxexpo.org“>SCALE about SVG and how it can be used to tie together graphics on the open-source desktop. If you’re in LA this weekend (Feb 12-13) come check it out! Use the promo code “FREE” for a free expo pass or “NEWSP” for a discount on a full access pass.
For those needing to convert raster images to SVG:
http://delineate.sourceforge.net
Delineate is a tool for converting raster images to SVG using AutoTrace or potrace. It loads images using JIU and displays results using Batik. Input formats are JPEG, PNG, GIF, BMP, TIFF, PNM, PBM, PGM, PPM, IFF, PCD, PSD, RAS.
Dbus is a option to comunicate the apps.