In revision 9288 I fixed the inverted coordinate system bug, starting
from a patch by Thomas Holder.
While this is a rather invasive change, fixing bugs caused by removing
the coordinate inversion is simple (often it boils down to tweaking a
single line of code), so I think we'll manage to fix any remaining
regressions before the release.
Oh dear, I really am no good at mailing lists. I accidentally emailed this to
Krzysztof instead of the mailing list. Sorry!
On 06 April 2010 at 17:49 "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
> 2010/4/5 sjatkins@...2336... <sjatkins@...2336...>:
> > Then, develop a command-line app that will actually do the conversion. I'll
> > be
> > using C++. I haven't decided on an XML library yet - any suggestions?
> You should use libxml2 and libxslt - that's what Inkscape uses.
> However, it might be better to write an internal extension rather than
> a separate command line application. Look at src/extension/internal/.
> You can also consider using XSLT.
Thanks, that's really helpful - I wasn't sure where in the codebase to look.
Making it an internal extension does sound much better than an external
application. I'm not very familiar with XSLT, and it's probably better to stick
with C++ as I know it better.
> > Once the command-line program is working, I'll start on giving it a GUI. I
> > can't
> > seem to find anything about what UI library Inkscape itself uses - can
> > anybody
> > tell me?
> It uses GTK+ and gtkmm. Again, look at existing input extensions - the
> extension system should satisfy your GUI needs. You just put the
> parameters you need in an .inx file and the GUI is created
> Regards, Krzysztof
I think I might not need to add a GUI if I do this as a extension, but if I do
I'll use the extension system like you suggest.
I'm interested in applying to create an KML - SVG converter. KML and SVG are
similar enough that it makes sense for there to be a way to convert from one to
My plan would be:
>From now until the end of week 1 or 2: Study both formats and work-out the
equivalents between KML and SVG. I know there are features of KML - namely,
placemark descriptions, which will not convert directly to SVG. There are
probably other features too. I'll try to deal with these in any time I have
remaining at the end. I'll also need to work out a way to convert the
coordinates systems, and deal with sizing the image - using the KML coordinates,
the image would be very small, in a very large document.
Then, develop a command-line app that will actually do the conversion. I'll be
using C++. I haven't decided on an XML library yet - any suggestions?
* Plan the structure of the program.
* Focussing first on KML -> SVG, gradually add tags to convert, and check they
* Once KML -> SVG works, add SVG -> KML. Should be a case of reversing the
existing conversion functions.
* Write some usage documentation.
Once the command-line program is working, I'll start on giving it a GUI. I can't
seem to find anything about what UI library Inkscape itself uses - can anybody
tell me? It would be better to use the same one, to make maintenance easier. The
GUI will send commands to the command-line program, to keep the two separate,
and so that Inkscape itself can use the command-line one at some point if
* Design the UI.
* Implement it.
* Write some user documentation.
* A command line program that can convert SVG to KML, and back, successfully.
* (Probably) A GUI to go with the command-line program.
If I get time:
* Allow importing/exporting as KML from within Inkscape.
* Find ways of handling 'placemark' KML elements, and any others that do not
convert easily to SVG, so that a user can convert to SVG, edit, and convert
back, without losing anything. Possibly by including hidden elements in the SVG,
or using comments.
Is this a decent plan? Is there anything I've missed?
I am new to Inkscape, but have been involved in some open source projects (mainly Java-ish stuff).
I downloaded the latest Windows release and tried it out. I am wondering if this is a known issue, since it is so badly broken. (Inkscape April 3 drop, Windows Vista)
I am trying to use a Wacom Bamboo tablet. Inkscape looks like it recognizes the tablet, but I can't seem to get it to work with the caligraphy tool. My tablet works with 0.47, after some fiddling.
Additionally, there are two GUIs for setting up input hardware now. The old one looks like 0.47, and the new one looks very cool, but for the life of me I can't figure out how to make it work. And keep in mind, it could be user error - I am new to Inkscape. But I am thinking that a Wacom Bamboo tablet should "just work" with a drawing application...
Sooooo... are the hardware input dialogs still "in-work"? If not, I'll be happy to provide details and screen shots. I just don't want to clutter your bug tracking system before checking.
I'm a third year electrical engineering student at National University of
Singapore looking forward to participate in Google summer of code 2010. I
noticed that Inkscape was accepted as a mentoring organization. After
looking at the project ideas, I decided to go ahead with the exercise.
I downloaded Bazaar for windows, as my laptop supports only Windows OS. I
have gone through the basic bazaar tutorial. I would like to know what else
is expected out of a typical applicant. Kindly help out,
Thanks a lot,
I'm using Inkscape in a new business I am working on, and I have discovered
some blocking-features that are missing (at least, I have not found them in
the 0.47 version of Inkscape:
- Vertical alignment property for a text block, so text can be shown at
the top, the bottom, or centered.
- Kerning adjustment for texts.
- Tracking adjustment for texts.
- Word-spacing adjustment for texts.
My new project really need these features from Inkscape, so we'd like to
provide funds for the project so they can be included as soon as possible.
As we are currently in the process of getting funds from investors, I'd like
to know what would be the approximated budget for implementing these
features, and how log it would take (approximately).
Thank you very much for your kind support, and for creating Inkscape.
David Marín Carreño
Please do not forget to update the Release Notes as PART of your adding
or changing features process...
Krzysztof, Coordinates change needs to be added.
Jon, Glyph dialog needs to be added.
Can anyone else think of other items that still haven't been added?
On Apr 3, 2010, at 11:29 AM, Jon Cruz wrote:
> Now, it is true that these meta components are dependent on an SPDesktop. However, they do not need to depend on "fetch the desktop pointed to by the global variable held in a known location". Instead it is easy to apply dependency injection (though we probably want to stick with manual instead of framework driven). The *KEY* yet subtle difference here is in changing things away from "a dialog reaching out and grabbing the global pointer desktop" to instead have "a dialog uses the desktop that is handed to it"
> Now, I should probably point out that we are *very* close to having those. That is, with just a bit of refactoring we can reach successful dependency injection on the dialogs and panels.
There is an update on this point. In cleaning up the Fill & Stroke dialog so I could get rid of the copy-n-paste extra class (along with the plethora of rogue tile bug pattern occurrences) I was able to convert it to be properly dynamic and work nicely no matter if it were floating or docked, single or multiple. (This happened to also fix bug #270623 ""Fill and Stroke" panel is mirrored between open windows")
I now have that tracking extracted into a stand-alone class, and have already reused it in a different panel. That new code is at
Aside from fixing the immediately visible problems such as bug #270623, other improvements also happened as a consequence of the change. One of these is that prior to this a change in one view of one document would cause a cascade of event processing in all other dialogs for all views in all documents. Things had been all wiring themselves to the global inkscape application instance and listening for changes there. After switching to the new DesktopTracker the updated dialogs only are invoked when their specific desktop has a change (in selection, pertinent contents, document reload, etc).
And of course there is the added benefit of getting things a little more multithreading friendly. That will be good too.
So far I've not gone out to switch all of our dialogs over to this paradigm. Krzysztof expressed proper concern that we might expose some latent bugs in the process of switching. Since we are very close to 0.48, we should probably only change code that is actively being worked on, so we touch only things that we are looking at and are observing the behavior of.
Oh, and if anyone does happen to be working in any code that happens to use SP_ACTIVE_DESKTOP or SP_ACTIVE_DOCUMENT, one minor tweak with a lot of benefit would be to make sure those are only used at the top of a function and are stored to a local variable. Then the function can work against that local variable and gain a bit of safety. And that will make a latter pass to switch things cleaner that much easier.