November 2008 - Inkscape Devel

compiler errors on windows
by pete mcquain 12 Nov '08

12 Nov '08

Hello, I'm trying to get my build environment up and running under Vista and am running into a compiler error: src/display/nr-svgfonts.h:37: error: 'cairo_text_cluster_flags_t' has not been declared I'm using the command-line tools and I'm building against the most recent source from SVN. I got the most recent devlibs zip and mingw from http://inkscape.modevia.com/win32libs/. Does the devlibs archive have the correct cairo includes? Thanks! pete mcquain

3 3

Smooth transitions in Bézier paths
by Diederik van Lierop 11 Nov '08

11 Nov '08

Hi, I hope you don't mind if I increase the traffic on inkscape-devel even more ;-) At some point an idea popped up to only snap to nodes at discontinuities in paths, and not to nodes at smooth transitions from one Bézier segment to another. This is more intuitive (less "Hey, what it is Inkscape snapping to now?") and might increase performance. Problem is that in the object-snapper I only have access to SPCurve, which is a wrapper for "old-style" NArtBpath. It's easy to find out whether a point is inbetween two Bézier segments, but how do I find out if a transition is smooth? I guess that should be done by comparing the control points, or is there an easier way? With the transition to lib2geom, will the NArtBpath be deprecated in favor of the Path class? (that would make this rather exercise useless in the long run). Any pointers would be appreciated here, Diederik

11 36

Rendering test results now with totals
by Jasper van de Gronde 11 Nov '08

11 Nov '08

The rendering test results page now shows totals for each displayed run (in addition to color coding the results and linking bug related tests to their launchpad bugs): http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html This makes it a little easier to see the results at a glance. (Currently still 64 out of 164 tests fail...)

1 0

Doxygen conventions
by Krzysztof Kosiński 11 Nov '08

11 Nov '08

Somebody undid my changes to the files in src/bind/, so I'd like to discuss the doxygen convention used for files here. I already said about this in another thread but it wasn't too visible. I think the proper template for a source file goes like this: /** @file * @brief Brief description of what this file contains */ /* Authors: * Some Author <author@...2068...> * * Copyright (C) 2008 Authors * Released under GNU GPL, read the file 'COPYING' for more information */ #ifndef INCLUDE_GUARD #define INCLUDE_GUARD // ... code ... #endif /* Local Variables: mode:c++ c-file-style:"stroustrup" c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +)) indent-tabs-mode:nil fill-column:99 End: */ // vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 : Important points: 1. @file on the first line - it has to be present to document a file, and no point in moving it to the second line since it's boilerplate. When @file isn't present, usually the Inkscape namespace is documented instead of the file. 2. Copyright information not included in the doxygen comment - it's not very useful there 3. Include guard after file description and copyright information - this is the current convention; it makes the placement consistent between headers and .cpp files 4. Completely nothing after vim modeline - otherwise it doesn't work, at least in gedit It seems the main issue of contention was 2, but I don't know what are the arguments for leaving the copyright info in the documentation. I don't think there are any copyright issues with the doxygen comments because the documentation is meant for internal use and not widely useful outside of the Inkscape developer community. Even if that's the case we could put a (C) notice on the main page so that other pages are not cluttered with duplicated information. Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Doxygen-conventions-tp20389927p20389927.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

6 8

A lot random crashes in recent SVN version
by Vladimir Savic 10 Nov '08

10 Nov '08

Note: Subject of this mail is not a complaint. I just wanted to bring this to focus. Here's the backtrace of one that looks like snapping related. I can repeat these crashes, but it happens mostly while dragging objects around and panning using middle mouse button. BTW, Looks like one needs to press middle mouse button absolutely still for some time in order to pan around. Also doesn't happen all the time, but when it does, that's the workaround. At least here. Regards, Vlada inkscape: /usr/include/boost/optional/optional.hpp:578: typename boost::optional_detail::optional_base<T>::reference_type boost::optional<T>::get() [with T = NR::Rect]: Assertion `this->is_initialized()' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f641eee6700 (LWP 28144)] 0x00007f64172865c5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f64172865c5 in raise () from /lib64/libc.so.6 #1 0x00007f6417287bb3 in abort () from /lib64/libc.so.6 #2 0x00007f641727f1e9 in __assert_fail () from /lib64/libc.so.6 #3 0x00000000005a250e in Inkscape::ObjectSnapper::_collectPaths (this=0x1b26ec8, t=<value optimized out>, first_point=<value optimized out>) at /usr/include/boost/optional/optional.hpp:578 #4 0x00000000005a255d in Inkscape::ObjectSnapper::_snapPaths (this=0x6df0, sc=@0x7fff26f38de0, t=@0x6df0, p=@0xffffffffffffffff, first_point=@0x10171dc0, unselected_nodes=0x7f64175a89d0, selected_path=0x0) at object-snapper.cpp:400 #5 0x00000000005a2dd3 in Inkscape::ObjectSnapper::freeSnap (this=0x1b26ec8, sc=@0x7fff26f38de0, t=@0x7fff26f38ddc, p=@0x8f2fbf0, first_point=@0x7fff26f38dd8, bbox_to_snap=@0x7fff26f39100, it=0x10e7ca30, unselected_nodes=0x0) at object-snapper.cpp:587 #6 0x00000000005994b7 in SnapManager::freeSnap (this=0x1b26ea8, point_type=2, p=@0x8f2fbf0, first_point=true, bbox_to_snap=@0x7fff26f39100) at snap.cpp:163 #7 0x000000000059a355 in SnapManager::_snapTransformed (this=0x1b26ea8, type=2, points=@0x10e7ca90, pointer=@0x10e7cd68, constrained=false, constraint=@0x7fff26f39320, transformation_type=SnapManager::TRANSLATION, transformation=@0x7fff26f396c0, origin=@0x7fff26f39350, dim=Geom::X, uniform=false) at snap.cpp:449 #8 0x000000000059ad95 in SnapManager::freeSnapTranslation (this=0x6df0, point_type=6, p=@0xffffffffffffffff, pointer=@0x10171dc0, tr=<value optimized out>) at snap.cpp:601 #9 0x0000000000595545 in Inkscape::SelTrans::moveTo (this=0x10e7ca10, xy=<value optimized out>, state=<value optimized out>) at seltrans.cpp:1406 #10 0x000000000058d519 in sp_select_context_root_handler (event_context=0x1846b9c0, event=0x10241f40) at select-context.cpp:537 #11 0x000000000053e4a2 in sp_event_context_root_handler (event_context=0x6df0, event=0x6df0) at event-context.cpp:892 #12 0x00000000007b53d4 in sp_marshal_INT__POINTER_POINTER (closure=0x20c9c00, return_value=0x7fff26f39de0, n_param_values=<value optimized out>, param_values=0x7fff26f39be0, invocation_hint=<value optimized out>, marshal_data=0x525e20) at helper/sp-marshal.cpp:475 #13 0x00007f641c87e20d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #14 0x00007f641c89208c in ?? () from /usr/lib64/libgobject-2.0.so.0 #15 0x00007f641c893392 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #16 0x00007f641d797ff5 in gtk_signal_emit () from /usr/lib64/libgtk-x11-2.0.so.0 #17 0x0000000000775c3c in sp_canvas_arena_send_event (arena=0x2071480, event=0x10241f40) at display/canvas-arena.cpp:335 #18 0x0000000000775ca6 in sp_canvas_arena_event (item=<value optimized out>, event=0x10241f40) at display/canvas-arena.cpp:322 #19 0x00000000007b56a0 in sp_marshal_BOOLEAN__POINTER (closure=0x1006970, return_value=0x7fff26f3a470, n_param_values=<value optimized out>, param_values=0x7fff26f3a270, invocation_hint=<value optimized out>, marshal_data=0x775c60) at helper/sp-marshal.cpp:352 #20 0x00007f641c87e20d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #21 0x00007f641c891d6d in ?? () from /usr/lib64/libgobject-2.0.so.0 #22 0x00007f641c893392 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #23 0x00007f641d797ff5 in gtk_signal_emit () from /usr/lib64/libgtk-x11-2.0.so.0 #24 0x000000000078f950 in emit_event (canvas=<value optimized out>, event=<value optimized out>) at display/sp-canvas.cpp:1344 #25 0x0000000000791755 in sp_canvas_snap_watchdog_callback (data=<value optimized out>) at display/sp-canvas.cpp:1678 #26 0x00007f641b1a40ab in ?? () from /usr/lib64/libglib-2.0.so.0 #27 0x00007f641b1a393a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #28 0x00007f641b1a7040 in ?? () from /usr/lib64/libglib-2.0.so.0 #29 0x00007f641b1a750d in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #30 0x00007f641d72e977 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #31 0x00000000004527c9 in sp_main_gui (argc=1, argv=0x7fff26f3aa48) at main.cpp:855 #32 0x0000000000452c8e in main (argc=1, argv=0x7fff26f3aa48) at main.cpp:665 (gdb)

2 2

LPE on groups with shapes
by unknown＠example.com 09 Nov '08

09 Nov '08

