On Friday 01 December 2006 21:44, Ping@... wrote:
> On 11/29/06, Magnus Vigerl=F6f <wigge@...> wrote:
> > Yes, we could support overlapping areas, but I see a danger in confusing
> > the
> > user if the tablet works differently for one spot depending on where you
> > came
> > from...
> I thought about this one again. Now I agree we should not support
> overlapped area. But, with a different reason :). The edges between two (=
> more) areas for the same tool will be taken care of by the screen mapping
> options (suppose they are called ScreenTopX, ScreenTopY, ScreenBX, and
> ScreenBY. User should define a virtual screen which is larger than their
> actual screen so the inner of the defined tablet area maps onto the whole
> screen. That means leaving rooms around the edges if users don't want to
> jump from one setting to the other. But, it will be decided by users not
> us, developers.
And my own arguments are thrown back at me ;) Yes, this would be better tha=
the way I suggested. If we allow the Screen-Top/Bottom coordinates to be bo=
smaller and bigger than the screen we actually have '[ 1559640 ] Screen=20
mapping' in a little box.
The only 'problem' I can see with that would be that if the area of the scr=
that we map to is smaller than the physical we'll still have the same probl=
with using the pixels closest to the edges.. Maybe these are two completely=
different sets of properties that we should keep separated?
> For tablets with more than one channel, more than one InputDevice might be
> > in
> > prox at the same time, can't they? This construct would support several
> > InputDevies to be in prox at the same time as the information that is
> > stored
> > for this purpose resides together with the tool, and is not global. If
> > Wacom
> > decided to make a tablet with ten channels this construct will support
> > this
> > too without any changes..
> 2 is the maxium as far as I can see since we only have 2 hands :).
You can get some nice effects if you take several crayons, hold them tight=
together in your hand, and draw with them all at the same time on the=20
> > I'll use the example configuration you defined earlier, but lets use two
> > different styluses with erasers each one being defined for thee differe=
> > areas, so we'll have some more InputDevices (12 of them). The worst case
> > in
> > this construct would be 4 checks on the tool and 3 checks for the area
> > (if there's a current area in-prox and that doesn't match we only need =
> > check
> > the other two, so either way we only need to make three area checks).
> Could not follow this concept closely yet. This is ok. I normally
> understand code more accurately than human language (That's my fault :).
Ok, let's make some code then...
I think I have the info I need for the first step now, so I'll start doing=
some changes based on what we've discussed so far. It'll be a number of=20
patches each one doing something simple. Do you want all patches in one=20
Patch-request (Tracker item) so they are in the same place? (I'm willing to=
remake them if there will be a conflict due to other changes...)
> Different areas can have the same InputDevice as destination. This will
> > probably not be useful at the moment, but if (menu)buttons are
> > implemented with areas on this level the implementation will be easy.
> How do you implement the same InputDevice with different areas? This soun=
> a bit complicated.
No, it doesn't really make much sense if you think of using different areas=
that sends movement data to the same InputDevice. That would probably confu=
the user as well as being hard to configure.
But, imagine that you agree with me for a minute that defining areas on the=
active area of the tablet that acts like buttons is something we want to do.
The areas for the buttons wouldn't be any different from the areas that are=
defined for each tool when there are multiple InputDevices for different=20
areas of the tablet. After all it's just an area you need to check if the=20
tool is inside in, the only difference is what you do once you got a match.
Mapping movement data will be pretty straight-forward, just send it to the=
InputDevice, you only need a pointer to an InputDevice here.
=46or buttons we probably want to send the presses/releases to a separate=20
InputDevice. Ok, I have absolutely no idea if the button-information should=
be treated as a separate device (like the pad on the g4) or included in the=
same device tied to a tool, but either way the reasoning is valid.
There will not be only one button defined and sending them to different=20
InputDevices is not a good idea. Hence the reason of sending information=20
about different areas to the same InputDevice. There need to be some=20
additional information associated with the area definition so each button=20
will be given a specific identity (no, not necessary unique).
The difference between the movement and button case would be extracting som=
additional information of what to do with the data for the specific area=20
before button-events are generated for the InputDevice. Hopefully this will=
not be too complicated.
> > I understand. Maybe we can go with Andrew's suggestion.
> > You mean using the area just outside the active area of the tablet? In
> > that
> > case I just have to object.. I think it is only as useful as the fixed
> > menu
> > definition in the X-driver.
> No, I mean his following statement (I am thinking of xsetwacom command):
> - For tablets that don't have built-in menu strips menus by default
> will be disabled, but should be definable via some interactive
> application that will remember strip position/length and either
> generate some statements for xorg.conf, or store into some file from
> which they can be loaded somehow at startup.
Hmmm... Ok, haven't seen this paragraph... Oh.. Something ate the mail from=
Andrew for some reason, so I never saw it until now (checked the sf=20
Ok, you're at the simple menu bar-thingy. I still think this will be=20
insufficient and want a more flexible way to define 'menus' in a generic wa=
for any tablet and any layout.
But, that's a discussion for a later time, I've got some changes to make in=
the source based on what we've agreed on so far and this is something that=
won't affect that part.