Smooth transitions in Bézier paths
by Diederik van Lierop
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
12 years, 6 months
Doxygen conventions
by Krzysztof Kosiński
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.
12 years, 6 months
A lot random crashes in recent SVN version
by Vladimir Savic
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)
12 years, 6 months
LPE on groups with shapes
by unknown＠example.com
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
12 years, 6 months
2geom update: new Rect and OptRect
by unknown＠example.com
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
12 years, 6 months
[Fwd: [CREATE] Suggested dates for LGM 2009 Montreal]
by Jon Phillips
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...
12 years, 6 months
locking objects on canvas
by ryrych＠...400...
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
12 years, 6 months
build break
by Bob Jamison
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
12 years, 6 months
