Hi again suv. I test my debian repo version of inkscape and both releases of BSpline... and i couldent see diferences in brehabiours on right click.

When you click the right button, the last segment is, in the three cases deleted, but because have live effects while drawing, the resulting path is like before/when you start this last segment.

Maybe i lost somethig?

Hi, Jabier.

-----Mensaje original----- De: ~suv <suv-sf@...58...> Para: jabier.arraiza@...2893... Cc: inkscape-devel inkscape-devel@lists.sourceforge.net Asunto: Re: [Inkscape-devel] Help need whith branch compile in windows. Fecha: Thu, 14 Feb 2013 07:11:16 +0100

On 2013-02-14 01:11 +0100, Jabiertxo Arraiza Cenoz wrote:

Hi to all. Some users have problem with the BSpline and Spirolive branch for windows. Brainless offer to me compile it to windows.

Its hard, but finaly hi locate the problem whith some fonts, he think is solved and finaly can make the executable.

The build issues related to the compiler version have been sorted out: apparently the Windows installer of TDM-GCC has an odd concept of usability and happily defaults to installing a newer version (4.7.1) instead of the one specifically downloaded (4.6.1).

But other user have the same problem, whith fonts and when open preferences dialog, inkscape crash.

I think the problem isnt in the modifications added to the branch... Any body whith knoweledge in windowd, and some english..., could help to me to help this users? Or do directly.

Post: http://www.inkscapeforum.com/viewtopic.php?f=11&t=13496

AFAIU Druban repeated at least twice that the same problems occur with unmodified development snapshot builds by UweSch and thus are neither related to Brainless' builds specifically, nor to your changes in the LiveSpiro+BSpline branch.

