On Thu, Sep 29, 2011 at 5:18 PM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Thu, Sep 29, 2011 at 04:38:54PM -0700, Jason Gerecke wrote: >> 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. > > tbh, the slow implementation of the GNOME panel is not in the property code. > those bits are the easiest ones to write and aside from a little > deduplication I'm not even sure how much a library would help here anyway. > The hard bit is figuring out which values to feed into the property. > Perhaps I'm misunderstanding you, but when I refer to the "property-setting code" I don't mean the low-level calls to X(Get|Change)DeviceProperty. I'm imagining a library exposing functions like "SetThreshold", "SetFirmness", etc. Some (like the former) trivially map to properties, others (like the latter) are a simplified representation of what happens under the covers.
>> 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? > > that makes sense too. if you go back the git history you'll note that > xsetwacom wasn't part of the split initially and only added lateron. If you > want to split this into a separate tool again I'd be ok with that though I > do like xsetwacom being less to type than xinput to tweak properties. > > the main question though is: do you really think xsetwacom in its current > form will be enough? the amoung of bugs I see from our customers because > xsetwacom is just a simple CLI is quite high. > I'm not sure I understand what you're asking. Are you saying that you're getting a high number of bug reports that are actually feature requests? If that's the case, I'm OK with continuing to bolt new functionality on to xsetwacom as time goes on. We should be promoting use of the desktop-integrated tools over xsetwacom, but if a customer has a request for something generally useful and difficult to script in an environment without such tools, I see little reason to not consider adding it to xsetwacom. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
