Hi Diederik and others,
First of all, I am very sorry if I broke compile on Linux, please fix what needs to be fixed, I cannot check if it works! (makefile?)
I have just committed a new feature: temporary canvasitems. Now, it is possible to create a canvasitem, and pass it to SPDesktop saying it should be displayed for a certain timelength. When that time has elapsed, the object is automatically deleted.
To make a canvasitem temporary, do this: spdesktop->add_temporary_canvasitem(canvasitem, 2000); This will destroy the canvasitem automatically after 2000 milliseconds. One can also prematurely delete the canvasitem (handy for showing snapping). One should do this: Inkscape::Display::TemporaryItem * tempitem; tempitem = spdesktop->add_temporary_canvasitem(canvasitem, 2000); And then later on to remove the item: spdesktop->remove_temporary_canvasitem(tempitem); It is perfectly safe to call this function even after the 2 seconds have elapsed, because it checks whether the object has already been deleted or not.
In order to demonstrate and test the code, I have enabled the test LPEs, and added a Point parameter to lpe-Stacktest that is briefly flashed on-canvas when you press the edit oncanvas button. Draw a freehand path, apply lpe-'doEffect stack test', then press the edit oncanvas button next to the 'test' parameter; it should show a cross at the location of the parameter oncanvas. I have tested a bit, it *seems* bug-free... :)
Special request to Diederik: Can you use the code from /live_effects/parameter/point.cpp, method param_editOncanvas, to flash the location of a snap ? This was my main motivation for writing all this!
I hope people find other interesting things that can be briefly shown on canvas; like an arrow pointing to the parent object of a clone? :-)
Cheers, Johan
J.B.C.Engelen@...1578... wrote:
I have just committed a new feature: temporary canvasitems.
That's very cool!
Special request to Diederik: Can you use the code from /live_effects/parameter/point.cpp, method param_editOncanvas, to flash the location of a snap?
Yeah, very likely I can. I'm currently still working on some really nasty snapping bugs, but once I've tackled those this is the first RFE I will implement! Considering the current progress I'm making though, this might take some time :-(
Diederik
Perhaps you can point me to the file(s) where the snapping point is finally determined? I've forgotten the precise details.
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Diederik van Lierop Sent: zondag 2 maart 2008 16:56 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: temporary on-canvas indicators
J.B.C.Engelen@...1578... wrote:
I have just committed a new feature: temporary canvasitems.
That's very cool!
Special request to Diederik: Can you use the code from
/live_effects/parameter/point.cpp, method param_editOncanvas, to flash the location of a snap?
Yeah, very likely I can. I'm currently still working on some really nasty snapping bugs, but once I've tackled those this is the first RFE I will implement! Considering the current progress I'm making though, this might take some time :-(
Diederik
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
J.B.C.Engelen@...1578... wrote:
Perhaps you can point me to the file(s) where the snapping point is finally determined? I've forgotten the precise details.
Unfortunately it's not at a single location in our snapper code. For example, have a look at seltrans.cpp, around line 920:
// Snap along a suitable constraint vector from the origin. std::pair<NR::scale, bool> bb = m.constrainedSnapScale(Snapper::SNAPPOINT_BBOX, _bbox_points, it, s,
_origin_for_bboxpoints);
std::pair<NR::scale, bool> sn = m.constrainedSnapScale(Snapper::SNAPPOINT_NODE, _snap_points, it, s,
_origin_for_specpoints);
if (bb.second || sn.second) { // If we snapped to something /* Choose the smaller difference in scale. Since s[X] == s[Y] we can ** just compare difference in s[X]. */ double const bd = bb.second ? fabs(bb.first[NR::X] - s[NR::X]) : NR_HUGE; double const sd = sn.second ? fabs(sn.first[NR::X] - s[NR::X]) : NR_HUGE; s = (bd < sd) ? bb.first : sn.first; }
Here we call the snapmanager twice, and only after that it is decided which of the two results leads to the closest snap. So it's in seltrans were the flashing should be invoked. On two places in scaleRequest(), two in stretchRequest(), one in skewRequest(), etc. The code calculating which snap is the closest is different for each case, which makes merging of this code not very straightforward.
Besides, we might not always want something to flash, e.g. when dragging a single node in the node tool. It would be quite obvious in such a case what's snapping. When scaling a complex object though the flashing is really valuable.
Regards,
Diederik
Thanks Diederik,
Although it seems the snappers return the necessary displacement, and not the point to which they snapped. I propose to make the snappers return something like a SnapInfo struct:
struct SnapInfo { bool snapped; //did we snap? Geom::Point snaplocation; // to which point did we snap SnapType type; // some info about the sort of snap (tangential, node-on-node, whatever, this is future work of course) ... }
This assumes one always snaps to a *point* which is not always the case maybe. I'll wait a bit for you to work on it, I think you know more about it. I really just gave it a quick glance.
I do have a bugreport though: guides don't snap! the guideSnap function never gets past the check if it should snap at all, so it always returns Inkscape::SnappedPoint(p, NR_HUGE, 0, false). Can you look into this Diederik? Once guide snapping works, you'll see the snapindicator on-canvas :)
Cheers, Johan
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Diederik van Lierop Sent: zondag 2 maart 2008 17:20 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: temporary on-canvas indicators
J.B.C.Engelen@...1578... wrote:
Perhaps you can point me to the file(s) where the snapping
point is finally determined?
I've forgotten the precise details.
Unfortunately it's not at a single location in our snapper code. For example, have a look at seltrans.cpp, around line 920:
// Snap along a suitable constraint vector from the origin. std::pair<NR::scale, bool> bb =m.constrainedSnapScale(Snapper::SNAPPOINT_BBOX,
_bbox_points, it, s,
_origin_for_bboxpoints);
std::pair<NR::scale, bool> sn =m.constrainedSnapScale(Snapper::SNAPPOINT_NODE,
_snap_points, it, s,
_origin_for_specpoints);
if (bb.second || sn.second) { // If we snapped to something /* Choose the smaller difference in scale. Sinces[X] == s[Y] we can ** just compare difference in s[X]. */ double const bd = bb.second ? fabs(bb.first[NR::X] - s[NR::X]) : NR_HUGE; double const sd = sn.second ? fabs(sn.first[NR::X] - s[NR::X]) : NR_HUGE; s = (bd < sd) ? bb.first : sn.first; }
Here we call the snapmanager twice, and only after that it is decided which of the two results leads to the closest snap. So it's in seltrans were the flashing should be invoked. On two places in scaleRequest(), two in stretchRequest(), one in skewRequest(), etc. The code calculating which snap is the closest is different for each case, which makes merging of this code not very straightforward.
Besides, we might not always want something to flash, e.g. when dragging a single node in the node tool. It would be quite obvious in such a case what's snapping. When scaling a complex object though the flashing is really valuable.
Regards,
Diederik
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Awesome! It indeed already works (I now found the switch "snap guides while dragging") ! I'll tweak it a bit more, as it is not doing what I want it to do now :) and then add indicators for the other snaps aswell. Cool!
Johan
________________________________
From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Diederik van Lierop Sent: maandag 3 maart 2008 18:35 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: temporary on-canvas indicators J.B.C.Engelen@...1578... wrote:
Although it seems the snappers return the necessary displacement, and not the point to which they snapped.
No, the snap manager returns an absolute position, for sure! There are some pieces of code that could easily lead to confusion on this matter, e.g. in the node tool.
I propose to make the snappers return something like a SnapInfo struct: struct SnapInfo { bool snapped; //did we snap? Geom::Point snaplocation; // to which point did we snap SnapType type; // some info about the sort of snap (tangential, node-on-node, whatever, this is future work of course) ... }
The first two parameters are already being returned in current SVN. Currently we return a "SnappedPoint", as outlined in snapped-point.h
I do have a bugreport though: guides don't snap! the guideSnap function never gets past the check if it should snap at all, so it always returns Inkscape::SnappedPoint(p, NR_HUGE, 0, false). Can you look into this Diederik? Once guide snapping works, you'll see the snapindicator on-canvas :)
Is this the same as the issue below (which I discussed with Bulia on february 7th)? I'm thinking of making the whole guide-line snap again, as it used to do in the earliest implementations... Copied from a previous mail to this list: Diederik van Lierop wrote:
bulia byak wrote:
On Jan 13, 2008 3:39 PM, Diederik van Lierop <mail@...1689...> mailto:mail@...1689... wrote:
This has been explained by Max and Gez, so I guess that has been cleared up. BTW, what has changed recently is that only the part of the guide near the cursor now snaps, not the full length of the guide.
Well, I just tried, and for me guideline does not snap to a rect, after i ticked "snap guides while dragging" and both snap to paths and snap to nodes. And dragging it with mouse over the rect. What am I doing wrong?
It works for me. Are you moving the mouse pointer itself very close to the node you want to snap to? Because only a small part of the guide will snap, i.e. only that part of the guide that is within snap range from the pointer. BTW, although I've coded this myself, I'm not sure if I like this behaviour. It does give more control however, and an RFE was filed for this.
For example, SnapManager::freeSnapTranslation does not return an absolute snappoint, but a transformation (dx,dy). I am trying to hook the snapindicator up in places where there is an absolute coord though. But could you look into these special cases where it is not so easy?
Thanks!
Johan
________________________________
From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Diederik van Lierop Sent: maandag 3 maart 2008 18:35 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: temporary on-canvas indicators J.B.C.Engelen@...1578... wrote:
Although it seems the snappers return the necessary displacement, and not the point to which they snapped.
No, the snap manager returns an absolute position, for sure! There are some pieces of code that could easily lead to confusion on this matter, e.g. in the node tool.
I propose to make the snappers return something like a SnapInfo struct: struct SnapInfo { bool snapped; //did we snap? Geom::Point snaplocation; // to which point did we snap SnapType type; // some info about the sort of snap (tangential, node-on-node, whatever, this is future work of course) ... }
The first two parameters are already being returned in current SVN. Currently we return a "SnappedPoint", as outlined in snapped-point.h
I do have a bugreport though: guides don't snap! the guideSnap function never gets past the check if it should snap at all, so it always returns Inkscape::SnappedPoint(p, NR_HUGE, 0, false). Can you look into this Diederik? Once guide snapping works, you'll see the snapindicator on-canvas :)
Is this the same as the issue below (which I discussed with Bulia on february 7th)? I'm thinking of making the whole guide-line snap again, as it used to do in the earliest implementations... Copied from a previous mail to this list: Diederik van Lierop wrote:
bulia byak wrote:
On Jan 13, 2008 3:39 PM, Diederik van Lierop <mail@...1689...> mailto:mail@...1689... wrote:
This has been explained by Max and Gez, so I guess that has been cleared up. BTW, what has changed recently is that only the part of the guide near the cursor now snaps, not the full length of the guide.
Well, I just tried, and for me guideline does not snap to a rect, after i ticked "snap guides while dragging" and both snap to paths and snap to nodes. And dragging it with mouse over the rect. What am I doing wrong?
It works for me. Are you moving the mouse pointer itself very close to the node you want to snap to? Because only a small part of the guide will snap, i.e. only that part of the guide that is within snap range from the pointer. BTW, although I've coded this myself, I'm not sure if I like this behaviour. It does give more control however, and an RFE was filed for this.
participants (3)
-
unknown＠example.com -
Alexandre Prokoudine -
Diederik van Lierop