- Inkscape Devel - Inkscape Mailman

today's compile error
by bulia byak 16 Nov '07

16 Nov '07

main.cpp: In function 'void sp_do_export_png(SPDocument*)': main.cpp:981: error: 'errno' was not declared in this scope main.cpp:981: error: 'ERANGE' was not declared in this scope -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Re: [Inkscape-devel] [Inkscape-user] Improved performance of the object snapper
by bulia byak 16 Nov '07

16 Nov '07

On Nov 16, 2007 12:04 PM, Diederik van Lierop <mail@...1689...> wrote: > bulia byak wrote: > > IMHO the key thing here is not just snapping to extensions of bbox, > > but _visualizing_ what it is that you snap to. In AI, it flashes the > > snap line when it snaps. We need to add infrastructure that would > > enable such displays when snapping, then smart guides will be easy. > > > > Absolutely! It's also needed for the post-snap visualization that was > discussed a few months ago, in which something lights up for a second at > the point that has snapped. What would be a good starting point in the > code to find out how such a thing would be drawn to the canvas? Do you > already have passive elements like that, not allowing user interaction > and disappearing after some time? Of course. We have a number of classes that draw various helper things on the canvas. These classes handle proper canvas redraw (so you don't have to worry about that) and usually have methods for setting coordinates, colors, showing/hiding etc. Note that unlike regular objects, these helper thingies can use inverse color so they are visible on any background. But these classes do not do any user interaction; that is performed by upstream classes that uses these display classes. They also have no provisions for automatically disappearing after a time, that you will need to add in your own code. Here they are: display/sp-ctrlline - draws a straight line, used by node tool bezier handles and by gradient tool for gradient lines display/sodipodi-ctrrect - draws an upright rectangle, used for rubberband selection display/sodipodi-ctrl - draws a number of various small fixed-size shapes, such as diamond, circle etc; used for knots and nodes display/sp-ctrlquadr - draws an arbitrary quadrilateral, used for text selection display/canvas-bpath - draws an arbitrary path with antialiasing, used for the red helper path in Node tool and for Pen tool, as well as for Tweak tool's circle (note: this one is slightly buggy, it leaves behind some dirt on the canvas; I want to switch it to using cairo but it's not yet possible due to incompatibility of buffer formats). You can search the codebase for a lot of examples of using these things. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Re: [Inkscape-devel] [Inkscape-user] Improved performance of the object snapper
by unknown＠example.com 16 Nov '07

16 Nov '07

About the disappearing after some time: desktop->messageStack()->flash( Inkscape::WARNING_MESSAGE, "blah" ); That puts a message on the statusbar for a couple of seconds. -Johan > -----Original Message----- > From: inkscape-user-bounces(a)lists.sourceforge.net > [mailto:inkscape-user-bounces@lists.sourceforge.net] On > Behalf Of Diederik van Lierop > Sent: vrijdag 16 november 2007 18:05 > To: Inkscape User Community > Subject: Re: [Inkscape-user] [Inkscape-devel] Improved > performance of the object snapper > > bulia byak wrote: > > IMHO the key thing here is not just snapping to extensions of bbox, > > but _visualizing_ what it is that you snap to. In AI, it > flashes the > > snap line when it snaps. We need to add infrastructure that would > > enable such displays when snapping, then smart guides will be easy. > > > > Absolutely! It's also needed for the post-snap visualization > that was discussed a few months ago, in which something > lights up for a second at the point that has snapped. What > would be a good starting point in the code to find out how > such a thing would be drawn to the canvas? Do you already > have passive elements like that, not allowing user > interaction and disappearing after some time? > > Diederik > > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all > challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Inkscape-user mailing list > Inkscape-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-user >

1 0

SVN error
by Michael Yinger 16 Nov '07

16 Nov '07

