Hi,
I just checked in a new version of my mesh branch. There was some major restructuring to use a simple array of nodes for the internal representation rather than the complicated side and corner classes I had before. This was motivated by adding support for tensor meshes which naturally calls for an array. Tensor meshes were added as an experiment to see if they would help in smoothing color transitions across patch boundaries (they don't seem to help very much) and are not envisioned to be part of the SVG specification for meshes.
New/newish features:
Corner operations:
Ctrl-B: Toggle selected patch sides between linear and curve. (Select both corner nodes of side to select side.)
Ctrl-C: Attempt to convert selected sides into elliptical arcs by changing the length of the Bezier handles.
Ctrl-G: Toggle on/off tensor points for selected patches. (Select all four corner nodes of a patch to select patch.)
Ctrl-J: Attempt to smooth color transition around a corner by changing length of Bezier handles. This needs lots of work to make it truly useful.
Ctrl-K: Sample colors underneath mesh at corner nodes. For nodes at edge of mesh, move sample point inside mesh.
Older features:
1. Create a simple one patch square mesh the size of an objects bounding box. (Select the third button on the Gradient Tool-Tool Bar and then click-drag on object. You won't see a change as the default mesh has all four corner colors set to the former object color. Click on object again to see mesh handles.)
2. Drag corner nodes (diamonds).
3. Change color of corner nodes.
4. Drag handles (circles). There is no indication of what handle belongs with which corner node or path so it can be confusing. And all handles are shown. (Should be able to toggle on/off handle visibility.)
5. Divide a row or column of patches into two rows or columns. (Double click on the lines connecting corner nodes. Double clicking elsewhere may lead to a crash.) The row/column will be split at the place you click.
6. Save the mesh. The mesh is saved in the proposed SVG standard format (likely to change).
7. Read in saved meshes.
Bugs:
* Frequent crashes. * Changing node color isn't saved until a node is moved. * Linear patch sides are shown as non-linear when corner node moved. * Selected nodes become unselected when any of the corner operations are done. * etc.
Note, a trunk version of the Cairo rendering library is needed.
My branch can be found at:
https://code.launchpad.net/~tavmjong-free/inkscape/mesh
Tav
Hi,
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
Cheers, Josh
On Wed, Jan 11, 2012 at 5:16 AM, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I just checked in a new version of my mesh branch. There was some major restructuring to use a simple array of nodes for the internal representation rather than the complicated side and corner classes I had before. This was motivated by adding support for tensor meshes which naturally calls for an array. Tensor meshes were added as an experiment to see if they would help in smoothing color transitions across patch boundaries (they don't seem to help very much) and are not envisioned to be part of the SVG specification for meshes.
New/newish features:
Corner operations:
Ctrl-B: Toggle selected patch sides between linear and curve. (Select both corner nodes of side to select side.)
Ctrl-C: Attempt to convert selected sides into elliptical arcs by changing the length of the Bezier handles.
Ctrl-G: Toggle on/off tensor points for selected patches. (Select all four corner nodes of a patch to select patch.)
Ctrl-J: Attempt to smooth color transition around a corner by changing length of Bezier handles. This needs lots of work to make it truly useful.
Ctrl-K: Sample colors underneath mesh at corner nodes. For nodes at edge of mesh, move sample point inside mesh.
Older features:
- Create a simple one patch square mesh the size of an objects bounding
box. (Select the third button on the Gradient Tool-Tool Bar and then click-drag on object. You won't see a change as the default mesh has all four corner colors set to the former object color. Click on object again to see mesh handles.)
Drag corner nodes (diamonds).
Change color of corner nodes.
Drag handles (circles). There is no indication of what handle belongs
with which corner node or path so it can be confusing. And all handles are shown. (Should be able to toggle on/off handle visibility.)
- Divide a row or column of patches into two rows or columns. (Double
click on the lines connecting corner nodes. Double clicking elsewhere may lead to a crash.) The row/column will be split at the place you click.
- Save the mesh. The mesh is saved in the proposed SVG standard format
(likely to change).
- Read in saved meshes.
Bugs:
- Frequent crashes.
- Changing node color isn't saved until a node is moved.
- Linear patch sides are shown as non-linear when corner node moved.
- Selected nodes become unselected when any of the corner operations are
done.
- etc.
Note, a trunk version of the Cairo rendering library is needed.
My branch can be found at:
https://code.launchpad.net/~tavmjong-free/inkscape/mesh
Tav
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
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
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
On Fri, 2012-01-20 at 13:43 -0800, Josh Andler wrote:
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
Should be fixed now (modulo F&S alpha... see below).
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.
Unlike an object than can have a separate fill opacity (i.e. alpha) and overall opacity (opacity slider), stops can only have one opacity. Whoever implemented stop opacity chose to only allow the opacity slider to change it. Since they are different for normal fill/stroke I don't think they should be the same for stops. The correct solution is probably to have the alpha slider grayed out when editing stop color.
Looking forward to your demo.
Tav
Just checked in some new features.
A fourth button (next to the mesh button) toggles on/off conical gradients creation. For this to be really useful, the ability to select nodes by clicking on patch sides needs to be implemented so that it is easy to select individual nodes at the center (where multiple nodes are on top of each other).
Two spinners set default number of rows and columns for new meshes.
Initial meshes for stars and arcs will match their geometry.
There have been a variety of bug fixes too... but don't expect stability!
Tav
On Wed, 2012-01-11 at 14:16 +0100, Tavmjong Bah wrote:
Hi,
I just checked in a new version of my mesh branch. There was some major restructuring to use a simple array of nodes for the internal representation rather than the complicated side and corner classes I had before. This was motivated by adding support for tensor meshes which naturally calls for an array. Tensor meshes were added as an experiment to see if they would help in smoothing color transitions across patch boundaries (they don't seem to help very much) and are not envisioned to be part of the SVG specification for meshes.
New/newish features:
Corner operations:
Ctrl-B: Toggle selected patch sides between linear and curve. (Select both corner nodes of side to select side.)
Ctrl-C: Attempt to convert selected sides into elliptical arcs by changing the length of the Bezier handles.
Ctrl-G: Toggle on/off tensor points for selected patches. (Select all four corner nodes of a patch to select patch.)
Ctrl-J: Attempt to smooth color transition around a corner by changing length of Bezier handles. This needs lots of work to make it truly useful.
Ctrl-K: Sample colors underneath mesh at corner nodes. For nodes at edge of mesh, move sample point inside mesh.
Older features:
- Create a simple one patch square mesh the size of an objects bounding
box. (Select the third button on the Gradient Tool-Tool Bar and then click-drag on object. You won't see a change as the default mesh has all four corner colors set to the former object color. Click on object again to see mesh handles.)
Drag corner nodes (diamonds).
Change color of corner nodes.
Drag handles (circles). There is no indication of what handle belongs
with which corner node or path so it can be confusing. And all handles are shown. (Should be able to toggle on/off handle visibility.)
- Divide a row or column of patches into two rows or columns. (Double
click on the lines connecting corner nodes. Double clicking elsewhere may lead to a crash.) The row/column will be split at the place you click.
- Save the mesh. The mesh is saved in the proposed SVG standard format
(likely to change).
- Read in saved meshes.
Bugs:
- Frequent crashes.
- Changing node color isn't saved until a node is moved.
- Linear patch sides are shown as non-linear when corner node moved.
- Selected nodes become unselected when any of the corner operations are
done.
- etc.
Note, a trunk version of the Cairo rendering library is needed.
My branch can be found at:
https://code.launchpad.net/~tavmjong-free/inkscape/mesh
Tav
On Mon, Jan 23, 2012 at 7:27 PM, Tavmjong Bah wrote:
A fourth button (next to the mesh button) toggles on/off conical gradients creation. For this to be really useful, the ability to select nodes by clicking on patch sides needs to be implemented so that it is easy to select individual nodes at the center (where multiple nodes are on top of each other).
Tav,
Having spent a couple of hours with this (well, mostly restarting after crashes :)) I have just one question.
Do we anyhow affect development of Cairo? Because I'd really hate to say to our users that we failed to deliver some new features/fixes due to lack of fixes in upstream version of Cairo that got into distributions.
Alexandre Prokoudine http://libregraphicsworld.org
On Tue, 2012-01-24 at 17:26 +0400, Alexandre Prokoudine wrote:
On Mon, Jan 23, 2012 at 7:27 PM, Tavmjong Bah wrote:
A fourth button (next to the mesh button) toggles on/off conical gradients creation. For this to be really useful, the ability to select nodes by clicking on patch sides needs to be implemented so that it is easy to select individual nodes at the center (where multiple nodes are on top of each other).
Tav,
Having spent a couple of hours with this (well, mostly restarting after crashes :)) I have just one question.
Well, I did warn you that the code was buggy... In these dire times, Save and Revert are your friends.
Do we anyhow affect development of Cairo? Because I'd really hate to say to our users that we failed to deliver some new features/fixes due to lack of fixes in upstream version of Cairo that got into distributions.
I'm not the person to ask. We could ask the Cairo list. The current version, 1.10, was first released in September of 2010 so one would think a new release would be due. The Scribus people must also be interested.
However, even if Cairo were to make a new release right now we would still have other issues. I will start a new thread for those.
Tav
On Tue, Jan 24, 2012 at 6:33 AM, Tavmjong Bah <tavmjong@...8...> wrote:
On Tue, 2012-01-24 at 17:26 +0400, Alexandre Prokoudine wrote:
Do we anyhow affect development of Cairo? Because I'd really hate to say to our users that we failed to deliver some new features/fixes due to lack of fixes in upstream version of Cairo that got into distributions.
I'm not the person to ask. We could ask the Cairo list. The current version, 1.10, was first released in September of 2010 so one would think a new release would be due. The Scribus people must also be interested.
However, even if Cairo were to make a new release right now we would still have other issues. I will start a new thread for those.
Just to make note of, using cairo trunk builds here (thanks to xorg-edgers ppa), most random crashes I've had with Inkscape trunk as well as the mesh branch throw a message in the terminal saying "stack smashing detected" followed by a line referencing cairo. Whether that's us using cairo incorrectly or cairo trunk having some painful bugs, I don't really know. Most of the odd triggers that do this with trunk don't trigger it with the 0.48.x branch (and it's also built against the same cairo, we just don't use it as extensively).
Cheers, Josh
Oooops, replace Ctrl by Alt below!
On Wed, 2012-01-11 at 14:16 +0100, Tavmjong Bah wrote:
Hi,
I just checked in a new version of my mesh branch. There was some major restructuring to use a simple array of nodes for the internal representation rather than the complicated side and corner classes I had before. This was motivated by adding support for tensor meshes which naturally calls for an array. Tensor meshes were added as an experiment to see if they would help in smoothing color transitions across patch boundaries (they don't seem to help very much) and are not envisioned to be part of the SVG specification for meshes.
New/newish features:
Corner operations:
Ctrl-B: Toggle selected patch sides between linear and curve. (Select both corner nodes of side to select side.)
Ctrl-C: Attempt to convert selected sides into elliptical arcs by changing the length of the Bezier handles.
Ctrl-G: Toggle on/off tensor points for selected patches. (Select all four corner nodes of a patch to select patch.)
Ctrl-J: Attempt to smooth color transition around a corner by changing length of Bezier handles. This needs lots of work to make it truly useful.
Ctrl-K: Sample colors underneath mesh at corner nodes. For nodes at edge of mesh, move sample point inside mesh.
Older features:
- Create a simple one patch square mesh the size of an objects bounding
box. (Select the third button on the Gradient Tool-Tool Bar and then click-drag on object. You won't see a change as the default mesh has all four corner colors set to the former object color. Click on object again to see mesh handles.)
Drag corner nodes (diamonds).
Change color of corner nodes.
Drag handles (circles). There is no indication of what handle belongs
with which corner node or path so it can be confusing. And all handles are shown. (Should be able to toggle on/off handle visibility.)
- Divide a row or column of patches into two rows or columns. (Double
click on the lines connecting corner nodes. Double clicking elsewhere may lead to a crash.) The row/column will be split at the place you click.
- Save the mesh. The mesh is saved in the proposed SVG standard format
(likely to change).
- Read in saved meshes.
Bugs:
- Frequent crashes.
- Changing node color isn't saved until a node is moved.
- Linear patch sides are shown as non-linear when corner node moved.
- Selected nodes become unselected when any of the corner operations are
done.
- etc.
Note, a trunk version of the Cairo rendering library is needed.
My branch can be found at:
https://code.launchpad.net/~tavmjong-free/inkscape/mesh
Tav
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (5)
-
Alex Valavanis -
Alexandre Prokoudine -
Josh Andler -
Tavmjong Bah -
~suv