Re: [Gimp-developer] 6 DOF HID support

2010-07-20 Thread Sven Neumann
On Sun, 2010-07-18 at 07:55 +0200, Cedric Sodhi wrote:

 I also might want to map Tilt (which GIMP currently has no support
 for)

That is incorrect. GIMP has had support for Tilt for more than ten years
(since before version 1.0). It was limited to the Ink tool though until
recently.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 6 DOF HID support

2010-07-20 Thread GSR - FR
Hi,
s...@gimp.org (2010-07-20 at 1409.51 +0200):
 On Sun, 2010-07-18 at 07:55 +0200, Cedric Sodhi wrote:
 
  I also might want to map Tilt (which GIMP currently has no support
  for)
 
 That is incorrect. GIMP has had support for Tilt for more than ten years
 (since before version 1.0). It was limited to the Ink tool though until
 recently.

It had full support for a long time, not only ink tool, via GIH
exporter's Tilt X  Y options. But there are not many GIH, and even
less using the full feature set avaliable.

GSR
 
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 6 DOF HID support

2010-07-18 Thread Alexia Death
On Sun, Jul 18, 2010 at 8:55 AM, Cedric Sodhi man...@gmx.net wrote:

 GIMP/GTK accounts for the channel's existance, but GIMP does not know what to 
 do with a Wheel channel, as what GTK identifies it, and can only handle the 
 button events to be mapped to mouse-wheel events.

GIT does. Wheel is as mappable in dynamics as any other input. You
cant try it if you have either artpen or airbrush.

 So much for the canonical input devices and their fixed meanings. I don't 
 think anything is fixed and it just depends on the type of input device how 
 likely one might want to change it. That's what I meant by a sliding line.

You never want to map X,Y and pressure to UI functions. That just
woudnt make sense. Maping tilt or wheel to UI functions would make the
pen unusable in its primary function. There was a bug recently in
wacom drver that made wheel send scroll events. The pen just wasnt
usable in UI. So, Im sorry, but tablets axes are not something you
want to map to ui.

 I also might want to map Tilt (which GIMP currently has no support for),
Again wrong. Try 2.7.1 or GIT.


 And unfortunally, there is no way of fixing this somewhere else. GTK offers a 
 way to swap channels and map buttons which is a complete redundancy to what a 
 driver or xmodmap can do. But it offers no way to give the Axis actual 
 meanings in the program, which is what only IT can and should do.
You really should take a look at development versions before writing
here. Please look at either 2.7.1 or GIT then we can talk again.

-- 
--Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 6 DOF HID support

2010-07-17 Thread Cedric Sodhi
A small PS: Enabling Screen for the 3dmouse device in Extended Input Devices 
renders the mouse dead for drawing.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 6 DOF HID support

2010-07-17 Thread Alexia Death
Just so its said first, input stuff is business of GTK. Gimp conjumes what GTK 
provides.

On Saturday, July 17, 2010 22:45:07 Cedric Sodhi wrote:
 I, as a user, would like to directly corelate the axis (x motion event!!!)
 to zoom, pan, color, etc! Therefore I say that this needs a coherent
 interface where such mappings can take place.
Any paint options are mapped via dynamics, try 2.7 from git and you'll see 
what I mean. Pan and Zoom are UI controlls and such part of a different 
concept. One that does not exist yet. This concept is where mapping axis of 
odd devices like navigator to UI and action control should be set.

 
 I think these major points which can bring a great advantage for any
 professional who uses the appropriate input devices.
Tablets are paint and draw tools and their axis have fixed meanings. Chaninging 
that would be silly. Navigators and other such tools are separate business.

-- Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 6 DOF HID support

2010-07-17 Thread Cedric Sodhi
There is a sliding border between what is a canonical input device and what is 
absused, so to say, as an input device. Consider my tablet (Intuos). You say it 
has axis with fixed meaning? I beg to differ! The device provides a 
6-dimensional motion event. Channel 0 to 4 being more or less what you said, 
fixed with something that would not make sense to change (I'll revise that in a 
second), then channel 5 corresponds to the wheel on the tablet. The driver also 
emits a button event when scrolling the wheel but at the same time it provides 
positional data in the motion vector.

GIMP/GTK accounts for the channel's existance, but GIMP does not know what to 
do with a Wheel channel, as what GTK identifies it, and can only handle the 
button events to be mapped to mouse-wheel events.

So much for the canonical input devices and their fixed meanings. I don't think 
anything is fixed and it just depends on the type of input device how likely 
one might want to change it. That's what I meant by a sliding line.

I also might want to map Tilt (which GIMP currently has no support for), which 
is channels 3 and 4 to something like color (or just brush size). As with the 
rather inconsistent way GIMP/GTK handles all this stuff right now, only one 
hardcoded channel, that is the channel identified as Pressure by GTK (usually 
2) can have any effect. Every channel mapping is 100% hardcoded which is maybe 
not what you want with a canonical input device and is certainly not what you 
want if you use additional input devices.

And unfortunally, there is no way of fixing this somewhere else. GTK offers a 
way to swap channels and map buttons which is a complete redundancy to what a 
driver or xmodmap can do. But it offers no way to give the Axis actual meanings 
in the program, which is what only IT can and should do.

On 07/17/2010 09:54 PM, Alexia Death wrote:
 Just so its said first, input stuff is business of GTK. Gimp conjumes what GTK
 provides.

 On Saturday, July 17, 2010 22:45:07 Cedric Sodhi wrote:
 I, as a user, would like to directly corelate the axis (x motion event!!!)
 to zoom, pan, color, etc! Therefore I say that this needs a coherent
 interface where such mappings can take place.
 Any paint options are mapped via dynamics, try 2.7 from git and you'll see
 what I mean. Pan and Zoom are UI controlls and such part of a different
 concept. One that does not exist yet. This concept is where mapping axis of
 odd devices like navigator to UI and action control should be set.


 I think these major points which can bring a great advantage for any
 professional who uses the appropriate input devices.
 Tablets are paint and draw tools and their axis have fixed meanings. 
 Chaninging
 that would be silly. Navigators and other such tools are separate business.

 -- Alexia
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer