Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!sialis!dmshq!com50!pai!erc From: erc@pai.UUCP (Eric Johnson) Newsgroups: comp.windows.x Subject: Re: Not impressed with MacX (< 3 Mouse Buttons) Message-ID: <1563@pai.UUCP> Date: 4 Dec 90 22:03:22 GMT Organization: Boulware Technologies, Inc., Burnsville, MN Lines: 183 [A discussion regarding systems that have fewer than three mouse buttons and what to do about it, since so many X programs wrongly assume three mouse (pointer) buttons are available...] lightning.McRCIM.McGill.EDU!mouse (der Mouse) writes... >>> ...I wouldn't simulate them... >>> ...[if you do simulate the "missing" mouse buttons, it would] >>> ensure that said broken clients don't get fixed. I wrote... >> Unfortunately, from xterm on, just about every client that uses the >> mouse uses more than one button. lightning.McRCIM.McGill.EDU!mouse writes... > That doesn't mean they aren't broken. No offense, but I really don't care what's considered broken and what isn't. What I worry about includes time and hassles. How much time and how much hassle is it going to take to get a working system? A real example: I tried to set up Interactive's 386/ix with a system that had a two-button Microsoft mouse. The X version was a customized R3 that ISC delivered and it came with the uwm window manager. (This was a few versions ago.) Uwm was essentailly unusable out of the box, because you needed the third mouse button (which was NOT emulated). The end system was intended for my boss, a new X user at the time. I'm sorry, but it's rather hard to explain not only how to get X going but that nothing will work as documented and that everything must be reconfigured--using a very primitive and confusing configuration mechanism (for a graphical interface, X is pretty hard to configure). The ISC people seem to have changed their tune now, but originally they followed your advice. Maybe you're correct. I don't care (again, no offense intended). All I know is that the hassle level went way up. Maybe I should have ported R4 (386 Unix vendors are only now offering R4 and only some of them at that), because R4 twm is much better with these issues, but frankly, I didn't have the the time. Again, I care about time and hassles. Another real example: Early versions of the Sun OpenWindows X/NeWS server presented a StaticColor visual as the default, instead of the more common PseudoColor visual. Technically, the Sun version was correct, and I'm sure Rosenthal et al could quote all the religious dogma to that effect. I really don't care. What it meant was that a lot of software (especially the X contrib stuff) simply wouldn't work. At that point, it didn't matter who was correct, just that I had to spend a lot of time getting things to run. Now, I still see no good reason for the StaticColor default. Using a PseudoColor default would have also been technically correct and would have made my life a lot easier since I was using a lot of non-technically- correct software. The bottom line: I was a lot less productive, I wasted a lot of time and I dealt with a lot of grief (eventually I went back to the MIT R4 since I only have 8 MB of RAM on my SPARC 1). Yes, that X contrib stuff should have been "fixed" (and still should be for much of it). I'm not holding my breath, though. > For that matter, I have seen at least three X clients that break if you > don't use PointerRoot focus, in that if the mouse is not inside their > window they ignore keystrokes, even if the window manager has given the > keyboard focus to the window in question. Shall we therefore require > all window managers to use PointerRoot focus? > Just because a given brokenness is widespread doesn't make it any less > broken. You're absolutely right. The problem is, what do you do today? Now, I'd first like to say that I appreciate all the effort you spend trying to help people on the net, and help them write "non-broken" X code. But, when I see statements like "this is broken and should be fixed" or "get a real computer" (not attributed to you) and the like, warning flags go up. I, and a lot of others (at least I suspect a lot) must live in a world where we need to do work today. All the religious dogma just doesn't sit well with me. Sure, all this "broken" stuff should be fixed. But, there's nothing wrong with trying to make things continue to work out in the mean time. HP, for example, now ships three-button mice. If you happen to have an old two-button mouse, though, the nice HP folks have a means of emulating the "missing" button. Is it elegant? I don't know. Is it broken? I don't care. Is it convenient? Yes. That's the bottom line. > And since I, unlike...[]... > don't have a customer base that must be catered to no matter how > unreasonable they get, I can refuse to support such brokenness. I don't have this luxury. Furthermore, I don't find it unreasonable to ask for a graphical environment that works. Our users, who are generally reasonable, expect the whole system to work right. If it doesn't, it's our problem. So, I generally don't have the luxury of laying blame either. It doesn't matter if the problem is in the hardware, the operating system, the networking interface drivers, the X server or our X clients, the problem falls into our laps and we have to deal with it. In such a situation, I don't care who (or what) is to blame, I just want to get the problem solved. > My X11R4 on the NeXT presents a pointer device with only two buttons. I > have received two different patches to implement the "missing" button > by chording the two existing buttons. Neither one will go in (though I > will distribute them with the thing, once I get around to rebuilding > the distribution.) If I may make a suggestion, maybe then you'll want to "fix" various pieces of common X software that seem to require a third button. (I actually think this would be a good idea. Just watch new X users for awhile and you'll see a lot of confusion when they try to figure out which mouse button to use.) > In another note, someone from SGI said that it had the luxury of always > being on an 8-bit PseudoColor server with a 3-button mouse. Having a homogenous hardware platform is a nice luxury, but another luxury I don't have. Perhaps that person at SGI would like to send me a loaner system? > I can just > see programs from such a person[%] blindly assuming an 8-bit > PseudoColor visual as the default. Does this then mean that all > servers must provide an 8-bit PseudoColor visual? No, it means that > such programs are broken! Encouraging people to write better code is a good thing, and you seem to do this. Putting up with "broken" things is part of what I have to do since I live in an imperfect world. Perhaps you don't. > X has always promised the existence of a pointer device. I'm not sure > whether it promises the existence of at least one pointer button. It > has never promised more than one button. > [%] I don't remember who this person was, and don't mean this > personally - I have no basis for judging the portability of your > code, never having seen any of it. I take no offense at all and hope you don't either. I think, though, that we come from rather different backgrounds, since our main differences seem to be one of attitude. When we (BTI) needed to port our software to UNIX, we knew two things: 1) that we had to support a number of different architectures and flavors of UNIX and 2) that we absolutely required graphics--lots of graphics (our package is designed for factory automation). Luckily, C programs are fairly portable on UNIX-based systems. But, at the time, graphics was the tough one. After looking around, we saw that our only hope was using the X Window System (X10 originally). X was available on a number of platforms and the source was also available, thus allowing us to port X if the need arose (which it hasn't yet). X was the only reasonable hope we had at writing graphics-intensive code that could run on a number of platforms, without rewriting all the code for each platform. We didn't choose X because we thought the X model was the "right" (or one true proper) way to do things. We didn't choose X because of its network orientation (although that has proven to be a great advantage). We choose X because it worked and it was the only thing that worked (i.e., met our criteria). If I were to look around today, I'd make the same conclusions. X is still hard to learn. X is still hard to program. X is still hard to use. But, X is still the only real choice. So, I'm willing to put up with a lot of things that don't work completely right, so long as they manage to get the job done. Maybe now you can see where I'm coming from, even if you don't agree. Don't take this personally, OK? > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu Have fun, -Eric P.S. Shouldn't it be der Maus (das Maus? -- I don't have my Deutsch/ English dictionary handy)? -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA