[ubuntu-x] Fwd: Wacom tablets, TabletPC and Xorg support for Ubuntu 9.04 (Jaunty)

[Loïc Martin]

Matthew Paul Thomas wrote :
> Loïc Martin wrote on 11/11/08 20:50:
>> ...
>> I've done a mockup at
>> https://help.ubuntu.com/community/Wacom/PropertiesMockup and I'm
>> attaching a compressed Inkscape SVG. Only the first
> 
> This looks like a good start. However, it should be on wiki.ubuntu.com
> (or live.gnome.org), not help.ubuntu.com, because it's not a help page.

I'll move it to https://wiki.ubuntu.com/Wacom/PropertiesMockup. I might
wait a day or so till I have an updated mockup.

>> I also started a thread for discussing this possible tool on
>> linuxwacom-discuss (so we don't mix discussion about the tool and
>> discussion of the solution adopted for Jaunty). As for request on the
>> LWP side it's nice if this discussion happens in LWP's mailing list, so
>> other distribution have the opportunity to see what we do and
>> participate. The thread is at
>> http://sourceforge.net/mailarchive/forum.php?thread_name=4919DE29.5090906%40gmail.com&forum_name=linuxwacom-discuss
> 
> I'm not keen on joining another mailing list just to design one window
> (especially since, as shown by its Web archive, a majority of its
> messages are spam). But you're welcome to forward this feedback there.

I had the same problem. Filter [SPAM] in the subject and
linuxwacom-discuss at lists.sourceforge.net in the recipient and you'll be
safe (not much traffic compared to ubuntu-devel-discuss).

I can run around and try to mix the two discussions together, but it's
going to be increasingly difficult. We need linuxwacom input on the
subject. I'm sure we all agree we want their opinion (the tool itself
would need their input, especially for TabletPC) and a collaboration
would add tremendous value to our users. They always end up looking at
linuxwacom for documentation, and having it conflict with the method in
Ubuntu means we'll keep having forum threads and erroneous Launchpad bug
reports where people were advised by fellow Ubuntu users to compile the
drivers and follow an outdated model (/dev/input/event# on USB,
/whatever/ttsy0 for TabletPC) for the configuration.

I'd understand it might not be possible, but if you could get into the
list for the first discussions, even deactivating receiving emails from
the list while keeping the possibility to forward your own emails to
linuxwacom-discuss, that would really help. I'm sure they'd appreciate
an @canonical address showing up here and there ;)

> In Gnome, mouse and touchpad settings are handled in a single tabbed
> window. Why should tablet settings be in a separate window? Could they
> instead be another tab in the same window?

I don't know why they couldn't. However, if we want this program to be
also "endorsed" by the Linux Wacom Project, it can't pull a dependency
on Gnome. See Ron's email at
http://sourceforge.net/mailarchive/forum.php?thread_name=20081112162718.GA11442%40homer.shelbyville.oz&forum_name=linuxwacom-discuss

Ron wrote:
>>> > > Preferably something simple that works without forcing KDE
>>> > > or GNOME etc. on people -- but we can keep this in a separate
>>> > > package so the core linuxwacom driver deps can remain minimal.
>> > 
>> > It needs to integrate better than a motif application though  ;) 
> 
> If it's vanilla gtk widgets, you won't hear too many complaints
> from me  :)   If people _have_ to install large chunks of KDE or
> GNOME (or motif:) to use it though, that may not be as popular.
> 
> I can't really think of anything it would need from them anyway,
> but if there is something, it should probably be an optional extra
> either as some sort of plugin, or that detects them at runtime if
> they are present (and works for most other things if they are not).

Keybooad and Mouse are already separate in Gnome. I don't see a tablet
as a mouse, nor a mouse as an "extended input device", but it's also up
to what other people think (LWP, Gnome, KDE) and what distributions
think. We've got Ron input for Debian, let's hope we can get
Fedora/Suse/RH/Mandriva/Gentoo opinion. Using different configuration
tools when switching desktop/distributions is hardly a good user
experience, and tablets/TabletPC are still niche enough that duplicate
programming efforts can't reasonably be expected.

Back to your email:
> 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 ;)

Loïc