On Oct 13, 2010, at 12:27 AM, Fmiser wrote: >>>> Kuba Ober wrote: >>>> >>>> A good assumption is that of a two-button mouse >>>> with only left button available while dragging. This >>>> assumption would make Xcircuit work with trackpads on all >>>> platforms (including MacBooks, a machine I'm on). > >>> Tim wrote: >>> >>> I have handled this largely as a matter of key and button >>> bindings. I have always used 3-button mice and am annoyed >>> with the fact that it is difficult to get them anymore. >>> Honestly, do people think it's that hard to figure out how >>> to move three fingers independently? Anyway, invoking >>> xcircuit with "xcircuit -2" is more compatible with a >>> standard 2-button mouse. Most functions associated with the >>> middle mouse button are moved to the right button, and >>> functions associated with the right button are moved to the >>> escape key. > >> Kuba Ober wrote: >> >> I agree, just that the chosen defaults are so far from >> everyday human interface guidelines that it makes it almost >> useless out of the box without referring to the manual first. >> That's a big no-no when it comes to basic usability. This is a >> minor rant as changing the defaults is trivial, but >> nevertheless it has to be done. > >> People are used to certain ways you interact with a 2D drawing >> space. I can get Adobe Illustrator, MS Paint, Inkscape, GIMP, >> even old Protel/Orcad, and be productive within minutes. With >> Xcircuit -- no way. Xcircuit has other usability shortfalls, >> namely very poor discoverability and no visualization for core >> concepts. > > Those are all targeted as general purpose graphic tools. Try a > CAD program. It's a focused purpose graphic tool. Even the > concept of interface with CAD is different, so the user > interface is odd compared to "mainstream" graphics tools.
I don't know but the two parametric 3D CADs that I've used (Solid Edge and Alibre Design) behave pretty much like any other graphical application out there, and I don't think it cuts down on their usability. Heck, they are slightly better in that they provide instant feedback on the element that any action will affect: there's instant highlighting of elements, so if you click you know exactly what the click will affect. >> I'm kind of a usability freak, so I'll be putting in some >> works towards that. > > I'm all for usability. But I think what you are actually > referring to is "similarity usability" - meaning the interface > needs to be "approachable for the lazy". :) > > I think this is what Tim was referring to when he wrote: > >> Personally, I don't even like the "common man-machine >> interaction" methods, most of which seems to involve kowtowing >> to whatever Microsoft implemented (or Cadence, in the EDA >> world, which is much, much worse). > > I believe I agree with him. I think he is saying "Just because > it's common does not make it usable." I agree, but there's no reason not to use the default ways of doing things where they don't interfere with the workflow. Think of what it takes in Xcircuit right now to change any property of an element (color, fill, linewidth, rotation, parameters). With right click bringing up a short-form context menu, you could change those with but a few clicks, all very close to the initial right-click. This cannot reduce usability, and does not interfere with anything in how Xcircuit currently works. It could be transparently added. Unless you've learned to invoke end-action excessively, that is. >>> Philip wrote: >>> >>> I have not had to run XCircuit on anything but an X Windows >>> session since I quit dual booting and went with virtual >>> machines. And my X server is setup to chord for middle >>> click. > >> Kuba replied: >> >> I don't know what "chord for middle click" means, > > "press both the right and the left button at the same time = > middle-click" > > I even have the track pad on my laptop setup to recognize a > two-finger tap as a middle-click. What about the right click, though? My trackpad has one button. Apple's default for right-click is IIRC Alt+click, some people (myself included) change it to two-finger tap. There's no way to click with two buttons at the same time, and emulating a third button necessarily involves the keyboard -- so while you can have right-click by using two fingers and thus just the trackpad, for the middle button you'd need to use Alt-, Control-, Command- or Shift-Click. Messy IMHO. >> ... but there are some default actions people expect of >> buttons. Like right click bringing up a context menu, for >> example -- where you could, say, change basic element >> properties like color, linewidth, etc. This promotes less >> mouse motion while not having to reach for the keyboard. > > Please - no. Not unless the button can also retain the > current "action-terminate" function _and_ the keystroke > actions are not removed. That shouldn't be a problem. The interface is stateful: when you're in the middle of an action, bringing up a context menu makes no sense. That's how it currently works with text entry: when you enter text, pressing 'z' is interpreted to mean you want to insert a letter 'z', not zoom out. > The interface is so streamlined and usable I for one would > strongly not want to disturb that for broader appeal or more > conformity. > > But - I'm not a software developer. :) I'm just a user with > many hundreds of hours on graphic tools. I may sound resistant > to progress. Honestly that's not the intent. If moving from C > to C++ and Qt makes the software easier to maintain and advance > - do it! But if along the way it makes XCircuit's interface > just as clumsy as the other 2-D graphic choices, I'd say it's > not worth it. It's a matter of preference, I guess. I will probably put in two sets of bindings: one for three-button mice, one for trackpads. Please understand that all this is just smalltalk at the moment. I'm not making any functionality changes at the moment, all I'm doing is trying to preserve what's there, perhaps adding goodies, and moving the code from C to C++, and from xlib/Xt to Qt. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
