April 2005 - Inkscape Devel - Inkscape Mailman

gcc 4.0 rc1 available
by Bob Jamison 11 Apr '05

11 Apr '05

I saw this morning that the Gcc project has made a pre-release cut, announced here: http://gcc.gnu.org/ml/gcc/2005-04/msg00479.html It is very easy to install this version: 1) tar jxf gcc-4.0.0-20050410.tar.bz2 2) cd gcc-4.0.0-20050410 3) mkdir objdir 4) cd objdir 5) ../configure --disable-shared --enable-languages=c,c++ 6) make > /dev/null 7) (su) 8) make install The '--disable-shared' flag will build libstdc++ statically, so that we can deliver binaries to others without adding a dependency on the latest version. Bob

1 0

Save to OCAL
by unknown＠example.com 11 Apr '05

11 Apr '05

I was looking through the RFEs for script ideas and I saw "[ 1059410 ] Fuelling OpenClipArt with simple 'publish' export button" <http://sourceforge.net/tracker/index.php?func=detail&aid=1059410&group_id=9…> Without much thought I think this would be a good idea. I also think it is something I might be capable of writing in Python. Anyone have any suggestions as to how this would best be implemented? Is there anything sticky I should look out for with the Public Domain part? Aaron Spike

4 4

Re: [Inkscape-devel] save-on-close issue
by Bryce Harrington 11 Apr '05

11 Apr '05

On Wed, Feb 16, 2005 at 11:55:09AM -0500, mental@...3... wrote: > Quoting Bryce Harrington <bryce@...260...>: > > So something like this? > > > > gboolean lastViewOfDocument(SPDocument* doc, SPDesktop* > > view) const; > > Nearly. Two things: > > 2. s/gboolean/bool/ In general do we prefer bool over gboolean? I notice many instances of gboolean in the Gtk+ code, should I be changing those to bool as I reimplement them in Gtkmm? Bryce

2 1

Help with Win32 MinGW build
by William Lear 10 Apr '05

10 Apr '05

I am having difficulties trying to build Inkscape using the procedures described on the Wiki Win32Port page. I believe I have followed Bob Jamison's directions to the letter. I hate to admit defeat, but I am in need of newbie help. I am using MinGW V3.1.0-1, ink32libs-050202.7z, and a fresh CVS update as of today, 4/10. Everything is installed in the default locations: C:/mingw, c:/gtk. Other than a few seemingly innocuous type mismatch warnings, everything seems to compile OK until I start getting a large number of undefined references, such as: c:/gtk/lib/libgtkmm-2.4.a(clipboard.o)(.text+0x203e): In function `ZNK3Gtk9Clipboard16wait_for_targetsEv': /usr/local/xmingw/lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/c++/3.4. 2/bits/stl_list.h:1162: undefined reference to `std::_List_node_base::hook(std::_List_node_base*)' c:/gtk/lib/libgtkmm-2.4.a(clipboard.o)(.text+0x2316): In function `ZN41_GLOBAL__N_clipboard.cc_3F6EE7DC_4C12096827Signal Proxy_TargetsReceived12gtk_callbackEP13_GtkClipboardPP8_GdkAtomiPv': /usr/local/xmingw/lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/c++/3.4. 2/bits/stl_list.h:1162: undefined reference to `std::_List_node_base::hook(std::_List_node_base*)' This continues until the make terminates due to errors: c:/gtk/lib/libsigc-2.0.a(trackable.o)(.text+0x392): In function `ZN4sigc8internal23trackable_callback_list12add_callback EPvPFS2_S2_E': /usr/local/xmingw/lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/c++/3.4. 2/bits/stl_list.h:1162: undefined reference to `std::_List_node_base::hook(std::_List_node_base*)' c:/gtk/lib/libsigc-2.0.a(trackable.o)(.text$_ZNSt4listIN4sigc8internal18trac kable_callbackESaIS2_EE5eraseESt14_List_iter atorIS2_E+0x15): In function `ZN4sigc9trackableC1Ev': /home/rjamison/xmingw/libsigc++-2.0.3/sigc++/trackable.cc:30: undefined reference to `std::_List_node_base::unhook()' make[1]: *** [inkscape.exe] Error 1 make[1]: Leaving directory `C:/inkscape/inkscape/src' make: *** [all] Error 2 Any help or pointers would be greatly appreciated. Thanks, Bill

2 2

assertion `bpd->moveto_idx >= 0' failed
by unknown＠example.com 10 Apr '05

10 Apr '05

I was playing around with an effect script I wrote yesterday. <http://www.ekips.org/comp/inkscape/koch.php> And I found that if I add a path to the document with the following pathdata: M208.57143 703.79075L174.516731473 751.46188866L239.616096737 756.673375098L208.57143 703.79075ZM414.28571 715.21933L354.791910976 765.893698391L462.153883759 809.766643481L414.28571 715.21933ZL435.919819746 753.935147186L460.519786772 711.050828191L414.28571 715.21933ZM488.57143 578.07647L504.042810705 635.178562182L568.765082358 575.851235234L488.57143 578.07647Z I see this message on the console: ** (inkscape:5371): CRITICAL **: void gnome_canvas_bpath_def_closepath(GnomeCanvasBpathDef*): assertion `bpd->moveto_idx >= 0' failed I'm guessing that the sticky part is "ZL435.919819746 753.935147186" because there is a closepath directive that is not followed immediately by a moveto. But I think this is within the bounds of the spec: 'If a "closepath" is followed immediately by a "moveto", then the "moveto" identifies the start point of the next subpath. If a "closepath" is followed immediately by any other command, then the next subpath starts at the same initial point as the current subpath.' <http://www.w3.org/TR/SVG/paths.html#PathDataClosePathCommand> So it would seem to me that "g_return_if_fail (bpd->moveto_idx >= 0)" in "src/svg/gnome-canvas-bpath-util.cpp" says "fail if the current subpath doesn't begin with a moveto" when it means to say "fail if the current path doesn't begin with a moveto." Aaron Spike

1 0

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