Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: MOTIF vs Athena. Practical to conditionalize?
Message-ID: <940@attc.UUCP>
Date: 18 Dec 90 17:25:34 GMT
References: <3132@gazette.bcm.tmc.edu> <7036@mitech.com> <3165@gazette.bcm.tmc.edu> <1990Dec14.164540@ap.co.umist.ac.uk> <2024@metasoft.UUCP>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 64

In article <2024@metasoft.UUCP> alan@metasoft.UUCP (Alan Epstein) writes:
>	...
>>|> MOTIF is awfully dependent upon itself.  It is very easy to use
>>|> Athena widgets in any other Xt-based toolkit, but not MOTIF.
>	...
>Does this mean that an application cannot use Motif and Athena
>widgets together, or that they cannot co-exist in the same widget
>hierarchy, or that sometimes there are problems with some
>organizations of these widgets?
>
    co-exist:
    Depends on defintion of "co-exist". For the most part, you can
    create any widget as a child of (almost) any Motif manager.
    For the most part, you can also realize (display and see) such
    a child. In Motif 1.0, I'v run into instances of code which,
    being unable to decide what type this child is left  
    the case statement without assigning any values - but using
    those later. (I assume that's fixed in 1.1).

    organization:
    Again, what is organization ? If you mean geometry management,
    it is most likely to work as  good or as bad as for other Motif widgets.
    Note that most Motif geometry managers have some other specific
    purposes, such as XmRowColumn which primary purpose is to held
    together Motif's menu subsystem. XmRowColumn is therefore really
    picky about it's children.

    Most of the problems are in the areas of STYLE and BEHAVIOR
    enforcement along with KEYBOARD TRAVERSAL. Motif managers assume
    (in some cases) that children have particular translations and
    or callbacks, sometimes even directly access child's instance
    structure (for known children) to accomplish the desired behavior.
    How can they do it for an unknown child ?

    Thus, you can put a non-Motif widget into Motif hierarchy. But
    you should also expect that some of the Motif  functionality may 
    be lost in that combination. Depending on situation, you may be
    able to compensate for it (configuring your widget), or not.
    The least damaging places for non-Motif widgets seems to be
    XmBulletin board and XmMainWindow.

    Motif-izing other widget is not an easy task. My experience is
    that to achieve the full Motif compatibility, most of my widgets
    had to subclass off of some existing Motif class, such as
    XmPushButtonGadget or XmRowColumn, carrying over tons of useless 
    resources and un-doing operations of superclasses Intialize and
    SetValues code.
    In other instances, such as my own WsText widget, where I could
    not subclass off of Motif, I had to duplicate /steal lots of
    Motif code - and to make the widget play with Motif I have to
    augment translations on per-instance basis.

    However, even with the problems above, Motif is still a great
    toolkit. The problems are due to the effort to make the use
    (creation) of the *typical* UI components as easy as possible.
    Considering a complex functionality, such as Motif keyboard
    equivalency, and the development deadlines, something had to be left
    for "later" - in particular provisions for extensibility and
    other widget accomodation. 
-- 
=*= 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