odesta@chinet.UUCP (Odesta Corp.) (05/17/88)
I'm just starting to play with X, and think the whole concept is great. I particulary like the concept of the toolkit, and hiding the program's main event loop. My problem is that I don't really have a feel for when to use the toolkit, when to use Xlib, how to use Xlib to create widgets for use with the toolkit, etc. Should my goals be to make EVERYTHING a widget? Or to get by with as few widgets as necessary? Is it "cool" to call XtMainLoop, and then still do traditional event processing in other parts of my code? Is anybody aware of any documentation that deals with this type of issues? More generally, how can I make sure I have the latest and greatest docs? (I don't have access to ftp, unfortunately). Also, is there any example code out there I might be able to get my hands on? Thanks a lot, Daniel Rabe
swick@ATHENA.MIT.EDU (Ralph R. Swick) (05/17/88)
Date: 16 May 88 22:59:48 GMT
From: att!chinet!odesta@bloom-beacon.MIT.EDU (Odesta Corp.)
My problem is that I don't really have a feel for when to use the toolkit,
when to use Xlib, how to use Xlib to create widgets for use with the
toolkit, etc.
You should use whichever layer you understand and will get your
particular job done the fastest. Xt is designed to allow you to
use most of Xlib directly if/when you need to do so.
Should my goals be to make EVERYTHING a widget?
Probably. In the long run, the application will be easier to maintain
this way and there's much greater opportunity for your code to be
shared by other applications.
Is it "cool" to call XtMainLoop,
and then still do traditional event processing in other parts of my code?
If you mean 'call XNextEvent myself', then you're very likely to get into
trouble. If you merely want to register an event handler, that is
definitely supported, though you currently need a widget wrapper under
which to do so. If you want block-for-input style interfaces, then
you'll have to write some widgets that simulate this behavior and that
export blocking style procedural interfaces.
More generally, how can I make sure I have the latest and greatest docs?
(I don't have access to ftp, unfortunately). Also, is there any
example code out there I might be able to get my hands on?
If you have Release 2, you have the latest and greatest public docs and
most of the available example code.diamant@hpfclp.SDE.HP.COM (John Diamant) (05/19/88)
> If you mean 'call XNextEvent myself', then you're very likely to get into > trouble. If you merely want to register an event handler, that is > definitely supported, though you currently need a widget wrapper under > which to do so. If you want block-for-input style interfaces, then > you'll have to write some widgets that simulate this behavior and that > export blocking style procedural interfaces. I have implemented a functional interface to some routines that I needed to have block until a particular button was pressed. I called XtNextEvent and XtDispatchEvent in my own loop (terminating on a condition set by a callback on the button). It seems to work fine for blocking. Once the button is pressed, it falls through and causes my function to return. Then, the real XtMainLoop() takes over again. Is there something wrong with doing this (it appears to work fine)? My function which invoked this was called by a callback associated with another button, so the XtDispatchEvent from the real XtMainLoop was on the stack at the time. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
haynes@WSL.DEC.COM (05/21/88)
Calling XtNextEvent and XtDispatch event yourself inside XtMainLoop will work. There are a few things to be careful of: If you don't consume the event, you better push it back and return or be prepared to deal with the consequences of ignoring events. In older versions of the intrinsics, deleting widgets actually happened at the next XtNext event. This is wrong in the case of recursive event dispatching, and has been fixed in the latest spec. If you aren't deleting widgets in any of this code, don't sweat this. Work procs are handled by XtNextEvent. If you register work procs at various levels of the recursion, they should be willing to be invoked at different levels than they were registered. The toolkit was explicitly designed to make it possible have either a "pull" (read/blocking) model of the world or a "push" (event driven/non-blocking) model of the world. We also believe that it is possible to mix the two views. The bottom line is that it will work, but you have to exercise some care. These are power tools you're dealing with... Have at it! -- Charles
diamant@hpfclp.SDE.HP.COM (John Diamant) (05/24/88)
> Calling XtNextEvent and XtDispatch event yourself inside XtMainLoop > will work. There are a few things to be careful of: Thanks. That sounds great. > Work procs are handled by XtNextEvent. If you register work procs > at various levels of the recursion, they should be willing to be invoked > at different levels than they were registered. Could you clarify what work procs are? I can't find any such reference in the documentation or code. The only handling I find in XtNextEvent is for destroylists and input and timer procedures. The only thing I can think that you might mean is a generic term for callbacks, event handlers, etc. > The toolkit was explicitly designed to make it possible have either a > "pull" (read/blocking) model of the world or a "push" (event > driven/non-blocking) model of the world. We also believe that it is > possible to mix the two views. That's very good to hear. Both interface approaches are useful and a mix is probably the best combination. Thanks, John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant