nazgul@alphalpha.com (Kee Hinckley) (05/01/90)
In article <9004261330.AA15617@gh.sei.cmu.edu> ejh@SEI.CMU.EDU (erik) writes: >From: Matt Landau <mlandau@diamond bbn com> ... >=The real point of standardization should be so that *you only have to >=write it once*. That means once for the Mac, MS-Windows, Presentation >=Manager, X with a Motif personality, X with an Open Look personality, >=or X looking like a Lisp Machine for that matter. >Still agree 100%. I agree that in terms of industry expansion a single API is more important than L&F. I also believe that you can write a singel API that will drive all of the above L&Fs. But it won't be useful for any real applications. >=Unfortunately, no one in the industry is moving in that direction. ... >If you really believe what you wrote above, check out Serpent. It allows you >to do just what you want. You need only write one (count 'em: ONE) program >and one interface description to integrate your favorite toolkit of the >moment. As a Serpent application has NO knowledge of the UI toolkit being >used, you'd never have to rip your application apart again. Serpent does just what Open Dialogue did. You move the interface description into a separate file with its own 'language'. Now I only have to write one program (maybe), but I have to learn a new interface description language and write multiple versions of that. Not to mention suffering through longer compile/link times and extra process overhead. I don't question the usefulness of separating the UI from the program (although I do question whether it can always be done), but I don't see it as a solution to the too-many-L&Fs problem. For instance. I have a program with a 'Close' button in the 'File' menu. Whenever I open a file I want to modify the item to say 'Close <filename>'. Nice user-friendly thing to do. Of course now we need to build up this big abstraction, since my program isn't supposed to know that there is a 'File' menu, or a 'Close' button, it just knows that someone can tell it to close. Okay, so we'll put all of this in the IDL. Now, is your IDL powerful enough to handle that? If so I claim that you've invented a new programming language and you haven't solved the one-toolkit-for-all-L&Fs problem at all. If not, then I have to deal with the user interface in my program, and special case it for different toolkits. >So, if you really want to help solve the problem, pick up Serpent and >integrate one toolkit. If only a dozen people did the same, the user >interface wars would be over. This misses a basic problem. The interface wars might be over from an *application programmer's* point of view, but that doesn't do a thing for the user. The user has a number of different brands of workstations, running software (I hope) from a number of different ISVs. Offhand I think they'd like the UI question to be resolved in a way that makes their applications all the same - I know I would. So, what to do? None of the toolkits out there are wonderful. None of the UIs are perfect. Should we wait until the standards bodies come up with an answer? Nonsense. They can only come up with something worse, since the politics are so fierce they have to deal with hybrids. I think all we can do is pick one, go with it, throw our support behind it, and work hard to make it better. Otherwise OS/2 is going to win the war. -kee -- +-----------------------------------------------------------------------------+ | Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | | 148 Scituate St. | Smart fax, dial number. | | | Arlington, MA 02174 | Dumb fax, dial number, | BBS: 617/641-3722 | | nazgul@alphalpha.com | wait for ring, press 3. | 300/1200/2400 baud | +-----------------------------------------------------------------------------+