haynes@DECWRL.DEC.COM (07/03/87)
First, thanks very much for the comments on the toolkit. Basically, I have a fairly unhelpful reply to all of your comments, wait for the X11 toolkit. I'll go into this in more detail with each point, but basically the toolkit was DESIGNED for X11, and some of the functionality is not possible in a retro-fit to X10. Point by point then: Hi. I don't know if this is the right list, but since mail to decwrl seems to disappear down a black hole, I thought I'd try this forum. Send a redirect if appropriate. What address and path are you using? 1. Get/Set Attributes: it's probably a mistake to have routines like XtWidgetGetValue and XtWidgentSetValue instead of just using getvalue and setvalue messages. The reason for this is that if one wants to get/set a widget attribute, one has to know what class of widget it is. Using the old method, one just sent it a message and got back a reply. Unless the toolkit is going to supply a routine which returns the address of the get/set routines for a given widget, then this change was a *big* mistake. To carry this idea a little further, there should probably be only one public routine for a widget: its creation point. All other calls to the widget should probably be through messages. You're absolutely right. We're exploring various solutions to this right now, I personally favor having a widget data record for every widget, and having widget create procs return a pointer to this record. This also solves the multiple screen problem. All widget records would have a common section at the beginning, including get and set procs. This would again allow "generic" operations on widgets. Other possible solutions are a new event type, or re-introducing messages (which is actually equivalent). 2. Batch Windows: window creation under the toolkit is SLOW. Yeah, I know. It's MUCH better in X11. The max program uses many button boxes containing many command, label, and boolean boxes. Ideally, I'd like to be able to create all of the subwindows of a button box in one fell swoop using the XCreateWindowBatch command. But, since widgets like to create their own windows in order to size themselves ideally, I really need two calls: XtWidgetFrame(parent,args,narg,opaqueframe) which gets called first. This does whatever calculations it needs to initialize the opaque frame. I then do the Batch and then call XtWidgetCreate() with an extra attribute in the arglist: the respective window that I created with the Batch. Now everyone says that window creation becomes cheap in v11. I hope so. In the mean time is there hope for v10 and the toolkit? We are not doing any development on the X10 toolkiit. One other thing, in X11 it is possible to "re-parent" widgets. Unless you have this capability, you MUST create the parent widget before it's children. This makes it hard for parent widgets to create themselves correctly on initial creation, and causes extra server calls. As for using XCreateWindowBatch, one possibility opened up by widget records is to have a widget create call that fills in the widget record, but doesn't actually create the window, allowing the parent widget to do exactly what you ask. I would like to have all of the necessary widget window attributes as standard fields in the common widget record. Otherwise, what you're proposing sounds fine. 3. Lint: someone should really run the toolkit through lint. Two reasons: first, we'll probably catch a few dumb logic errors; second, one can use lint to make an llib-lXt library which the toolkit programmers can use. This helps in catching a lot of dumb errors. (Right now, Xtlib fails lint miserably--I tried it.) Yeah, we've done that. I'm a strong type fiend myself, so lint is being used and the library is being created now. 4. Strange bug: when I have my toolkit program exit, the server doesn't seem to freeup some/all of the resources I allocated. The windows go away, but the memory doesn't doesn't contract. This is really strange, since none of the other X programs I run have this problem. Needless to say, when I go through a heavy edit-compile-run cycle, my X server gets larger and larger and larger. Has anyone seen this behavior under v10? It could be my server (Xis). No idea. I don't think this is toolkit related, since I *think* the server is supposed to free all resources for a connection when that connection closes (modulo use by other connections) so I think this is a server bug. 5. Callbacks on mouse-clicks: only left-click generates a callback. It'd be nice if any click generated a callback and the callback routine was told, via a parameter, which button transitioned. In the X11 world (and I thought the X10 world, but it's been awhile...) all widgets use the translation manager. In which case, the button responsible for the transition is specifiable. I have some enhancements to the transltion manager spec which I expect to be in the X11 beta toolkit that allow exactly what you're talking about. Thanks again for the feedback. -- Charles