On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: >> 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.
No, no need. However since you object to ad hoc solutions such as a daemon to monitor events, runtime xsetwacom commands will remain broken until integrated into the Desktops. And presumably at that point become obsolete. >> 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... It's always good to improve the documentation. I'm not sure how that follows though. The information is from the man pages. The scripts serve as a concrete example of the man page information in use. Or are you suggesting running each runtime command separately in a terminal rather than as a script? How is that helpful to a user? >> 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. The relevant links are in the mediawiki's "External applications" in the 'Graphical Configuration Tools' section, along with: http://bugzilla-attachments.gnome.org/attachment.cgi?id=179668 http://live.gnome.org/Design/SystemSettings/Tablet http://live.gnome.org/Design/System%20Settings/Tablet/Screen > 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 realize that. Hopefully some of the content, including the scripts, help a little. As I mentioned earlier it would be nice to have some graphics professionals chime in along with some UI designers. We did have an IT supervisor from a professional graphics shop speak up a few weeks ago about the lack of a daemon or whatever to reapply .xinitrc settings lost due to a hot plug. This was proving problematic for his large deployment of Intuos4's on KVM switches to his RHEL6 based servers/workstations. Since he was from an internationally respected, household name graphics art shop we perhaps missed an opportunity for a fruitful dialog. He did provide feedback in the form of posting their solution, a modification of cyberfish's daemon to monitor hot plugging. The other solid feedback we had was from Alexia (a Gimp dev.) and her patch set using tool serial numbers to distinguish between input tools so they can have different settings. That would be valuable for any gui. Hopefully that hasn't fizzled out and Alexia will be back with an update after the last round of reviews. >> 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. >> >> 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. That was from an "experiment", because a lot of users wanted to use ID #'s. They felt the "device names" were too long and cumbersome. I was demonstrating both worked. However since ID #'s can change with hot plugging I generally encourage using the "device names". Although the comments explain this I could change the scripts to just "device name"? > 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 > ... No objection to this in principle. I thought it probably better to imitate wacompl's .xinitrc and stick to the xsetwacom command format the user would use to change an individual parameter, rather than add another seeming xsetwacom format into the mix. While some users, especially long time ones, have learned the xsetwacom commands, that doesn't mean they've learned BASH scripting. So the directions would have to be clear. > 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? Well of course they're nearly identical. Any default setup should be, whether gui or whatever. It's only when the user starts adding customizations that the variations occur. Especially tablets with pads. The question is how much to provide? Build from the man pages or give examples they can assemble into their own individualized script? > as with all scripts, forcing defaults to the default value is generally a > bad idea. The general idea is to have the tablet behave as the default setup. The user then choses what to customize. Say she's experiencing the the line lag with the stylus seen by some in Gimp because of the long standing GTK CPU usage bug. Then she'd want to up her RawSample for her stylus. The script shows that RawSample applies to the stylus, the default, and the allowed range she has to work with. Sure all in the man page. The idea is convenience. > 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. That is a valid concern. But please notice the dichotomy between your concern about getting user feed back on parameter default changes in the driver v.s. user concern about the UI abruptly changing on them and rendering their efforts in mastering the xsetwacom command parameters useless until they learn the new ones. Not that the reasons for changing the UI interface weren't good, just that it is a two way street. > 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? I have a user asking me right now why setting a Button to "f1" isn't working. Despite having a script as a template. > 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. The BambooPT script was originally written to duplicate the default Wacom tablet button assignment in Windows XP. Except xf86-input-wacom-0.10.5's xsetwacom could not assign a left click to Button4 so back a page in Firefox was chosen. The point is to provide examples. The user is free to change the settings. > Cheers, > Peter I've been tracking this discussion in its various forms for about a year and it continues to remind me of Voltaire's aphorism: "The perfect is the enemy of the good." :) Meanwhile, depending how you want to count it, the Linux Wacom Project for "modern" systems is at 9 months without a configuration gui and counting. Despite a lot of needed hard work. No doubt the scripts could benefit from some clean up. 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
