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