Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!cory.Berkeley.EDU!dheller From: dheller@cory.Berkeley.EDU (Dan Heller) Newsgroups: comp.windows.x Subject: Xaw vs. Xt Summary: move Xaw out of /usr/include/X11 Message-ID: <12461@pasteur.Berkeley.EDU> Date: 15 Apr 89 09:51:40 GMT Sender: news@pasteur.Berkeley.EDU Reply-To: dheller@cory.Berkeley.EDU (Dan Heller) Organization: University of California, Berkeley Lines: 44 One problem with the athena toolkit which is beginning to annoy me more and more is that it is too tightly bound to the "generic" X11 distribution. I'm talking mostly about the include files in X11 that have athena toolkit widget specific defines in it. As I pointed out in a previous posting, it seems to me that the proper way to provide the programmer access to a "widget" is to allow him to include a public include file in which he can use the data structures, types, classes, and XtN-strings that the widget uses. That is, the define XtNscrollProc shouldn't exist in X11/StringDefs.h yet it's an athena ScrollWidget attribute and it belongs in Scroll.h. The generic file X11/StringDefs.h has all sorts of athena toolkit specific defines -- this is inconsistent with the desired prototyping schemes that the athena toolkit is trying to propagate. With the introduction of new toolkits growing, it is more and more likely that the programmer doesn't want to use the athena toolkit and use something else instead. Yet, that "something else" may want to define XtN's that happen to match athena's or someone else's toolkit. I propose that the athena toolkit's include files should exist in its own directory -- "Xaw" for example -- and encourage others to follow suit. It's ok if it exists under /usr/include/X11 -- new toolkits may want to install themselves under that directory as well. Now a program can have in its include headers: #include #include #include #include #include The "intrinsics" should remain in the top X11 include directory and provide all the XtN's and data structures and classes, etc.. That is, anything that's toolkit-independent and intrinsic-specific should remain on top and toolkit specifics should be under its own directory. This will prevent compiler warnings and errors resulting from using another toolkit that happens to have similarities with the athena toolkit. It will also provide a good framework for new toolkit implementors to follow. Dan Heller