Hi everyone
Since it's my first attempt at trying to make things improve in a software, using cvs, and trying to understand a whole project (and written in c++... sometimes), please don't be too harsh on me and on my english level, I'm just a little frenchy :)
Very used to illustrator, I miss some little things that make life easier, like moreeffective snapping.
So I tried to understand the whole object tree, reading both the doxygen and the code (...when there were comments) and finally managed to have a patch made. The functionnality is a pretty little one, I just made guides highlight when moved objects snap against them. For now, this only works for dragged objects and rectangles being drawed.
I post this for anyone to check if I do right, naming functions, indenting, thinking the whole problem, so please, feel free to over-comment my "work", for me to know if I can go on with these kind of updates. This is the first patch of my life, I hope I've made it well. Could you test that ?
Next things I could look at could be : - Snapping modes (enable/disable) Bounding box and dots snapping. I thik it could be great too temporarily disable bounding box snapping, just to make sure only dots do it.
- Providing visual feedback of which of these is used now (you grab a rectangle, its bounding box snaps a guide, the guide turns red (default highlight color), and a little text appears along the guide saying (snapping to boungbox). If you drag farther, the boundingbox will stop snapping and it's the corner dot that will do, so the text'll be "dot snapping" or something like this... maybe snapped dots could be highlited too
- Making grid lines highlight when snapped, just like guides (it was much easier for guides since they are separate objects and the color/hicolor alread existed)
- Trying to make more snapping objects... maybe angled guides, objects themselves, middle of objects, etc... all these could be mode enabled/disabled.
What do people think ? What feature would you like most ?
Mathieu Dimanche wrote:
Hi everyone
Hi and welcome aboard!
Since it's my first attempt at trying to make things improve in a software, using cvs, and trying to understand a whole project (and written in c++... sometimes), please don't be too harsh on me and on my english level, I'm just a little frenchy :)
Don't worry, we have many contributors that have a native language other than English. We've seen it all by now. ;)
Next things I could look at could be :
- Snapping modes (enable/disable) Bounding box and dots snapping. I
thik it could be great too temporarily disable bounding box snapping, just to make sure only dots do it.
Yes, bounding box and node (dots) snapping would be handy... I'd recommend also checking into snapping anywhere along a path as well.
- Providing visual feedback of which of these is used now (you grab
a rectangle, its bounding box snaps a guide, the guide turns red (default highlight color), and a little text appears along the guide saying (snapping to boungbox). If you drag farther, the boundingbox will stop snapping and it's the corner dot that will do, so the text'll be "dot snapping" or something like this... maybe snapped dots could be highlited too
I do have to say that is one thing that I really like about Illustrator... the visual feedback. I think it really is an excellent place to follow the example from in this case. We may want to look into having color coded highlighting based on which layer an object belongs to (ala Illustrator). But the text feedback would be excellent in my book.
What do people think ? What feature would you like most ?
Glad to see you working on this! As I mentioned above, welcome aboard! Now to go apply that patch to check it out...
-Josh
Hi Mathieu,
Thanks for the patch. It looks OK to me (I haven't tried it yet, just read). There are two issues that I see:
1 Something's wrong with the patch file: some (all?) files are listed twice
2 I don't like having to insert desktop->namedview->reset_snapped_visual_feedback() into all contexts on mouse up. Since extra calls of this function should do no harm, I propose to do this once in event-context.cpp root handler, in case GDK_BUTTON_RELEASE unconditionally no matter which button was released (just below xp = yp = 0;). This way it will work in all tools without you having to change anything in each tool's event handlers.
Next things I could look at could be : - Snapping modes (enable/disable) Bounding box and dots snapping. I thik it could be great too temporarily disable bounding box snapping, just to make sure only dots do it.
How do you want to do that?
- Providing visual feedback of which of these is used now (you graba rectangle, its bounding box snaps a guide, the guide turns red (default highlight color), and a little text appears along the guide saying (snapping to boungbox). If you drag farther, the boundingbox will stop snapping and it's the corner dot that will do, so the text'll be "dot snapping" or something like this... maybe snapped dots could be highlited too
Good idea, except that please use the statusbar for such messages - it's where we display all textual hints and tips for the user.
- Making grid lines highlight when snapped, just like guides (it wasmuch easier for guides since they are separate objects and the color/hicolor alread existed)
Would be nice too.
- Trying to make more snapping objects... maybe angled guides,objects themselves, middle of objects, etc... all these could be mode enabled/disabled.
Yes, you can just go through the list of SPObjects and see what meaningful way to snap them we're not using yet.
What do people think ? What feature would you like most ?
We have no shortage of snapping requests - just search our RFE tracker or this list. Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Good idea, except that please use the statusbar for such messages - it's where we display all textual hints and tips for the user.
Bulia, would you be opposed to redundancy on this? I think using the statusbar is definitely a must, but would you oppose the kind of "floating tooltip" that Illustrator has (not quite as distracting as regular tooltips though). The advantage to it being next to the cursor is that your eyes can stay focused on where you're working, but it gives info on what it's snapping to. A few examples of how it works in AI (sorry about the lack of Cursor, but you'll see where it should be) for those unfamiliar, can be found at:
http://www.scislac.com/inkscape/ai-node1.png http://www.scislac.com/inkscape/ai-node2.png http://www.scislac.com/inkscape/ai-node3.png
They're small, discrete, and informative (especially in complex docs). As with so many things in the UI, I'd opt for making it optional through Inkscape's prefs though.
-Josh
On 12/5/05, Joshua A. Andler <joshua@...533...> wrote:
Bulia, would you be opposed to redundancy on this? I think using the statusbar is definitely a must, but would you oppose the kind of "floating tooltip" that Illustrator has (not quite as distracting as regular tooltips though).
I'm not exactly opposed, I just think it's going to be rather messy and distracting. But if anyone wants to implement it as an option, I'm fine with that. It's only that we don't currently have any code for this kind of display, it needs to be coded entirely from the lowest level up. It's also going to be tricky if you want it to be smart to avoid placing text over color boundaries where it's hard to read. It's similar to geographic software that uses complex algorithms for placing location names, and it's quite tricky.
http://www.scislac.com/inkscape/ai-node1.png http://www.scislac.com/inkscape/ai-node2.png http://www.scislac.com/inkscape/ai-node3.png
Heh, dumb Illustrator simply does not have any statusbar worth speaking about, so no wonder they have to resort to this :)
(I apologize if "dumb" offends anyone, but just today I had to run AI to convert a bunch of Inkscape artwork to AI format for a client, under tight deadline, and I was once again incredibly annoyed and frustrated by this crappy "industry standard". I really hate AI, it's a torture to use after Inkscape or Xara.)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 12/5/05, Joshua A. Andler <joshua@...533...> wrote:
Bulia, would you be opposed to redundancy on this? I think using the statusbar is definitely a must, but would you oppose the kind of "floating tooltip" that Illustrator has (not quite as distracting as regular tooltips though).
I'm not exactly opposed, I just think it's going to be rather messy and distracting. But if anyone wants to implement it as an option, I'm fine with that. It's only that we don't currently have any code for this kind of display, it needs to be coded entirely from the lowest level up. It's also going to be tricky if you want it to be smart to avoid placing text over color boundaries where it's hard to read. It's similar to geographic software that uses complex algorithms for placing location names, and it's quite tricky.
That's exactly the kind of functions I'd like as visual feedback. For now, I'm pretty sure I'm not familiar enough with the sources, but I'd really like to see that done so I'll go for more little updates and when I'm strong enough, I try :)
On 12/5/05, bulia byak <buliabyak@...400...> wrote:
Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
And after this is fixed, the next urgent change is to make snapping distance (both guide and grid) work in screen pixels, as opposed to absolute units as now. In other words, an object must snap at the same screen distance from the guide/grid always, regardless of zoom.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Hi Mathieu,
Thanks for the patch. It looks OK to me (I haven't tried it yet, just read). There are two issues that I see:
1 Something's wrong with the patch file: some (all?) files are listed twice
As I thought, my first patch isn't that glorious :-) Just to be sure I'll not break anything, I made a copy of my inkscape folder and it showed in the patch... So there's the new one (which works, I hope), I made it after Carl's seltrans modification so it show work well now.* *
2 I don't like having to insert desktop->namedview->reset_snapped_visual_feedback() into all contexts on mouse up. Since extra calls of this function should do no harm, I propose to do this once in event-context.cpp root handler, in case GDK_BUTTON_RELEASE unconditionally no matter which button was released (just below xp = yp = 0;). This way it will work in all tools without you having to change anything in each tool's event handlers.
I just tried that, and you're right, it's really cleaner and it works well, it's in the new patch. But think I still need to modify every context, for each start of a GDK_MOTION_NOTIFY requires a desktop->namedview->reset_snapped_visual_feedback() to downlight everything. It could be done in event-context.cpp root handler too maybe, but I would need to check every context, especially not calling the resetting when we're dragging a guide to move it (and whoops, its highlighting disappears). And I tried it, and seems not to work (select-context.cpp, line 484). Is this event being triggered after the same one in select-context ? How to make it append before ? What do you think ? Is it worth the try, having a single call while motion is triggered, with multiple cases to check ?
Next things I could look at could be :
- Snapping modes (enable/disable) Bounding box and dots snapping. I
thik it could be great too temporarily disable bounding box snapping, just to make sure only dots do it.
How do you want to do that?
Maybe some more icons in selection context, as seen on http://paris.charougna.com/inkscape/Snapping_Icons.png
It could be useful, as the object type selection mask icons in Maya or more like the "object snaps" menu in Rhino3D.
We have no shortage of snapping requests - just search our RFE tracker or this list. Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
I think Carl is working on that, but I could look.
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
I just tried that, and you're right, it's really cleaner and it works well, it's in the new patch. But think I still need to modify every context, for each start of a GDK_MOTION_NOTIFY requires a desktop->namedview->reset_snapped_visual_feedback() to downlight everything.
Well, why do you need to downlight on each MOTION_NOTIFY? This sounds unclean and may even slow it down, since motion events may come very fast. Can you try to do that in Snapper instead? I think if you add to Snapper::vector_snap not only highlighting when there's snap but also downlighting when there's _no_ snap, it would take care of this automatically. Tool contexts that do snapping already keep calling vector_snap while the mouse is being dragged. Then the only situation when you have to downlight artificially is when you snapped something and released mouse without unsnapping it, and that's what the event_context release handler already takes care of.
Next things I could look at could be :
- Snapping modes (enable/disable) Bounding box and dots snapping. I
thik it could be great too temporarily disable bounding box snapping, just to make sure only dots do it.
Maybe some more icons in selection context, as seen on http://paris.charougna.com/inkscape/Snapping_Icons.png
Yes, that would be nice, except maybe it's better to do this in the statusbar instead (I know it's crowded, but snapping is important enough to use a small section of the statusbar on it).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak a écrit :
Maybe some more icons in selection context, as seen on http://paris.charougna.com/inkscape/Snapping_Icons.png
Yes, that would be nice, except maybe it's better to do this in the statusbar instead (I know it's crowded, but snapping is important enough to use a small section of the statusbar on it).
as long as there are only a few toogling on snapping types, we could maybe use the same technique as in StudioTools (http://www.alias.com/eng/support/studiotools/documentation/Using/Aids2.html)
bulia byak a écrit :
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
I just tried that, and you're right, it's really cleaner and it works well, it's in the new patch. But think I still need to modify every context, for each start of a GDK_MOTION_NOTIFY requires a desktop->namedview->reset_snapped_visual_feedback() to downlight everything.
Well, why do you need to downlight on each MOTION_NOTIFY? This sounds unclean and may even slow it down, since motion events may come very fast. Can you try to do that in Snapper instead? I think if you add to Snapper::vector_snap not only highlighting when there's snap but also downlighting when there's _no_ snap, it would take care of this automatically. Tool contexts that do snapping already keep calling vector_snap while the mouse is being dragged. Then the only situation when you have to downlight artificially is when you snapped something and released mouse without unsnapping it, and that's what the event_context release handler already takes care of.
I didn't really mean downlight _everything_, but erase the hightlights that were ON and now OFF. I can be a whole HighlightGroup (one per Snapper), or just some HightlightItem in it (the HighlightGroup for the grid could have 4 Items in it at frame f, 2 lines and 2 text-hints, and just have 1 line and 1 hint at frame f+1 so the highlightmanager knows he must update the group (delete 2 items), and the 2 remaining items if they changed and need update.
my idea was to make the snapping objects tell the highlighting manager what they needed to be shown as highlighted, so the manager gives them an HighlightGroup to fill with graphical HighlightItems. If the group already existed in the previous update phase, the snapper updates the infos of its previous group. If no group existed, the highlight manager creates a brand new one. The only thing needed is then to call some highlight manager member before every redraw to mark "old" (previous frame) groups for deletion, let them be filled/updated by snappers (or other objects that want to highlight things) during the motion_notify event and deleting the groups and items still marked before the final highlight drawing.
By doing this, I intended to separate the snapper objects from the highlight objects so the highlight manager could be separate from snapping, to allow us (maybe in the future) to highlight things that are not snapped. I didn't want any drawing management to be in Snapper objects, so HighlightItems and HighlightGroups are here to hold the informations for highlighting a specific object.
About speed, I think this method could be efficient because if Snapper::vector_snap does the downlighting, then for every frame to draw, all snappers must tell the highlight manager the current state of every graphical highlight object (line/dot/etc...) they contain, either now (during vector_snap) or keep this state so it can tell this back to the highlight manager when this one wants to draw everything. I didn't want this state to be in the Snapper object but filled in a group by it, so not only snappers can highlight things, and I don't like the idea of a snapper member doing "making really sure this line of mine is to be OFF the highlight layer for this frame (...just in case)", because it means every Snapper will have to check the status of all its highlightable components.
I'm not sure I'm clear enough and I probably need to do what ScislaC told me yesterday :)
[08:12:39] <ScislaC> mtou: you might want to look at Bulia's outline view code when you want to highlight the objects, it's probably not too far off in some ways
On 12/7/05, Mathieu Dimanche <mdimanche@...8...> wrote:
Well, why do you need to downlight on each MOTION_NOTIFY? This sounds unclean and may even slow it down, since motion events may come very fast. Can you try to do that in Snapper instead? I think if you add to Snapper::vector_snap not only highlighting when there's snap but also downlighting when there's _no_ snap, it would take care of this automatically. Tool contexts that do snapping already keep calling vector_snap while the mouse is being dragged. Then the only situation when you have to downlight artificially is when you snapped something and released mouse without unsnapping it, and that's what the event_context release handler already takes care of.
I didn't really mean downlight _everything_, but erase the hightlights that were ON and now OFF.
Sure. But this is not what I was talking about. My point is that downlighting can only happen in the same situation when some highlighting (i.e. snapping) might happen, and therefore it makes sense to do both highlighting and downlighting in one function - the one which various contexts call to get snapped coords. Those contexts or situations where no snapping is done would not spend time trying to downlight anything. So I propose to add a call to downlighting to the same place as highlighting, that is, Snapper::vector_snap (or whatever is its currently named after Carl's changes) and remove any downlight calls from contexts. Does that make sense?
my idea was to make the snapping objects tell the highlighting manager what they needed to be shown as highlighted, so the manager gives them an HighlightGroup to fill with graphical HighlightItems. If the group already existed in the previous update phase, the snapper updates the infos of its previous group. If no group existed, the highlight manager creates a brand new one. The only thing needed is then to call some highlight manager member before every redraw to mark "old" (previous frame) groups for deletion, let them be filled/updated by snappers (or other objects that want to highlight things) during the motion_notify event and deleting the groups and items still marked before the final highlight drawing.
Right, except the Snapper::vector_snap has no idea of motion_notify events. It's just called whenever it's convenient for the contexts. In other words, it's a call to snapper that causes high/down lighting, not any motion_notify by itself.
By doing this, I intended to separate the snapper objects from the highlight objects so the highlight manager could be separate from snapping, to allow us (maybe in the future) to highlight things that are not snapped. I didn't want any drawing management to be in Snapper objects, so HighlightItems and HighlightGroups are here to hold the informations for highlighting a specific object.
Sure, this makes sense. Just also separate highlighting calls from contexts :)
About speed, I think this method could be efficient because if Snapper::vector_snap does the downlighting, then for every frame to draw, all snappers must tell the highlight manager the current state of every graphical highlight object (line/dot/etc...) they contain, either now (during vector_snap) or keep this state so it can tell this back to the highlight manager when this one wants to draw everything. I didn't want this state to be in the Snapper object but filled in a group by it, so not only snappers can highlight things, and I don't like the idea of a snapper member doing "making really sure this line of mine is to be OFF the highlight layer for this frame (...just in case)", because it means every Snapper will have to check the status of all its highlightable components.
No. Snapper does not have to know anything about what's highlighted. It just calls a generic "downlight everything" function on the highlighting manager, and that's where it will figure out what's up and what needs to be switched off.
I'm not sure I'm clear enough and I probably need to do what ScislaC told me yesterday :)
[08:12:39] <ScislaC> mtou: you might want to look at Bulia's outline view code when you want to highlight the objects, it's probably not too far off in some ways
No, outline mode is entire in the arena layer, you don't need that. If you need to highlight arbitrary paths, you'll need to look up how canvas items for paths are created by the Pen tool (those green and red temporary curves).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
We have no shortage of snapping requests - just search our RFE tracker or this list. Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
I think Carl is working on that, but I could look.
Carl, so are you working on this?
Also, could you please make sure that your new object snapping and any other user-visible snapping changes are described in the rel notes?
Thanks!
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 12 Dec 2005, bulia byak wrote:
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
We have no shortage of snapping requests - just search our RFE tracker or this list. Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
I think Carl is working on that, but I could look.
Carl, so are you working on this?
I'll take a look.
Also, could you please make sure that your new object snapping and any other user-visible snapping changes are described in the rel notes?
Yes, I'll sort out the release notes and RFEs when I've got the new snap code into a state that I'm happy with. There's still some problems.
Cheers
Carl
On 12/13/05, Carl Hetherington wrote:
Yes, I'll sort out the release notes and RFEs when I've got the new snap code into a state that I'm happy with. There's still some problems.
Btw, would it be possible to change defaults for snap distance from 0.4 px to, say, 2 or 5 px? Are you planning to track down snap distance spinbox issue (rotate mousewheel over it just once and the value becomes 1000000 or something) too?
Alexandre
On 12/13/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
Yes, I'll sort out the release notes and RFEs when I've got the new snap code into a state that I'm happy with. There's still some problems.
Btw, would it be possible to change defaults for snap distance from 0.4 px to, say, 2 or 5 px?
With my proposed change, the default units will be screen pixels, not px. I think 5 screen pixels is a good default.
Are you planning to track down snap distance spinbox issue (rotate mousewheel over it just once and the value becomes 1000000 or something) too?
That's a question for Ralf who just redesigned that dialog. Maybe it's already fixed?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Are you planning to track down snap distance spinbox issue (rotate mousewheel over it just once and the value becomes 1000000 or something) too?
That's a question for Ralf who just redesigned that dialog. Maybe it's already fixed?
Ah, nearly missed that. I have no mousewheel here so I can't test that but I can limit min/max values to saner numbers if this suffices. I think step value of 1.0 is okay so why it's up at max with one roll is beyond me.
ralf
Hi Carl!
Just wanted to drop you an email and see how things are going? We've not heard from you in quite a while.
We're about to start the release process for Inkscape 0.44, and I just wanted to follow up with you on how the snapping code is, and if there are any remaining fixes you'd like to get in for this release?
The snapping code looks good, but there's one bug identified in the snapping code that would be very nice to get resolved:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429049&gro...
We're thinking of a feature freeze within a couple weeks, and a (hopefully) short bug fix period. Do you think you'll have time within the next few weeks to look at this one?
Thanks, Bryce
On Tue, Dec 13, 2005 at 06:27:33PM +0000, Carl Hetherington wrote:
On Mon, 12 Dec 2005, bulia byak wrote:
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
We have no shortage of snapping requests - just search our RFE tracker or this list. Personally, I think the most urgent change is to make grid snapping snap only to the visible grid lines - that is, if you zoomed out so that every 10th line is shown, snap only to those 10th lines, not to the invisible lines in between. This should take care of most of the "snapping does not work" complaints, because at most practical zooms, snapping distance is smaller than the visible distance between grid lines, and may be even smaller than a screen pixel, so people just don't realize that it's actually snapping.
I think Carl is working on that, but I could look.
Carl, so are you working on this?
I'll take a look.
Also, could you please make sure that your new object snapping and any other user-visible snapping changes are described in the rel notes?
Yes, I'll sort out the release notes and RFEs when I've got the new snap code into a state that I'm happy with. There's still some problems.
Cheers
Carl
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 23 Apr 2006, Bryce Harrington wrote:
Hi Carl!
Just wanted to drop you an email and see how things are going? We've not heard from you in quite a while.
Hi all,
Sorry I've not been about. Usual story, been very busy with other things.
We're about to start the release process for Inkscape 0.44, and I just wanted to follow up with you on how the snapping code is, and if there are any remaining fixes you'd like to get in for this release?
The snapping code looks good, but there's one bug identified in the snapping code that would be very nice to get resolved:
http://sourceforge.net/tracker/index.php?func=detail&aid=1429049&gro...
We're thinking of a feature freeze within a couple weeks, and a (hopefully) short bug fix period. Do you think you'll have time within the next few weeks to look at this one?
I hope to be able to look at the snap code this week. Will let you know how I get on.
Cheers
Carl
On Mon, 5 Dec 2005, Mathieu Dimanche wrote:
Hi everyone
Since it's my first attempt at trying to make things improve in a software, using cvs, and trying to understand a whole project (and written in c++... sometimes), please don't be too harsh on me and on my english level, I'm just a little frenchy :)
Very used to illustrator, I miss some little things that make life easier, like moreeffective snapping.
So I tried to understand the whole object tree, reading both the doxygen and the code (...when there were comments) and finally managed to have a patch made. The functionnality is a pretty little one, I just made guides highlight when moved objects snap against them. For now, this only works for dragged objects and rectangles being drawed.
Thanks very much for the patch :-)
I post this for anyone to check if I do right, naming functions, indenting, thinking the whole problem, so please, feel free to over-comment my "work", for me to know if I can go on with these kind of updates. This is the first patch of my life, I hope I've made it well. Could you test that ?
My instinct is that you might be better off doing this using additional canvas objects (like you have suggested in some of your comments). In other words, you highlight things by creating a new object to overlay the thing you are highlighting.
I think this would make things much more general; the highlight operation is adding a canvas object, and un-highlight is removing all the "highlight" objects (which you could keep in a list). Otherwise you have a special case for each thing you've highlighted: note which guide line you changed and then change it back, note which grid line(s) you changed and then change them back etc. etc. Also, I think in some cases (e.g. highlighting a snap to a path) you're probably going to want to add new objects (perhaps a little circle, or something) rather than just changing existing ones.
However I'm not an expert with the canvas so I'd be interested in anybody else's comments.
Cheers
Carl
Carl Hetherington a écrit :
My instinct is that you might be better off doing this using additional canvas objects (like you have suggested in some of your comments). In other words, you highlight things by creating a new object to overlay the thing you are highlighting.
I think this would make things much more general; the highlight operation is adding a canvas object, and un-highlight is removing all the "highlight" objects (which you could keep in a list). Otherwise you have a special case for each thing you've highlighted: note which guide line you changed and then change it back, note which grid line(s) you changed and then change them back etc. etc. Also, I think in some cases (e.g. highlighting a snap to a path) you're probably going to want to add new objects (perhaps a little circle, or something) rather than just changing existing ones.
Hi Carl & everyone
I was thinking of using different canvas items, and your comment made me think about it harder :) So I wrote an almost complete (I hope) list of what could be done in order for this highlighting feature to be usable and very open in the future.
Please feel free to comment, I'll have a look at the sources and begin :)
Mtou
I --------------------------------------------------------------------------------------- List of changes to do :
in SPNamedView * a new SPhighlight *o_highlights to handle every highlighting. * a new show_current_highlighting() calling o_highlights to make highlighting item draw on screen * a new reset_highlighting() calling o_highlights to delete every highlight_item
a new class SPhighlight * container for all highlight_groups currently drawn. * a show_all_groups() function - calling all highlight_groups to draw themselves (on the sketch layer or another one ?) - positionning optionnal hint texts to avoid overlap, out of screen, and maybe color similarities with the background - choosing the right colors for the visual feedback of the group depending on where (layer color) and what it is * a hide_all_groups() function, deleting all highlight_groups
a new class SPhighlight_group * prefered color * list of SPhighlight_itemS to draw (segments, dots or hints) * can draw all its items based on their types and delete them * can draw the textual hints, or just some of them if SPhighlight doesn't agree * can give the bbox of textual hints back to SPhighlight for smart placement by the only object who knows everything to show. * can adjust hint placement to respect SPhighlight directives (forbidden bounding boxes on the screen ?, depending on the mouse position) and hints' prefered placement given by the snapping object.
a new class SPhighlight_item * base for all highlight items.
virtual classes from SPhighlight_item * handle specific highlighting parameters * a big draw_highlight() function which instanciate SPCanvasItem objects (old or new ones) * prefered ordering (front/middle/back) ???
* SPhighlight_item_dot - one point - drawing style ("cross", "colored dot", etc...)
* SPhighlight_item_segment - 2 points or a <point/vector> pair - bool for finite or infinite line
* SPhighlight_item_hint - text - prefered placement (along line, horizontal, at point, etc...)
in *-snapper objects * every snapped-to object (guide, gridline, object dot, object segment, object curve) adds himself an SPhighlight_item_xxxx to the namedview's o_highlights when asked to by snapping functions from snap.cpp, because it's the only one who knows what to highlight, what for, and what to write as an hint and where.
On Tue, 2005-12-06 at 14:26 +0100, Mathieu Dimanche wrote:
Please feel free to comment, I'll have a look at the sources and begin :)
a new class SPhighlight
a new class SPhighlight_group
a new class SPhighlight_item
Okay, first of all, please follow the standard naming conventions for classes Inkscape.
Classes should be named like SPHighlight, SPHighlightGroup, and SPHighlightItem.
Except... the SP* prefix is a holdover from Sodipodi. Please don't use it for new code. New classes should go in the Inkscape:: namespace instead.
For example, Inkscape::Highlight, Inkscape::HighlightGroup, and Inkscape::HighlightItem.
In general, please famliarize yourself with the coding standards here:
http://www.inkscape.org/doc/coding_style.php
Other than that, your basic concept sounds good.
-mental
MenTaLguY a écrit :
Okay, first of all, please follow the standard naming conventions for classes Inkscape.
Classes should be named like SPHighlight, SPHighlightGroup, and SPHighlightItem.
Except... the SP* prefix is a holdover from Sodipodi. Please don't use it for new code. New classes should go in the Inkscape:: namespace instead.
For example, Inkscape::Highlight, Inkscape::HighlightGroup, and Inkscape::HighlightItem.
In general, please famliarize yourself with the coding standards here:
http://www.inkscape.org/doc/coding_style.php
Other than that, your basic concept sounds good.
-mental
I have now checked that and will respect the coding style, I promise :)
Is the Inkscape namespace necessary ? it seems classes like Snapper are not in the Inkscape namespace...
On Wed, 2005-12-07 at 10:04 +0100, Mathieu Dimanche wrote:
Is the Inkscape namespace necessary ? it seems classes like Snapper are not in the Inkscape namespace...
Ideally, but admittedly we've not been very consistent about it. Still, it helps avoid potential symbol conflicts with libraries and the like.
-mental
MenTaLguY a écrit :
On Wed, 2005-12-07 at 10:04 +0100, Mathieu Dimanche wrote:
Is the Inkscape namespace necessary ? it seems classes like Snapper are not in the Inkscape namespace...
Ideally, but admittedly we've not been very consistent about it. Still, it helps avoid potential symbol conflicts with libraries and the like.
-mental
yeah, sure it's cleaner, I'll try to be strict about that too :)
mtou
On 12/6/05, Mathieu Dimanche <mdimanche@...8...> wrote:
a new class SPhighlight * container for all highlight_groups currently drawn. * a show_all_groups() function - calling all highlight_groups to draw themselves (on the sketch layer or another one ?)
SPCanvas has no layers as such. Just add a new SPCanvasItem on it and move it in the z-order appropriately (perhaps to the very top).
BTW, the entire SVG drawing is a single SPCanvasItem called SPCanvasArena. Only the arena is exported to bitmap, for example. All other canvas items are just helpers for editing.
- positionning optionnal hint texts to avoid overlap, out ofscreen, and maybe color similarities with the background
You don't need to worry about color similarities - just use the inverse color for it and it will always differ from the background. Then you only need to avoid color boundaries interfering with the text.
- choosing the right colors for the visual feedback of the groupdepending on where (layer color) and what it is
Or you can make the highlight item consisting of different parts, one part inverse and the other fixed color (perhaps depending on layer). That's how the nodes (using SPCtrl canvas item type) are displayed in node tool: the inner part of the square is fixed gray/red/blue and the outline is inverse.
* a hide_all_groups() function, deleting all highlight_groups
Hiding is not the same as deleting, with regard to SPCanvasItems.
* SPhighlight_item_dot - one point - drawing style ("cross", "colored dot", etc...)
We already have SPCtrl for that, with different shapes and sizes - reuse it.
* SPhighlight_item_segment - 2 points or a <point/vector> pair - bool for finite or infinite line
We don't really have infinite lines - e.g. guidelines are drawn to whatever the span of the visible rectangle is (see sp_guideline_render).
Overall, your plans are quite ambitious :) I'll be happy to see them implemented. Carl is the highest authority on the snapper classes that he wrote, but I may be of help with canvas-related code.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak a écrit :
SPCanvas has no layers as such. Just add a new SPCanvasItem on it and move it in the z-order appropriately (perhaps to the very top).
BTW, the entire SVG drawing is a single SPCanvasItem called SPCanvasArena. Only the arena is exported to bitmap, for example. All other canvas items are just helpers for editing.
I just had read that in src/desktop.cpp :
/* SPDesktop provides a certain set of SPCanvasItems, serving as GUI/ / * layers of different control objects. The one containing the whole/ / * document is the drawing layer. In addition to it, there are grid,/ / * guide, sketch and control layers. The sketch layer is used for/ / * temporary drawing objects, before the real objects in document are/ / * created. /
so I thought this sketch layer (not used it seems, maybe deprecated ?) was the kind of things I could use to draw highlights...
- SPhighlight_item_dot
- one point
- drawing style ("cross", "colored dot", etc...)
We already have SPCtrl for that, with different shapes and sizes - reuse it.
I think the HighlightItemDot could call an SPCtrl to draw ? the object can then have other options/parameters, like the prefered position, the "don't show that if the hightlight layer is too crowdy"/priority, etc...
- SPhighlight_item_segment
- 2 points or a <point/vector> pair
- bool for finite or infinite line
We don't really have infinite lines - e.g. guidelines are drawn to whatever the span of the visible rectangle is (see sp_guideline_render).
I was wanting just to have 2 line behaviors depending on 2 points, the "draw just between the 2 points", what's called a line segment in french (but I don't know if english uses this word), and the "draw past the points too, as guid or guide do in sp_guideline_render.
Overall, your plans are quite ambitious :) I'll be happy to see them implemented. Carl is the highest authority on the snapper classes that he wrote, but I may be of help with canvas-related code.
I will check the commit Carl said would to 10h ago to update my viewing of the whole implementation of this :)
On 12/6/05, Carl Hetherington <lists@...169...> wrote:
My instinct is that you might be better off doing this using additional canvas objects (like you have suggested in some of your comments). In other words, you highlight things by creating a new object to overlay the thing you are highlighting.
Exactly. It's more generic that way, and easily extensible to different highlight types (including text labels - which however will need a new type of SPCanvasItem that we don't have yet). All without having to dig into the internals of grid or any other existing structure - just display your highlight line on top of a grid line.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (8)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Carl Hetherington -
Joshua A. Andler -
Mathieu Dimanche -
MenTaLguY -
Ralf Stephan