On Mon, Jan 11, 2010 at 12:28:49PM +1000, Peter Hutterer wrote:
> On Sun, Jan 10, 2010 at 11:36:27AM -0800, Ping wrote:
> > On Sat, Jan 9, 2010 at 7:20 PM, Ron <[email protected]> wrote:
> > > Signed-off-by: Ron Lee <[email protected]>
> > > ---
> > >
> > > Another trivial one, that hopefully should save us some "how does it work"
> > > faqs from end users. The current xsetwacom --list output gives me:
> > >
> > > "Wacom Graphire3" eraser ERASER
> > > "Wacom Graphire3" cursor CURSOR
> > > "Wacom Graphire3" STYLUS
> > >
> > > It wasn't initially obvious to me which part of that was what --get/set
> > > wanted as its 'dev_name' identifier. After looking at the code it is,
> > > but we can probably lower the bar a little further pretty easily.
> > > The following, or some variation on the theme, should help there.
> > >
> > > So long as it's clear '"Wacom Graphire3" eraser' is the verbatim dev_name,
> > > I don't really mind how it is formatted.
> >
> > '"Wacom Graphire3" eraser' works for me.
> >
> > >
> > > Peter: would it be worth accepting and matching on the type name for
> > > --get/set too? Or are those too likely to be ambiguous? We already
> >
> > What happens if we have more than one tablet or more than one tool
> > with the same type? Do we list all of the tool with the same type?
>
> xinput prints the following to stderr if that happens
> fprintf(stderr,
> "Warning: There are multiple devices named \"%s\".\n"
> "To ensure the correct one is selected, please use "
> "the device ID instead.\n\n", name);
>
> I think this would be a good enough solution for xsetwacom too. The same
> approach would work for specifying a type that's also a device name.
And we already do the same if the '"long and" quoted' name is not unique,
as I assume it would be if I plug in 2 Graphire3's etc.
Passing -v there will show you the ID number. We could include that
in the 'non-verbose' output too though if useful.
> > > accept the id number, and --get ERASER is a bit less horrible to type
> > > than the quoted monster above anyhow. I can send another patch for
> > > that if you think it's worth having...
> >
> > We don't have to use that "monster" :). But we do need a way to
> > get/set the specific tool's info with an unique parameter. Do you have
> > a suggestion?
>
> The ID matching doesn't go away though so that's always the last option if
> the more convenient parameters don't work. The only case where that'd break
> is if users assigns numerical device names to their devices. A case of
> "don't do that" :)
>
> Given that the majority of users don't have more than one tablet, I think
> having tutorials suggest things like "xsetwacom --get ERASOR foobar
> something" is a good idea, it applies to most tablets regardless of the
> device itself.
Yes, my first guess was that this would be no worse than the ambiguity
we have under /dev/input with multiple tablets of the same or different
types. I just wasn't sure if that was also true for the possible atom
types, if it is, then I think we cover both "easy" and "you've got a
few to choose from".
> > As for the patch below, the initial reason for the output was to make
> > it backward compatible with the old xsetwacom so we may be able to use
> > some of the existing programs, such as wacomcpl, if there is no other
> > alternatives available for us. I am open to changes, especially when
> > it makes the driver and xsetwacom more user friendly. But, I think we
> > need to have an alternative before we break the existing one.
If we need to keep compatibility, then we can make this a new option
and keep the existing one behaving as it is? I wondered a bit about
whether we should switch to 'list' without the '--' anyhow so that we
have a common interface with xinput where such functions do overlap ...
I thought it may already be incompatible though, as the old xsetwacom
sourced the type name from this:
static TYPEXLAT xTypes[] =
{
{ WACOMDEVICETYPE_CURSOR, "cursor" },
{ WACOMDEVICETYPE_STYLUS, "stylus" },
{ WACOMDEVICETYPE_ERASER, "eraser" },
{ WACOMDEVICETYPE_TOUCH, "touch" },
{ WACOMDEVICETYPE_PAD, "pad" }
};
While the new one uses the upper case Atom names from xorg. Maybe
they only differ in case?
> > Any suggestion on a new GUI to replace wacomcpl?
heh, funny you should mention that at just this moment. I'll keep that
for the GI thread then. There seems to be some bubbling movements on
this front finally now too ;)
> right now, wacomcpl (first time I tried it since the fork) is badly broken
> for xf86-input-wacom in default setups. we encourage users to use
> hotplugging instead of static configuration wacomcpl so most devices have
> names such as "Wacom Intuos4 6x9". wacomcpl however can't parse spaces in
> device names but even with this fixed up there's still a lot of issues and
> only few options actually work. So wacomcpl needs some fixing anyway to be
> able to handle the default setup. I'd be happy to make the xsetwacom output
> more legible since I expect more users to use that tool than wacomcpl.
>
> in regards to the GUI configuration tool - this is a tricky problem, though
> not technically. We have two major desktop environments (kde and gnome) both
> of which will likely do their own thing. For gnome, that'd be similar to the
> gnome-mouse-properties applet.
>
> I don't think we should add this to the driver though. Having it as a
> separate repository is one option, the better option is to actually have it
> part of gnome/kde so we get to benefit from their maintainers a bit and
> reduce the need for header-syncing and stuff like that.
>
> I've sort-of promised Ping a gnome tool but so far I've failed to deliver :(
I think there might be a qt thing that plugs into KDE's configuration
already:
http://www.kde-apps.org/content/show.php/kcm+tablet?content=114856
I'm not a KDE user, so I haven't tried it, but I'm led to believe by people
who are that this plugs into the 'native' KDE config in the way that it is
supposed to.
That one credits this:
http://www.gtk-apps.org/content/show.php?content=104309
Which seems to be a GPL binary only deb of a python script that wraps
xsetwacom. At which point my interest waned fast, because at that time
it wasn't clear xsetwacom was coming back.
I've heard mumblings of something happening gnome side, but I've heard
that before, so I'll leave them "pending substatiation" :)
I haven't looked at GI's thing yet, but I saw that from the BTS, right
between all of these ;)
> > > diff --git a/tools/xsetwacom.c b/tools/xsetwacom.c
> > > index f7817b2..6673a28 100644
> > > --- a/tools/xsetwacom.c
> > > +++ b/tools/xsetwacom.c
> > > @@ -980,7 +980,7 @@ static void list_one_device(Display *dpy, XDeviceInfo
> > > *info)
> > > if (nitems)
> > > {
> > > type_name = XGetAtomName(dpy,
> > > *(Atom*)data);
> > > - printf("%-16s %-10s\n", info->name,
> > > type_name);
> > > + printf("type: %-10s name: '%s'\n",
> > > type_name, info->name);
> > > }
> > >
> > > XFree(data);
> > > --
> > > 1.6.5.3
>
> I'd prefer it if the name would be first and the type second, even though
> that probably make the output less nice.
That was my first instinct too except for how they tabulated visually.
Ron
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
