- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] DXF import
by Bryce Harrington 10 Apr '05

10 Apr '05

On Sat, Apr 09, 2005 at 06:40:15AM -0500, aaron@...749... wrote: > Jon A. Cruz wrote: > >One thing I was thinking, when I saw the first messages on this thread, > >was that even if there are some other DXF converters we might want to do > >our own anyway, since there might be higher-level semantics we could > >preserve differently, or might map into Inkscape-specific extensions. > >Thinking of some of the things wanted like diagramming, connectors, etc. > > Two links that I saw a while back that might be of interest: > http://www.ribbonsoft.com/dxflib.html Mmm, good find. That's exactly the type of thing needed. I downloaded the code and browsed through it. It looks like to create a dxf2svg converter one would need to do this: Create a sub-class of DL_CreationInterface called something like SvgCreator. SvgCreator's job would be to build up a tree of SVG elements from the DXF data as parsed by this library. To do this, in SvgCreator implement all of the virtual methods in DL_CreationInterface - addCircle(), addLine(), addKnot(), etc. Each of these routines would need to create the corresponding SVG element. I.e., in addCircle(DL_CircleData), you'd convert the contents of the DL_CircleData structure into SVG data and add it to your SVG tree. The next question is, how do you build the SVG tree? This is basically just a data structure to contain XML data, so you could probably use some existing XML library to do it. There is also some SVG-specific code out there you could look at reusing, such as Cairo, librsvg, or even Inkscape itself, in the src/xml directory. (Anyone have a suggestion for which lib would be best to use?) Finally, given the built-up tree, you need code to write it out to an SVG file. Presumably, whatever code you've selected for building the XML tree will include some sort of writer function, so in theory you can just call that, and you're done. :-) So to recap, this looks pretty straightforward. To code it you'll need to be moderately comfortable with C++. You'll need to create one class, and hook two libraries together. You'll need to create a makefile for it, and set up the usual packaging stuff too, but this is all pretty straightforward. I think this'd be a 2-weekend project for someone with good C++ skills, and perhaps thrice that (but an excellent learning project) for a C++ newbie. Anyway, wish I had time to do more than just give advice, but I hope this helps. This looks totally do-able, it just needs a bit of coding time. It'd sure be handy, and I bet it'd get used pretty widely. Bryce

2 1

Gtkmmification status
by Bryce Harrington 10 Apr '05

10 Apr '05

Several people have taken interest in how the Gtkmm work is coming along, particularly in where they could help move it forward. The Gtkmm conversion is required for the 0.42 release, so it's got the high priority currently. We've got a ton of cool features besides gtkmm already in the can, so we have strong incentives to getting gtkmm done. We really don't want to bump the gtkmm work to next release; we've already bumped it for the past three releases, plus we have a bunch of other highly requested features (like the layer dialog) that are dependent on the gtkmm work being in place. Good progress has been made so far, but as you can imagine, reimplementing the Inkscape interface is not a trivial task! We've got most of the bones in place, but there's a lot of flesh to be hung. We had started from the point of Gtkmmifying dialogs. We've made good progress in this area, and have converted most of the simpler dialogs. There's a few challenges still left, such as figuring out how to do TreeView-based dialogs like the XML Editor and the much-anticipated Layer Dialog, however for the most part I think we've got a good framework in place so it'll just be the effort needed to do the conversions. There's still a lot of TODO's in the code for doing things like hooking up preferences, gaining some better abstractions, etc. Jon Philips has been plugging away at some of these items. Converting dialogs to Gtkmm is pretty straightforward. You choose the dialog you want to convert, create a new class derived from Inkscape::UI::Dialog, and go through the old dialog code, migrating function calls over. You look at the manual on gtkmm.org to learn what the C++ versions of the gtk calls are. Usually you can eliminate a lot of unnecessary code in the process (gtkmm is more concise, and the Dialog class takes care of a lot of the basics for you). Meanwhile, Jon Cruz has been experimenting with a cool new idea that abstracts the contents of dialogs into "Panels" that could either be presented in dialogs or embedded in the GUI frame itself. I think this adds flexibility that many users may find quite helpful; it should be possible for someone to adapt the Gtkmm dialog architecture to this without too much trouble. Jizzbug has done a bang-up job of Gtkmmifying all the toolbar and menu stuff. The Gtkmm interface now at least *looks* like the current interface. There's still some optimizations and tweaks needed - button sizes aren't quite right, for example, and we probably need to update the toolbars and menus with recent changes to the main codebase, but these are bite-sized tasks that seem very appropriate for new Gtkmm developers so I'm not worrying about them for now. There's still a lot of chunks of the UI that haven't even been started yet, such as the statusbar and rt-click context menu. They're of medium priority, so I'm not worried about them yet, but they'll definitely have to be tackled before we can make the new UI the default. The highest priority right now is getting the Canvas hooked up. This will be a major milestone to achieve since it'll finally let us *see* SVG documents inside the new interface. With that in place, the work of hooking up toolbars, menu items, dialogs, etc. can finally get under way in full earnest. It looks to me like the path to achieving this is to C++-ify SPView and SPSVGView more, then reimplement SPDesktop and SPDesktopWidget in Gtkmm. This is what I'm focusing on myself right now. Last night I created some C++ member function wrappers for the sp_view* routines, and intend to continue this work through the weekend. Converting SPDesktop will be a sizeable project, but I'm hopeful within a week or so I'll have it in working order, if not completely done. I'm really looking forward to having the Gtkmm work available for us to use in the main interface. Beyond just making the ui code a lot easier to work with, it's bringing in some rather cool innovations we will be able to take advantage of. It will eliminate a ton of quirks in the current UI. It will give users much more flexibility in how the UI is laid out. It will enable us to do some much more sophisticated UI designs, and give Inkscape the advanced UI capabilities that other leading edge GNOME applications have today. :-) As you can see, there's a lot of areas where work can be done in parallel. There's still a lot of blank-page type areas for pure creativity, other areas that mostly work now but need good problem solvers to perfect, and plenty of bulk-work places where C++/gtkmm novices can have a big impact while they learn. I would strongly urge anyone that has some time in the coming months, a little C++ skill, and an interest in pushing Inkscape forward, to think about joining in on the Gtkmm effort. Contact me and let me know what you're interested in, and I'll help you get going. :-) Bryce

