jkh@violet.berkeley.edu.UUCP (05/27/87)
We've all been playing with Ram Rao's X Toolkit for awhile (the "snapshot" toolkit, released many eons ago on decwrl.dec.com) and are sort of wondering where it is in development. When is the next release scheduled for? Is it scheduled? What's MIT doing? Jordan Hubbard U.C. Berkeley jkh@violet.berkeley.edu
karlton@decwrl.DEC.COM (Philip Karlton) (05/28/87)
An X/V11 version of the X toolkit will enter alpha test on July 15th when the server and library enter beta test. PK
karlton@decwrl.UUCP (05/29/87)
Last night I said >An X/V11 version of the X toolkit will enter alpha test on July 15th when the >server and library enter beta test. This is what I get for posting late at night; July 15th is a definite type. Beta test starts on June 15, 1987. Alpha test for the toolkit is also on June 15. PK
yanagida@ole.UUCP (Bruce A. Yanagida) (05/29/87)
In article <3724@jade.BERKELEY.EDU> jkh@violet.berkeley.edu(Jordan K. Hubbard) writes: >We've all been playing with Ram Rao's X Toolkit for awhile (the >"snapshot" toolkit, released many eons ago on decwrl.dec.com) and >are sort of wondering where it is in development. When is the next >release scheduled for? Is it scheduled? What's MIT doing? > > Jordan Hubbard > U.C. Berkeley > jkh@violet.berkeley.edu In addition to the questions above, I would like to know how close will the real version of the Toolkit be to the "A Proposed Architecture" paper. If it's not identical, what are the differences? It's tough to plan your development on software that doesn't exist yet. -- Bruce A. Yanagida Seattle Silicon Corporation 3075 112th Ave NE Bellevue, WA 98004 (206)-828-4422 UUCP: ...!uw-beaver!tikal!ole!yanagida
PAYNE@latlog.UUCP (10/24/87)
I am trying my best to get some use out of the toolkits but I have a few
(simple) questions:
Widgets no longer appear to be X-windows , whilst I can live with
this it would appear to give me problems with mixing widgets and
windows?
For instance: how do I use XtAddEventHandler when I am trying to get
input from ordinary X windows as this procedure expects
a Widget id?
Also , is there no concept on the dispatcher of getting back unrecognized
events as there was in the alpha release (we consider this useful as we
do not always want to have to register handlers, i.e. we would like
the choice).
We would also appreciate an update on the toolkit position and how
competing toolkits might affect the issue???????????????
Thanks, Julian Payne (European Silicon Structures).bobmi@hpcvlo.HP.COM (Bob Miller) (10/26/87)
In the new X Toolkit widgets are the coin of the realm. And every widget contains a window. XtAddEventHandler (aside from doing an XSelectInput on the specified event and window) attaches the event handler to the core part of the widget instance structure. When the event of interest finally occurs it is from this widget event table that the handler procedure is taken. So, in order to use XtAddEventHandler you will need to surround your window with a widget structure. As you suspected, the dispatcher has no facilities for notifying your program that an event did not belong to any widget. Short of rewriting XtDispatchEvent (one of the 2 routines in XtMainLoop) you will have to live with this. --Bob Miller
kit@athena.mit.edu.UUCP (10/28/87)
I was talking to Ralph Swick the other day about the problems of not having a window widget, he and I decided that it would be a good thing, so I wrote one. It is a hack on the label widget, and takes an event handler and a callback, and aclosure as arguments, this it handles its events and you do not need to call XtAddEvent I think this is the right thing to do. It seems to work, but I haven't had time to bash on it yet. The design may change tho. If anyone wants it let me know. BTW there is a little know (at least to me) argument to toplevel widgets that allows then to resize, it is called 'XtNallowtopresize' setting this to true allows buttonboxes to do the right thing, I foud this out the hard way, just thought I might save some of you some headaches. Chris Peterson MIT Project Athena - Systems Developement Disclaimer: These are my optionions, not Athena policy.
PAYNE@latlog.UUCP (11/09/87)
I have some questions about the X toolkit (my last query did not seem
to get through):
1) How do you register ordinary windows (i.e. not widgets) with the
dispatcher. If this is not possible then the XtDispatch routine
should indicate whether or not it used the event?
2) Can more than one function be called automatically by the dispatcher
for the same widget (or window) and the same event mask?
3) I have got the text widget to work but I have had some problems
understanding how it should be used:
a) When you pass a string to XtTextStringCreate does it use the
string as a buffer or does it copy the string to its own buffer,
who is in charge of checking that the buffer does not overflow
and dealing with it when the end of the buffer is reached?
b) What I want to do is have a XttextAppend widget where I can send
it a prompt and then type commands in which I can send to the
application every time I get a newline. The text widget is
wonderful for appending text and moving through the text (I love
the emacs-type functionality) but it seems very hard to get
information back about what I typed. At the moment I have to
check key press events and maintain my own buffer, I can't read
the data itself because I need to distinguish between what the
user typed and what the application printed.
c) I assume that the only way for the application to put text into the
widget is by using XtTextReplace, if this is so and the function
is public then the typedef for XtTextBlock should be in Text.h
and not TextP.h? (XtTextBlock is the type of one of the arguments)
4) Do I need to write my own forms or will they appear with the next release?
Should this type of query go straight to the toolkit people? If the answer
is yes could someone tell me who the correct person to send queries to is??
Keep up the good work.
Julian Payne.
European Silicon Structures (ES2).price@DECWRL.DEC.COM (11/11/87)
Julian Payne asks several questions:
1) How do you register ordinary windows (i.e. not widgets) with the
dispatcher. If this is not possible then the XtDispatch routine
should indicate whether or not it used the event?
The current toolkit requires a widget to be registered with the
toolkit. This means that your window must be packaged ( "wrapped" ) in
a widget. The current toolkit does not include a "Window Widget". I expect
that this will appear shortly, since there has already been xpert traffic
discussing the need for such a beast. In the mean time, you must write a
widget to contain you window. The widget doesn't really have to do much
else; it can be a subclass of the Core widget, and you can use the widget
handle to externally register event handlers for expediency.
2) Can more than one function be called automatically by the dispatcher
for the same widget (or window) and the same event mask?
yes.
3) I have got the text widget to work but I have had some problems
understanding how it should be used:
a) When you pass a string to XtTextStringCreate does it use the
string as a buffer or does it copy the string to its own buffer,
who is in charge of checking that the buffer does not overflow
and dealing with it when the end of the buffer is reached?
It uses the string as a buffer. It does not copy it. This is probably
not a good idea, but that's the way it currently works. The Text widget
is *supposed* to handle overflow checking, but it currently doesn't. This is
not a feature.
b) What I want to do is have a XttextAppend widget where I can send
it a prompt and then type commands in which I can send to the
application every time I get a newline. The text widget is
wonderful for appending text and moving through the text (I love
the emacs-type functionality) but it seems very hard to get
information back about what I typed. At the moment I have to
check key press events and maintain my own buffer, I can't read
the data itself because I need to distinguish between what the
user typed and what the application printed.
You should be able to achieve this functionality by using the translation
manager. At least that is the intent. Unfortunately, the current text
widget does not list a DoCallback() function in its textActionsTable (Text.c).
The simple fix is for you to add this function yourself. You would then
specify that the RETURN key inserts and also calls back in your .XtActions
file, or in an ActionsTable you pass when you create the text widget.
This needs to be fixed in a future release. (I can't commit MIT to this,
but I expect it will probably happen).
c) I assume that the only way for the application to put text into the
widget is by using XtTextReplace, if this is so and the function
is public then the typedef for XtTextBlock should be in Text.h
and not TextP.h? (XtTextBlock is the type of one of the arguments)
Yes, it should be in Text.h.
4) Do I need to write my own forms or will they appear with the next release?
A forms widget should appear in the next release (Here I go committing
MIT again, though). It's port didn't make the deadline for this release.
Should this type of query go straight to the toolkit people? If the answer
is yes could someone tell me who the correct person to send queries to is??
This type of query is definitely appropriate here. We (toolkit group) will
make every effort to respond promptly.
-chuckPAYNE@latlog.UUCP (11/17/87)
I have been using the X toolkit for some time now and have got to the point where I want to be able to have multiple instances as children of the root window (not the toplevel widget). I missed most of the earlier discussion on the toplevel widget so I hope someone will be kind enough to explain the situation again. In the belief that I could not do this given the current toplevel implementation I have created a root window widget which does nothing but whose id I can pass through to other widgets as their parent (exactly as you would do for windows). Is this the correct approach or will I run into problems at some point? Incidentally I am currently getting warnings telling me that the widget is not managed in XtGeometryRequest, I haven't yet discovered if this refers to the parent (i.e. my root widget) or the child widget. Is it possible for the toolkit team to put out an `approved' fix for this problem to save us hacking up our own, or alternatively please tell me where I am going wrong if what I want to do is already possible? I have another releated question, I am using a SUN 3/110 so I have access to two screens. I would like to explore the possibility of writing to the two screens from within one application, can I do this using the toolkit as it currently stands? Related to this is a question for the window manager people, why do I have to run a uwm for EACH screen, surely one uwm could deal with all screens, after all thats what the X server does? Thanks, Julian Payne. European Silicon Structures (ES2). (payne@latlog.uucp)
PAYNE@latlog.UUCP (02/15/88)
I have a question about the translation tables: How do you alter a single translation at the program level i.e. when you call XtCreateWidget rather than through a user supplied value? Thanks, Julian Payne. European Silicon Structures (ES2). (payne@latlog.uucp)
swick@ATHENA.MIT.EDU (Ralph R. Swick) (02/16/88)
Two (new) functions allow programmatic modifications to a widget's translation table; XtOverrideTranslations and XtAugmentTranslations. The former replaces entries in the table, the latter appends only if the event sequence does not already exist in the table.
rusty@velveeta.berkeley.edu (03/16/88)
Overall, I'm _VERY_ impressed. Many, many thanks to the X Toolkit
people!
Here are some complaints, suggestions, and questions:
Widget placement; needs something like TeX "glue". For example, I am
making a dialog box that consists of a label widget with the string
"really quit?" and under it 2 buttons "yes" and "no". I want the yes
button flush left and the no button flush right. I couldn't get this
layout. I would like to be able to put a spring or some "glue" that
has infinite expandability between the 2 buttons.
Documentation needs more work.
Needs a XT(1) manual page like the X(1) manual page. It's
wrong for user-level manual pages for programs that were
written with Xt to rely on the user reading the X Toolkit
programmer's documentation for additional info on command line
options and whatnot. Likewise for manual pages that refer the
user to the Xlib documentation (cf, X(1)). There needs to be
a section 1 manual page devoted to resources, or put it in the
X(1) manual page.
Xt needs a set of (3X) manual pages.
Needs a better/clearer explanation of what things are
inherited from the very top. E.g., where is it documented
that the -icon option starts a toolkit program iconified?
Should be more forceful about telling programmers to use the
provided typedefs. For example, I've seen several occurences
of "sizeof(char *)" in applications when it should be
"sizeof(String)".
The section on the XtN{left,right,up,down} and XtNrubber stuff
is very unclear to me. I played around with them but they
didn't do very much.
How do you startup a toolkit window and get it placed somewhere? That
is, I want to use a popup dialog/query window and don't want the user
to have to use the mouse to place it, it should just pop up near the
mouse.
--------------------------------------
rusty c. wright
rusty@cartan.berkeley.edu ucbvax!cartan!rustyswick@ATHENA.MIT.EDU (Ralph R. Swick) (03/16/88)
> Widget placement; needs something like TeX "glue". Yes, the FormWidget is deficient in many respects. Expect improvements as soon as we get a chance to implement our paper design. We also have some other contributed code to merge. > Documentation needs more work. Acknowledged. > I want to use a popup dialog/query window and don't want the user > to have to use the mouse to place it. A PopupShellWidget class is in the works for Xaw which will do parent-relative positioning.
bettaieb@hslrswi.UUCP (bettaieb) (03/17/88)
Lately I have been working on user interfaces, and I found special interest in X windows. As is always the case, the best way to evaluate a software package is to try it. So I am trying to do that now. I must say that from the beginning I was biased by the idea that "it is easier to start with the Xtoolkit", but I noticed that most people on the net talk about Xlib rather than Xtoolkit. I would like to start a discussion and exchange of ideas regarding user interfaces based on Xtoolkit (or oldXtk). If you have any experience or interest in the same field, please forward it to me (or directly to the net) and I will try to summarize and post it. I will try to post every now and then some sample programs, or make them available for anonymous ftp. e-mail: bettaieb@hslrswi.UUCP
mikew@wyse.wyse.com (Mike Wexler) (03/23/88)
If I have an existing program and would like to add some buttons, popup menus, dialogue boxes, how do I do this? For example, lets say I wanted to take the paint program from the distribution and add some buttons to change modes, how would I do this? Another related question, how do I right an application(not a Widget) that does graphics under the X Toolkit?
toth@ichthyosaur.cis.ohio-state.edu (Susan Korda Toth) (04/05/89)
xman core dumps with Segmentation violation for us. We run Sun OS 3.5.1 on Sun 3's. We have X11R3 with 9 fixes, and compiled it with GNU CC 1.34. We have version 34 of the Toolkit library (it dumped also with version 33, but with a different calling sequence according to the core file). Ex.: section 1 comes up first by default and we change to section 3. We call up a manpage from section 3, then try to switch back to the directory with the MIDDLE button. It segm. violates for sure. It dies most often with the sequences (core file): RedrawThumbs() XtResizeWidget() ... XtManageChildren() XtManageChild() or DeleteBackwardWord() ... XtDestroyWidget() Phase2Destroy ManpageButtonPress() We have more than 800 manual pages in section 3. If we call up section 2 after section 1 and then section 3, it behaves well. Thanks for any help. -- Susan Toth Syst. Programmer, CIS, OSU
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (04/19/89)
> We have more than 800 manual pages in section 3. If we call up section > 2 after section 1 and then section 3, it behaves well. I have been reworking this code. R4 will have true dynamic allocation of manual pages so this and other problems that people are having with the current allocation scheme should go away. Chris D. Peterson MIT X Consortium