On Wed, Feb 23, 2011 at 10:03 AM, Chris Bagwell <[email protected]> wrote:
> On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer
> <[email protected]> wrote:
>>
>> 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).
So we want the user to read man wacom, xsetwacom, xinput and then
assemble their own script combining xsetwacom and xinput? I agree
that the xinput improvements are welcomed and proving useful and I've
added xinput commands to my scripts.
>
> 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.
>
Getting UI input is proving problematic.
> Are these bash scripts?
They are an imititation of wacomcpl's .xinitrc, except organized into
input tool sections and minus at the end of the script:
# run the primary system script
. /etc/X11/xinit/xinitrc
Which is the old X script chain.
> 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
Fair enough, and good ideas. But rather than blowing the users mind
on exposure to this wouldn't an interface hiding this be better?
While some Wacom users have put in the time to learn the xsetwacom
interface that doesn't mean they've learned BASH scripting, or want
to.
> 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.
Tool input sections are intended to include the useful options, not
all valid options.
> 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?
It's not a question of liking. Users need to configure their tablet
buttons, and some need to for each application they use (profiles).
Especially graphic professionals with the professional models like the
Cintiq and Intuos4. There's a reason the high end tablets have all
those buttons and strips and a touchwheel. This is a big help to
their work flow in individual applications. Pressure and stylus
button assignment go along with that. They very much object to
anything that slows them down, time being money to them. They are
willing to invest some time in technical details to get their setup
the way they need it. It all becomes muscle memory to them.
Others need to vary parameter's to deal with individual bugs on their
systems. Some will want to vary parameters like ScrollDistance and
TapTime etc. to get a feel they like.
> 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"?
No. The current default with it on for tablet PCs and off for tablets
is fine. That's my mistake if I have it on for tablets. Force of
habit.
> 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?
Correct. But default and range is stated. I must have left them in
as examples. I agree it would be better to set all of the pressure
curves to default.
> 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?
Most with a single stylus button prefer it to be a right click. That
is a perennial question/request. A patch to make Button 2 3 the
default was committed months ago. Most with two stylus buttons
including rockers prefer Button 2 3 and Button 3 2. But not all.
> I'll kinda ignore the rest of buttons because I'm not sure how people
> use "pad" buttons.
Hence the need for graphic professional input. I've included some of
the feed back I've gotten in the scripts and alternate examples. The
point is there is no standard. Different folks are going to want
different settings in Gimp, Inkscape, MyPaint, Blender, etc. depending
on their usage and preferences. And that's why the 'profile' concept
is important.
> Chris
Favux
------------------------------------------------------------------------------
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
