Wacom Tablets & TabletPC Properties Tool

This page is aimed at discussing a possible tool for configuring Wacom Tablets & Tablet PC in Ubuntu 9.04 (Jaunty).

The purpose of the tool is to allow users to set up their Wacom input devices graphically instead of manually editing xorg.conf. In that aspect it differs from wacomcpl and Tablet Apps, however the rest is similar (if the rest gets implemented).

The tool will save the configuration in xorg.conf, and enabling the tablet will ask the user to logout and login (that part will also need to check the user's sudo rights and ask for his password). To get immediate setting applied, the tool can use xsetwacom, which should still work with other methods than wacom.

These properties (= everything else than enabling the wacom in xorg.conf) can be save in a file in the user directory that gets run by Gnome when the session start. However, tablet PC might appreciate the possibility for an Administrator to set some properties (mainly calibration) system-wide (xorg.conf), in which case we can have a "Set preferences globally" checkbox.

The tool can then be expanded to allow the configuration of devices properties - stylus sensitivity, Expresskeys configuration and calibration of the stylus for Cintiq and TabletPC so that the position of the pen tip matches the position of the X cursor (though this fonction would also deserve an applet, since calibration can change depending on the user's point of view). See "Extended version"

Feel free to edit the page to add your comments or propose different layouts. You can edit the .svg mockup in Inkscape, then attach your proposition, or just add any other sketch.

Mockups

Gnome

Current version

• SVG file - Work file editable with Inkscape.

Extended version

• SVG file - Work file editable with Inkscape.

Feedback from MPT

What is the "Activate Tablet" checkbox for? In what situations would you want it to be unchecked?

"Tablet model" seems to be followed by a button. What does the button do? If it's for changing the tablet model if it was incorrectly detected, would an option menu work better?

"Write configuration in /etc/X11/xorg.conf" and "Write Xorg HAL configuration file in /etc/hal/fdi/policy" are both utter gibberish. How could they be eliminated?

It's not clear what the "Stylus" or "Calibrate" buttons do. Could they be reworded?

I can guess what "Sensitivity" and "Smoothness" are, but I have no idea what "Click Force" or "Sup[p]ress Points" mean. Could they be reworded to be more understandable? (By the way, slider labels should use sentence case, not title case.)

How would I tell whether I'd set the correct values for any of those sliders? Should the window contain a test drawing area?

Would it make sense to change "Layout" to "Buttons"? That seems to more precisely cover what you set in the tab.

I suggest making menus look different from buttons in the mockup, otherwise it's hard to tell which is which.

I don't understand the distinction between "Apply", "Save", and "Close". If changes took effect immediately, none of those buttons would be necessary.

Response

> What is the "Activate Tablet" checkbox for? In what situations would you > want it to be unchecked?

There's decent probalility the HAL method will still not work for Jaunty. See the LWP discussion, but if HAL really can't change their opinion, the workarounds aren't clear.

"Activate Tablet" is there for the xorg.conf method. It would write the configuration in xorg.conf or remove it at will (as long as we keep the statu quo in Ubuntu, which is no xorg.conf wacom lines by default). If an user doesn't use a Tablet anymore (or prefer the .fdi method), we need also to provide a way to revert the xorg.conf

The fdi HAL method wouldn't require it - the tablet is plugged, it's already active (I suppose the .fdi won't cause problems for KDE like xorg.conf does).

> "Tablet model" seems to be followed by a button. What does the button > do? If it's for changing the tablet model if it was incorrectly > detected, would an option menu work better?

I was following the System>Preferences>Keyboard>Layout Tab. There's many tablets and TabletPC, following the method for kb sounded like a good idea. I'm open to other ideas, but I'm not sure what you mean by option menu (if you can please give an example in Gnome or sketch a quick layout - you can also fire Inkscape). I'd need a crash course in Gnome UI vocabulary, if you've got a link.

Good autodetection of the tablet would probably be ok with HAL for USB, but AFAIK it doesn't work (at the moment?) for TabletPC & serial tablets. We need lw input there.

The other tabs are specific to the tablet model, we can't just get generic tablets.

> "Write configuration in /etc/X11/xorg.conf" and "Write Xorg HAL > configuration file in /etc/hal/fdi/policy" are both utter gibberish. How > could they be eliminated?

By ensuring we make a good default or Jaunty (probably still the xorg.conf method).

However keeping a way to chose the other method is important since we'll have to make it easy for users to try it. The option output by the tools are the same, have a look in the wiki, but outputing to the fdi or xorg.conf doesn't seem any more complex programming wise. We could have an "Advanced" option, but it doesn't fit well with Gnome. And when we switch to HAL completely, *BSD and others might still use xorg.conf (but I've no idea).

> It's not clear what the "Stylus" or "Calibrate" buttons do. Could they > be reworded?

Stylus is the name used by the lwp and traditional on Linux (it's also the name of the input device in X). I just checked their manual, and Wacom uses Pen for the Windows/Mac tab, but then use Tip in the documentation, which is confusing. For reference: _Wacom_ _Linux_ Pen/Tip stylus Eraser eraser ExpressKeys pad Touch Strip Left/Right Strip

We could use the Windows names, "Pen" or better "Pen Tip" (the eraser is also on the pen, but that's a detail for Wacom) instead of stylus (translation wise, in French it's stylet, the French for stylus, not crayon or stylo ).

The button named Stylus on Fig2 is for choosing what input device properties the user want to set (stylus, eraser, touch? - and possibly cursor if that's not handled by mouse properties) - compare Fig3/4 where the user clicks on Device : Stylus and changes it to Device : Pad. Fig3/4 are for Layout, only stylus and pad. Pad doesn't have properties on the other hand, unless we still can't get detect Pad key order properly and the doublet fig4/5 can't get taken care, then Fig4 could be in Properties (note: wacomcpl doesn't detect the pad buttons order, somebody at lw may know what the problem is, and if with a few effort on our part to collect user's button layout we could make sure Fig4 is not necessary).

Calibrate only shows for Cintiq & TabletPC. It's the word used by Wacom (& the lwp for wacomcpl), it pops up two cross, top left and bottom right, the user clicks on each and the cursor will show right below the pen tip instead of 1cm appart. The position could be bottom left instead of just below the "Stylus" button, unless we unclutter Fig1 and move "Calibrate" in the "General" tab - but I feel keeping "Calibrate" in Stylus/Pen/Pen Tip makes it easier to understand (the ones that have a normal tablet don't see it).

Arguably "Calibrate" also need a Gnome and a KDE applet, since they are often used (Calibrating is required each time the user changes its position). But the Tool is where Windows/Mac users are going to look (even Linux users forget about applets...) and that way it will also work in Xubuntu (+ other desktops).

If we want to make "Calibrate" more clear, I need some suggestions because I can't figure how to better phrase it.

> I can guess what "Sensitivity" and "Smoothness" are, but I have no idea > what "Click Force" or "Sup[p]ress Points" mean. Could they be reworded > to be more understandable? (By the way, slider labels should use > sentence case, not title case.)

That was just a copy/paste from wacomcpl. Sentence will make it easier, I'll check how Wacom calls that in their manual (but their UI is a mess) and try to turn it into sentences.

We can also use a graphical representation, see TabletApps http://alexmac.cc/tablet-apps/ latest screenshot, under "Device Pressure"

I didn't know how difficult it would be to add it for the programmer, nor if he'll have the time for that, but the code for TabletApps is quite small. If it's already a Gtk widget, why not? Tell me if you think it's worth investigating.

> How would I tell whether I'd set the correct values for any of those > sliders? Should the window contain a test drawing area?

Yes, same reason as above, I'd be delighted to put one, but I'm not sure if it will be too big a burden for a first shot at programming it. The testing area in TabletApps looks nice, but I tried it and couldn't see any difference after changing the settings, whereas I can see the difference in Inkscape. I might just be blind though.

For Tablet users even a small zone to check double-clicking speed with the toll might help, but we need somebody with a pen for that.

> Would it make sense to change "Layout" to "Buttons"? That seems to more > precisely cover what you set in the tab. Maybe Buttons for Fig3/4 and Layout for Fig5 (Layout comes from Keyboard Settings in Gnome) so that's four tabs instead of 3?

> I suggest making menus look different from buttons in the mockup, > otherwise it's hard to tell which is which. > > I don't understand the distinction between "Apply", "Save", and "Close". > If changes took effect immediately, none of those buttons would be > necessary.

If changes takes effect immediately, Apply is useless. Close doesn't do anything, but I saw it on Gnome setting apps (Mouse/Keyboard). But that's not possible on all tabs with the xorg.conf method (the first tab at least needs a Save or something for the xorg.conf method).

Save can get rid of too if we're sure about what the default configuration will be for Jaunty. The UI maybe is too much influenced by the actual experience in Ubuntu(or Linux?) where you prefer to triple check what you're doing before ever thinking about commiting it to a configuration file