Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!ico!attc!marbru From: marbru@attc.UUCP (Martin Brunecky) Newsgroups: comp.windows.x Subject: Re: Multiple Inheritance (kindasorta) in Xt Message-ID: <948@attc.UUCP> Date: 2 Jan 91 19:10:29 GMT References: Reply-To: marbru@auto-trol.UUCP (Martin Brunecky) Distribution: comp Organization: Auto-trol Technology, Denver Lines: 63 In article mitch@edsvcs.osf.org (Mitch Trachtenberg) writes: > > Here are some thoughts on how it might be possible to >mix in some kinda-sorta multiple inheritance capabilities to Xt >using the object class, making a minimum of changes to Xt. >It may be blue-sky, and it's probably late for R5, but I welcome >reactions in any case. > Just some ideas/issues to contribute to the brainstorm. On the Set|GetTreeValues. ========================= In my Text widgets, my SetValues(Hook inR3) propagates the arguments down to the "supporting objects" - in this case source and sink. So the SetValues on the "big guy" can (and does) SetValues on those "little guys". It can be even improved by filtering out arguments applicable to the "big guy" only.... No additional Xt support needed. The only thing that's BAD about it is: - interaction with X resource database. The user must KNOW that the support object "xyz" will be created under the "bug guy" and that he must specify resources for "xyz" properly qualified. - XtGetResourceLists does not know anything about "supporting object", and thus can NOT retrieve any such resources. However. Is it relly so important to *hide* supporting objects ? One of the Motif's controversies is exacly around those "confusion functions" intended to *hide* objects (such as shells) from the user. Why not make the user AWARE of the fact that the PushButton is in fact a composite of A,B and C where B and C are automatically created by A (unless provided by the user as non-default resources). An example. Every Motif widget that (currently) has all those 3D outline resources could be substantially reduced (instance size) using *reference* to a (shared) "3DOutlineObject". Many applications will need a single one, some may need more. The application writer would have to know about such an object, even if it was automatically created by the Motif toolkit as a default one. Inheriting multiple geometry management. ======================================== Composite widgets have lots of functionality, ONE of them being geometry management. I have found that it beneficial to SEPARATE the geometry management into a "support object". I.e. my composite widgets know about "GMbaseClass" and re-vector all the geometry related class methods to the instance-specific GM object's methods. (Note that the SetValues on the supporting object may have to inform the parent about some changes, so I use callbacks installed by the parent - but that's the case in any "support object"). Similarly to the case above, the resources are the problem. And again, by knowing about my "GM support object", the application writer can adress this one directly. -- =*= 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