- Inkscape Devel - Inkscape Mailman

Newest go-ooo.org has built in SVG support
by rygle 04 May '08

04 May '08

Don't know if you know about the community built version of OpenOffice.org, but it's at http://go-ooo.org. It boots quicker than the standard OOo, and has a few other great enhancements, like apparently now the ability to import SVG's directly. Still haven't tested this, as it's a 130Mb download, but the previous go-ooo.org version was noticeably quicker than the default on my computer, and a little more stable too I think. Any comments? Cheers, Rygle. -- View this message in context: http://www.nabble.com/Newest-go-ooo.org-has-built-in-SVG-support-tp17034415… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

compile fails, linux, rev 18505:
by bulia byak 03 May '08

03 May '08

make[2]: Entering directory `/home/d/ink/inkscape/src' make[2]: *** No rule to make target `dom/cssparser.cpp', needed by `dom/cssparser.o'. Stop. please fix :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Batch export feature idea/request.
by Brian Vanderburg II 02 May '08

02 May '08

I have a set of several objects I'd like to batch export. I export them all to a single directory. To have multiple color sets I have a few key items and all of the objects are updated (mostly clones/etc), but then the problem is that batch export wants to write over the previous files so I must manually specify new files: directory layout: items.svg red/item1.png red/item2.png red/item3.png blue/item1.png blue/item2.png blue/item3.png etc With batch exports, after I save the red items and then change the key items to me the stuff blue, batch export still wants to save as red/item?.png A simple solution is in the batch export dialog provide an additional option 'Batch export to directory: '. When enabled, any existing export directory information would be ignored and only the filename portion of the exported file would be used, or if not available the object id. Then I can make the items red, batch export ,select 'Put all files in dir' and choose 'red' for the directory and export. Then change the key items to make it all blue, batch export but choose 'blue' as the export directory, etc for other colors. Something like the attached image Brian Vanderburg II

1 0

Re: [Inkscape-devel] Buildtool -- new
by Bob Jamison 02 May '08

02 May '08

When you say "btool something" that something is one of the targets in build.xml. The project has a default target listed at the top (dist). This is the one that will be executed, after all of its dependent targets, unless you specify another one. You can pick any target to execute. So you can say: btool compile ...and only run a compile, with no linking or copying. I guess you could add a pair of targets, something like this: <target name="refresh_prepare" description="delete the build.dep file to force a regeneration"> <delete file="build.dep"/> </target> <target name="refresh" depends="refresh_prepare,compile" description="force the cc task to regenerate its cache">  </target> The second task doesn't need to do anything. It just says: "before me, run refresh_prepare, and then compile" I'm not sure how to work that into the scheme of the rest of the target hierarchy, though. :) bob -----Original Message----- >Nice, > >Can you alias that, so that -Drefresh=true is just refresh, so you can >simply go 'btool refresh'? >

1 0

Re: [Inkscape-devel] Buildtool -- new
by Bob Jamison 02 May '08

02 May '08

Just a reminder, for when you do an "svn update". If, in the left column, in addition to U and G, you see any A or D for added or deleted files, then you will need to regenerate the dependency list. Also, at link time, if you see errors about missing symbols, then you probably have too many or too few .o files in the /build/obj directory. This is another clue that you need to refresh the dependency cache. The "clean" target has a task for deleting build.dep, so "btool clean" always works, if all else fails and you need to take drastic measures. Another trick: if you need to force a rebuild of a certain set of files, but don't want to rebuild the whole tree, then look in /build/obj. The directory structure mirrors /src. Just delete the corresponding .o's and run btool again. bob

1 0

Buildtool -- new "refreshCache" flag
by Bob Jamison 02 May '08

02 May '08

After thinking about telling Rygle about deleting build.dep to force a recomp, it occurred to me how kludgey that is. So I added yet another flag to the <cc> task, refreshCache="true/false". Setting this to true will force a regeneration of the cache. But you say "Hey, I don't want to edit build.xml every time I want to clean the cache!" Fair enough. So I added another property to build.xml, "refresh=false". This value is used in the <cc> task as refreshCache="${refresh}" To change this, and force a refresh, merely redefine "refresh" on the command line: btool -Drefresh=true You should see this near the top of the output: overloading property 'refresh' = 'true' This is a workaround to the problem: how to specify a task-specific parameter on the command line. I need to figure this one out eventually. By the way, did you know that you can do this? Calling btool this way: btool -Ddist=c:/inkscape ...sends the completed Inkscape distro directly to c:\inkscape :) Since btool uses URIs, "\" or "/" doesn't matter. Let me know if you have any problems. But this is a good example of how btool can be modified, and new Tasks added, to perform whatever build functionality we need. bob

2 1

Build problems - Last two commits (18500 & 18501)
by rygle 02 May '08

02 May '08

