Hey Tavmjong,
Thanks! I've been playing around (mostly today) and it seems that transparency is causing crashes very consistently for me. I was hoping to demo this over the weekend and stay up all night making a really intricate picture (transparency was needed for what I had in mind). I still plan to see what I can whip up later and will share the results, I just can't promise it will wow anyone. :)
Anyway, I just wanted to throw the backtrace your way and give you the steps to reproduce. This could very well be a cairo bug, but it looks to me more like it's in style handling on our end.
Step 1: Create mesh Step 2: Select mesh control/corner point Step 3: In F&S dialog try to modify Alpha value, it bounces right back to previous position Step 4: Try to modify Opacity value (either in F&S dialog or main window bottom status bar widget) Crash
Observation: In other gradient types it appears that in the F&S dialog does not keep Alpha/Opacity locked together even though they change the same value in a style (which is a complete assumption on my part). Note this is editing gradients stops/control points, not on an object proper. Whichever slider (Alpha or Opacity) that you use last sets the new alpha value and the other slider stays where it was. Either way, this seems like a bug in trunk afaict, I may be incorrect though.
From GDB:
Program received signal SIGSEGV, Segmentation fault. SPIPaint::read (this=0x7fffffffcb10, str=0x0, style=..., document=0x0) at style.cpp:3437 3437 while (g_ascii_isspace(*str)) { (gdb) bt #0 SPIPaint::read (this=0x7fffffffcb10, str=0x0, style=..., document=0x0) at style.cpp:3437 #1 0x0000000000901770 in sp_item_gradient_stop_set_style ( item=<optimized out>, point_type=<optimized out>, point_i=4, fill_or_stroke=<optimized out>, stop=<optimized out>) at gradient-chemistry.cpp:776 #2 0x0000000000480ed6 in GrDrag::styleSet (this=0x30a2f10, css=<optimized out>) at gradient-drag.cpp:305 #3 0x00000000008d4085 in operator() (this=<synthetic pointer>, _A_slot=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:834 #4 operator* (this=<synthetic pointer>) at /usr/include/sigc++-2.0/sigc++/signal.h:306 #5 operator()<sigc::internal::slot_iterator_buf<sigc::internal::signal_emit1<bool, const SPCSSAttr*, StopOnTrue>, bool> > (last=..., first=..., this=0x7fffffffcdef) at ui/view/view.h:33 #6 sigc::internal::signal_emit1<bool, SPCSSAttr const*, StopOnTrue>::emit ( impl=<optimized out>, _A_a1=@...2742...) at /usr/include/sigc++-2.0/sigc++/signal.h:854 #7 0x00000000008d31c7 in emit (_A_a1=@...2742..., this=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:2781 #8 sp_desktop_set_style (desktop=0x1bc9c00, css=0x1c34c10, change=true, write_current=<optimized out>) at desktop-style.cpp:191 #9 0x0000000000882c0e in Inkscape::UI::Widget::SelectedStyle::on_opacity_changed (this=0x2fd5bc0) at ui/widget/selected-style.cpp:1147 #10 0x00007ffff5b825f8 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #11 0x00007ffff1c68364 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007ffff1c788f3 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x00007ffff1c7ffeb in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff1c801b2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff5f47159 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #16 0x00007ffff1c68364 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x00007ffff1c78615 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x00007ffff1c7ffeb in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x00007ffff1c801b2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x00007ffff5e1a40a in gtk_adjustment_value_changed () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #21 0x00007ffff5f472d9 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #22 0x00007ffff5f48a04 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #23 0x00007ffff5f4ab3b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #24 0x00007ffff6dc26e7 in Gtk::Widget::on_button_press_event(_GdkEventButton*) () from /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1 #25 0x00007ffff6dc5503 in Gtk::Widget_Class::button_press_event_callback(_GtkWidget*, _GdkEventButton*) () from /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1 #26 0x00007ffff5ed6c68 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #27 0x00007ffff1c68364 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x00007ffff1c78bfa in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x00007ffff1c7fecd in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #30 0x00007ffff1c801b2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #31 0x00007ffff5ff0bb1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #32 0x00007ffff5ed4e23 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #33 0x00007ffff5ed5183 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #34 0x00007ffff54b8fac in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #35 0x00007ffff16ac7da in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #36 0x00007ffff16acba0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #37 0x00007ffff16acf9a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x00007ffff5ed41b7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #39 0x000000000046e8e0 in sp_main_gui (argc=1, argv=0x7fffffffe1e8) at main.cpp:978 #40 0x00007ffff093030d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #41 0x000000000046d981 in _start ()
Thanks for your awesome work on this as always, I look forward to playing more in-depth.
Cheers, Josh
On Thu, Jan 12, 2012 at 6:06 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Patch applied. Thanks! Also fixed bug in toggling on tensor nodes.
Tav
On Thu, 2012-01-12 at 11:44 +0000, Alex Valavanis wrote:
Yes, it's a case of us being forced to switch to glib top-level headers for glib 2.31 support. It was fixed in lp:inkscape r10762 (patch attached). I *think* that's the only necessary change for now. At some point, I'll get round to top-level-ication of all the rest of the gnome library headers but they shouldn't cause any other build failures (yet!)
AV
On 12 January 2012 11:24, ~suv <suv-sf@...58...> wrote:
On 12/01/2012 03:24, Josh Andler wrote:
On 11/01/2012 14:16, Tavmjong Bah wrote:
My branch can be found at:
On Ubuntu Precise I'm getting the following when trying to compile, I don't hit it in either trunk or the 0.48.x branch... also, bzr status shows everything as being kosher.
CXX dir-util.o dir-util.cpp: In function ‘std::string sp_relative_path_from_path(const string&, const string&)’: dir-util.cpp:21:42: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:27:36: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp: In function ‘const char* sp_extension_from_path(const char*)’: dir-util.cpp:54:31: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp: At global scope: dir-util.cpp:63:39: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp: In function ‘char* inkscape_rel2abs(const char*, const char*, char*, size_t)’: dir-util.cpp:74:16: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:95:18: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:100:22: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:111:20: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:119:33: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:129:33: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:141:27: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp: In function ‘char* inkscape_abs2rel(const char*, const char*, char*, size_t)’: dir-util.cpp:160:18: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:177:20: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:179:33: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:191:32: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp:196:20: error: ‘G_DIR_SEPARATOR’ was not declared in this scope dir-util.cpp: In function ‘gchar* prepend_current_dir_if_relative(const gchar*)’: dir-util.cpp:230:33: error: ‘g_get_current_dir’ was not declared in this scope make[3]: *** [dir-util.o] Error 1
This was fixed (or addressed) in trunk already, see Bug #901599 https://bugs.launchpad.net/inkscape/+bug/901599 “dir-util.o fails to build with glib 2.31 in Ubuntu precise”
The relevant revision in trunk appears to have been on 2011-12-08: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10762 but maybe there are additional related commits (@Alex, could you comment?).
AFAICT, the last merge of trunk into the mesh branch was done some time ago (2011-10-31): http://bazaar.launchpad.net/~tavmjong-free/inkscape/mesh/changes
<off-topic> Yesterday, I tried for the first time and succeeded to build the mesh branch on OS X 10.7.2 Lion, with cairo from git master ;) </off-topic>
~suv