rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (07/29/90)
I don't care about the IMPLEMENTATION issues involved in doing this.
Then you are being unrealistic. Efficiency (or lack thereof) of Xt-based
toolkits is a major issue right now. Performance is not to be dismissed
lightly.
From a PROGRAMMERS PERSPECTIVE, it is completely unreasonable for a widget
to remain silent when you set the wrong resource (either at creation time,
or during XtSetValues())...
I don't know precisely what you mean by "at creation time". Nor do I know
what being not "silent" means to you. If you care to back up the complaint
with a thoughtful exposition of the problems (with cogent examples) and
desired changes, you are more likely to get somewhere. As you are an
employee of a Consortium member, you should also know that there is a
Consortium channel that could be used for this discussion, which might
(or might not) be more effective.
From an END-USERS PERSPECTIVE, it is unreasonable for no errors to be
reported when a user sets the wrong resource in an .Xdefaults, app-default
or xrdb file.
This is a nice general statement to which I have a very hard time attaching
any meaningful semantics. For example, I have in my defaults file:
*ShapeStyle: Oval
Should every widget in the universe that doesn't have such a resource go
blatting out somewhere that I tried to set a bogus entry at creation time?
You'll need to be much more precise about what your complaint is.
How many times have you had to deal with a clueless user who
claims your program is buggy because they mispelled a resource name and
therefore the program didn't work right?
There are solutions to this problem. But since I haven't really seen what
you propose the solution to be, it's hard to compare.
How many end-users want to have the internals of the Xtoolkit
and X resources mechanisms explained to them in response to the problems
outlined above?
None. But I suspect most end-users also don't want to specify resources
the way they are specified today (with a text editor). It is possible that
a better interface to resource specification will go a long way towards
helping with this problem. I don't claim it's a complete solution. But
until I understand better what your complaints really are, it's hard to
get very far.marbru@auto-trol.UUCP (Martin Brunecky) (07/30/90)
In article <9007282124.AA00523@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > > I don't care about the IMPLEMENTATION issues involved in doing this. > >Then you are being unrealistic. Efficiency (or lack thereof) of Xt-based >toolkits is a major issue right now. Performance is not to be dismissed >lightly. > I agree with both of you -). From an Xt user's point of view, (by the user I mean a programmer writing an Xt based application), the current behavior is highly undesirable. That is, using an invalid resource name in either XtCreateWidget or XtSetValue or XtGetValue does NOT produce any kind of feedback (except for that nothing happens). I agree with Bob that the area of widget creation is a highly sensitive one. One of the major Xt drawbacks today is that you cannot AFFORD to destroy and re-create widgets on fly - the overhead is intolerable, and thus we end up with huge, static widget trees, memory usage of which is again - intolerable. From my knowledge of Xt internals I don't believe that penalty added by flagging argument list items as valid and checking for invalid at the end would be measurable. But, we can have it both - using an ennvironmental variable to turn argument list checking ON during development, and leave it OFF for production runs. > > From an END-USERS PERSPECTIVE, it is unreasonable for no errors to be > reported when a user sets the wrong resource in an .Xdefaults, app-default > or xrdb file. > >This is a nice general statement to which I have a very hard time attaching >any meaningful semantics. For example, I have in my defaults file: > *ShapeStyle: Oval >Should every widget in the universe that doesn't have such a resource go >blatting out somewhere that I tried to set a bogus entry at creation time? >You'll need to be much more precise about what your complaint is. > Here you are touching my favorite one. What we need, is a LINT for X resource files. The primary problem with such a tool is that it needs to know the widget tree, not only the resources. That's why I am pushing the idea of having the widget tree definition contained WITHIN resource files, and NOT something separate such as UIL/UID crap. If you decide to use resource files to define BOTH your widget tree AND your resources ( such as done in WsXc or Mri contributions to comp.sources.x ), the idea of resource file LINT is quite feasible. Now, with resource file LINT you can specify what kind of checking you want. You may get a list of ALL the resources applicable to a given widget, or you can get a list of all widgets that understand a particular resource (or don't understand it) etc. You don't impose any performance penalty - you just use it when something is suspicious. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404