- Inkscape Devel - Inkscape Mailman

guidlines warning
by Jon A. Cruz 01 Mar '08

01 Mar '08

Not sure if this actually affects anyone, but I ran across a clump of warnings display/guideline.cpp: In function ‘void sp_guideline_render (SPCanvasItem*, SPCanvasBuf*)’: display/guideline.cpp:140: warning: passing ‘double’ for argument 3 to ‘void sp_guideline_drawline(SPCanvasBuf*, gint, gint, gint, gint, guint32)’ ... eight of those in a row. I'll be fixing them.

1 0

Tablet feature updates
by Jon A. Cruz 29 Feb '08

29 Feb '08

I've added the first cut of extending tablet support to switch tool based on input device being used. If anyone has a tablet and could give it a spin that would help.

7 12

How to mark bugs for 0.46.x in LaunchPad?
by Maximilian Albert 29 Feb '08

29 Feb '08

Hi, sorry for this seemingly stupid question, but how can I mark a bug as also affecting 0.46.x so that it can be picked up by Bryce or Josh and copied over to the release branch? Neither of "Also affects another project/package" seems to work. :( Thanks for any hints, Max

3 4

Dev opinions needed: when to activate SPDesktops?
by Maximilian Albert 29 Feb '08

29 Feb '08

Hi all, during my investigation for the cause of bug #195373 [Creating a new document breaks a 3D box] I have found that when a new desktop is created, it isn't automatically set active right away. Namely, in sp_desktop_widget_new() the function inkscape_add_desktop() is called, but in this function the new desktop is *appended* (instead of *prepended*) to the list of existing desktops. Thus the following 'if' construct if (DESKTOP_IS_ACTIVE (desktop)) { ... } is not triggered (except for the very first desktop). I wonder if this is intentional. Well, it probably is, but why? :) Is there any reason why new desktops shouldn't be activated upon creation? The current behaviour is what's causing bug #195373 since the perspectives in the _old_ desktop/document are updated according to the toggle states of toolbar buttons in the _new_ desktop. There might be other ways to fix this but the easiest I have found is to simply change g_slist_append (inkscape->desktops, desktop); to g_slist_prepend (inkscape->desktops, desktop); in line 891 of inkscape.cpp. However, this would render the above-mentioned 'if' construct obsolete and I guess that there was a reason for introducing it in the first place. But since inkscape_add_desktop is not called from any other place except sp_desktop_widget_new() it looks like a rather safe thing to do. I committed this change to SVN in rev. #17510. Please tell me if there are any objections or concerns that this could break other things. I will then revert it and try to find a different fix. Otherwise this should go into 0.46 as well (I'll file a bug in LaunchPad as soon as I know that it's safe to do). Thanks, Max

4 5

Regarding README
by Alexandre Prokoudine 29 Feb '08

29 Feb '08

Hi, Could somebody with a real extensions mojo please review "Extension Dependencies" section of README file in the root directory of sources? It looks kind of outdated. P.S. man page says: "...(C) 1999–2007..." Cheers, Alexandre

1 0

minor items in LPE stuff
by Jon A. Cruz 29 Feb '08

29 Feb '08

I've seen these three warnings: live_effects/lpeobject.cpp: In member function 'LivePathEffectObject* LivePathEffectObject::fork_private_if_necessary(int)': live_effects/lpeobject.cpp:261: warning: comparison between signed and unsigned integer expressions live_effects/lpe-curvestitch.cpp: In member function 'virtual std::vector<Geom::Path, std::allocator<Geom::Path> >Inkscape::LivePathEffect::LPECurveStitch::doEffect_path (std::vector<Geom::Path, std::allocator<Geom::Path> >&)': live_effects/lpe-curvestitch.cpp:92: warning: comparison between signed and unsigned integer expressions live_effects/lpe-curvestitch.cpp:93: warning: comparison between signed and unsigned integer expressions I think the first one is minor, and the second pair just need a change from 'int' to 'gsize', but I'm not sure what it might do to calculations inside the loops. If anyone who knows those parts could give it a quick look, that would help. Thanks.

2 1

Regarding WMF, PS-based AI, SK and FIG files support
by Alexandre Prokoudine 29 Feb '08

29 Feb '08

Hi, During last weekend I played with UniConvertor and found out that: 1) Its support for WMF is better than the one of wmf2svg simply because objects are editable at once. You can also have a look at feature support tables at [1] and [2]. 2) Old PS-based Adobe Illustrator files look pretty cool, though the ones created with Freehand still don't open correctly. What doesn't work is importing text when fonts in use are absent. UC just drops such text objects. I'm talking to Igor about fixing it. We can have this by just replacing the converter call to cdr2svg.sh which is already written in a universal way. This implies no strings changes at all. If we look a little further, we can ditch the Sketch/Skencil dependency (skconvert, actually) for opening .sk files (UniConverter actually used to be part of Sketch not so long time ago, thus it's same as skonvert in this case). Same probably applies to XFig dependency (fig2dev utility) for opening .fig files, but the very few XFig 3.2 files I had around didn't work at all with UC. I'm talking to Igor about fixing this as well. What is beautiful about this approach is that we will have all these things for free on _all_ platforms, since we are shipping UniConvertor for both Linux, Mac and Windows in 0.46. Here is my proposal: 1. Rename cdr2svg.sh to uniconv2svg.sh 2. Fix ai_input.inx, cdr2svg.inx, sk_input.inx and wmf_input.inx to use it. Probably fig_input.inx too, if a bugfix UC release is out before we package 0.46. Is this acceptable during Hard Freeze? Later we could also add extensions to support CDT (CorelDRAW templates), CCX (Corel Compressed Exchange), CMX (Corel Presentation Exchange), CGM (Computer Graphics Metafile), AFF (Micrografix Draw) and SK1 files the very same way (I've already written .inx files). But this implies strings changes. Thus either 0.46.1 or 0.47. [1] http://www.sk1project.org/modules.php?name=Report&page=08 [2] http://www.sk1project.org/modules.php?name=Report&page=06 Alexandre

2 6

object selection framework
by SF Markus Elfring 28 Feb '08

28 Feb '08

Hello, I try to continue a discussion for a previous feature request. https://bugs.launchpad.net/inkscape/+bug/186576 How much are details around the issue "multiple object selection" supported by the class "SPSelectContext" already? http://inkscape.modevia.com/doxygen/html/structSPSelectContext.php Regards, Markus

1 0

Inkscape / GSoC '08 proposal
by Bryce Harrington 28 Feb '08

28 Feb '08

Hi all, I'm hearing some rumblings that Google will be running their Summer of Code project again this year, and want to put out a proposal for discussion about how we should handle it this year. SoC has been great for bringing new ideas to Inkscape from a number of sources, yet often the newly written code needs follow up work to sand rough corners or to make it fit more correctly within our architecture. However, between SoC mentoring during the summers, and release work at other parts of the year, core developers haven't really had a good solid amount of time to focus on this digestion. There is concern that another summer's worth of code would put us further behind in this regard. Of course, given the major benefits that have accrued from our past involvement, it would be a shame to have to sit it out! But I think there is a compromise which will solve this, if we set two criteria for this year's involvement: 1. All Inkscape GSoC projects this year must be implemented as extensions, with no changes required to Inkscape's core 2. All mentoring be done by developers who will not be focusing on the 0.47 codebase refactoring efforts. (In particular, developers with good extension development experience.) We will limit the number of candidates we accept to the number of mentors available. I think this approach will prove valuable in a few different ways. First, extension writing is likely going to be a much easier learning curve for students than learning to build and work within inkscape's codebase. Second, it keeps their code distinct and discrete from inkscape's codebase, avoiding any increase in 'entropy' in our core code. Third, it will help add value to our extension community, and give them resources to do achieve things that would have had trouble competing against core codebase feature priorities. Please let me know what are your thoughts on this proposal? If you support it and have written extensions before, would you also be willing to be a mentor? Bryce

11 23

[Solved] Rev ~ 17554 - build issues on linux
by Bernard Gray 28 Feb '08

28 Feb '08

Hi Guys, I resolved this with some help in irc - I'm not sure whether that's logged anywhere though, so here's a static summary: I was receiving the following errors after running 'make' on rev ~ 1755x: ================= /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_font_get_type()' /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_glyph_get_type()' /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_fefuncR_get_type()' /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_fefuncG_get_type()' /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_fefuncB_get_type()' /home/bgray/svn/inkscape/src/sp-object-repr.cpp:194: undefined reference to `sp_fefuncA_get_type()' libinkpre.a(sp-fecomponenttransfer.o): In function `sp_feComponentTransfer_children_modified': /home/bgray/svn/inkscape/src/sp-fecomponenttransfer.cpp:112: undefined reference to `sp_fefuncR_get_type()' /home/bgray/svn/inkscape/src/sp-fecomponenttransfer.cpp:113: undefined reference to `sp_fefuncG_get_type()' /home/bgray/svn/inkscape/src/sp-fecomponenttransfer.cpp:114: undefined reference to `sp_fefuncB_get_type()' /home/bgray/svn/inkscape/src/sp-fecomponenttransfer.cpp:115: undefined reference to `sp_fefuncA_get_type()' live_effects/liblive_effects.a(effect.o): In function `Inkscape::LivePathEffect::Effect::New(Inkscape::LivePathEffect::EffectType, LivePathEffectObject*)': /home/bgray/svn/inkscape/src/live_effects/effect.cpp:81: undefined reference to `Inkscape::LivePathEffect::LPESketch::LPESketch(LivePathEffectObject*)' /home/bgray/svn/inkscape/src/live_effects/effect.cpp:84: undefined reference to `Inkscape::LivePathEffect::LPEVonKoch::LPEVonKoch(LivePathEffectObject*)' /home/bgray/svn/inkscape/src/live_effects/effect.cpp:87: undefined reference to `Inkscape::LivePathEffect::LPEKnot::LPEKnot(LivePathEffectObject*)' extension/internal/libinternal.a(cairo-renderer.o): In function `sp_asbitmap_render': /home/bgray/svn/inkscape/src/extension/internal/cairo-renderer.cpp:392: undefined reference to `sp_generate_internal_bitmap(SPDocument*, char const*, double, double, double, double, unsigned int, unsigned int, double, double, unsigned long, _GSList*)' ============== I had not done a fresh checkout for ~ 6 months, and svn status showed lot of cruft left from various major code changes, deleting the directory and doing a fresh checkout from scratch resolved the issue - Regards, Bernie (cleary)

1 0