March 2007 - Inkscape Devel - Inkscape Mailman

Compiling with btool on Windows Vista
by Joel Holdsworth 29 Mar '07

29 Mar '07

Hi Everyone, I'm just in the process of trying to get involved with the development of inkscape, and I've spent the last few weeks trying to compile it by various methods. The btool method (as suggested here http://wiki.inkscape.org/wiki/index.php/Win32Port), is the simplest way, and in the end, the only way I can see to compile inkscape in Windows (although I have tried several approaches). Inkscape can be compiled no problem on a fresh install of Windows XP - I tried it on Virtual PC this morning. However, (and you may already be aware of this), it does not compile properly on Windows Vista, my main OS. First, mingwenv.bat runs successfully, whether running in an administrator or normal console. But there's hitch on the next step. The problem relates to g++ I think. If I do the step: "g++ buildtool.cpp -o btool", I get back the response "g++: _spawnvp: No such file or directory". It is possible to get past this step by compiling with btool with cygwin. However once you try and run btool.exe, you get the output printed below, which you may notice contains the killer line "i686-pc-mingw32-g++.exe: _spawnvp: No such file or directory". I think this must all be a problem with g++ in Vista. I'm not sure how what the dev team can do, but I think the wiki should be updated at least. Best Regards Joel Holdsworth ----------------------------------------- #################################################### # BuildTool v0.6, 2006 Bob Jamison #################################################### ######## PARSE : build.xml ######## PARSE COMPLETE ######## EXECUTE ## Target : init ---- task : mkdir : build ---- task : mkdir : inkscape ---- task : copy : src/helper/sp-marshal.h.mingw to src/helper/sp-marshal.h ---- task : copy : src/helper/sp-marshal.cpp.mingw to src/helper/sp-marshal.cpp ---- task : makefile : inkscape_version.h ---- task : makefile : config.h ## Target : compile ---- task : cc : regenerating C/C++ dependency cache : compile of build/obj/arc-context.o required by src/arc-context.cpp ============ cmd ============ i686-pc-mingw32-g++ -c -Wall -O3 -mms-bitfields -DVERSION=\"0.45.1\" -DHAVE_CONFIG_H -DXP_WIN -D_INTL_REDIRECT_INLINE -I. -Ic:/gtk210/include -Ic:/gtk210/include/glibmm-2.4 -Ic:/gtk210/lib/glibmm-2.4/include -Ic:/gtk210/include/gtkmm-2.4 -Ic:/gtk210/lib/gtkmm-2.4/include -Ic:/gtk210/include/gdkmm-2.4 -Ic:/gtk210/lib/gdkmm-2.4/include -Ic:/gtk210/include/pangomm-1.4 -Ic:/gtk210/include/atkmm-1.6 -Ic:/gtk210/include/cairomm-1.0 -Ic:/gtk210/include/sigc++-2.0 -Ic:/gtk210/lib/sigc++-2.0/include -Ic:/gtk210/include/gtk-2.0 -Ic:/gtk210/lib/gtk-2.0/include -Ic:/gtk210/include/atk-1.0 -Ic:/gtk210/include/pango-1.0 -Ic:/gtk210/include/glib-2.0 -Ic:/gtk210/lib/glib-2.0/include -Ic:/gtk210/include/libxml2 -Ic:/gtk210/include/freetype2 -Ic:/gtk210/include/cairo -Wno-comment -Ic:/gtk210/perl/lib/CORE -Ic:/gtk210/python/include -Isrc -Isrc/application -Isrc/debug -Isrc/dialogs -Isrc/display -Isrc/dom -Isrc/dom/io -Isrc/dom/odf -Isrc/dom/svg -Isrc/dom/util -Isrc/extension -Isrc/extension/implementation -Isrc/extension/internal -Isrc/extension/internal/libwpg -Isrc/extension/script -Isrc/graphlayout -Isrc/helper -Isrc/inkjar -Isrc/io -Isrc/jabber_whiteboard -Isrc/jabber_whiteboard/dialog -Isrc/libavoid -Isrc/libcola -Isrc/libcroco -Isrc/libnr -Isrc/libnrtype -Isrc/libvpsc -Isrc/libvpsc/pairingheap -Isrc/livarot -Isrc/pedro -Isrc/removeoverlap -Isrc/svg -Isrc/trace -Isrc/trace/potrace -Isrc/ui -Isrc/ui/dialog -Isrc/ui/view -Isrc/ui/widget -Isrc/util -Isrc/widgets -Isrc/xml src/arc-context.cpp -o build/obj/arc-context.o ============================= i686-pc-mingw32-g++.exe: _spawnvp: No such file or directory Make error: exec of command 'i686-pc-mingw32-g++ -c -Wall -O3 -mms-bitfields -DV ERSION=\"0.45.1\" -DHAVE_CONFIG_H -DXP_WIN -D_INTL_REDIRECT_INLINE -I. -Ic:/gtk2 10/include -Ic:/gtk210/include/glibmm-2.4 -Ic:/gtk210/lib/glibmm-2.4/include -Ic :/gtk210/include/gtkmm-2.4 -Ic:/gtk210/lib/gtkmm-2.4/include -Ic:/gtk210/include /gdkmm-2.4 -Ic:/gtk210/lib/gdkmm-2.4/include -Ic:/gtk210/include/pangomm-1.4 -Ic :/gtk210/include/atkmm-1.6 -Ic:/gtk210/include/cairomm-1.0 -Ic:/gtk210/include/s igc++-2.0 -Ic:/gtk210/lib/sigc++-2.0/include -Ic:/gtk210/include/gtk-2.0 -Ic:/gt k210/lib/gtk-2.0/include -Ic:/gtk210/include/atk-1.0 -Ic:/gtk210/include/pango-1 .0 -Ic:/gtk210/include/glib-2.0 -Ic:/gtk210/lib/glib-2.0/include -Ic:/gtk210/inc lude/libxml2 -Ic:/gtk210/include/freetype2 -Ic:/gtk210/include/cairo -Wno-commen t -Ic:/gtk210/perl/lib/CORE -Ic:/gtk210/python/include -Isrc -Isrc/application -Isrc/debug -Isrc/dialogs -Isrc/display -Isrc/dom -Isrc/dom/io -Isrc/dom/odf -I src/dom/svg -Isrc/dom/util -Isrc/extension -Isrc/extension/implementation -Isrc/ extension/internal -Isrc/extension/internal/libwpg -Isrc/extension/script -Isrc/ graphlayout -Isrc/helper -Isrc/inkjar -Isrc/io -Isrc/jabber_whiteboard -Isrc/jab ber_whiteboard/dialog -Isrc/libavoid -Isrc/libcola -Isrc/libcroco -Isrc/libnr -I src/libnrtype -Isrc/libvpsc -Isrc/libvpsc/pairingheap -Isrc/livarot -Isrc/pedro -Isrc/removeoverlap -Isrc/svg -Isrc/trace -Isrc/trace/potrace -Isrc/ui -Isrc/ui/ dialog -Isrc/ui/view -Isrc/ui/widget -Isrc/util -Isrc/widgets -Isrc/xml src/arc- context.cpp -o build/obj/arc-context.o' failed : No such file or directory Make error: problem compiling:

1 0

Re: [Inkscape-devel] SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Thorsten Wilms schrieb: > Just some idea of a slightly different organisation: > - Don't have the user add VPs or a box, but a perspective > object I'm not sure if I get you right here. Why would it be more convenient to add an "abstract" perspective object rather than just adjusting some VPs with a few drags, where you can _see_ what happens? Or do you mean that you want to be able to treat perspectives as objects of their own? Internally, perspectives will be separated from boxes anyway. This makes it possible to compare perspectives for different boxes, to copy them from one box to another (here some care must of course be taken as to which corners should remain fixed), to define a default perspective, etc. But boxes are a very convenient way to define perspectives, so why not use them for this purpose? > - The perspective object could come with 2 VPs on a horizon and > one box per default. That kind of perspective will be the default when dragging a box anyway (at least, in the beginning). You may be right, however, that one could try and separate the concepts a bit more from the user's point of view, too. But only if this doesn't make things less intuitive or more complicated to grasp. I'll give it some further thoughts. > - The number of VPs would be a parameter of the perspective > object like corners are for stars/polygons. Hmm, I think the number of VPs should be three unconditionally. However, each of them should be toggleable between 'finite' and 'infinite', i.e. the PLs either meet in a point or they are parallel. This provides a way to keep track of the _direction_ of parallel PLs, too. It's just an internal thing, though. > Hmm, for setups with several boxes in different perspectives, > VPs have to be organised in groups. For what purpose exactly? Max

1 0

Re: [Inkscape-devel] Multi-page UI
by Tom Lechner 29 Mar '07

29 Mar '07

Hi, Just in case anyone's interested, I've been writing a program called Laidout to lay out cartoon books of mine. It features sort of arbitrary impositions, including the ability to have non-rectangular pages. It does make a distinction between page, paper, and also page spreads (how it looks assembled, rather than how it looks on master printing pages). No art, trim, crop, bleed, and media box tags yet though. It has a viewer window where you edit the things in the pages, and also a spread editor, where you can rearrange page orders. One of my TODO items for a long time has been to somehow port my spread editor (after it gets a little more advanced) to Inkscape. There are just not enough hours in the day! Unless you happen to be me, Laidout's probably difficult to use, as everything's still in rough, primitive stages right now, but you can get the idea from these screenshots: http://www.laidout.org/screenshots I started writing Laidout years ago as an exercise to learn how to program better. It's been a much larger endeavor than I had at first been imagining, meaning the code's rather a mess, but I do get to lay out my books pretty easily! Tom http://www.tomlechner.com

2 1

Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
by Jon A. Cruz 28 Mar '07

28 Mar '07

On Mar 28, 2007, at 11:44 AM, Thorsten Wilms wrote: > A proposal to bring Blender-like splitable views, detachable panels > and tabs > to the WM level is on my too-long todo list. Splitable views and tabs are mechanisms that will probably solve all the problems people want MDI used to solve, but in a much better solution. In fact, having split views on a single document in a single window along with having a separate window for each document will probably be the best solution. Adding in tabs will be a solution for some people, but personally I don't use them nearly as much as others. Having both implemented and allowing the users to use as little or as much of each as they desire will probably maximize productivity, and that will be far better than trying to solve those with MDI.

3 2

Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
by Jon A. Cruz 28 Mar '07

28 Mar '07

On Mar 28, 2007, at 11:44 AM, Thorsten Wilms wrote: Thanks for the list. It's actually a bit outdated, especially for MS Windows users. > * Many child windows do not fill up the OS task management > interface, as they > are hierarchically organized. Users simply switch applications. As of Windows XP this is no longer an issue. Windows automatically collapses documents from the same app so that the management interface does not get filled up. Also, users usually want to switch to a *document*, not an *application*, so switching applications is actually a negative. > * With MDI (and also TDI), a single menu bar and/or toolbar is > shared between > all child windows, reducing clutter and increasing efficient use of > screen > space. The extent of benefit depends on the application and if windows are tiled or worked with individually. Most applications have more efficient screen use and customizable toolbars, so the base clutter is far less than it used to be. Additionally, unless the windows are tiled, there is no net gain, since switching from App A window A to App A Window B will bring forward and use the same screen pixel locations. > * All child windows for an application can be hidden/shown/ > minimized/maximized > as a whole. Again, questionable if it is an actual "advantage". It is a property/ behavior of MDI, but most studies indicate this is a negative for most users. People most often think of "documents" and tend to work "on documents" instead of "in applications". > * Without an MDI frame window, floating toolbars from one > application can > clutter the workspace of other applications, potentially confusing > users with > the jumble of interfaces. True. But this advantage is also gained by not having floating toolbars and does not require MDI to gain. SDI also has this advantage, so it really shouldn't be a factor here. > * Features such as "Tile" and "Cascade" can be implemented for the > child windows. A decent advantage. However, it is also a disadvantage in that it means all documents of a given application are tiled, not of a given set. The work-around in MDI to make this point an advantage is to only open documents for client A. However, that also then is the same thing to give SDI the same advantage.

1 0

Memoryleak? when creating text object
by unknown＠example.com 28 Mar '07

28 Mar '07

Hi all, I may have found a memoryleak (don't know what they look like). When i run Inkscape from gdb (svn-head, winxp) the debugger will catch a SIGTRAP after dragging and releasing the text tool: warning: HEAP[inkscape.exe]: warning: Heap block at 053640B8 modified at 053640C4 past requested size of 4 Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll The backtrace ends with: #56 0x00000000 in ?? () from #57 0x04a295c0 in ?? () #58 0x02b60000 in ?? () #59 0x00ab63fc in std::vector<Inkscape::Text::Layout::Chunk, std::allocator<Inkscape::Text::Layout::Chunk> >::_M_insert_aux () at c:/dev/gcc/gcc-4.1.1/objdir/i686-pc-mingw32/libstdc++-v3/include/bits/ios_base.h:169 Previous frame inner to this frame (corrupt stack?) This bug might be related to bug 1645874. When running Inkscape normally, nothing happens, other than that memory seems leaking (the allocated memory keeps increasing when more text objects are drawn with the texttool) Cheers, Johan

2 2

Arrangements for 'Kesäkoodi'
by Niko Kiirala 27 Mar '07

27 Mar '07

I received more information concerning Kesäkoodi, the Finnish equivalent for Google's Summer of Code. Now that they have gone through the submitted proposals, I have been qualified for the second round. That is, I should make a more through proposal for the project. With this proposal, I may get into the final round, where I should present this project plan in front of live audience... (no, I don't know why it has to be this complicated) Anyhow, now they do want to have some mentor / contact person from Inkscape side. As I understand this, this contact person should provide COSS (organizers of Kesäkoodi) with some comments on my work. I don't know for sure though, they haven't been too verbose on that. The project I am planning is to further develop the filtering system and to implement a couple new filters. I will post the project plan in further detail, as I get it done and translated in English. -- Niko Kiirala niko@...1267... http://niko.kiirala.com/

6 8

Re: [Inkscape-devel] Help about Animate Document in Inkscape
by Federico 27 Mar '07

27 Mar '07

Hello Mental, for being preciser I can add that some objects of the canvas possess a specific ID that comes set up manually. The extension must interrogate a DBMS and if in the result of the interrogation an object from the particular ID is content, to this object it comes modified attribute STYLE with data read from the DBMS. As an example: 1) design a rectangle and set the ID = “rect10” 2) DBMS comes interrogated and reads a line that contains a foreinkey “rect10” and this attributes style=fill: #ff9955; stroke: #000000; stroke-opacity: 0.98830408; stroke-width: 8; stroke-miterlimit: 4; stroke-dasharray: ninth; stroke- linejoin: round; stroke-linecap: butt 3) set the object with these attributes by means of the instruction node->setAttributes (“style”, ....., true); or sp_repr_set_attr(nodes[i],"style", ...); The problem is in the fact that, I make to execute the operations of "reading of the DBMS" and of "set attributes" in a secondary thread, and at the instruction “setAttributes” or "sp_repr_set_attr" an error of segmentation fault happens and Bryce has said to me that this error is from the multithreading, because Inkscape is ONLY SingleThreading. You could give a hand to me, is truly imporant. Thanks Federico On Lun, March 19, 2007 23:35, MenTaLguY wrote: > On Mon, 19 Mar 2007 19:31:12 +0100 (CET), Federico <fedemil@...1700... it> > wrote: >> I would have the necessity to modify the attributes of field STYLE of >> an object to regular intervals of time. > >> More in the detail, I would have necessity to write a â€œextensionâ € >> of >> Inkscape that reads the data of an object (rect, path, star, etc.) from >> a DBMS and he applies them to the present object on the screen. > > Could you please clarify the way in which these two requirements are > related to one another? > > -mental Naviga e telefona senza limiti con Tiscali Scopri le promozioni Tiscali adsl: navighi e telefoni senza canone Telecom http://abbonati.tiscali.it/adsl/

2 1

Requiring gcc >=4?
by jiho 27 Mar '07

27 Mar '07

Hello everybody, When compiling Inkscape with gcc 3.3 (on OS X but that should not be much of an OS X specific problem) we encounter many errors (Ex: isnan and isnormal not declared, -Wno-pointer-sign option not recognized and some other issues with the inclusion of math.h in some files and of cmath.h in others). All these are quite too technical for me to solve but from my initial research they appear to be somehow related to a compiler version problem. The bottom line is: Does the development team want Inkscape to require gcc >=4 (in which case we'll just upgrade gcc) or do you want to stay backward compatible (in which case I'll report all problems as bugs or on the list)? Thanks in advance. JiHO --- http://jo.irisson.free.fr/

4 4

SoC students deadline, update
by Alexandre Prokoudine 26 Mar '07

26 Mar '07

Hi, Student Application deadline is extended to 16:00 UTC March 27, 2007. http://groups.google.com/group/google-summer-of-code-announce/browse_thread… Alexandre

1 0