Path: utzoo!news-server.csri.toronto.edu!rutgers!bagate!dsinc!ub!zaphod.mps.ohio-state.edu!ncar!ico!attc!marbru
From: marbru@attc.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x.motif
Subject: Re: Setting keyboard focus
Message-ID: <1240@attc.UUCP>
Date: 13 Mar 91 18:04:16 GMT
References: <1991Mar7.124545@MAX7.llnl.gov> <39956@cup.portal.com> <1991Mar11.132140.18706@bellcore.bellcore.com> <49493@seismo.CSS.GOV> <1991Mar11.213058.5300@bellcore.bellcore.com>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Distribution: usa
Organization: Auto-trol Technology, Denver
Lines: 50

In article <1991Mar11.213058.5300@bellcore.bellcore.com> ik@ctt.bellcore.com (Ik Su Yoo) writes:
>
>Any Motif expert out there want to enlighten us of making
>XmProcessTraversal work as expected? I already did RTFM and RTF-FAQ.

   No, I don't claim to be a Motif expert. But I have some experience
   with the Traversal.c code in 1.0 (where I had to borrow/override),
   and I already did some research in 1.1.

   The main problem, as someone from OSF correctly pointed out, is that
   the traversal code is "byzantine".
   It just delas with (to my taste) too many if-this-and-not-that cases.
   Anytime you introduce a new case beyond what has been considered so far,
   (such as manager widgets nesting), one or more of those if's fails,
   resulting in a rejection of whatever request you have made.

   Just as an example, I have a Composite subclass, which needs to be
   traversible as a primitive UI element. In Motif 1.0, I was able to
   get around: For each XmTrav* call I pretend to be an XmPrimitive
   instance (by changing the class pointer plus several instance fields).
   Most likely, this will die in Motif 1.1.

   The only resolution I can see is a complete traversal redesign. Design
   with minimum (better none) dependencies/assumptions about widgets/gadgets
   used - for example using widgets "accept_focus" method rather than
   testing:  
     if ((XmIsPrimitive(w) && (XmPrimitiveWidget)w->primitive.traversal_on
     ||  (XmIsManager(w)   && (XmGadget)w->gadget->traversal_on ))
   (which reduces the set of traverable widgets to subclasses of Primitive
    and Gadget - nothing else, no extensibility whatsever).

   Similarly, the traversal should probably never depend on
     if (XmIsPrimitive(w) && XmIsManager(Xtparent(w)) 
      && XtIsShell(XtParent(XtParent(w)) ).

   My list of grievances could probably continue .... To summ it up,
   with the current implementation it often may be very difficult to
   accomplish the desired behavior. The redesign, on the other hand,
   is not going to be an easy task - there are lots of reasons why
   the current code is so "byzantine", and cleaning it up will be 
   a real challenge. But I believe it *must* be done, because adding
   new and new and new cases to the existing code leads nowhere.



-- 
=*= 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