Hi.

I have a thing that bugs me. I have a path and I have a rectangle. I make sure I've enabled the "Snap from and to midpoint of bounding box edges".
Then I try to move the path - the whole object at once or just a single node - to have it to snap onto one of the rectangle's midpoint of bounding box edges.

However, it won't work. I cannot get a path's node snap there. It does snap to the corners, but nowhere between.

But two different object DOES snap to each other midpoint of bounding box edges. But nothing else.

Grobe wrote:I make sure I've enabled the "Snap from and to midpoint of bounding box edges".
(…)
I cannot get a path's node snap there. It does snap to the corners, but nowhere between.

Nodes cannot snap to bounding box targets ('Snap bounding box corners' and 'Snap nodes or handles' have separate snap targets on the snapping toolbar, you can't "mix" them).

Use the new snap setting in the devel builds ('Snap from and to centers of objects') instead of trying to snap nodes to bounding box targets (see comment #7 of bug #788178 - still 'Work in Progress').

~suv wrote:

Grobe wrote:I make sure I've enabled the "Snap from and to midpoint of bounding box edges".
(…)
I cannot get a path's node snap there. It does snap to the corners, but nowhere between.

Nodes cannot snap to bounding box targets ('Snap bounding box corners' and 'Snap nodes or handles' have separate snap targets on the snapping toolbar, you can't "mix" them).

Use the new snap setting in the devel builds ('Snap from and to centers of objects') instead of trying to snap nodes to bounding box targets (see comment #7 of bug #788178 - still 'Work in Progress').

Yes, that's reminds me. Cannot mix the group og bounding box snapping and path snapping. In other words, it's by design. Well, maybe I file a wish to combine those groups (so they can snap to each other).

Grobe wrote:Yes, that's reminds me. Cannot mix the group og bounding box snapping and path snapping. In other words, it's by design. Well, maybe I file a wish to combine those groups (so they can snap to each other).

Yes, it's by design, and IIRC I have read explanations for/discussions about that somewhere in the bug tracker (edit: or the mailing list archives) (it's not just there for no reason).

/me hoping for Diederik to chime in here ;)

(Edit: see also this earlier comment)

Not to hijack topic, but if diederik chimes in, I have another snapping question. Way back some versions ago, we had many snapping improvements, including the ability to use Shift key, to temporarily disable snapping. However, with the next stable version release, that was lost. After I reported, it was fixed in the dev version at that time, and I looked forward to the next stable release. But in the next stable release (0.48) still the Shift key does not temporarily disable snapping. It's so frustrating that I didn't report it, but just hoped for the next. But now with 0.48.1, still no way to disable snapping. That was really an awesome feature, which I hope will someday return to a stable release! Maybe 0.48.2? (Isn't there a way to put it into the code, so that it doesn't get lost?)

EDIT
There were discussion in this forum about this here: viewtopic.php?f=5&t=5886

brynn wrote:Way back some versions ago, we had many snapping improvements, including the ability to use Shift key, to temporarily disable snapping. However, with the next stable version release, that was lost. After I reported, it was fixed in the dev version at that time, and I looked forward to the next stable release. But in the next stable release (0.48) still the Shift key does not temporarily disable snapping. It's so frustrating that I didn't report it, but just hoped for the next.

Confusing versions here? In which version was it lost? In 0.47 already? (Inkscape 0.47 saw the major refactoring of the snapping feature, including the new controls bar.) As far as I understood, the linked forum topic is about disabling snapping in the node tool context when moving a node (the shortcut with the 'Shift' modifier was lost in 0.48), but this was fixed and does work in 0.48.1.

Maybe you could describe what you are trying to do (which tool? what kind of action? tool and snap settings?), how it used to worked in the earlier version (I guess you are referring to 0.47?), what you expect and what actually happens for you in 0.48.1.

~suv wrote:Maybe you could describe what you are trying to do (which tool? what kind of action? tool and snap settings?)

Possibly you are referring to dragging a node handle, not a node itself? As described in the bug report linked to in the other topic (see bug #588628 and more specifically comment #3 et seq. of related bug #538487), the 'Shift' modifier for dragging node handles conflicts with dragging both handles at once of cusp nodes with two extracted handles. Apparently the needed discussion about which modifiers/shortcuts are still available never took place (no overview of existing usage and proposals to solve the the conflict provided) and Krzysztof decided to re-implement the 'Shift' modifier only for dragging nodes themselves, but not for handles.

To summarize: In Inkscape 0.48.1, temporarily disabling node snapping in the node tool context works when dragging nodes, but not when dragging node handles. This also applies to upcoming 0.48.2 and current development builds.

Ah-HA!
Yes, it is only node handles that don't snap! I guess in the way that I use Inkscape, I usually only need to disable snapping for node handles. When I saw that node handles did not respond to the Shift key, I assumed all had been lost, as before. I had forgotten about reading the info you provided in the link from the older topic. And I did read it! I think partly because the discussion at that time was fairly recent, I assumed it would continue, and perhaps had an expectation that it should be fixed by the next release.. But mostly, I forgot.

So I apologize. My memory is not what it used to be

Were any new discussion to take place, what would have to happen? I know that it was frustrating, when dragging a node with no handles, and using Shift to disable snapping, and instead, it would drag out a handle. But in my work, I would prefer only occassionally having to deal with that, in exchange for being able to quickly drag nodes without snapping via Shift. I do a lot of node editing, and typically have nodes snapped to a grid. And in my opinion, it's impossible to accurrately place a curve using a node handle, with snapping enabled. Even if I disable the grid snapping, the handle wants to snap to everything else.

Well, I guess at least we still have the snap control bar, and that's still much easier than going to Doc Props to disable snapping (as before 0.47)!

I certainly would be interested to read any discussion about this, ~suv. Can you tell me how to keep informed? If there were a current bug, I know I could subscribe to it. But without a current bug, I'm not sure how to follow this subject. (I've avoided subscribing to mailing list, due to large amount of mail, and little to no chance I could even understand most of it. For similar reason, I would hesitate to subscribe, just to keep up with this one issue.)

If I were to post a comment to bug #588628, would that stimulate the discussion, or would it need a developer (like yourself) to get the ball rolling again?
[If you could take another moment on this, why aren't there enough keys? Like for example 'd' for disable, or even 'd + s' for disable snapping. I'm just thinking that in some cases, we have 3-key combos for shortcuts, such as Ctrl + Shift + whatever. If I remember my college statistics, isn't that like 26 to the third power, speaking only of the alphabet keys?? It's been so long now (and I only got a B in that course, lol). But if there's a conflict with Shift key, why aren't there plenty of other keys that could be used instead?]

I'm sorry, Grobe

Thanks ~suv for explaining and referring to my comment in another thread. I don't think there's any more to add for me

Brynn, about the keys: preferably we'd use the modifier keys for this, i.e. shift / ctrl / alt / windows key, etc. These keys can be held for a while and released again, that's most natural I guess for temporarily changing some behaviour. All other keys will have to be pressed twice, and will act as a toggle. In principle that's also possible, and in fact we already have that for snapping (press the percent key to toggle snapping, which is even more cumbersome because that requires pressing both shift and 5, depending on the keyboard layout). IMHO it would be preferable to use shift everywhere for disabling snapping.

The bigger issue here is that someone would have to look into all tools, and look at all combinations of modifier keys and see what they currently do. There will be more conflicts than just this snapping one, and therefore a new mapping of keys should be proposed and discussed, covering all tools. Discussing this on launchpad would be best, in a new bug report. We can direct everyone there from the forum and the mailing lists. All we're missing here is a volunteer to start this tedious work.

I find it hard to believe that no one knows what effect the modifier keys have on each tool!

There will be more conflicts than just this snapping one....

Such as?

I'm good with tedious projects, but don't know the code. Does this require knowing the code, or someone to just enable each tool, and write down what each modifier key does? I think I would be good at coding, it's just the learning curve that has discouraged me.

But I think I don't understand what you're saying. Could you clarify? I really would love to be able to contribute, other than unexpectedly discovering bugs, lol.

brynn wrote:If I were to post a comment to bug #588628, would that stimulate the discussion, (…)

Not really - commenting on closed reports doesn't necessarily trigger an action or discussion.

brynn wrote:[If you could take another moment on this, why aren't there enough keys? Like for example 'd' for disable, or even 'd + s' for disable snapping. I'm just thinking that in some cases, we have 3-key combos for shortcuts, such as Ctrl + Shift + whatever. If I remember my college statistics, isn't that like 26 to the third power, speaking only of the alphabet keys?? It's been so long now (and I only got a B in that course, lol). But if there's a conflict with Shift key, why aren't there plenty of other keys that could be used instead?]

I don't really follow your argument here - we already have a key ('%') to globally toggle snapping on/off (and you can customize that keyboard shortcut, if you'd prefer a different one - but likely you'll have to trade it against one already in use, or assign a combination of modifiers + key).
This issue is with temporarily disabling snapping while doing an action with the mouse - for this, it's common practice in Inkscape to use a modifier key (like in the select tool: but even there you'll notice that 'Shift' can have different effects depending on the type of action you are performing with the mouse).

dvlierop wrote:Discussing this on launchpad would be best, in a new bug report. We can direct everyone there from the forum and the mailing lists. All we're missing here is a volunteer to start this tedious work.

Maybe a page in the Inkscape Wiki (to ease collaboration to gather all information) would be better used first, and then a new report filed based on the findings? The bug tracker can be cumbersome for such a discussion (no threading, no editing) until there's an existing overview and some new proposals to unify the modifier usage across tool contexts.

brynn wrote:I find it hard to believe that no one knows what effect the modifier keys have on each tool!

As far as I understand the current situation, Inkscape has two types of "keyboard shortcuts": those that can be changed (listed&configured in 'share/keys/default.xml') and many other cases where usage/parsing of keyboard input (single key shortcuts, modifiers, etc) is directly defined in the code (aka hard-coded). Since Inkscape has many tools, and the source code is complex, the code concerning modifiers is spread across many *.cpp files. What is needed IMHO is an outside view, tediously going through all tool contexts and actions, noting down what each modifier and each combination of modifiers does, as well as listing all hard-coded shortcuts within tool contexts which do not have an associated verb (i.e. can't be configured and customized in the 'keys/default.xml' file). Then this information needs to be analyzed, and based on it one or more proposals can be made how to unify e.g. usage of modifiers across the interface within all tool contexts and what other changes would be required (if you try to solve one conflict with the 'Shift' modifier, you are likely to create another one, or a new inconsistency, with a different modifier or a combination of them).

What is needed IMHO is an outside view, tediously going through all tool contexts and actions, noting down what each modifier and each combination of modifiers does, as well as listing all hard-coded shortcuts within tool contexts which do not have an associated verb (i.e. can't be configured and customized in the 'keys/default.xml' file).

I could start on something like this right away, although I might need a little bit of guidance here and there. I might not be the best person, since I don't use the keyboard in my work with Inkscape, nearly as much as others. But I'm motivated, and could start right away. Perhaps someone could set up a system for compiling and submitting this info (such as a table, or chart, or specific type of outline form -- whatever would facilitate the needed analysis), and I would be glad to go through Inkscape, and test each tool. It sounds basically like collecting data, right?

Although I understand that I'm probably not the best qualified person; still, if it would be helpful, I would be glad to do it. You could think of me as a research assistant, lol! But seriously, just lmk

Hi Brynn,

You're sufficiently qualified, don't worry about that! You know Inkscape, and everybody knows you. That helps getting people to listen when you make a new proposal.

Some ideas to get started: you could go through Tavmjong Bah's book, because he already discusses a lot of the modifier keys. You could also download the sourcecode and search in the code for occurrences of GDK_SHIFT_MASK, GDK_CONTROL_MASK, or GDK_MOD1_MASK (i.e. ALT key). If you're on windows you could use for example Notepad++ for this job. Usualy there's some comment in the sourcecode that explains what the key does in that specific context. This way you can check if Tavmjong has missed some use cases. If you need help then just ask here or mail me directly.

You're effort will be much appreciated!

PS: There are some modifier keys that will behave differently when pressed before dragging, from when pressed while dragging. I don't recall where exactly, but please be aware of such dirty tricks.

Awesome
I'll get started right away!

But I'm still curious if there isn't a particular format for compiling the data, which would lend itself best to the analysis to follow? Maybe like a giant chart of a keyboard? Or just a table? Table -- column for each key, with tools listed below? Or the other way around -- column for each tool, with keys listed below??

And a couple more questions: About looking at the source code -- would either Notepad or Wordpad work for this, or would I need a more sophisticated editor (such as Notepad++, as you mentioned)? When I search out the occurrences of the strings you mentioned, is this to identify or confirm what ~suv referred to as "hard-coded" modifiers? Because I won't be able to understand anything about the code. I assume it will be fairly clear which tool each occurrence refers to (I guess by looking for the "title" of the section where I find an occurrence)?

Also, tav's book, that I would need to purchase (not a problem), or could I use the online version? I know that the book/PDF contains info that the online version does not. But since I haven't seen the book, I don't know if that additional info would include any key modifier info.

And finally, let's decide on the best place to discuss this. Poor Grobe! I'm so sorry, I did not want to hijack your topic ! What about the new Development forum, for now. Once I get a working data set, we can move elsewhere?

If I were you I would just start with a spreadsheet, with a column for each modifier key (SHIFT/CTRL/ALT), and a row for each use case, grouping the use-cases per tool. You can then simply place a checkmark in the cells as needed. Optionally add a fourth column to denoted any other keys, such as "%" for snapping. These however will not be related to a specific use-case, so you could just as well make a different table or list for these

Notepad++ will allow you through multiple files, which is very handy. Notepad++ will also use syntax highlighting, which makes things much easier to read. Just try for yourself, and use whatever you find most convenient. Both will work.

When I search out the occurrences of the strings you mentioned, is this to identify or confirm what ~suv referred to as "hard-coded" modifiers? Because I won't be able to understand anything about the code. I assume it will be fairly clear which tool each occurrence refers to (I guess by looking for the "title" of the section where I find an occurrence)?

Spot-on!

I have no idead about Tavmjong's book, I don't have a copy.

Good luck!