Knots vs CtrlPoint
Developers,
I've just been scrutinising the code for guidelines, specifically the code that draws the little circle indicating the main co-ordinate of the guideline.
What it looks like is back in 2009 the code src/display/sp-ctrlpoint code was a clone of the much older original code in src/display/sp-ctrlquadr which we've had since at least 2005.
ctrlquadr draws a square using cairo, used by ui/tools/text-tool only ctrlpoint draws a circle using cairo, used by display/guideline only
If we could replace these two instances with Knot objects, we should be able to remove this code completely? (11.8KB, 1150 lines) Are there any land minds you are aware of with this code? (somewhere it's being used without being able to find it?)
For comparison, SPCtrlLine and SPCtrlCurve are used by pen-tool, mesh-tool, gradient-tool, text-tool and the measure-tool. So they're very well used in comparison.
Best Regards, Martin Owens
From a conversation with Krzysztof there is also a goal to replace Knot (if by Knot you mean SPKnot) entirely with UI::ControlPoint, UI::SelectableControlPoint, and UI::Node since SPKnot had certain aspects that aren’t well designed. I can forward the conversation to you but it’s started as a thread in the mailing list with topic: “SPKnot, KnotHolderEntity, and KnotHolder”.
Regards, _______________________ Papoj "Hua" Thamjaroenporn papojt@...3117...
On Dec 6, 2015, at 6:46 PM, Martin Owens <doctormo@...400...> wrote:
Developers,
I've just been scrutinising the code for guidelines, specifically the code that draws the little circle indicating the main co-ordinate of the guideline.
What it looks like is back in 2009 the code src/display/sp-ctrlpoint code was a clone of the much older original code in src/display/sp-ctrlquadr which we've had since at least 2005.
ctrlquadr draws a square using cairo, used by ui/tools/text-tool only ctrlpoint draws a circle using cairo, used by display/guideline only
If we could replace these two instances with Knot objects, we should be able to remove this code completely? (11.8KB, 1150 lines) Are there any land minds you are aware of with this code? (somewhere it's being used without being able to find it?)
For comparison, SPCtrlLine and SPCtrlCurve are used by pen-tool, mesh-tool, gradient-tool, text-tool and the measure-tool. So they're very well used in comparison.
Best Regards, Martin Owens
Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2015-12-06 at 21:23 -0500, Papoj Thamjaroenporn wrote:
From a conversation with Krzysztof there is also a goal to replace Knot (if by Knot you mean SPKnot) entirely with UI::ControlPoint, UI::SelectableControlPoint, and UI::Node since SPKnot had certain aspects that aren’t well designed. I can forward the conversation to you but it’s started as a thread in the mailing list with topic: “SPKnot, KnotHolderEntity, and KnotHolder”.
Thanks for the update Papoj.
My strategy would be if it's easier to copy something simple for SPKnot replacement, then it'll just join the queue for replacement later. If on the other hand the UI::ControlPoint already exists and is something it's easier to use instead, (i.e other parts of the code use it) then point me to that and I'll have a read. Might be something simple.
Martin,
Hi Martin,
I am exploring mainly the LPE section of the code and SPKnots are used everywhere in LPE effects. The UI::ControlPoint that Krzysztof wrote has been used mainly in the UI part so far, I think, but not much in the LPE where we define nodes for effect interaction mostly via SPKnot, KnotHolder, and KnotHolderEntity. I might eventually work on replacing them with UI::ControlPoint but don’t have a specific timeline in my mind.
Regards, _______________________ Papoj "Hua" Thamjaroenporn papojt@...3117...
On Dec 7, 2015, at 12:16 AM, Martin Owens <doctormo@...400...> wrote:
On Sun, 2015-12-06 at 21:23 -0500, Papoj Thamjaroenporn wrote:
From a conversation with Krzysztof there is also a goal to replace Knot (if by Knot you mean SPKnot) entirely with UI::ControlPoint, UI::SelectableControlPoint, and UI::Node since SPKnot had certain aspects that aren’t well designed. I can forward the conversation to you but it’s started as a thread in the mailing list with topic: “SPKnot, KnotHolderEntity, and KnotHolder”.
Thanks for the update Papoj.
My strategy would be if it's easier to copy something simple for SPKnot replacement, then it'll just join the queue for replacement later. If on the other hand the UI::ControlPoint already exists and is something it's easier to use instead, (i.e other parts of the code use it) then point me to that and I'll have a read. Might be something simple.
Martin,
On 2015-12-07 24:46 (+0100), Martin Owens wrote:
I've just been scrutinising the code for guidelines, specifically the code that draws the little circle indicating the main co-ordinate of the guideline.
What it looks like is back in 2009 the code src/display/sp-ctrlpoint code was a clone of the much older original code in src/display/sp-ctrlquadr which we've had since at least 2005.
ctrlquadr draws a square using cairo, used by ui/tools/text-tool only ctrlpoint draws a circle using cairo, used by display/guideline only
If we could replace these two instances with Knot objects, we should be able to remove this code completely? (11.8KB, 1150 lines) Are there any land minds you are aware of with this code? (somewhere it's being used without being able to find it?)
For comparison, SPCtrlLine and SPCtrlCurve are used by pen-tool, mesh-tool, gradient-tool, text-tool and the measure-tool. So they're very well used in comparison.
After * Revision 14523: Remove CtrlPoint and replace with SPKnot https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14523
the anchors of guides (unlocked or locked) no longer hide along with the guide line itself. Any chance this could be changed to match the old behavior?
Regards, V
On 2015-12-10 11:11 (+0100), su_v wrote:
On 2015-12-07 24:46 (+0100), Martin Owens wrote:
<...>
If we could replace these two instances with Knot objects, we should be able to remove this code completely? (11.8KB, 1150 lines) Are there any land minds you are aware of with this code? (somewhere it's being used without being able to find it?)
<...>
After
- Revision 14523: Remove CtrlPoint and replace with SPKnot https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14523
the anchors of guides (unlocked or locked) no longer hide along with the guide line itself. Any chance this could be changed to match the old behavior?
Nevermind - Mc just committed a fix in r14524, thx.
Regards, V
Hi is posibol to show the guide dialog on knot double click? Anyway it looks very well, good work Martin!
El jue, 10-12-2015 a las 11:27 +0100, su_v escribió:
On 2015-12-10 11:11 (+0100), su_v wrote:
On 2015-12-07 24:46 (+0100), Martin Owens wrote:
<...>
If we could replace these two instances with Knot objects, we should be able to remove this code completely? (11.8KB, 1150 lines) Are there any land minds you are aware of with this code? (somewhere it's being used without being able to find it?)
<...>
After
- Revision 14523: Remove CtrlPoint and replace with SPKnot
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revisio n/14523
the anchors of guides (unlocked or locked) no longer hide along with the guide line itself. Any chance this could be changed to match the old behavior?
Nevermind - Mc just committed a fix in r14524, thx.
Regards, V
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2015-12-10 at 13:25 +0100, Jabier Arraiza wrote:
Hi is posibol to show the guide dialog on knot double click? Anyway it looks very well, good work Martin!
So many interesting wrinkles. I just noticed that dragging the node back onto the ruler doesn't delete the guide. (although dragging the line does) Probably a signal thing.
Thanks everyone for testing.
Martin,
On 2015-12-10 16:45 (+0100), Martin Owens wrote:
On Thu, 2015-12-10 at 13:25 +0100, Jabier Arraiza wrote:
Hi is posibol to show the guide dialog on knot double click? Anyway it looks very well, good work Martin!
So many interesting wrinkles. I just noticed that dragging the node back onto the ruler doesn't delete the guide. (although dragging the line does) Probably a signal thing.
Thanks everyone for testing.
Opening a document (Inkscape SVG file) with guides defined directly (e.g. via command line argument) crashes (rev >= 14523).
Steps to reproduce: 1) launch trunk 2) draw a guide from the ruler 3) save drawing, quit 4) relaunch inkscape with just saved file --> crash
Backtrace: https://gist.github.com/su-v/95d614d0c9e74cf52c64
Workaround for affected trunk users: launch inkscape first, then open the file from within Inkscape.
Regards, V
On Thu, 2015-12-10 at 17:13 +0100, su_v wrote:
Opening a document (Inkscape SVG file) with guides defined directly (e.g. via command line argument) crashes (rev >= 14523).
Steps to reproduce:
- launch trunk
- draw a guide from the ruler
- save drawing, quit
- relaunch inkscape with just saved file
--> crash
Backtrace: https://gist.github.com/su-v/95d614d0c9e74cf52c64
It's because SP_ACTIVE_DESKTOP is NULL at the time the SPKnot is created.
Does anyone have any ideas how to attack this issue?
Martin,
I just commit a fix, I hope is not a problem is a short diff.
Cheers, Jabier.
El jue, 10-12-2015 a las 15:07 -0500, Martin Owens escribió:
On Thu, 2015-12-10 at 17:13 +0100, su_v wrote:
Opening a document (Inkscape SVG file) with guides defined directly (e.g. via command line argument) crashes (rev >= 14523).
Steps to reproduce:
- launch trunk
- draw a guide from the ruler
- save drawing, quit
- relaunch inkscape with just saved file
--> crash
Backtrace: https://gist.github.com/su-v/95d614d0c9e74cf52c64
It's because SP_ACTIVE_DESKTOP is NULL at the time the SPKnot is created.
Does anyone have any ideas how to attack this issue?
Martin,
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-12-11 02:27 (+0100), Jabiertxo Arraiza Cenoz wrote:
I just commit a fix, I hope is not a problem is a short diff.
r14525 still crashes when loading a file with a guide from the command line (same steps).
New backtrace: https://gist.github.com/su-v/5bf662f1c47ea572be45
Regards, V
El jue, 10-12-2015 a las 15:07 -0500, Martin Owens escribió:
On Thu, 2015-12-10 at 17:13 +0100, su_v wrote:
Opening a document (Inkscape SVG file) with guides defined directly (e.g. via command line argument) crashes (rev >= 14523).
Steps to reproduce:
- launch trunk
- draw a guide from the ruler
- save drawing, quit
- relaunch inkscape with just saved file
--> crash
Backtrace: https://gist.github.com/su-v/95d614d0c9e74cf52c64
It's because SP_ACTIVE_DESKTOP is NULL at the time the SPKnot is created.
Does anyone have any ideas how to attack this issue?
Martin,
On Fri, 2015-12-11 at 02:27 +0100, Jabiertxo Arraiza Cenoz wrote:
I just commit a fix, I hope is not a problem is a short diff.
Thanks Jabier, I've added some cleanup since there's no point in doing the setup twice.
While playing with the code I noticed that it might be possible to use the new knot to do the whole arbitrary angle thing in the future. Obviously it'd be a full feature with a decent amount of work. But probably useful if the snapping could work (my play through setting the normal point was interesting but pointed out that snapping wasn't great, the point isn't saved in the svg, and doesn't even make much user sense atm)
Something to ponder for anyone wanting something to hack on in inkscape.
Best Regards, Martin Owens
On 2015-12-11 03:45 (+0100), Martin Owens wrote:
On Fri, 2015-12-11 at 02:27 +0100, Jabiertxo Arraiza Cenoz wrote:
I just commit a fix, I hope is not a problem is a short diff.
Thanks Jabier, I've added some cleanup since there's no point in doing the setup twice.
r14526 crashes when loading a file with a hidden guide line (now both from the command line, and when loaded from within Inkscape). Loading a file with visibles guide lines otoh seems to have been fixed in r14526.
Steps to reproduce: 1) launch trunk 2) drag a guide from one of the rulers 3) hide guides 4) save and quit inkscape 5) relaunch inkscape 6) open previously saved file --> crash
New backtraces: https://gist.github.com/su-v/569b7fc777ad351751f4
Regards, V
On Fri, 2015-12-11 at 02:27 +0100, Jabiertxo Arraiza Cenoz wrote:
I just commit a fix, I hope is not a problem is a short diff.
Jabier, I think you are right about moving the knot from display/guideline to sp-guide, being able to call the guideline signal on pass through from the node requires access to the SPGuide object which isn't available in SPGuideline. So the ruler stuff (and even the snap to origin) can't work yet.
It's actually very interesting how nasty SPKnot is if there's no desktop yet. I wonder if that's the thing we need to fix, so we have a on ready or some other signal to notify us when we can actually display things.
Any ideas?
Martin,
It's actually very interesting how nasty SPKnot is if there's no desktop yet. I wonder if that's the thing we need to fix, so we have a on ready or some other signal to notify us when we can actually display things.
Can be an adition so you were thinking in implementing emiting from desktop/desktop-widget and a signal connect for each class you want to check (ex:SPKnot)?
Cheers, Jabier.
Out of developer curiousity, is Inkscape using state machines / signals to structure tools, entities and so on?
On 11 December 2015 at 13:23, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
It's actually very interesting how nasty SPKnot is if there's no desktop yet. I wonder if that's the thing we need to fix, so we have a on ready or some other signal to notify us when we can actually display things.
Can be an adition so you were thinking in implementing emiting from desktop/desktop-widget and a signal connect for each class you want to check (ex:SPKnot)?
Cheers, Jabier.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 12/11/2015 12:02 PM, Martin Owens wrote:
It's actually very interesting how nasty SPKnot is if there's no desktop yet. I wonder if that's the thing we need to fix, so we have a on ready or some other signal to notify us when we can actually display things.
I think the order should be to create the Desktop and have it ready before even starting to ask if we will load a file or a default.svg template or anything.
But sometimes ther is no desktop, for example rendering to PNG from commandline.
El vie, 11-12-2015 a las 16:30 +0100, Marc Jeanmougin escribió:
On 12/11/2015 12:02 PM, Martin Owens wrote:
It's actually very interesting how nasty SPKnot is if there's no desktop yet. I wonder if that's the thing we need to fix, so we have a on ready or some other signal to notify us when we can actually display things.
I think the order should be to create the Desktop and have it ready before even starting to ask if we will load a file or a default.svg template or anything.
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (7)
-
Jabier Arraiza -
Jabiertxo Arraiza Cenoz -
Marc Jeanmougin -
Martin Owens -
Olof Bjarnason -
Papoj Thamjaroenporn -
su_v