swick@ATHENA.MIT.EDU (Ralph R. Swick) (05/18/88)
Date: Mon, 25 Apr 88 15:45:53 -0100
From: mcvax!latlog!PAYNE@uunet.UU.NET
I have some suggestions for very minor changes to the intrinsics, is this
the place to send my comments?
Sure, this is the appropriate place for public discussion.
1) Shell widgets should only get mapped in XtRealize if mapped_when_managed
is set (I believe this is already being dealt with).
Yes. The X Consortium is currently discussing an update to the Intrinsics
specification and this is a part of that update.
2) XtDispatchEvent should return TRUE if the event was used by the intrinsics
Yes. This is also in the new draft spec.
3) Composite widgets should have an XtorderProc to allow the order proc to
be set in the argument list.
Agreed. This is a bug.
4) Shell widgets should have an XtsaveUnder property for servers that support
this feature.
It is already there.
This may also imply that the shell widget should grab the server when
mapped and ungrabserver when unmapped as I am not sure of the advantage
of save unders when the server is not grabbed?
You may be correct about save unders, but I prefer to let the
application decide if and when to grab. Note that map requests are
assumed to succeed (eventually) whereas grabs may fail.
5) A utility function get widget geometry would be nice to save applications
having to access widget fields directly (I have a function
XtGetWidgetGeometry which takes a widget and passes back x, y, width, height
and border_width if the parameters are non-NULL).
Perhaps there should be access methods for every resource field of all
widgets. Life could get pretty cluttered, however. In the case of geometry,
the view has been that only the parent and the individual child have any
need to be concerned with these fields except in extraordinary cases.
If you have an extraordinary case, XtGetValues is the general-purpose
mechanism for querying widget state.
I also have some comments on the athena widgets:
1) If would be nice if all the composite widgets are subclass of simple, or
add the cursor and insensitive border into core (a better idea I think).
My own view as to what should be in core is based on whether there is any
real advantage over putting such things in a common subclass(es), and
whether the extra space in every widget instance justified the advantage.
My preferred approach would be to subclass Composite in the same way as
was done for Simple.
2) Simple should have a flag to turn the insensitive border feature on
and off.
Sure, I'll add this to the wish list. I suspect a better approach is
to add a 'make_yourself_insensitive' method.
3) The text widget should have a callback list for when the buffer is exceeded.
On the wish list.
4) The text widget should allow better access to subresources, I have had
real problems accessing the subresources (I couldn't getXtSetSubresources
to work) and I don't seem to be able to set text subresources in my
defaults file (this may be due to the way I am doing this?).
There was a bug in the way Text created it's subparts. Xstuff will have
the update soon.
5) Nicer form semantics
On the to-do list.
A general point about the intrinsics, is it possible to use widget actions
by a non-event trigger, i.e. say in my actions table I have my own action
on a particular event type which will then conditionally call a superclass
action, how do I do this when I can't put it in my action table because it
doesn't always get called (clear?).
What I am saying is, is it possible to have a function of the type
XtMakeAction("unhighlight()", &event) which acts as if the event passed through
had triggered the event? This would allow full access to widget actions, or
can this be done already?
I think I understand you. The superclass actions are available to you
automatically by naming them in your own translation table. The superclass
could also export it's actions as methods through the class structure.
What you would like is a public interface to the action table so you can
use the superclass' symbolic action name in your subclass implementation.
Sounds like a reasonable idea to me; I'll give it some thought. Since
the actions table is a public structure, you do have sufficient information
to implement it yourself.
-RalphPAYNE@latlog.UUCP (06/21/88)
I have a question about translation tables wrt key events. This is what I want to do: using the text widget I want to add another action called interrupt (say) and bind it to ctrl-C (say). However it appears that I can not do this if the initial translation table doesn't contain an explicit translation for ctrl-C (is my interpretation correct?). Would it not be nicer if, for key events, the application was able to add extra key translations without the widget having to put in every possible combination of key strokes and modifiers? I suppose the same should go for button events as well. This is a little confusing, I hope you understand what I am trying to say!! Julian Payne, European Silicon Structures (ES2) (payne@latlog.uucp)
swick@ATHENA.MIT.EDU (Ralph R. Swick) (06/28/88)
Date: Tue, 21 Jun 88 13:46:33 -0100
From: mcvax!latlog!PAYNE@uunet.uu.net
using the text widget I want to add another action called interrupt (say)
and bind it to ctrl-C (say). However it appears that I can not do this
if the initial translation table doesn't contain an explicit translation for
ctrl-C (is my interpretation correct?).
Your interpretation is incorrect. XtAugmentTranslations and
XtOverrideTranslations will add a binding for any event sequence
you care to specify. In the case of the Athena text widget, there
is a binding for every KeyPress event so you will need to use
XtOverrideTranslations to force any new key binding to replace
the default one.