My vote is for the simplest approach - just define a new constant for Alt in one place and do not touch all other files. Reason: since I'm questioning the utility of this whole idea, I want its implementation to be as non-intrusive as possible from the coding viewpoint.
On 8/8/07, Thomas Worthington <tww@...1737...> wrote:
Okay, I've checked the source code out and had a quick look at it with an eye to doing something about the Alt-mouse issue on Linux.
There are currently only 50 hardwired references to GDK_MOD1_MASK in the whole source tree (over 21 .ccp and .h files).
Two options spring to mind: 1 Define a new global, ALT_KEY_MASK (say) and default it at run-time to the value of GDK_MOD1_MASK unless the user sets it to another value in their shortcut file, then do a simple search and replace for all occurances of GDK_MOD1_MASK. This would mean that the user's choice to treat something else as Alt (presumably Meta) would be global and not only for the mouse combinations. This would at least be consistant for that user and also for developers who would simply use the new global ALT_KEY_MASK everywhere they would previously have used GDK_MOD1_MASK.
2 Alternatively we could be more selective about the replacement so that only mouse combinations would be affected. This would mean that developers working on items not involved in the question of Alt+mouse need never bother about it but it would mean that a user who opted to change the Alt key would be faced with some functions where it was still Alt and others where it was now whatever they had picked instead.
There's also the issue of the hint text. In the former case there is some justification for not altering it and just letting a user who's made the decision to change live with the fact that the hint text still says "Alt", but in the second case the functions modified would really have to be changed (and changed back if they undo the key mapping).
At the moment I'm enjoying being able to easily use node sculpting using Meta-mouse and am very happy to continue on to impliment option 1 but obviously it affects more files which might make others unhappy.
This is a list of the files GDK_MOD1_MASK appears in (and the number of occurances in each):
./src/dialogs/xml-tree.cpp:1 ./src/helper/window.cpp:1 ./src/ui/dialog/dialog.cpp:1 ./src/ui/view/edit-widget.cpp:1 ./src/box3d-context.cpp:1 ./src/gradient-context.cpp:2 ./src/flood-context.cpp:1 ./src/dropper-context.cpp:1 ./src/gradient-drag.cpp:3 ./src/connector-context.cpp:1 ./src/seltrans.cpp:3 ./src/event-context.cpp:1 ./src/select-context.cpp:8 ./src/rect-context.cpp:1 ./src/dyna-draw-context.cpp:3 ./src/object-edit.cpp:7 ./src/context-fns.cpp:1 ./src/nodepath.cpp:4 ./src/node-context.cpp:2
./src/macros.h:4 ./src/modifier-fns.h:4
What does everyone think? This would shift the responsibility for how to cope with the mouse squarly onto the user's shoulders. S/he would have the option to stick with the "official" shortcuts and modify their WM or to consciously select a different keyboard mod value. Developers can then forget about the issue.
Now the caveat: I'm not a C++ programmer, although I've been programming for 29 years so I'm not a newbie. Be that as it may, I might be totally misunderstanding how deeply this change would affect the project so more experienced heads need to tell me if I'm barking up the wrong tree before I start chopping it down. And on that mixed metaphor I shall conclude.
Thanks,
Thomas Worthington
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel