dheller@cory.Berkeley.EDU (Dan Heller) (09/15/88)
I've gotten a lot of confusing answers to my latest question, so I'd like to rephrase it and elborate on the important points. The question at hand is: how do you call XtCreate[..]Widget() and pass XtN... parameters that are intended for "sub"-widgets within the widget, not intended for the widget itself that you're creating. I've been writing a toolkit package of my own which contains mostly single functionality widgets. e.g. there are no "form"-type or shell-widgets; I use some athena widgets for those purposes. One of my widgets is a "pushbutton" widget which displays in its window a pixmap -- as opposed to a command widget which displays text. Now, the programmer can create a widget which is a picture of a pencil to go into "draw" mode of a draw program... you get the idea... stay with me, now. I have also written a scrollbar widget which uses two pushbuttons at the top and bottom (or left/right) ends of the scrollbar which are arrow-icons similar to the mac or sunview. The scrollbar widget contains two widgets that I'd like to provide the programmer the ability to specify alternate pixmaps or callback funcitons. For example, if you provide a different set of icons to a particular scrollbar, you can make it look like a "slider", which is much different from a scrollbar, but similar enough that you can use the same widget to implement it. What's more, I have another widget which is a "listbox" of items (strings, pixmaps, etc). It's very similar to the viewport widget in that there is a window which is scrollable, but unlike the viewport widget, this widget knows about the type of items within it and scrolls accordingly. There's more to it than that, but the point is, I want to be able to allow the programmer to modify the scrollbar or the arrow icons within the scrollbar. This has nothing to do with user-defaults or anything as it is not intended for list-box scrollbars to necessarily look like other scrollbars ... Of course, you can always specify resource manager stuff and it'll work, but that's not the issue here. So, can I add to the resource list within the widget file or what? Need good suggestions... Dan Heller <island!argv@sun.com>
asente@decwrl.dec.com (Paul Asente) (09/17/88)
In article <5681@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes: >The question at hand is: how do you call XtCreate[..]Widget() and >pass XtN... parameters that are intended for "sub"-widgets within >the widget, not intended for the widget itself that you're creating. Well, this is going to be complicated, so have your toolkit manual ready... First, the parent widget must be prepared for this; i.e. it must be written to expect it. The subwidgets don't have to do anything. One sentence answer: use Xt{Get,Set}Subresources in the parent widget's initialize_hook, set_values_hook, and get_values_hook procedures. More verbose answer: the toolkit will happily allow resources in the arg list that do not apply to the widget you're creating/set valuesing/get valuesing. It just ignores them. So, you can specify resources for any of the subwidgets that are not the same as resources for the parent widget, and the parent widget never notices the difference. The intrinsics will call the initialize_hook procedure after it calls the initialize procedure, and will pass the initialize_hook procedure the args that were passed in. You then call XtSetSubresources with these args, passing the subwidget as the base parameter and the subwidget's resource list as the resources. You do set_values and get_values analagously. The key is that all the widgets must have separately named resources; otherwise you can't tell just what widget the resource is specified for. -paul asente asente@decwrl.dec.com decwrl!asente
begeddov@software.ORG (Gabriel Beged-Dov) (09/19/88)
Date: 17 Sep 88 00:56:48 GMT From: Paul Asente <asente@decwrl.dec.com> Organization: DEC Western Software Lab References: <5681@pasteur.Berkeley.EDU> Sender: xpert-request@athena.mit.edu In article <5681@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes: >The question at hand is: how do you call XtCreate[..]Widget() and >pass XtN... parameters that are intended for "sub"-widgets within >the widget, not intended for the widget itself that you're creating. One sentence answer: use Xt{Get,Set}Subresources in the parent widget's initialize_hook, set_values_hook, and get_values_hook procedures. How would you handle chained sub-widget resources (i.e. ones that are defined in a superclass of the sub-widget)? Also, how would the sub-widget set_value methods get invoked ? <In possible answer to Dan Heller's question:> Many of the HP widgets seem to deal with similar issues to the ones Dan Heller is raising (see XwScrollBarWidget, XwScrolledWindowWidget, XwTitleBarWidget). There, the parent usually defines a set of "shadow" resources that are the external interface (both for the application and the resource DB) for accessing the state of the sub-widgets (without having to know thier names). SetValues of these resources are often simply passed thru, by the parent, to the "real" resources in the sub-widget. In other cases the parent has some private state or constraints associated with the value of the "shadow" resource. GetValues can be a little trickier. There seem to be 3 approaches that a parent can take in order to keep the shadow resource in synch with the child resource. "Write-Thru" is the default one where the parent assumes that whatever value was last written to the child is correct. "Immediate Write-Back" (which is what the HP Scrollbar uses) gets the child resource values immediately after setting them thereby ensuring synch at that point. "Lazy Write-Back" is something a really paranoid parent might do by having a get_values_hook procedure that would check if any shadow resources were being requested and then get them from the child. Dan also mentions passing thru callbacks to the sub-widget which has a different set of problems. A parent cannot naively pass-thru a callback resource to a child. The main reason is that callback lists have two representations (internal and external). XtCreate (or XtAddCallback) expects Callback lists to be in external format and then compiles them into internal format. If the child is created and passed the shadow callback list, the list will already be in internal format (as a result of the XtCreate or XtAddCallBack done to the parent). The intrinsics will then try to recompile it for the child (not what you want). One way the parent can handle this is to have a callbackProc that it adds to the sub-widget callback list instead of passing thru the shadow list. When this callbackProc is called it should invoke the entries on the shadow callback list managed by the parent. Gabe Beged-Dov csnet: begeddov@software.org Software Productivity Consortium arpanet: begeddov%software.org@relay.cs.net
begeddov@software.ORG (Gabriel Beged-Dov) (09/19/88)
In my last message I asked:
How would you handle chained sub-widget resources (i.e. ones that are
defined in a superclass of the sub-widget)? Also, how would the
sub-widget set_value methods get invoked ?
The first question is only relevant for the R2 intrinsics. Along with
alot of other enhancements, the R3 intrinsics cache the superclass
resources in the class resource list. This allows subclass resource
defaults to override superclass defaults. In the R2 intrinsics the
superclass resources are chained by Xt{Get,Set}Values but not by
Xt{Get,Set}Subvalues (this makes sense since sub-parts don't have a
class hierarchy).
Sorry for any confusion.
Gabe Beged-Dov csnet: begeddov@software.org
Software Productivity Consortium arpanet: begeddov%software.org@relay.cs.net