On Wed, Feb 23, 2011 at 02:55:07PM -0600, Favux ... wrote: > 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.
actually, yes. I want users to _understand_ the parameters they're applying to the driver. the amount of bug reports I see where users just copy/pasted some config file and then filed a bug is quite high. "$feature isn't working! clear regression from version foo.bar!" "please attach your config file" "sure, here it is. I've just updated to newest $package and it's still broken" "uhm. you have disable-feature in your config" "oh. well I got this config from $website and they told me to use it" this isn't a wacom problem, it applies to lots of packages. to give you a real-world example: http://cgit.freedesktop.org/xorg/xserver/commit/?id=ec1bfbc66926130e1153facc3b92ee175f1cb6b6 we had to take this option out of the server because I got too many bugreports. all of these were by users who just read somewhere that they needed to turn this option off (or copied xorg.conf files from various sites), never read the man page and then filed bugs that the server was broken. this option did one specific thing. it wasn't overly useful but there was nothing wrong with it per-se. I fear that with these scripts as they are now we're prone to run into the same issues. the goal is to make it _easy_ for the user to figure out how to change settings, but not to take the thinking process away from them. for example, the header of the shell script (with the DEVICE bit) could be part of a xsetwacom man page EXAMPLES section? re-quoted because I have two answers :) > So we want the user to read man wacom, xsetwacom, xinput and then > assemble their own script combining xsetwacom and xinput? I agree mind you, the whole point of xsetwacom is that users don't need xinput. I still expect them to read the wacom man page so they understand what they're changing though. > > 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. Just add a #!/bin/bash to the top of the script to avoid any confusion. otherwise it'll be executed in the user's shell which may or may not cause issues. > > 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. yeah, I agree. the scripts should not try to do more than the very basic stuff. otherwise you suddenly start adding features over features and you end up with e re-implementation of the driver in shellscript. which isn't my definition of a great weekend :) > 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. that's the one piece of info I heard last year too: any UI configuration tool must support profiles. the GNOME tool isn't there yet obviously but that's one of the things on the list. if I could just get the current stuf in... Cheers, Peter ------------------------------------------------------------------------------ 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
