I've gotten to a point in the tablet work where I'm ready do do more, but we'll need some fundamental changes to the internals.
Basically we will need to revisit anywhere we are using GDK_MOD1_MASK, GDK_CONTROL_MASK, GDK_SHIFT_MASK, etc.
The problem is that things are addressing the *physical* aspect of how things are triggered instead of the *logical* aspect. Up until now this has mainly affected Mac users. However, as I add more tablet support, I'm hitting up against that exact same set of limitations.
For example, on other OS's the extra buttons on a Wacom tablet itself can be mapped to various modifier keys. On OS X I have the option to set things to shift, Option(alt), Control and Command. That works ok for now, since it lets me draw with only the tablet (since I don't need to touch the keyboard for those).
It would be good to have that same freedom of workflow (or actually more) on Linux. But with Ubuntu, those four or eight extra buttons actually show up as buttons (numbers 9, 10, 11, 12, 13, 14, 15, and 16 on an Intuos3). So if someone is using a standard stylus on the tablet instead of just 3 buttons they get 11! Now that is where we need to start being able to use those buttons.
Instead of requiring an Alt-click to select under, for example, we could allow for Btn9+click to do the same function.
One additional factor to consider is non-tablet input. There are many different devices that GIMP supports through other means. It would be good if our internals had support for that too. See the "Hardware Support" section at http://www.gimp.org/features/
So the first round is to do a survey of the code and figure out the smart way to replace instances of "is the user dragging while holding down the ALT key?" with "is the user doing a tertiary drag" or "is the user doing a smart-draw drag" instead. I also would want to get away from a single "the magic key" for everything, and allow for context-specific use.
On Tue, Mar 11, 2008 at 11:23 PM, Jon A. Cruz <jon@...18...> wrote:
So the first round is to do a survey of the code and figure out the smart way to replace instances of "is the user dragging while holding down the ALT key?" with "is the user doing a tertiary drag" or "is the user doing a smart-draw drag" instead. I also would want to get away from a single "the magic key" for everything, and allow for context-specific use.
I agree in principle, but no "tertiary" and "smart" drags please. They would confuse the hell out of both users and developers. Please go on with your change, but please keep the old names for things. They are learned in a lot of brains and documented in a lot of texts. Let Alt+click remain Alt+click, which is the name world knows it under, even if you will allow some other levers or appendages to emulate it.
On Mar 11, 2008, at 11:34 PM, bulia byak wrote:
I agree in principle, but no "tertiary" and "smart" drags please. They would confuse the hell out of both users and developers. Please go on with your change, but please keep the old names for things. They are learned in a lot of brains and documented in a lot of texts. Let Alt+click remain Alt+click, which is the name world knows it under, even if you will allow some other levers or appendages to emulate it.
OK.
So the naming of things can remain the same, especially for anything user-visible. That much definitely sounds good.
Hopefully we can get feedback from others too on what insights they might have. Also any info people might have had on bit's they've looked at in the past and thought "hmmm... maybe this should be cleaned up"
Perhaps an idea would be to make a look-up table:
{ "alt select drag", settings (i.e. GDK_MOD1_MASK or some other thing) "shift node drag", settings ..., }
Then instead of 'if (event->button.state & GDK_MOD1_MASK)' you can do 'if ( try_match_in_userkeys_table("alt select drag", event->button.state) )' Loading the settings in the table from preferences would allow people to assign their own things for it? (as a first step, because all tooltips have to be changed accordingly :S aaargh)
Haven't thought this through; so there might be a simple reason not to do this.
Johan
participants (3)
-
unknown＠example.com -
bulia byak -
Jon A. Cruz