pjatter@sandia.UUCP (09/07/87)
Newsgroups: comp.windows.x, comp.lang.ada
Subject: X with Ada?
Summary:
Expires:
Sender:
Reply-To: pjatter@sandia.UUCP (Paul Attermeier)
Followup-To:
Distribution: na
Organization: Sandia Natl Labs, Div. 9224
Keywords: Ada
Is X and Ada a practical combination? My organization's systems
are currently implemented using C and Sunwindows, but future projects
need to be done using Ada.
Sunwindows makes calls back to the application program which is no
problem when the application is in C, but if it is in Ada you need to
call Ada from C, something I don't know how to do. (vice versa is easy).
From what little I've seen of the X toolkits, it appears that
X makes 'callbacks' to the application program. If X is in C
(which would be acceptable in our 'Ada' system) and the application
is in Ada, it looks like we still have the same problem.
Do we need to wait for an Ada implementation of X? Will such a thing
be available in my lifetime? Am I missing a more obvious solution?
--
Paul Attermeier
uucp: ...{ucbvax | gatech}!unmvax!sandia!pjatter
arpanet: pjatter@sandia-2hyland@esosun.UUCP (Steve Hyland) (09/11/87)
In article <249@sandia.UUCP> pjatter@sandia.UUCP (Paul Attermeier) writes: >Is X and Ada a practical combination? Yes. We are currently using a subset Ada binding to X. More pertinent: >From what little I've seen of the X toolkits, it appears that >X makes 'callbacks' to the application program. If X is in C >(which would be acceptable in our 'Ada' system) and the application >is in Ada, it looks like we still have the same problem. Yes, the current X toolkit allows the user to include a call-back routine in the argument list. Since this would violate the spirit of Ada, we will not allow this. We have a similar problem in the intrinsics, with the use of event handlers in widgets. The answer ? Its not completely obvious to me at this point. More to the point, however; the toolkit is a SUGGESTED set of sample widgets. How they are implemented is very specific to C. How they are implemented in our version will be very specific to Ada. In other words, to the interface user, the widgets will appear the same. To the application programmer, C widgets and Ada widgets will be different from each other. And for the widget programmer, as with the C version, the toolkit will be a template for creating other widgets. Some of the ways in which we are considering implementing widgets: Tasking : seems to be more in the spirit of Widgets-As-Objects, Procedure Calls: that is, you create a widget with a procedure call, and must handle the events that occur in that widget. We are leaning toward widgets as task types, since this seems (at least, intuitively) the correct approach. My only concern is overhead associated with lots of tasks. Anyone else have any thoughts ? >Do we need to wait for an Ada implementation of X? Will such a thing >be available in my lifetime? Am I missing a more obvious solution? No, you do not need to wait if you are in a hurry. A basic binding can be hacked out fairly quickly. On the other hand, we have a STARS contract to build the Ada binding (which will become public domain, I believe) to X and the X Toolkit. The final versions of these, to be deliverable in about a year, will be completely written in Ada. An interim version, which binds to the C version of X11 will be available in about 6 months. >Paul Attermeier >uucp: ...{ucbvax | gatech}!unmvax!sandia!pjatter >arpanet: pjatter@sandia-2 Steve Hyland SAIC
newman@Leo.UUCP (09/13/87)
In article <64@kvasir.esosun.UUCP> hyland@kvasir.UUCP (Steve Hyland) writes: >In article <249@sandia.UUCP> pjatter@sandia.UUCP (Paul Attermeier) writes: > >>From what little I've seen of the X toolkits, it appears that >>X makes 'callbacks' to the application program. If X is in C >>(which would be acceptable in our 'Ada' system) and the application >>is in Ada, it looks like we still have the same problem. > >Yes, the current X toolkit allows the user to include a call-back >routine in the argument list. Since this would violate the spirit of >Ada, we will not allow this. We have a similar problem in the intrinsics, >with the use of event handlers in widgets. The answer ? Its not completely >obvious to me at this point. > Is there some obvious reason that you can't pass an Ada function as a parameter to the toolkit's C functions? How does this violate the "spirit of Ada"? *Any* toolkit is going to depend on the use of call-back functions. If the toolkit is going to dispatch each event to the appropriate widget, it needs to have a mapping of {Window ID, Function-To-Call}. This mapping be a linked list, an array, a hash table, or whatever, but whatever it is, it can only get filled by having someone pass a callback function as an argument. If Ada can't handle that, maybe Ada needs to be extended. /Ron Newman
karsh@nicmad.UUCP (Bruce Karsh) (09/16/87)
In article <1415@bloom-beacon.MIT.EDU> newman@Leo.UUCP (Ron Newman) writes: > >*Any* toolkit is going to depend on the use of call-back functions. I don't agree with this. It bothers me that X has two different mechanisms for sending messages when it would considerably simplify things if only one were used. The X event mechanism is sufficient to handle all the message passing requirements that the callback mechanism handles. I think that X events should be extended and generalized so that they would allow events generated by toolkit gadgets to be handled in the same way that normal X events are handled. For example, if you move a slidebar, the toolkit should generate a SlidebarMoved pseudo X event, which gets queued in the same way that regular X events are queued. Your event loop would handle this pseudo event in the same way that it handles regular X events. There would not have to be special treatment for X events versus X toolkit events. Does anybody know why X has two different kinds of message passing mechanisms? Couldn't we just get rid of call-backs? Does anybody have any ideas on what the "right" message passing mechanism for X should be? [I like the idea that each toolkit gadget should be it's own lightweight process that sends messages to other interested processes whenever its state changes]. -- Bruce Karsh {uwvax,ihnp4}!nicmad!karsh
lamy@utegc.UUCP (09/18/87)
In article <1415@bloom-beacon.MIT.EDU> newman@Leo.UUCP (Ron Newman) writes: > >*Any* toolkit is going to depend on the use of call-back functions. Ada may not allow passing functions as parameters, but you can either instantiate a generic procedure and call that, or do without the notion of call-back procedures at the Ada level and do it in a different style, either by posting back events or by actual rendez-vous... As far as "extending Ada" goes, whoever proposed that one must have forgotten the smiley face! Jean-Francois Lamy lamy@ai.toronto.edu, lamy@ai.toronto.cdn AI Group, Dept of Computer Science lamy%ai.toronto.edu@relay.cs.net University of Toronto, Canada M5S 1A4 {uunet,watmath}!ai.toronto.edu!lamy
diamant@hpfclp.HP.COM (John Diamant) (09/21/87)
> >*Any* toolkit is going to depend on the use of call-back functions. > > I don't agree with this. It bothers me that X has two different > mechanisms for sending messages when it would considerably simplify > things if only one were used. The X event mechanism is sufficient > to handle all the message passing requirements that the callback > mechanism handles. This is true, I think. They are both turing equivalent mechanisms. You're also probably right that having two different mechanisms complicates things, but the question still remains which one is better. > I think that X events should be extended and > generalized so that they would allow events generated by toolkit > gadgets to be handled in the same way that normal X events are > handled. Personally, I would prefer the opposite direction. I prefer callbacks, because it places the procedural burden on the toolkit instead of the user/programmer. I find it very appealing that I can declaratively state the times in which my callbacks are to be executed, and not have to worry about passage of control. > Does anybody know why X has two different kinds of message passing > mechanisms? Couldn't we just get rid of call-backs? Does anybody have > any ideas on what the "right" message passing mechanism for X should be? I suspect that the reason is simply that others had the same ideas that I do about the implicit control information achievable through callbacks, and chose to implement it that way. I too, would like to see only one mechanism for message passing, but I would rather it be callbacks. Multiple callbacks for the same event have to be supported, of course, for this to be meaningful. > -- > Bruce Karsh > {uwvax,ihnp4}!nicmad!karsh John Diamant TSBU UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO