Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!think.com!mintaka!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.windows.x Subject: Re: Help on Motif builders Message-ID: <1991Jan4.041648.1950@alphalpha.com> Date: 4 Jan 91 04:16:48 GMT References: <9101030322.AA07340@gh.sei.cmu.edu> Organization: asi Lines: 90 In article <9101030322.AA07340@gh.sei.cmu.edu> Erik.Hardy@sei.cmu.EDU writes: >> The application writer must know/understand enough about the principles >> of the Xt user interface methods/style/operation mode to make the >> user interface writer's job even possible. > >In a word, no. The AW need know nothing about the underlying technology, be >it Xt, CORE, Xlib, PHIGS, or whatever. Idealism is nice, but it doesn't work. Domain/Dialog was written with this separation mandated. The next generation (Open/Dialogue) allowed the separation but no longer mandated it. There's a reason for that. In an ideal world my app never has to know about the underlying technology, but we don't live in a ideal world. There are things I can do on the Mac which aren't practical under X. There are quirks in Xt that I have to work around in my application. There are operations that I add to my application because the interface makes them necessary. I'm not saying that the separation isn't a good idea - just that I don't believe in absolutes. >Yes, the UI writer was the primary target, but it requires no knowledge of >Xt, although it does require knowledge of the underlying object system. If >you like, you can think of Serpent as providing a different toolkit than Xt; >however, note that Serpent is not limited to Xt-based object systems: you >could integrate CORE into Serpent if you wanted to, and it wouldn't change >the Serpent language one wit. At the risk of being rude: however, note that C is not limited to Xt-based object systems: you could integrate CORE into C if you wanted to, and it wouldn't change the C language one wit. The question then becomes, "How is writing in Serpent different than writing in C?" The answer is presumbably that Serpent is a language tuned to writing interfaces. That might even be a good answer. But it's important to remember the question. >> Using UIMS (like Serpent) DOES increase productivity >> in some areas, but those are often the 10% of the entire effort >> (depends great deal on application, I don't happen do design the >> interfaces to "ls" command). > >It has been suggested that, even if there's no other reason, Serpent can >easily be used as a prototyping system, so that one can get a quick look at >the layout and the behavior of a UI. If this is the place where one spends >10% of the entire effort, it can certainly be worth it down the road. Now we're talking - except that I don't want to learn a new language just to prototype, but on the other hand I need some sort of language, because many of the problems that make applications have to worry about the interface have to do with the dynamic changes that occur when the application is running. (At this point I expect Neil to say "WinterP is the answer!" :-). It's not clear that there is any answer here that would make me happy. Right now I think a good IDT would be nice, but I haven't seen one that does the kind of stuff I want yet. >I would never advocate using Serpent to design or implement the UI for >something as simple as the ls command. But, if one was to build a large >system (for instance, an operating system and all of its attendant >utilities), then I would advocate it. But Serpent would actually probably be a good tool for "ls". It's the large system where performance, quirks, dynamic changes and the like all start to matter. I guess the other reason I shy away from the separation of church and state (or whatever) right now is that today's toolkits just aren't powerful enough. As a result I need to exert a large amount of control over each widget and the layout of multiple widgets that is very specific to my application. It would certainly be a good idea to separate out that from the rest of my application, however the interface still ends up being a *lot* of C code. Furthermore, it's not trivial C code, and it certainly isn't going to be written in Serpent. The correct model then is presumbably to create a Serpent interface to that C code, and then access it using the standard Serpent mechanisms from my application. What is the advantage to doing that, as opposed to creating an object model (I'm using C++) for my interface and simply using the objects to access the interface? It seems to me I still get much the same level of abstraction, but actually have less work to do (not to mention one less thing to port to each platform). -kee -- Alfalfa Software, Inc. | motif-request@alfalfa.com nazgul@alfalfa.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.