9:45 a.m.
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 ?
10:15 a.m.
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
2:07 p.m.
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
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
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
was
much 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
3:22 p.m.
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
3:42 p.m.
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
2:17 a.m.
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 :)
10:41 p.m.
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
2:13 a.m.
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.
1:22 p.m.
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
1:01 a.m.
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)
1:01 a.m.
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
7:53 a.m.
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
7:24 a.m.
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
10:27 a.m.
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
11:34 a.m.
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
10:13 p.m.
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
2:36 a.m.
> 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
1:26 p.m.
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&...
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
3:29 a.m.
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&...
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
3:40 a.m.
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
5:26 a.m.
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.
10:10 a.m.
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
1:04 a.m.
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...
7:20 a.m.
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
7:56 a.m.
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
2:01 p.m.
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 of
screen, 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
group
depending 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
1:18 a.m.
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 :)
1:26 p.m.
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
6428
days inactive
6570
days old
inkscape-devel@lists.inkscape.org
27 comments
8 participants
participants (8)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Carl Hetherington -
Joshua A. Andler -
Mathieu Dimanche -
MenTaLguY -
Ralf Stephan