ROBY%POGUN@dupont.COM ("Trey Roby Ponca City, OK", ETN 442-4848) (12/22/90)
I need input...
Where I work, there are certain people searching for the easiest way
to start their programmers writing with X and Motif. Some think
that it is possible to buy a Motif builder that will totally insulate
the programmers from having to learn any X or Motif.
The Motif builders I have seen so far (EasyX and DEC's VUIT) will
only write the initial Widget creation. However, the callbacks are
left to the programmer, which means to me (and please correct me if
I am wrong) that a programmer must know at least Motif and Xt to
handle callbacks.
My questions:
1. Has anyone seen a Motif builder that requires no knowledge
of X or Motif to use?
2. Is it true that Motif builders are not a short cut for
learning Motif, but only helps to speed up writing
an application?
3. What percent of your time does a Motif builder save you
when you write a front end?
I would greatly appreciate input from anyone who has experience or
knowledge of Motif builders.nazgul@alphalpha.com (Kee Hinckley) (12/24/90)
In article <9012221248.AA01095@expo.lcs.mit.edu> ROBY%POGUN@dupont.COM ("Trey Roby Ponca City, OK", ETN 442-4848) writes: > 1. Has anyone seen a Motif builder that requires no knowledge > of X or Motif to use? No. Although even using the Motif toolkit you often won't need much knowlege of X. However you should have a grounding in the basic concepts (particularly in the ways in which X is asynchronous). > 2. Is it true that Motif builders are not a short cut for > learning Motif, but only helps to speed up writing > an application? I can imagine using an IDT to help learn widget capabilities. There are some interactions that aren't clear from simply reading the docs, and a builder can make it easier to play. Unfortunately most of the interactions that aren't clear occur when things change dynamically, and most IDTs aren't any help there. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.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.
Erik.Hardy@SEI.CMU.EDU (12/27/90)
Trey Roby asks: > 1. Has anyone seen a Motif builder that requires no knowledge of X or Motif to use? Simply put, Serpent requires no knowledge of X or Motif to use it, i.e., it requires no coding of Motif or X; you still have to know what attributes you want to set for a particular Motif widget. If you want more information about Serpent, write me. > 2. Is it true that Motif builders are not a short cut for learning Motif, but only helps to speed up writing an application? Well, some Motif builders are a short cut, whereas some make it so you don't have to learn Motif (coding) at all. Erik Hardy (erik@sei.cmu.edu) SEI/User Interface Project
nazgul@alphalpha.com (Kee Hinckley) (12/27/90)
In article <9012262204.AA01041@gh.sei.cmu.edu> Erik.Hardy@SEI.CMU.EDU writes: >Simply put, Serpent requires no knowledge of X or Motif to use it, i.e., it >requires no coding of Motif or X; you still have to know what attributes you >want to set for a particular Motif widget. If you want more information >about Serpent, write me. All you've done is transfer the work to another area. If someone has already done the particular task you need to have done, then you don't have to worry about it (but that's true if I write my interface in C too, although Serpent's structure probably encourages reusable code). On the other hand, if the operation I need *hasn't* been done by someone, I not only have to learn how to do it in Motif, I need to learn how to write the Serpent code *too*. Tanstaafl. I have a Selection Dialog that lets you change the name of a folder. Anytime I create it, I want to set the typein focus to the input area (it starts off on the Okay button) and select the current foldername. Seems reasonable. Do I need to learn Motif to do it? Yes. Do I need to learn Xt to do it? Yes. Can I do it in Serpent? Almost certainly, but I'm still going to have to learn Motif/Xt in order to do it the first time. From then on I can presumbably just use the Serpent interface that I wrote. Is it worth it to use Serpent? Perhaps. UIMS' like Serpent and Open Dialogue have advantages, they can make some things easier. They can also make some things harder. If you think the advantages outweigh the disadvantages then go for it. But the ride's free only where the road has already been paved. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.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.
Erik.Hardy@SEI.CMU.EDU (12/30/90)
Kee eloquently explains how using a tool like Serpent allows one to not have to learn Xt/Motif/whatever only if someone has already done the Motif work; he also correctly points out that the Motif code has 'just' been shifted to another place. But therein lies the 'big win': by shifting the Motif work away from the application and away from the dialogue, the designers responsible for those tasks are free to work their respective magics without having to deal with Xt coding; they work within paradigms that are appropriate to their jobs. Motif (or any other technology) integration and maintenance is, and should be, left to technology experts. erik SEI/User Interface Project
marbru@attc.UUCP (Martin Brunecky) (01/03/91)
In article <9012300134.AA17670@gh.sei.cmu.edu> Erik.Hardy@SEI.CMU.EDU writes: > >But therein lies the 'big win': by shifting the Motif work away from the >application and away from the dialogue, the designers responsible for >those tasks are free to work their respective magics without having to deal >with Xt coding; they work within paradigms that are appropriate to their >jobs. Motif (or any other technology) integration and maintenance is, and >should be, left to technology experts. > WHAT technology experts are you talking about ? The application writer or the user-interface writer ? 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. The tool like Serpent is no help to him, because he *should not* even attempt to write UI. The user interface writer is the likely target of Serpent. However, beyond simple test programs, every single application I have seen requires damned well and deep knowledge of Xt, Motif (or another toolkit). 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). In my case, I am finding a simplistic tool - Wcl - by fare the most adequate. It sure does not have the bells and whistles. But it also does not require me to study an entirely new paradigm. It only promotes and emphasizes the Xt approach. And it is extensible, easily and naturally. And repeating the work that has been done before ? What about the cut-and-paste approach so familiar in coding ? -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
Erik.Hardy@sei.cmu.EDU (01/03/91)
Let's see...I wrote: >>But therein lies the 'big win': by shifting the Motif work away from the >>application and away from the dialogue, the designers responsible for >>those tasks are free to work their respective magics without having to deal >>with Xt coding; they work within paradigms that are appropriate to their >>jobs. Motif (or any other technology) integration and maintenance is, and >>should be, left to technology experts. then Martin Brunecky <attc!marbru@bloom-beacon mit edu> wrote: > WHAT technology experts are you talking about ? > The application writer or the user-interface writer ? Well, actually, neither. Perhaps you're under the impression that one or the other *must* perform Motif coding. Application writers have an abysmal record writing good user interfaces; this is even worse when there are 50 application writers all writing their own UIs and all thinking they own the screen. Ever look at the UIs in some of the current defense systems? > 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. > The tool like Serpent is > no help to him, because he *should not* even attempt to write UI. Well, here's something we both agree on, to an extent, i.e., I agree with the secondary clause in this sentence, but Serpent (or anything else that shields the AW from the specifics of the UI) can help him by the simple fact that he need not even consider the UI. > The user interface writer is the likely target of Serpent. However, > beyond simple test programs, every single application I have seen > requires damned well and deep knowledge of Xt, Motif (or another > toolkit). 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. > 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. 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. erik BTW, your Wcl cut-and-paste argument is not convincing, as one could use that approach no matter what the language.
marbru@attc.UUCP (Martin Brunecky) (01/04/91)
In article <9101030322.AA07340@gh.sei.cmu.edu> Erik.Hardy@sei.cmu.EDU writes: > >then Martin Brunecky <marbru@auto-trol.com> wrote: > >> 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. > I can't disagree more. The event driven model of Xt based application is so significantly different from the old-style, solicited-input approach, that an application writer MUST be aware of it. There are lots of applications with graphical user interface based on Apollo GPR, Sun's Pixrect, DEC UIS etc etc. Convreting, twisting and munging those applications to run under the X event driven model is a nightmare. Just because the *application* code was not *designed* for an event-driven user interface. You may suggest that a UI living as a separate process can solve the problem. May be - for the "ls" command. But my CAD/CAM applications are heavily graphics oriented. The graphics application design *must* be aware of the new interaction model, otherwise it is doomed to cause an enormous amount of pain. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
nazgul@alphalpha.com (Kee Hinckley) (01/04/91)
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.
Erik.Hardy@sei.cmu.EDU (01/04/91)
Martin Brunecky: >>> 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. me: >>In a word, no. The AW need know nothing about the underlying technology, be >>it Xt, CORE, Xlib, PHIGS, or whatever. Martin again: > I can't disagree more. The event driven model of Xt based application > is so significantly different from the old-style, solicited-input > approach, that an application writer MUST be aware of it. There is nothing in Serpent that presupposes the event model; solicited input is handled just fine. Martin (and others), I presume you'll be at the X Conference. Whaddya' say we table this for now and pick it up there? erik yaccity yacc (don't awk back)