<off-topic> (your branch compiles and works fine on OS X btw - after a few quick tests I just miss that in LiveSpiro and BSpline mode the right mouse button doesn't finish the path in the same way as in the other existing modes ;-) ) </off-topic>

- Font warnings: The warnings about failing to load certain fonts seem related to recent changes in trunk >= 12105 (see also [1]), but AFAIU they don't cause Inkscape to crash. There have been a few reports about random crashes with the Windows port related to the font-menu changes [2], but - based on the 'steps to reproduce' in the bug reports - those crashes are always triggered by accessing the font drop-down list, and not when opening preferences or document properties.

[1] http://inkscape.13.n6.nabble.com/Font-family-drop-down-menu-change-tt4966042.html#a4966064 [2] https://bugs.launchpad.net/inkscape/+bug/1122374 https://bugs.launchpad.net/inkscape/+bug/1122839

- Corrupt preferences/user keymap file: The problem with corrupt preferences/keymap files had been mentioned by Druban earlier (late January, before the recent font-related changes, and with revisions earlier than r12089) [3] - at that time, I had tried to reproduce it but failed: using custom keyboard shortcuts created with trunk, and switching between stable and trunk versions didn't trigger crashes nor serious conflicts/file corruptions e.g. on OS X and Ubuntu 12.10. It would be helpful if Druban filed a report in the bug tracker and attach a zip archive with the default Inkscape preferences folder which worked without issues with development snapshot builds last year, and one that got "corrupted" after switching between recent development snapshot builds and latest stable 0.48.4, to allow further investigation.

[3] http://www.inkscapeforum.com/viewtopic.php?f=29&t=13430&p=51518&hilit=corrupted#p51518

- Crash when opening Inkscape Preferences / Document Properties: Probably I would have pointed to similar bug reports as Brainless already did in the forum topic [4]: maybe Druban's recent crashes are also related to/triggered by certain color profiles installed on that specific machine. IIRC Druban used to have a custom default template with a color profile linked in - maybe this also contributes to the mentioned problems. Again it could be helpful if Druban filed a new bug report (with zip archives of the inkscape preferences folder, including any relevant ICC color profiles if possible). Maybe JazzyNico or Alvin will then be able to reproduce the crashes on Windows and provide backtraces from gdb…

[4] https://bugs.launchpad.net/inkscape/+bug/498141 https://bugs.launchpad.net/inkscape/+bug/455894

On 13-3-2013 10:13, Jabier Arraiza wrote:

Is posibol the manipulation of original path from a live_effect code? For now you can edit the propieties of the LPE in all tools (fill,select,circle...) if the path is selected.

This sounds like a bad idea. Manipulating inkscape:original-d triggers running the live path effect code. So if that code manipulates original-d, it is very easy to end up in an infinite loop.

What exactly do you want to do?

Cheers, Johan

On 13-3-2013 19:40, Jabier Arraiza wrote:

Hi Joan.

Is for lpe-bspline. I want to update the handles of original path for reset all handles to a fixed position. Need it because the bspline lpe use the values of the handles to generate ths BSpline, so if I move handles width the node tool the bspline update too. I need if is posibol to do it whith the LPE widget this otherwise, whithout the node tool.

I think it is a good idea to be able to use the handles for LPE calculations! You could make the change to the handles upon applying the effect, using Effect::doOnApply(SPLPEItem const* lpeitem). However, as you can see, that method is now defined using const, meaning you are not allowed to change the path. It is safe to change the path (the method that calls doOnApply disables LPE calculation), but perhaps it is better to add it to the effect's LPE dialog buttons (so that one can reset the handles also after modifying them).

It is some work to add a button to the LPE widget, but not impossible. Upon pressing the button, it can take the desktop selection, and modify the path accordingly as you wish. To add a button, your LPE has to define its own virtual Gtk::Widget * newWidget(); and call Effect::newWidget() first, like so:

Gtk::Widget * YourLPE::newWidget() { Gtk::VBox * vbox = dynamic_castGtk::VBox*( Effect::newWidget() );

// create your button widget .......... vbox->pack_start(*widget, true, true, 2);

return dynamic_cast<Gtk::Widget *>(vbox); }

ciao, Johan

Hello Johan. Thanks for your help, I have a working code fot testing that create a new custom widget in the BSpline live effect of this branch: lp:~jabiertxof/inkscape/0.49.x+SpiroLive+BSpline.

Thanks to you, and ~suv poining, i undertand a little bit more about c++ and inkscape!

@~suv: Any sugestion/feedback more? Another branch testing?

Hi, Jabier.

-----Mensaje original----- De: Johan Engelen <jbc.engelen@...2592...> Para: jabier.arraiza@...2893... Cc: inkscape-devel@lists.sourceforge.net Asunto: Re: [Inkscape-devel] Manipulate original paths from a livepatheffect Fecha: Thu, 14 Mar 2013 00:12:51 +0100

On 13-3-2013 19:40, Jabier Arraiza wrote:

Hi Joan.

Is for lpe-bspline. I want to update the handles of original path for reset all handles to a fixed position. Need it because the bspline lpe use the values of the handles to generate ths BSpline, so if I move handles width the node tool the bspline update too. I need if is posibol to do it whith the LPE widget this otherwise, whithout the node tool.

I think it is a good idea to be able to use the handles for LPE calculations! You could make the change to the handles upon applying the effect, using Effect::doOnApply(SPLPEItem const* lpeitem). However, as you can see, that method is now defined using const, meaning you are not allowed to change the path. It is safe to change the path (the method that calls doOnApply disables LPE calculation), but perhaps it is better to add it to the effect's LPE dialog buttons (so that one can reset the handles also after modifying them).

It is some work to add a button to the LPE widget, but not impossible. Upon pressing the button, it can take the desktop selection, and modify the path accordingly as you wish. To add a button, your LPE has to define its own virtual Gtk::Widget * newWidget(); and call Effect::newWidget() first, like so:

Gtk::Widget * YourLPE::newWidget() { Gtk::VBox * vbox = dynamic_castGtk::VBox*( Effect::newWidget() );

// create your button widget .......... vbox->pack_start(*widget, true, true, 2);

return dynamic_cast<Gtk::Widget *>(vbox); }

ciao, Johan