Hi guys, Having problems building the last two trunk revisions on Win32; SVN 18500 gives me this; ===== Make error line 201: problem compiling: mingw32-g++: src/dom/svgparser.cpp: No s uch file or directory mingw32-g++: no input files ===== So I updated to SVN 18501, and someone changed main.cpp, which now gives me this error; ===== Make error line 201: problem compiling: src/main.cpp: In function 'void sp_do_ex port_png(SPDocument*)': src/main.cpp:1027: warning: 'sp_item_invoke_bbox' is deprecated (declared at src /sp-item.h:215) src/main.cpp: In function 'bool replaceArgs(int&, char**&)': src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::f tCreationTime' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::f tLastAccessTime' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::f tLastWriteTime' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::n FileSizeHigh' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::n FileSizeLow' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::d wReserved0' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::d wReserved1' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::c FileName' src/main.cpp:1419: warning: missing initializer for member '_WIN32_FIND_DATAW::c AlternateFileName' src/main.cpp:1523: error: invalid conversion from 'const gchar*' to 'gchar*' src/main.cpp:1523: error: initializing argument 1 of 'void std::vector<_Tp, _A lloc>::push_back(const _Tp&) [with _Tp = gchar*, _Alloc = std::allocator<gchar*> ]' ===== I don't think the first error has yet been dealt with, but the second error simply occurs before the first error gets a chance. Cheers, Rygle. -- View this message in context: http://www.nabble.com/Build-problems---Last-two-commits-%2818500---18501%29… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 7

LGM
by Alexandre Prokoudine 02 May '08

02 May '08

Hi, So, who is coming to LGM? :) Alexandre

4 3

New Extensions and Translation or other requirements
by rygle 01 May '08

01 May '08

Hi, Inductiveload has been busy fixing and making extensions. The version of Add Nodes in trunk can now divide into a given number of segments (see LP#171856), and there is also now a Render -> Polar Grid option in trunk (see LP#224522). Soon there will also be a Render -> Cartesian Grid extension, but that's got a slight problem being sorted (see LP#224955). I've recently added the new files to /share/extensions/Makefile.am - I realise that affects the Linux (Mac?) build process, even if it doesn't affect Win32. Does /share/extensions/Makefile.am also flag files for translation (seems to hint at that)? If not, is there a need to change something else for translations? Is there anything else that needs to be updated for new extensions? Cheers, Rygle. -- View this message in context: http://www.nabble.com/New-Extensions-and-Translation-or-other-requirements-… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 2

Re: [Inkscape-devel] [Bug 171856] Re: Segment Division
by Aaron Spike 01 May '08

01 May '08

Rygle wrote: > Hi guys, just trying to get my head around all this. No problem. > I committed this and milestoned for release in 0.47, but I assumed that > Aaron and/or a release warden would check it out before the proper > release. I was trying to flag somehow that this is new and needs to be > approved. That's why I set it as Wish List and Fix Committed, not Fix > Released. Should I have instead marked it as Fix Released and nominated > it for release 0.47? Or just leave any milestoning/nomination because > it's automatically in? Seems like it won't get noticed by release > wardens then. There are no release wardens for 0.47 yet. Release wardens impose marshal law during release times to make sure things get out the door in a reasonable amount of time and without any avoidable nasty bugs. During the normal development cycle we average contributors are in charge. If you've been granted commit access the Inkscape community trusts you to decide what goes into the tree. > I'm also unsure, but based on Maximillian's comments, but do some people > feel that applying patches treads on toes if the bug is assigned to > someone else? I merely wanted to get it into trunk so that people would > find any problems with it. I've seen some good patches that didn't make > it into 0.46 because they didn't get attention. Should I not commit > patches when the bug is assigned to someone else? Please be frank, > because I don't want to offend others. I think sometimes applying a patch assigned to another person could possibly maybe tread on another person's toes perhaps. This time it didn't. I grabbed this patch because the author had written me individually about the change and because there doesn't seem like a lot of people who want to deal with python patches. But I knew that I wasn't going to get around to committing it until the weekend and it is very important to have quick turn around on patches. This shows that we value the work being done and encourages repeat contribution. Just think how discouraging it is when I sit on a two line python patch that is obviously fine. You're timing was excellent. Feel free to commit a patch. As long as you do due diligence. Meaning: You understand the issue it addresses. You test it locally to see that it does address that issue. You do not notice any major regressions as a result of it. Otherwise ask for a little clarification and help. And if you feel comfortable, go ahead and assign bugs to yourself. :-) And, yeah, it probably doesn't hurt to ask if the bug is assigned to someone else. I know in my situation sometimes I don't comment everything I know on the bug because I don't think of it. There might be some issue I want to check into. So if you ask I'd be more likely to write that in the bug comments. Not trying to hide info; I just don't think of these things all the time. Thanks for applying this patch! Aaron P.S. I'm copying Inkscape-devel to give people a chance to disagree with me. :-)

1 0