Hi all, Did group LPE ever work on shapes in a group? I.e. I have a group with stars in it, then apply bendpath on the group. The SVG is correct, but Inkscape displays the stars unbent. It's because of this here: static void sp_star_update (SPObject *object, SPCtx *ctx, guint flags) { if (flags & (SP_OBJECT_MODIFIED_FLAG | SP_OBJECT_STYLE_MODIFIED_FLAG | SP_OBJECT_VIEWPORT_MODIFIED_FLAG)) { sp_shape_set_shape ((SPShape *) object); } if (((SPObjectClass *) parent_class)->update) ((SPObjectClass *) parent_class)->update (object, ctx, flags); } during an 'update', sp_shape_set_shape is called again, which resets the shape's curve of the group-lpe calculation... (if i comment that line out, group lpe works fine...) Can someone help me on this one? What's the solution? Cheers, Johan

1 0

2geom update: new Rect and OptRect
by unknown＠example.com 08 Nov '08

08 Nov '08

Hi all, I just updated 2geom in our trunk. It contains the 'new' Rect and OptRect (and Interval and OptInterval). Geom::Rect can no longer be empty. It *always* contains a rectangle. Geom::OptRect contains a rect or nothing (which means an empty rect). The same holds for Geom::Interval and Geom::OptInterval. For example, boundingbox functions return an OptRect. You have to check whether it is empty or not, before you use the values in the Rect. If you didn't and turns out the bbox is empty, Inkscape will crash :-) Note that Rect's no longer have the method 'isEmpty'. Rect's do have the 'hasZeroArea' method. If this is true, the Rect contains a single point, like a (0,0)-(0,0) rectangle. It's not empty, it contains one point (0,0). (OptRect and OptInterval have the same usage as boost::optional<Rect>) I made Inkscape compile with this update, and tried to fix cases where there was not an explicit empty check. I may have introduced/uncovered bugs, sorry for that. Let us know about what you've found. Cheers, Johan

3 3

[Fwd: [CREATE] Suggested dates for LGM 2009 Montreal]
by Jon Phillips 08 Nov '08

08 Nov '08

Hi all, please see below about possible dates for LGM 2009. Please do reply to this thread if concerns or high-fives on and/or join the Create mailing list where we are hammering this all out. http://create.freedesktop.org Jon -------- Forwarded Message -------- > From: Louis Desjardins <louis.desjardins@...400...> > To: Create ML <create@...626...> > Subject: [CREATE] Suggested dates for LGM 2009 Montreal > Date: Fri, 7 Nov 2008 17:23:39 -0500 > > Hi all, > > Here are the best possible dates for LGM 2009. > > May 6-7-8-9, 2009. > > LGM would start on Wednesday morning and end on Saturday, end of the > day! (maybe with a party?!?!) > > Before we make that the official dates, anyone with serious concerns > about those dates, please speak up asap! > > Side note : we "could" move that from 7-10 including Sunday instead of > Wednesday. But why not take Sunday to visit... or relax... of have a > beer on a terrasse!!! :-) Or a poutine! ;-) > > Anyway, you let me know! > > Cheers!!! > > Louis > > -- > Louis Desjardins > Organiser > Libre Graphics Meeting 2009 - Montréal > _______________________________________________ > CREATE mailing list > CREATE@...626... > http://lists.freedesktop.org/mailman/listinfo/create -- Jon Phillips San Francisco, CA + Guangzhou + Beijing GLOBAL +1.415.830.3884 CHINA +86.1.360.282.8624 jon@...235... http://www.rejon.org IM/skype: kidproto Jabber: rejon@...896... IRC: rejon@...897...

1 0

locking objects on canvas
by ryrych＠...400... 07 Nov '08

07 Nov '08

hello! I create many objects on canvas without using of layers. Sometimes it is impossible to get any object. Inkscape has option allows us to lock object but this is very uncomfortable. Also that doesn't enable us to unlock particular object. Have you ever thought about adding new feature - locking/unlocking object on canvas like in Corel Draw? This is very cool stuff. It doesn't exclude functionality of layers but adds possibility of creating simple things in simple way. Think about icons. Many icons are created on one layer. But managing such objects in further future is terrible. I propose to add new entry to context menu. Clicking on it will show a small padlock on object (like in Corel). I hope that isn't hard to coding but makes sense in my opinion. I also hope I made myself clear. :) cheers, Wojtek Ryrych

3 2

build break
by Bob Jamison 07 Nov '08

07 Nov '08

Hi all, Just wanted to let people know that the build needs a couple of files tweaked for it to succeed: src/ui/dialog/input.cpp src/ui/dialog/tiledialog.cpp It's minor for both. They just need the lines added: #ifdef HAVE_CONFIG_H #include "config.h" #endif I would have done it myself, but when I svn upped to see if it had been fixed yet by somebody else, I got a fresh copy of verbs.h instead. (Which means: compile everything!) So maybe someone else can do it? Thanks! bob

2 1