On Sun, Oct 2, 2011 at 4:52 PM, Peter Hutterer <peter.hutterer@...> wrote:
> On Fri, Sep 30, 2011 at 10:28:34AM -0700, Jason Gerecke wrote:
>> On Thu, Sep 29, 2011 at 5:18 PM, Peter Hutterer
>> <peter.hutterer@...> 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.hutterer@...> 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.
>
> Firmness is a good example. How will you try to expose it? In the driver
> it's a bezier curve, controlled by 4 points. gnome-settings-daemon exposes
> that curve as a gsetting. the panel however exposes it as a 7 point slider
> (which I 'stole' from wacomcpl). In a client library, how would you expose
> it? 4 points? 7-point scale? 15-point scale? variable-point scale? All of
> them?
>
> The library can do any of the above but you have to have a really good
> understanding of which functionality to expose in what way and how they
> interact with each other.
>
> It also illustrates the need for different desktop tools. Not all of them
> are the same. GNOME may be happy with a slider but KDE is more likely to
> want the pressure curve exposed as bezier curve. I don't think there's the
> one-size-fits-all tool.
>
All of the "n-point scale" firmness options can be trivially
normalized to a float with range [0, 1]. But I understand what you're
getting at -- what goes in the library, what stays out, and why?
There's no reason the library has to be a one-size-fits-all tool. The
library should provide an abstraction of the underlying properties,
and if that abstraction doesn't fit with the needs of some client
program, it can always fall back to setting the X properties directly
(with all of the required understanding of interaction that goes
alongside that). The library should make the *common case* easy to
implement. If there are multiple common cases, it might be OK to add a
few different interfaces in, but that should be a conscious decision.
>> >> 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.
>
> If it wasn't for time limitation. I've been advocating the gnome tool for
> what must be over a year now. And so far I've spent _a lot_ more time fixing
> wacomcpl than writing the gnome tool (despite writing that one twice). And
> every hour spent on one thing can't be spent on another thing.
>
> Assume you add a new functionality to xsetwacom. If it turns out to be
> buggy, will you spend your time fixing it or spend time integrating the same
> functionality into the desktop? What if the functionaly was essentially
> buggy by design? For example MapToOutput. Maps the tablet to an output,
> until you unplug that monitor, or resize, or rotate, or unplug the tablet,
> etc. While it works on the surface, a lot of deployments won't be happy
> because one of these things may be common.
>
> You then spend time developing scripts that reapply whenever something
> happens, etc. So you just end up stacking hacks, never getting to actually
> work on the real solution.
>
> You know why I worked on wdaemon? Because a customer is using wacomcpl,
> which in turn uses xsetwacom but only on login (or right when you run it).
> And that doesn't work with a KVM switch. And wdaemon essentially disables
> hotplugging. Yes, a program that was designed to _enable_ hotplugging in the
> X server is now used to _disable_ hotpluging, so that tablets can be
> persistently configured with xsetwacom.
>
> In my experience, short-term hacks _always_ come back to bite you again.
> I agree that adding features to xsetwacom is easy and convenient. But I
> don't think it's a long-term solution and it will come back to bite us soon.
>
I wholeheartedly agree that short-term hacks should be avoided when
possible. If you re-read the paragraph you quoted, you'll see that I
"see little reason not to *consider* adding" features. If a customer
demands something that requires a hack, we may not be able to avoid
putting development time into the hack, but we *can* choose where that
hack lives.
For example, suppose we have a customer who requires automatic tablet
re-mapping when they rotate their displays. Arguably the "correct"
solution would be to add code to something like gnome-settings-daemon
to respond appropriately to RandR events. If the correct solution
isn't possible, we can't just ignore their request -- something's got
to give. There are any number of ways to solve their problem, some
more hackish than others. We don't necessarily have to add a code to
xsetwacom if there is a less-hackish way of accomplishing the same
thing (which there almost certainly is).
Jason
---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
|