From: Ping@LinuxWacom <pin...@gm...> - 2006-12-01 20:44:17
|
On 11/29/06, Magnus Vigerl=F6f <wi...@bi...> 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 overlappe= d area. But, with a different reason :). The edges between two (or more) area= s 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 scree= n 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. I don't think we should send the prox-out at the very moment we passes the > edge of the area since that will make it harder to use and to have any > precision when working around the edges. It will be even worse than how > the > graphire worked in 0.7.6-1 since we only had one tool in that case and th= e > pointer just froze. Here we might end up moving a different tool on the > other > side of the screen when the edge is passed... So having a little buffer, > 1/4 > inch or so could be enough, outside the area that you have defined will > help > the user to use the edges. As I described above, let users decide it with Screen mapping options. We send prox-out when it is out. > The > > major issue for this solution is with serial PL, UD, and TabletPC. The= y > > *may* need to switch tools (from eraser to stylus) after an eraser is > > detected (refer to wcmSerial.c and wcmISDV4.c as well as wacom.c for PL= ) > > Have only had a glance, but I think I saw one place that actually sent a > prox-out for the old device before sending the next one (for a different > tool), so is this really a problem on this level? Maybe not. I am not very sure. We'll know when we get there. > We need to keep track of which InputDevice that is currently in prox. In > the > current implementation only one InputDevice can be in prox for each tool, > so > when an prox-out arrives it's quite easy to know which one to send it to. > > Here, we will have several InputDevices to choose from, and it is fully > possible that the coordinates for the event is not within the bounding bo= x > of > the InputDevice currently in prox. By collecting all area into one place > we > can store additional information such as the current area (=3DInputDevice= ) > in > prox to send the prox-out event to. Agree. 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 :). > I agree. No configuration changes are needed to define several different > areas > for the same tool (=3Dseveral InputDevices). The 'additional structures' = are > purely source code constructs, not configuration. Works for me. > I'll use the example configuration you defined earlier, but lets use two > different styluses with erasers each one being defined for thee different > 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 (i= f > there's a current area in-prox and that doesn't match we only need to > 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 :). Yuck... That was pretty hard to write in the way I wanted... I hope it's no= t > too hard to follow... I am still here :). Different areas can have the same InputDevice as destination. This will > probably not be useful at the moment, but if (menu)buttons are implemente= d > with areas on this level the implementation will be easy. How do you implement the same InputDevice with different areas? This sounds a bit 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. Ping |