1 0

Re: [Inkscape-devel] DXF import
by Bryce Harrington 10 Apr '05

10 Apr '05

On Sat, Apr 09, 2005 at 10:50:36AM +0200, Tobias Jakobs wrote: > Am Freitag, den 08.04.2005, 17:34 -0700 schrieb Bryce Harrington: > > > Anyway, I would imagine that for the DXF module in OO, the situation > > would be similar, however it may be well worth doublechecking. > > Basically, what you'd need to do is dig into the OpenOffice codebase and > > locate the chunk of code that handles DXF, and figure out how much work > > it'd be to extract it. Then, of course, you'd need to find some way to > > turn that into SVG; since OO doesn't yet have SVG export, that'd > > probably be a show-stopper, but who knows. > > > My OO.o has SVG export, or did you mean import? Sorry, I meant "a stand-alone SVG export functionality". Bryce

1 0

Re: [Clipart] developing an xml schema standard for packaged multimedia
by Bryce Harrington 10 Apr '05

10 Apr '05

On Tue, Apr 05, 2005 at 01:48:18PM -0400, Nathan Eady wrote: > Mike Traum wrote: > >I think an xml schema should be developed for a bundle of multimedia > >files. There may be one already, but in my brief search I was not > >able to come up with anything. > > Maybe I'm just old-fashioned, but I would think that an archive format, > such as PKWare ZIP format, would make more sense than XML for a bundle > of files. Even OpenOffice, which uses XML extensively, uses ZIP for > packaging up groups of related files together. Seems to work very > well. Java and Mozilla also use the ZIP format for similar purposes > (jar and xpi, respectively). Johan Ceuppens created a jar-based format for contining multiple SVG files about a year ago for Inkscape. See inkscape/src/inkjar/ for details. It would be nice to build atop that effort. It did not include a metadata format IIRC but it does handle the storage/compression/CRC parts. It was originally created to enable packaging of SVG presentations. In fact, inkview includes support for browsing these files (inkview mypackage.jar). Bryce

1 0

Donation System Proposal
by Bryce Harrington 10 Apr '05

10 Apr '05

Hi all, The other day we received another donation to Inkscape ($10, less SourceForge and PayPal fees). :-) For about a year we've talked on and off about donations for Inkscape. The major question is not getting the money, but deciding how to apply the money appropriately. Of course, we've had no shortage of ideas... From bug bounties/contracts, to hardware, to developer support, to sponsoring attendance at conferences. I like all the ideas, although some would be more feasible than others. However, the one idea I think I like the best, to start with, is to fund contract work to enhance file import/export converters. I.e., accumulate enough funding to pay a developer to augment an existing xyz2svg tool for use with Inkscape. Here is my reasoning for this proposal: 1. These extensions are distinct from the main Inkscape codebase, thus eliminating a range of potential conflicts of interests, learning curve issues, and so forth. 2. Users *definitely* want to see the file converters improved. This is often a crucially important need for them, and they will see the benefits of the improvements immediately. 3. File converters haven't tended to attract attention from many developers. Maybe they're not considered 'sexy' enough? Using money as a motivator is worth a shot. 4. These converters will have definite value beyond Inkscape. A lot of programs out there are starting to gain SVG support. If we are able to gain good xyz2svg converters, this could benefit them as well, plus would help build the reputation of SVG as a good format for interoperability, which helps all of us out a lot. 5. I emphasize focus on enhancing _existing_ tools over creating new ones for several reasons. First, the work of creating a basic tool that does the first 80% of the conversion is usually not too hard and actually kind of fun; the hard part is getting that last 20%, and that's where I think funding development will be most effective. Also, it can be harder to track progress for development of a tool being written from scratch. 6. We can allow users to contribute to the specific converter they wish to support; i.e., we establish one pool for the AI extension, another for DXF, another for VSD, etc. and allow people to choose which one their donations will go to. Here are the challenges I see for this proposal, and how we'd be able to deal with them: a. Funds collection/distribution: If we get a large number of donations, there may be an administrative overhead to keep track of them. I'll set up an account that allows us to accumulate the funds via SourceForge, and for now I'll just handle the accounting manually. If it becomes burdensome, myself or someone can script it up better. b. Donation fees: Currently, SF and Paypal impose fees for donations. A $10 donation works out to be $8.48. It'd be nice to preserve a larger proportion, but beggers can't be choosers. If someone less lazy than me wants to set up something better, let me know. c. Deciding the contract terms. This is the point I'm not sure about, but clearly we need to have some way of establishing the minimum goals for the funding. I'm open to suggestions, but sure we can figure something out; contracting developers is nothing particularly new. d. Deciding who is allowed to bid on the work. I'm concerned about random people bidding on the work, and also think that the spirit of the donations is to also help further Inkscape development in general. Thus I would be tempted to limit participation to people who have a track record of doing development work for Inkscape. These people will be "known quantities", and will have a stake in doing a good job. e. Deciding when to close donations and open bidding. In other words, how do we decide how much money to raise? It's often difficult to determine how much time it'd take to implement a feature. My thought is to leave this open ended - we simply post what the expectations are and how much $$ has been collected, and when a developer feels enough has been raised, he submits a bid to do the work. This way, "the market" is left to decide what the rate should be. f. Deciding what file converter features to allow donating to. My feeling is that we should just leave this open to the donors. Any donation target that someone puts money against is worth adding to the list. g. Legal/contractual paperwork and such. I'm blissfully clueless here. Maybe this part is the achilles heel of the whole idea, or maybe it's no big deal, I have no idea. But people have paid other people to do work before, and I'm sure it can be sorted out somehow. Anyway, let me know what y'all think of this proposal. Worth doing? Bryce

3 2

Re: [Inkscape-devel] DXF import
by John Taber 09 Apr '05

09 Apr '05

Are there any plans for a DXF import ? Right now I have to open a DXF in Open Office Draw, save as SVG, then import into Inkscape. Too bad OO is not GPL otherwise could just take that code module and stick into Inkscape, but maybe there are others.

6 9

Re: [Inkscape-devel] DXF import
by John Taber 09 Apr '05

09 Apr '05

Are there any plans for a DXF import ? Right now I have to open a DXF in Open Office Draw, save as SVG, then import into Inkscape. Too bad OO is not GPL otherwise could just take that code module and stick into Inkscape, but maybe there are others.

3 2

Allowed INX param types
by unknown＠example.com 09 Apr '05

09 Apr '05

I was wondering. What are all of the possible param types that can be passed to scripts? I'm wondering specifically if it is possible to specify quoted strings and one of a set of enumerated value. Aaron Spike http://www.ekips.org/comp/inkscape/wavy.php

1 0

NEW: Load from URL
by Bryce Harrington 08 Apr '05

08 Apr '05

As a configure-time option, Inkscape now supports loading SVG's from a remote URL via HTTP. This is implemented using the GNOME VFS library. This is a library that Inkscape has not had a dependency on previously, so it's implemented as an optional dependency that is controlled during configuration via the --with-gnome-vfs flag. In other words: $ ./configure --with-gnome-vfs $ make $ src/inkscape http://openclipart.org/clipart//animals/bugs/butterfly_jonathan_dietr_01.svg The file is loaded into memory and parsed directly, rather than saving to a temporary file, so it loads pretty fast. Enjoy, Bryce

4 5

Re: [Inkscape-devel] Scripting
by unknown＠example.com 08 Apr '05

08 Apr '05

aaron@...749... wrote: > ted@...11... wrote: > >> This is really nice. Aaron, one thing that we'd talked about in the >> past is starting to move twoards having a seperate package of scripts, >> to remove some dependencies from the base Inkscape package. So, you'd >> have "inkscape.rpm" and "inkscape-scripts-python.rpm" that you'd >> install (if you wanted). >> >> As someone who is starting to write more scripts, do you have thoughts >> on this? Would you perhaps want to start such a package? Do any of >> the packagers out there have any thoughts? > > I'd love to start a package, but I'm sure I wouldn't have a clue. I > thought I read somewhere that Inkscape was leaning toward a CPAN-like > setup perhaps an XML-RPC service. In some ways I think distributing a > package of extensions doesn't fit well with the cause. Thinking about how scripts should be distributed reminded me of a question I wanted to as a few days ago. Should there be or is there a search path for extensions? Could I for instance install my custom effect scripts and thier *.inx files into ~/.inkscape/extensions ? Aaron Spike

2 2