GSOC: Cross platform WMF and EMF IO and other ideas
I have several ideas for GSOC 2009. I'll present all of them here.
Idea 1 is about improving Inkscape's data interoperability. This means being able to paste parts of drawings from Inkscape directly into OpenOffice.org and MS Word and the other way around. This would involve writing a cross platform WMF and EMF output extension (our current EMF extension is Windows only). This could be accomplished by using libwmf, but this project seems to be abandoned since 2002. Another option is to use some code from OpenOffice.org. Recently (2006), MS published a full specification of those formats, so writing a new library to read and write them isn't out of the question.
Idea 2 is has a similar goal to Idea 1 and it is to revamp the I/O extension system. This would involve unifying the code paths for open/save, export/import, clipboard, drag and drop, and create bitmap copy; unifying command line parameters for export (e.g. all extensions would accept --export-id); converting all extensions to load/save using GIO streams; and redesigning the Export dialog to allow exporting in any supported format.
Idea 3 is to refactor the tools code, so that each tool is a separate object, and the number of files that list all tools is reduced to a minimum. This would get rid of toolbox.cpp, as well as greatly simplify the writing of new tools.
Idea 4 is to replace Verbs with subclasses of Gtk::Action, with only one class per action (instead of one Verb class per several verbs). There would be a separate action group per document, and an additional one for global actions. Actions could be registered dynamically at startup.
Which idea, when implemented, would be the most beneficial to Inkscape?
Regards, Krzysztof Kosiński
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
I have several ideas for GSOC 2009. I'll present all of them here.
Is there any chance that you'd be open to suggestions outside of what you had listed? If so, I would recommend proposing to make Inkscape capable of editing more than one path at a time with the Node Tool. According to bulia byak, it will require a significant re-factoring of our path handling code to accomplish this. And as non-glamorous as it may seem, this one thing alone will open the doors to all kinds of new possibilities in the UI beyond the obvious.
Cheers, Josh
Joshua A. Andler-2 wrote:
Is there any chance that you'd be open to suggestions outside of what you had listed? If so, I would recommend proposing to make Inkscape capable of editing more than one path at a time with the Node Tool. According to bulia byak, it will require a significant re-factoring of our path handling code to accomplish this. And as non-glamorous as it may seem, this one thing alone will open the doors to all kinds of new possibilities in the UI beyond the obvious.
Of course I'm open to suggestions :) I can take this project, but I need more information about what should be done, and where to start (e.g. which files contain the relevant code). This is only mentioned as "multiple-path editing support".
@ Alexandre: I think UniConvertor doesn't have EMF support. It's not listed on their web page at least. WMF is a 16-bit format and not used much by modern software - it uses EMF instead.
Regards, Krzysztof Kosiński
2009/3/29 Krzysztof Kosiński wrote:
@ Alexandre: I think UniConvertor doesn't have EMF support.
This is why I wrote "work _on_ UniConvertor" :)
In fact there is some code to start from, but it's not inside UC codebase at the moment.
Alexandre
On Sat, 2009-03-28 at 17:57 -0700, Krzysztof Kosiński wrote:
Joshua A. Andler-2 wrote:
Is there any chance that you'd be open to suggestions outside of what you had listed? If so, I would recommend proposing to make Inkscape capable of editing more than one path at a time with the Node Tool. According to bulia byak, it will require a significant re-factoring of our path handling code to accomplish this. And as non-glamorous as it may seem, this one thing alone will open the doors to all kinds of new possibilities in the UI beyond the obvious.
Of course I'm open to suggestions :) I can take this project, but I need more information about what should be done, and where to start (e.g. which files contain the relevant code). This is only mentioned as "multiple-path editing support".
We can definitely provide more info and what you need. I know that bulia byak has a good idea of what all needs to be done. So... bulia, I CC'd you, want to chime in? ;)
Additionally, Krzysztof, can we get you to come join us in Jabber or IRC sometime? It seems like the discussions about SoC (and development in general) can be quite fruitful when more interactive. :)
Cheers, Josh
Joshua A. Andler-2 wrote:
Additionally, Krzysztof, can we get you to come join us in Jabber or IRC sometime? It seems like the discussions about SoC (and development in general) can be quite fruitful when more interactive. :)
Cheers, Josh
OK, I figured out Jabber so I'll try to show up there.
Regards, Krzysztof Kosiński
2009/3/29 Krzysztof Kosiński wrote:
I have several ideas for GSOC 2009. I'll present all of them here.
Idea 1 is about improving Inkscape's data interoperability. This means being able to paste parts of drawings from Inkscape directly into OpenOffice.org and MS Word and the other way around. This would involve writing a cross platform WMF and EMF output extension (our current EMF extension is Windows only). This could be accomplished by using libwmf, but this project seems to be abandoned since 2002. Another option is to use some code from OpenOffice.org. Recently (2006), MS published a full specification of those formats, so writing a new library to read and write them isn't out of the question.
The right option would be to work on UniConvertor
Alexandre
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
Idea 1 is about improving Inkscape's data interoperability. This means being able to paste parts of drawings from Inkscape directly into OpenOffice.org and MS Word and the other way around. This would involve writing a cross platform WMF and EMF output extension (our current EMF extension is Windows only). This could be accomplished by using libwmf, but this project seems to be abandoned since 2002. Another option is to use some code from OpenOffice.org. Recently (2006), MS published a full specification of those formats, so writing a new library to read and write them isn't out of the question.
Ok. For this one, first and foremost you need to ascertain what the possibilities and best choices actually are. Don't just guess.
Check to see
1) what data flavors does MS Office offer 2) what data flavors does MS Office accept 3) what data flavors does OpenOffice offer 4) what data flavors does OpenOffice accept 5) what data flavors does GTK+ offer 6) what data flavors does GTK+ accept
In the past, #5 and #6 have been blockers. If they don't allow something, then adding support in an application won't help.
There is a utility you can use for some debugging of that: http://sourceforge.net/projects/dragndrop/
Oh, and as to MS publishing a spec... historically that hasn't really helped with the actual implementation of code.
2009/3/29 Jon A. Cruz wrote:
Ok. For this one, first and foremost you need to ascertain what the possibilities and best choices actually are. Don't just guess.
Check to see
- what data flavors does MS Office offer
- what data flavors does MS Office accept
- what data flavors does OpenOffice offer
- what data flavors does OpenOffice accept
- what data flavors does GTK+ offer
- what data flavors does GTK+ accept
In the past, #5 and #6 have been blockers. If they don't allow something, then adding support in an application won't help.
There is a utility you can use for some debugging of that: http://sourceforge.net/projects/dragndrop/
Oh, and as to MS publishing a spec... historically that hasn't really helped with the actual implementation of code.
And to get an idea what one would be dealing with, it's worth reading http://sk1project.org/modules.php?name=Report
Alexandre
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
Idea 2 is has a similar goal to Idea 1 and it is to revamp the I/O extension system. This would involve unifying the code paths for open/save, export/import, clipboard, drag and drop, and create bitmap copy; unifying command line parameters for export (e.g. all extensions would accept --export-id); converting all extensions to load/save using GIO streams; and redesigning the Export dialog to allow exporting in any supported format.
I'm not seeing where changing the I/O system will do any of that.
*Other* work will do the unification.
Currently the Export dialog can export anything. It does not need a new I/O system to do that.
Instead of changing the I/O system, a far more productive approach would be to replace string use with a proper IRI reference class.
Oh, and clipboard and drag-n-drop already use the extension mechanism.
I'm not seeing where changing the I/O system will do any of that. Currently nearly all export options are handled using extension parameters, whereas most of them can be handled in a generic way by modifying the SVG that is passed to the extension before saving. The second item of that could be made orders of magnitude easier with some changes to the IO extension system.
Currently the Export dialog can export anything. It does not need a new I/O system to do that.
The Export dialog can only save PNGs, unless something has dramatically changed since I last looked at it. The Save dialog can save anything, but it doesn't have the options present in the Export dialog, like limiting the exported area.
Oh, and clipboard and drag-n-drop already use the extension mechanism.
The clipboard does, but it's fragile, and it requires saving to temporary files which is clearly suboptimal. That's because the extensions receive filenames instead of streams to save to or read from. Drag and drop uses an entirely different code path in interface.cpp.
By the way, I was just asking which idea would be the best, rather than which would be the worst :)
Regards, Krzysztof Kosiński
Response interspaced
On Sat, 2009-03-28 at 19:44 -0700, Krzysztof Kosiński wrote:
I'm not seeing where changing the I/O system will do any of that. Currently nearly all export options are handled using extension parameters, whereas most of them can be handled in a generic way by modifying the SVG that is passed to the extension before saving. The second item of that could be made orders of magnitude easier with some changes to the IO extension system.
Well... your initial message seemed to make the claim about changing the I/O system to gain things. I believe I agree with you that changing the I/O system will not really do any of that in and of itself.
Currently the Export dialog can export anything. It does not need a new
I/O system to do that.
The Export dialog can only save PNGs, unless something has dramatically changed since I last looked at it. The Save dialog can save anything, but it doesn't have the options present in the Export dialog, like limiting the exported area.
Sorry. There was a bit of English sematic hair-splitting there. I was not saying that the export dialog currently *does* export all types. Just that all the pieces are that that would allow one to do so.
My intent on that point was to emphasize that existing code can be used by the export dialog pretty much as-is. Therefore no new code for just that needs to be done.
What had gone more is that there was design intent to only "export" bitmap and to leave other things separate. That is, there are not limitations in the code base but in the UI designer selecting how to present things.
Oh, and clipboard and drag-n-drop already use the extension mechanism.
The clipboard does, but it's fragile, and it requires saving to temporary files which is clearly suboptimal. That's because the extensions receive filenames instead of streams to save to or read from. Drag and drop uses an entirely different code path in interface.cpp.
There are a few different factors here. One is the use of filenames themselves. At the moment that is due to running items in external processes and using stdout to get results. That makes for a very robust and extensible system, but does place certain limitations on non-ASCII data. (not that it means it can't be done, just that extra care has to be taken in doing so)
To change that, all we need to do is add a simple stdout catcher (adapter pattern) in place of passing the explicit filename. That's a very minor change that would allow for non-file conversion. If one were to switch to GIO on the other hand, the exact same code would be needed and *then* addition GIO conversion would have to be done as a separate additional step.
By the way, I was just asking which idea would be the best, rather than which would be the worst :)
Yes, I know. However to be able to evaluate ideas for the code, it is important to know what factors might be involved. Knowing what to look at can help show which tasks might take what amount of effort, etc.
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
Idea 3 is to refactor the tools code, so that each tool is a separate object, and the number of files that list all tools is reduced to a minimum. This would get rid of toolbox.cpp, as well as greatly simplify the writing of new tools.
The tools are more of separate objects now.
A proper splitting would not really get rid of toolbox.cpp, but instead create a new toolbox.cpp *per* tool.
However, we still will need toolbox.cpp to load up the defined ones from the XML definition and assemble the actual UI presentation.
But, yes, splitting each tool to a functional code unit and a UI code unit could simplify creation and addition of them.
On Sun, 2009-03-29 at 04:30 +0300, Alexandre Prokoudine wrote:
2009/3/29 Jon A. Cruz wrote:
But, yes, splitting each tool to a functional code unit and a UI code unit could simplify creation and addition of them.
What I'm inevitably thinking about is making it possible to create pluggable 3rd party tools.
Alexandre
Ah, yes.
However... what was planned from the beginning is that the extensions API would be expanded to allow for that.
So any work in this direction should be sure to include those. Live DOM is part of what is needed for externalizing tools.
Jon A. Cruz wrote:
A proper splitting would not really get rid of toolbox.cpp, but instead create a new toolbox.cpp *per* tool.
That's kind of the whole point, to have this code neatly separated :)
However, we still will need toolbox.cpp to load up the defined ones from the XML definition and assemble the actual UI presentation. But, yes, splitting each tool to a functional code unit and a UI code unit could simplify creation and addition of them.
The way I intend to do this, toolbox.cpp is in fact not necessary. The design idea I mentioned in an earlier post about actions ("static plugin") can be also applied to tools, so that there are no centralized files which list all tools that must be initialized. It would also potentially allow extensions to define new tools.
Regards, Krzysztof Kosiński
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
Idea 4 is to replace Verbs with subclasses of Gtk::Action, with only one class per action (instead of one Verb class per several verbs). There would be a separate action group per document, and an additional one for global actions. Actions could be registered dynamically at startup.
This has come up several times in the past. For approaching this task one should go through the dev mailing archives and collect up the various issues raised there.
The one-to-one of one Gtk::Action per will work in some cases, but breaks down in others. So forcing one-to-one will complicate implementation of many of them.
Also Gtk::Action is a very UI-centric class. We need something abstract that can represent an action on 1) a document 2) a desktop 3) the "Application" itself.
the case of #2 can be replaced by Gtk::Action appropriately, but the others don't really match conceptually.
Jon A. Cruz wrote:
The one-to-one of one Gtk::Action per will work in some cases, but breaks down in others. So forcing one-to-one will complicate implementation of many of them.
Also Gtk::Action is a very UI-centric class. We need something abstract that can represent an action on
- a document
- a desktop
- the "Application" itself.
the case of #2 can be replaced by Gtk::Action appropriately, but the others don't really match conceptually.
I followed some of that discussion. The main idea is to use one action group per document. For case #3, we use a separate global action group that does not act on any document but rather on the entire application.
I don't really understand the distinction between #1 and #2.
Regards, Krzysztof Kosiński
On Sat, 2009-03-28 at 17:19 -0700, Krzysztof Kosiński wrote:
Idea 1 is about improving Inkscape's data interoperability. This means being able to paste parts of drawings from Inkscape directly into OpenOffice.org and MS Word and the other way around. This would involve writing a cross platform WMF and EMF output extension (our current EMF extension is Windows only). This could be accomplished by using libwmf, but this project seems to be abandoned since 2002. Another option is to use some code from OpenOffice.org. Recently (2006), MS published a full specification of those formats, so writing a new library to read and write them isn't out of the question.
I think writing a new library is never a good idea. Patching theirs to make it better is probably more reasonable. I believe that Abiword and other use it also, so making it better helps a lot more projects than Inskcape. Making a new library for Inkscape only helps us.
--Ted
participants (5)
-
Alexandre Prokoudine -
Jon A. Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Ted Gould