On Sun, Jan 10, 2010 at 6:28 PM, Peter Hutterer <[email protected]> wrote:
>> > 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. I must have missed something here. Are we talking about xinput or xsetwacom? I am talking about xsetwacom. Right now we check the device name to decide which device (in fact it should be called tool since it is only a tool that is associated with a physical device. With so many confusing terms, let's still call it device for now :) we need to set/get data to/from. If we make it to check type, we will not check the name. Or will we? >> > 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" :) I guess the ID is from xinput. How many different options do we need to go through before we come to this last option? > 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. This limits us to one tool of a type even we only use one tablet for the whole X server. I have no problem for you guys to add this option. But I am not convinced to replace xsetwacom --get "dev_name" foobar something with xsetwacom --get type foobar something Then the question is, how do we know which device option we are going to check first: type or dev_name? This "monster" may be bigger than the dev_name itself :). >> 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. Any >> suggestion on a new GUI to replace wacomcpl? > > 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. Your wacomcpl-exec patch fixed this issue. So, no more comments. > 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 agree and I would love to see the up layers take care of the GUI stuff. The current issue is, at least for me, how long can we wait? Sometime we may have to live with the ugly one (wacomcpl) before we get a good one. I can make wacomcpl and related stuff into a separate repo if we don't have a solution when it is prime time for xf86-input-wacom. I am wishing for the best (that we don't have to port the ugly one over :). Ping ------------------------------------------------------------------------------ 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
