cwitty@csli.Stanford.EDU (Carl Witty) (08/04/89)
Vital Statistics: X Toolkit, Athena Widget set, X version 11 release 3 I'm trying to write some new widgets, and I'm having some problems. For example, I wanted a Toggle widget. This would be exactly like a Command widget, except that the user clicks once to set it, and clicks again to unset it--hence the name Toggle. The only changes should be in the action procedures. Since the X Toolkit Intrinsics attempt to be object-oriented, clearly the "right" way to do this is to subclass the Command widget. Unfortunately, this approach soon leads to difficulties. The new routines in Toggle need to call functions which are private to the Command widget (for example, Redisplay). This is impossible, because they are declared static. Therefore, I end up copying far too much of Command's implementation into Toggle.c. Alternatively, I could create Toggle by making it a subclass of Label, sibling of Command. I would end up using most of Command's implementation. This is also really ugly. Are there any clean solutions to this problem? If not, which of the above ugly solutions should I pick (should Toggle be a subclass of Label or Command?) Thanks! -- Carl Witty cwitty@csli.Stanford.EDU
deboor@buddy.Berkeley.EDU (Adam R de Boor) (08/05/89)
You should subclass off of Command. If you don't need to do anything special for Expose, you can just fill the slot with XtInheritExpose. If you do need to do something a little different, but want to use what your superclass does, the object-oriented buzzword you want is "to call your superclass", as: (* toggleWidgetClass->superclass->expose) (w, event, region) either before or after you've done your bit, whatever it may be. Similar things can be done for all other "methods". a
ISSLCK@NUSVM.BITNET (Law Chee Keong) (08/06/89)
In reply to Carl Witty's question: I think this has to do with the one of the oldest problems in toolkit design, ie. how do you achieve separation between display and input? Smalltalk's MVC model is an interesting approach, as it separates the display and input processing code into two objects, the view and controller portions, respectively. The X toolkit's notion of widgets on the other hand, combines the view and controller code together inside a widget. The two approaches have their own pros and cons. Hence, someone who wishes to subclass new widgets in the X toolkit may not have a very clear choice of which class to subclass from. Carl's problem is a good illustration of such a problem. This is also a good illustration of the numerous design choices available with an object-oriented approach. For example, InterViews also adopts an object oriented approach, but instead of organizing classes around widgets, they have several other interactor objects available to render the graphics of the toolkit objects. Okay, what am I trying to say? Object Oriented design techniques have made user interface code much more reusable - but it will not solve all your problems, especially if we are dealing with single inheritance. Very often, designers are forced to make difficult choices like which class to subclass from, and just exactly which functions and attributes to bundle into a class and which to abstract. (genericity vs. inheritance) Now, to answer Carl's question. I guess it is inevitable that you have to repeat some of the display code from the command widget. There is simply no clean way to avoid it if you simply want to subclass from an existing widget. Of the two choices you mentioned, I prefer subclassing from the Command widget since you need to write less code with this method, because you very nearly copy most of the existing code from the Command widget. Hope this is of use. C.K. Law Institute of Systems Science Singapore
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (08/07/89)
> For example, I wanted a Toggle widget... One will be avaliable in Xaw in Release 4. This Toggle Widget will do all you want and more :-) > The new routines in Toggle need to call functions which are private to the > Command widget (for example, Redisplay). That is not actually necessary, Other than fixing a couple of bugs in the Command widget I was able to subclass the Toggle without using any of the Command widget`s private functions. I did, however, need to get at the command widget`s action routines. While these should be Publically avaliable there is a bug in the MIT R3 Intrinsics that makes this impossible, this will also be fixed in the next release. > Are there any clean solutions to this problem? If not, which of the > above ugly solutions should I pick (should Toggle be a subclass of > Label or Command?) As I said I had only a few minor problems subclassing Toggle off of Command, so if you can`t wait for R4 then I would suggest subclassing off of Command. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213