marbru@auto-trol.UUCP (Martin Brunecky) (09/25/90)
WHITE PAPER: Using Xrm with Xt for a little more....
This posting is for those who work with Xt, who have some vague idea of
what the following line means, and who are willing to comment on the
proposal included in this posting.
MyApp*file_menu.btn1.label: Exit
Xrm may seem cryptic (not a long ago we used to say that "C" programming
language stands for "Cryptic" -), it is not a tool for everyone. But it
allows to create and maintain the user interface (UI) quickly and
efficiently. Not a long time ago I have found that the Xrm database can
define the ENTIRE (static) UI layout. Using Wc library (formerly WsXc),
the Xrm databse can define not only UI object data (resources), but also
objects and their hierarchies:
MyApp.menu.wcChildren: btn2,btn2,btn3
The STATIC definition of UI can be defined, maintained and customized
separately from application code. The application can be written so that
even a widget set in use can be switched.
USING Xrm to define application STATES
--------------------------------------
The stumbling block above is the word STATIC. With Wc library, similarly
to XUI/Xm's UIL, we are limited to a STATIC, initial definition of the
user interface. Any runtime changes (UI dynamics) must be CODED (in C or
any language of your choice), even though we can query our resource file
for additional data. Such coding often introduces a dependency on
specific objects and their hierarchy, usually taking away all the UI
specification flexibility.
The UI dynamics can be viewed as UI STATES. The STATE of the UI changes
when application pops up a menu. It changes when application decides to
remove fields from a dialog box. It changes ...
UI state changes may be triggered by the UI directly, or may be a result
of some application activity. In both cases, a new UI STATE must be
defined.
Some of the state changes are so trivial that a common callback provides a
sufficien solution: Manage(widget_name). More often, a state change
involves lots of code.
Now, being happy with Wc library, I am proposing the next step. Lets use
Xrm as a storage mechanism for application UI STATES.
The application code does not need to know the details of the new state.
All it needs to know is that as a result of it's computation it needs to
set the UI to a "state_B". The details of "state_B" can be defined
externally, to match the UI defined according to a specific locale.
So, here comes the suggested Xrm database syntax:
state_B*file_menu.btn1.label: Save data and Exit
state_B*file_menu.btn1.foreground: Red
^^^^^^^
Naturally, the state definition can apply to a specific sub-tree only.
I should have specified:
MyApp*file_menu.btn1.state_B.label: Save data and Exit
MyApp*file_menu.btn1.state_B.foreground: Red
^^^^^^^
To use such Xrm database extension, we need an additional application
interface. For example:
o WcSetNewState ( new_state )
where new_state is an Xrm path: "MyApp*file_menu.btn1.stateB"
This routine querries Xrm to find what resources for which widgets are
defined by the specified "new_state". Fetches such resources, converts
to appropriate representation (looking up resource lists), and calls
XtSetValues as needed.
o WcSaveAndSetState ( new_state, old_state )
This routine is similar to the one above, except that it first saves
resource values for each resource that will be changed, creating an
old_state definition within the current Xrm database. As sometimes we
may want to save resources that we are not changing (but may want to
reset later), we may need a reserved resource "value" (keyword) to
indicate this: MyApp*dialog.text_field: .WcSaveValue.
As always, routines above can be provided as convenience callbacks.
Implementation is fairly straightforward (well, almost-).
Except one detail. The current Xrm interface does NOT provide a way to
querry what follows a particular name/class specification. The
information is available within the _XrmHashBucketRec structure,
unfortunately private to Xrm. There is no interface "given the name/class
specification, return a list of following names/classes (next level) in
the database, both tight and loose bindings".
Since I can not blindly assume that ALL X implementors decided to follow
the MIT sample Xrm.c implementation, I can't just add my routine using
_XrmHashBucketRec definition from MIT tape. I desperately need a new
interface.
Thus, consider the paragraph above a wish list item for R5.
Note, such an interface can be usefull for other things as well. Imagine
a "LINT" tool for resource database ...
--
=*= 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 rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/26/90)
The current Xrm interface does NOT provide a way to
querry what follows a particular name/class specification.
I didn't really read the rest of your message. If there was a function
to enumerate the entries in a resource database that were valid completions
of a given resource prefix, would that satisfy you? I'm thinking the
function would take a procedure, and call it with every matching entry,
passing both lhs and value. More than you asked for, perhaps, but more
along the lines of something that's needed anyway.marbru@auto-trol.UUCP (Martin Brunecky) (09/27/90)
In article <9009261352.AA09599@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > > The current Xrm interface does NOT provide a way to > querry what follows a particular name/class specification. > >I didn't really read the rest of your message. If there was a function >to enumerate the entries in a resource database that were valid completions >of a given resource prefix, would that satisfy you? I'm thinking the >function would take a procedure, and call it with every matching entry, >passing both lhs and value. More than you asked for, perhaps, but more >along the lines of something that's needed anyway. No, sorry. I need to be able to find that under aaa.bbb... there are aaa.bbb.ccc...: aaa.bbb.ddd...: Basically, I need to descend the tree, for the moment without even caring what the right side is - that may come later. I would be happy to have a function that if called with a specification of a node (aaa.bbb) would call my (provided) function for all descendants of (aaa.bbb...). Naturally, I'd probably use it recursively. The issue is not what are the values (rhs), but what (lhs) defines are in the database. -- =*= 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
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/27/90)
I would be happy to have a function that if called with a specification
of a node (aaa.bbb) would call my (provided) function for all descendants
of (aaa.bbb...).
Sorry, I guess I wasn't clear enough. That's what I tried to say it would do.