On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer
<[email protected]> wrote:
> On Tue, Feb 22, 2011 at 02:35:19PM -0600, Favux ... wrote:
>> Peter would like these scripts vetted. So if you get a chance please
>> review them and comment.
>>
>> This is a sample of the the sample scripts. The idea is to provide a
>> text file as a framework to alter the tablet settings, similar to what
>> wacomcpl would have produced in its xsetwacom script file .xinitrc.
>
> I don't have to mention that wacomcpl is broken by design since server 1.4?
> and these scripts replicate the issue.
>
>> Except it is broken into input tool sections. This makes it easier
>> for the user to see what parameter adjustments are useful for a given
>> input tool.
>
> why don't we add this information to the man page?
> if only half the time that is spent on writing scripts to hack things up
> would be spent on proper documentation in the driver we wouldn't need the
> scripts in the first place...
Agree with this point. And I've come to enjoy improvements to xinput
list-props were it only shows values that make sense for current tool
(or xsetwacom equivalent).
>
>> The pad section attempts to "mimic" the physical button
>> layout for the tablet. I use the generic name .xsetwacom.sh for them.
>>
>> The defaults are used and stated with the ranges in the comments for
>> ease of use. This is obviously a hack while we wait for tablet gui's
>> for Gnome and KDE and the rest. As an aside I noticed the plan for
>> the Gnome gui is to be for tablets only, not tablet PCs. Hopefully
>> they will be able to use it anyway.
>
> if you refer to the missing "touch", that's just the current implementation.
> I'm still waiting for a "UI designer" to review my suggestion.
>
> other than that, there is no plan aside from "peter hacks it up whenever he
> finds a spare minute somewhere". I've gotten zero feedback for this tool so
> far so I'm still operating blindly.
I've looked at the screenshot but not code yet. :-) I'm waiting on
that "UI designer" as well. I'm always leery of hacking on something
when I know someone is going to come back and say "it needs just one
button on the screen that says 'make it work' and get rid of the
rest"... and make most the time useless.
>
>> Right now the pre-0.10-11 parameter names are used as the majority of
>> users are probably still pre-0.10-11 and will be until Natty, Fedora
>> 15, etc. are released in a few months.
Are these bash scripts? For the cosmetic name changes, you can use
associative arrays to hide some of this.
declare -A name_remap
if [ $xsetwacom_version -qt 2 ]; then
$name_remap["ClickForce"]="Threshold"
else
$name_remap["ClickForce"]="ClickForce"
fi
xsetwacom $STYLUS $name_remap["ClickForce"] 27
Of course, how to set xsetwacom_version is a little tricky. My idea
above is to remap the 0.10.x type version #'s to an easier to parse
integer. For versions of xsetwacom that have same interface, they map
to same integer value.
Partial example:
case `xsetwacom -V | awk 'NR==1{print $1}' in
0.10.1|0.10.2) xsetwacom_version=1;;
0.10.11|*) xsetwacom_version=2;;
esac
>>
>> The user can go on to use a subset of the script, usually the pad
>> button assignments with maybe stylus pressure etc., to generate a
>> profile for various programs such as Gimp if they desire. Which is
>> one of the reasons for showing alternate button assignment examples
>> for specific graphics programs.
>>
>> The general tablet script is placed in a start up file and the
>> profiles in launchers.
>>
>> We've been using them on Ubuntu forums since Lucid (10.04) X server
>> 1.7 released April 2010.
>
> ok, my main issue with the scripts is that they duplicate the device names
> heavily, which makes them hard to update (yes, search/replace, I know) and
> hard to read. worse, TabletPC-1FGT.sh mixes IDs and device names.
>
> one approach would be:
>
> DEV="Wacom Cintiq 12UX2"
> STYLUS="$DEV stylus"
> PAD="$DEV pad"
>
> xsetwacom set "$STYLUS" Suppress 4
> xsetwacom set "$STYLUS" RawSample 2
> ...
>
> once you start looking at that, you notice that the scripts are mostly
> identical. At which point I'm starting to wonder why we have 5 different
> scripts?
>
> as with all scripts, forcing defaults to the default value is generally a
> bad idea. It means that if we change the defaults in the driver to improve
> the behaviour users won't notice because they're blindly applying some
> settings. It also means we won't get user feedback because they don't even
> know anything has changed.
Agree. Especially were we are at right now, I'd expect those values
to improve each new release and scripts will hide these improvements.
>
> I'm not sure why there is a "alternative pad button assignment examples"
> section. Surely users who figure out Button2 "key ctrl" also figure out
> "key shift" without having someone pre-fill those in?
>
> and some of the settings are confusing at best. BambooPT's button
> assignments are rather random and that's afaict the only thing that's not
> set to the defaults.
>
Here is my take on overall topic.
1) Unclear to users what options are valid for each tool. Fix
documentations and xsetwacom output to help clarify.
2) Majority of users do not like default values for subset of
parameters and so majority users need something like these scripts to
overcome that. Can we change defaults so majority do not need these
scripts?
I see reoccurring theme in scripts that PressureCurve and TPCButton
are not at default values. The rest seem to be default values;
ignoring buttons for a minute.
Should we always default TPCButton to "on"?
Where did those PressureCurve values come from? There are at least 3
different values and I'm pretty sure the hardware "feel" is not that
different between models that need custom ones. I suspect they were
just 1 user preference per device type that contributed to scripts?
3) Buttons are messy.
Bamboo's fall into #2 (default values) and will have saner defaults
once everyone is using 2.6.37+ kernels.
Some of the stylus buttons fall into #2 as well. Based on scripts,
looks like we are inconsistent in what generates button #3 click.
Lets say stylus only has one button. What does user expect that to
do? Button #3? Today its probably button #2. If its rocker button,
do they still expect same behavior?
I'll kinda ignore the rest of buttons because I'm not sure how people
use "pad" buttons.
Chris
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
