mayer@hplabs.hpl.hp.com (Niels Mayer) (06/14/91)
In article <194@atesysv.UUCP> lanzo@atesysv.UUCP (Mark Lanzo) writes: >ASIDE: This isn't really related to the subject thread, but my >warning above reminds me of a quibble I have with Motif - It seems >to me that certain logical operations should transparently work on >either widgets or gadgets, without the programmer having to know >which class of object he is dealing with. > This is generally low on my list of gripes about Motif, but the lack of polymorphic operations (or even a C-attempt at such) in Motif is highly offensive to my sense of programming aesthetics. These features tend to confuse the beginning programmer to no end... the experienced Motif programmer treats his/her knowledge of all the special cases as increased job security :-). The one I really like is the hidden scrolled window parents on XmText and XmList widgets. All other widgets can be handled normally by a manager. If you happen to be using those specific scrolled widget variants you have to remember to tell the form to attatch to the XtParent() of the widget.... (Example -- try to set the XmNworkWindow resource on an xmMainWindowWidgetClass to a scrolled text widget without calling XtParent() on the scrolled text widget instance...) >For example, if you want to know the state of a toggle button widget, >you need to use the function XmToggleButttonGetState(). If on the >other hand you have a toggle button *gadget*, you must call >XmToggleButtonGadgetGetState(). It seems to me that XmToggleButtonGetState >should work for both the widget and the gadget. > Well, if you use a decent object oriented user interface language as a wrapper for Motif, you don't have to worry about this kind of ugliness. The language's object system takes care of such cruft for you automatically, ensuring that you use the correct "convenience functions" as methods, while only having to remember a single message name (such as :GET_STATE) for all classes (and subclasses) of toggle widgets. Which object-oriented user interface language?? WINTERP of course. >I got bitten by this one a while back when I modified a lot of code >to use gadgets instead of widgets. I spent a lot of time scratching >my head wondering why things didn't work until I discovered that I was >still using the widget "GetState" routine. It hadn't even occurred to >me that the gadget was not an essentially transparent replacement for >the widget. Some "convenience functions" in Motif do check to see if a gadget is being used, and some don't. In WINTERP, I made sure to treat all widget "convenience functions" as methods on widget classes, and gadget "convenience functions" as methods on gadget classes. Such things are important, because programming in WINTERP is interactive -- you don't want to have a core dump when you accidentally call XmTextSetString() on a label widget, rather, you want the system to give you an error like "no such method"... You then fix the problem, and try again without having to recompile or restart your application. PS: Hope y'all don't mind the plug, but hey, if Smythe, Brunecky et al get to claim that WCL is the ultimate solution for Motif programming, I should get equal time with WINTERP, no? :-) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *