dheller@cory.Berkeley.EDU (Dan Heller) (04/15/89)
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 <X11/Instrinsics.h> #include <X11/Shell.h> #include <X11/Xaw/Box.h> #include <X11/Xaw/Scroll.h> #include <X11/WidgetSet/Widget.h> 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 <island!argv@sun.com>
asente@decwrl.dec.com (Paul Asente) (04/16/89)
In article <12461@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes: > [Why are Xaw resources in StringDefs.h, among other things] It's not that StringDefs.h contains definitions for the Xaw widgets, it's that it contains definitions we thought would be commonly found in many widget sets. This was probably a minor mistake, since it forces widget writers to look for each resource to see if they need to define it themselves or not, but it's too late to do anything about it now based upon the amount of code that depends upon this. -paul asente asente@decwrl.dec.com decwrl!asente