Hi All, I'm trying to build an inkscape project by importing the inkscape SVN repository. Everything goes along fine until I get to xml-tree.cpp and I get an error. I've tried it with various SVN clients in Win XP and Linux (Fedora). I've been able to do this about a week ago. Can anyone explain what I'm doing wrong? Thanks for any help you can give. ... Added: C:\Documents and Settings\myinger\workspace\src\dialogs\item- properties.h Added: C:\Documents and Settings\myinger\workspace\src\dialogs\xml-tree.cpp Error: REPORT request failed on '/svnroot/inkscape/!svn/vcc/default' Error: REPORT of '/svnroot/inkscape/!svn/vcc/default': Could not read chunk delimiter: Secure connection truncated (https://inkscape.svn.sourceforge.net) Thanks. -- Mike

2 1

Re: [Inkscape-devel] perfect bound cover
by John Bintz 15 Nov '07

15 Nov '07

Alexandre Prokoudine wrote: > On Nov 9, 2007 2:44 PM, John Bintz <jcoswell@...1414...> wrote: >> That's because I didn't actually test to see if <_option> elements >> worked, I just assumed it would. :( I just put that fix into the >> extensions code and now it's working. Try it now. >> > > For some reason options do not show up as translated :-/ Unfortunately, I'm not seeing how you would make the translated option elements show up correctly, even after getting the <_option> tags working. :/ Aaron, Ted: do you have any insights? Thanks, John

3 6

Mouse Location
by Gail Carmichael 15 Nov '07

15 Nov '07

Hi all! I'm playing with a little accelerometer and I want to see how well I can get it to work in Inkscape so that it would replace the mouse. I was wondering if anyone could tell me where exactly the mouse location is read? I am literally going to plug code to read this accelerometer there instead. Clearly, this is not work that will be usable in Inkscape! Just for fun :) Thanks, Gail

6 8

Re: [Inkscape-devel] [Inkscape-user] Improved performance of the object snapper
by Alexandre Prokoudine 15 Nov '07

15 Nov '07

On Nov 15, 2007 10:35 PM, Diederik van Lierop wrote: > Alexandre Prokoudine wrote: > > I wonder if within current snapping framework the so called Smart > > Guides are possible. That is -- snapping without touching. > > This is new to me, but it looks like it simply aligns > vertically/horizontally to the boundingbox of objects at any distance, > am I correct? Yes, both BB and rotation center. > Such a thing is not supported by the current snapping > framework, but it shouldn't be too difficult to implement. Sounds like a dream :) > If implemented, it will need a key binding though to easily turn this > on/off because otherwise it will get annoying. Definitely! :) Alexandre

1 0

Re: [Inkscape-devel] [Inkscape-user] Improved performance of the object snapper
by bulia byak 15 Nov '07

15 Nov '07

On 9/5/07, Diederik van Lierop <mail@...1689...> wrote: > The last few days I've spent on improving the performance of the object > snapper. It used to take ages (e.g about 6 seconds on my machine) to > move a simple rectangle over a large text box, but I've managed to > reduce this significantly (i.e. < 1 sec.!). This was with both snapping > to paths and snapping to nodes turned on. For this I had to refactor the > object snapper code significantly, so I might have introduced new bugs > or regressions. Please be aware of this and report any suspicious > behavior, so we can have both fast and robust snapping in v0.46! Thanks, great news! Please add a note about that in the "speed and interactivity" section of the release notes as well. > Please note that the performance has only increased when using the > selector tool for transforming a number of points, e.g. when dragging a > selection. Using the node tool to drag a single node will not benefit > from this. I just tried to test this: opened new document, drew a spiral and a small rect, then opened doc prefs and turned on "snapping of: bbox corners" and "snapping to objects: snap to paths". But when I drag the rect it does not snap to the spiral. What am I doing wrong? > Before, for _every_ point in the selection being transformed (using the > selector tool), Inkscape would search for snapping candidates, build a > list of nodes and paths, and finally call convertWithBackData(). Only > then would it snap this single point and start all over again for the > next point in the selection. Now we only do this collecting and > converting stuff once, store the results, and then snap all points in > the selection (using the stored data). Not having to call > convertWithBackData really helps a lot! I think that in many common > cases this improves the performance dramatically. Yes, this is approximately how I imagined that. The convertWithBackData, as all livarot functions, is very slow. Hopefully we'll be able to use 2geom for that task one day. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

Compiling on Linux
by Docsonic 15 Nov '07

15 Nov '07

my apologies for cross-posting but I wasn't getting any response in Inkscape-User so I thought I might have posted to the wrong list. I tried to install the latest autopackage of Inkscape but it seems my glibc is too old (Requires GLIBC_2.4 - I have GLIBC_2.3.6 ... is it possible to release a GLIBC_2.3.6 autopackage?) and the package suggested I install from sources. When I try to compile the source, i get an error - ui/dialog/ocaldialogs.h:247: error: expected class-name before '{' token ui/dialog/ocaldialogs.h: In constructor 'Inkscape::UI::Dialog::FileListViewText::FileListViewText(guint, Inkscape::UI::Dialog::SVGPreview&, Gtk::Label&, Gtk::Button&)': ui/dialog/ocaldialogs.h:250: error: class 'Inkscape::UI::Dialog::FileListViewText' does not have any field named 'ListViewText' I use Debian Etch (stable) so it seems compiling myself is my best option but I have tried with about 5 different source packages and the result is always the same (the package which created this error was 16060 but it is still there in 16148). Thanks, Tony -- View this message in context: http://www.nabble.com/Compiling-on-Linux-tf4534516.html#a12940589 Sent from the Inkscape - Dev mailing list archive at Nabble.com.

6 18

Failing compile with 2geom/path.h
by Mason Thomas 14 Nov '07

14 Nov '07

Hi, I have recently been unable to compile Inkscape on Linux because of a compile failure in nodepath.cpp. It exhibits the same failure, even when I checkout an older version that used to compile for me! Here is the beginning of the message I get (it goes on much longer), could someone please help? Thanks, -Mason In file included from live_effects/effect.h:16, from live_effects/lpeobject.h:13, from nodepath.cpp:50: ./2geom/path.h:72: warning: `virtual Geom::Curve* Geom::Curve::reverse() const' was hidden ./2geom/path.h:313: warning: by `Geom::Curve* Geom::SVGEllipticalArc::reverse(double, double) const' ./2geom/path.h: In member function `Geom::BaseIterator<__gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > > > Geom::Path::begin()': ./2geom/path.h:376: error: `Geom::BaseIterator<IteratorImpl>::BaseIterator(const IteratorImpl&) [with IteratorImpl = __gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >]' is private ./2geom/path.h:472: error: within this context ./2geom/path.h: In member function `Geom::BaseIterator<__gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > > > Geom::Path::end()': ./2geom/path.h:376: error: `Geom::BaseIterator<IteratorImpl>::BaseIterator(const IteratorImpl&) [with IteratorImpl = __gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >]' is private ./2geom/path.h:473: error: within this context

4 5