nazgul@alfalfa.com (Kee Hinckley) (03/20/91)
> > Hey networld, > I've got a couple labels in a row column in a form in the main window > that don't resize whenever the label string resource is chaged. As a result > the operator has to resize the window the see the new label contents. I'm > not doing anything with the labels. Motif 1.1 under VMS on a VAXstation 3100. > Any help will be appreciated. I suspect this may depend on who their parent is, and here's why. According to Asente and Swick there are two ways you can play the resize game. In one the child requests a resize, the parent decides it's okay, returns Yes, and the child calls it's resize method. In the second the parent decides it's okay, reconfigures the widget, returns Done and the child doesn't have to do anything, since the resize method is called by the reconfigure. The catch here, and the reason it's important, is that the child never sees "Done", it always sees "Yes" in either case - so it needs to know which policy the widget-set is using. I could be wrong, but I think that Motif is not using either of these models consistantly - which could cause the problem you see. (Alternatively you might just have turned resizeWidth off in it or its parent.) Would anyone care to comment on which policy Motif uses? Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
vania@osf.org (Vania Joloboff) (03/21/91)
> I could be wrong, but I think that Motif is not using either of > these models consistently - which could cause the problem you see. Correct. Some widgets use GeometryYes, others use GeomtryDone, depending upon various factors, like coming from HP or DEC windows... We would like to fix that in 1.2 and move to a GeometryYes policy in every manager. However, it may break applications that have developed Motif subclasses and explicilty rely on the bogus behavior, for example a subclass of primitive that would behave differently if the parent is a BulletinBoard or a Frame. if MakeGeometryRequest == Yes if myparent is a Frame dothis else myparent is a BBoard dothat else etc That would not work any more. Any comment on the GeometryYes policy ?
nazgul@alfalfa.com (Kee Hinckley) (03/21/91)
> We would like to fix that in 1.2 and move to a GeometryYes > policy in every manager. However, it may break applications > that have developed Motif subclasses and explicilty > rely on the bogus behavior, for example a subclass of > primitive that would behave differently if the parent > is a BulletinBoard or a Frame. > > if MakeGeometryRequest == Yes > if myparent is a Frame dothis > else myparent is a BBoard dothat > else etc > > That would not work any more. That's fine - that's clearly a broken widget, or at least one which knows that it is dealing with broken widgets and must change when they are fixed. > Any comment on the GeometryYes policy ? Actually I have a number of thoughts about Geometry management in general. Andy Schulert and I are doing a paper for Xhibition which will talk about them and which expresses what we think the Motif widgets should do once they are consistent. Specifically on that question though, I think I would prefer Done instead of Yes. It puts a little more burden on the managers (but not much) and makes life easier for the primitives. It also seems like it's easier to change a widget to that policy than the other, which is good for integrating non-Motif widgets. Why might Yes be preferred? Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Uucp@resq.fidonet.org (Uucp) (03/25/91)
From uunet!osf.org!motif-talk-request From: uunet!Morgan.COM!chuck (Chuck Ocheret) To: sunrise.com!samborn Date: Fri, 22 Mar 91 11:56:15 EST Cc: motif-talk@osf.org > Is it really easier to add non-Motif widgets when the answer is Done? > Returning GeometryDone means that the Composite parent did the > resizing. It seems that having an XmManager resize a non-Motif widget > might get a little hairy. For example, in Athena, I believe that > there are widgets that use the SHAPE extension. How could an > XmManager possibly understand the SHAPE extension? I don't think an XmManager needs to know anything about the SHAPE extension. If the manager goes ahead and does a resize on the rectangular region specified in the geometry request, then the widget which was resized will take care of reshaping itself to fit its new geometry. I prefer GeometryDone by a long shot. ~chuck -- Uucp - via FidoNet node 1:269/133 UUCP: uunet!resq!Uucp