On Wed, Sep 28, 2011 at 10:52 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > This is a heads-up, a brain storming and ideas collection all at the > same time. > > xsetwacom is the previously small utility to tweak random driver functions. > This is what this tool should remain as. I'm happy to add any new driver > feature but I don't want semantic patches to filter into xsetwacom. It is > not designed for it and it would screw up the usability by a lot. > > Borderline cases that we already have are MapToOutput which technically > doesn't affect a driver setting. One step down the slippery slope is > MapToOutput next which starts cycling through outputs. > Much further down the line is the magic LED changes that we talked about in > the other thread - changing the LED at the same time as all button > assignments. > > This isn't to say that such a tool cannot exist but it won't be xsetwacom > and it won't be in the xf86-input-wacom repository. This is a driver. > > Jason and I talked about the need for a client-side library at XDC and the > possible need for another cli tool to change wacom driver settings. I > certainly agree with the client-side library, we need the ability for > clients to query e.g. model numbers and features. As for the commandline > tool - I think the correct integration will be in the desktops, not bolted > onto various commandline tools. But I'm certainly not going to stop anyone > from implementing it. > > If you have suggestions for said library, the future of a cli tool, please > voice them. > > I'm also CC'ing linuxwacom-discuss since this will affect users to some > degree, not just developers. > > Cheers, > Peter >
Peter already knows my stance on this, but I might as well make it public for the purpose of discussion. I see a client library as being useful for speeding up the new Gnome control panel's implementation. There's a fair bit of property-setting code in xsetwacom right now that would be useful for *any* control panel, and duplicating that code would be a waste of effort. It would make more sense to move these useful functions into a common library that could be called upon by xsetwacom, the Gnome GUI, a KDE control panel, and other tablet configuration clients. Where I don't quite see eye-to-eye with Peter is in the area of command-line clients. I agree that the CLI should be considered a fallback solution for when desktop integration is not possible. However, I don't see why that means we need to nerf the features available through xsetwacom. I can imagine a customer coming to us asking for support on an OS without a GUI CPL, but needing tools more advanced than the stripped-down xsetwacom offers. We could point them to an advanced version that we *also* maintain, but then what's the point of having the stripped-down version in the first place? If its to keep xf86-input-wacom as focused as possible, why not just split xsetwacom off into its own repository? You don't *need* anything more than the xinput utility to configure xf86-input-wacom, and if you *want* to configure more without a GUI, why not make the full-strength version available? Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
