gnb@bby.oz.au (Gregory N. Bond) (04/08/91)
I am confused about the behaviour of the table widget distributed with WCL
when some of the table contents are composite widgets. I have an app
I am prototyping that contains a line of buttons along the top and two
output areas (AtPlotter widgets, but any composite would do). I want
the first one to be 3/4 of the available space and the second one to
be 1/4 of the space. This I can do by specifying the layout
correctly. I also want to be able to unmanage the 2nd layout area
and have the 1st one cover the whole window, and then re-manage the
second widget and have the area split up in the 3-1 ratio again.
If the two output widgets are simple widgets (e.g. Labels) then
everything works exactly as expected. Stretching, shrinking,
everything; including the mapping and unmapping of the second widget.
If the output widgets are composite widgets (AtPlotter in my real app,
Box has the same problem), then stretching works OK, shrinkage almost
works, and unmapping/mapping fails miserably (the new window is mapped
but the first one is never resized, and you have top expand the main
window to uncover it.) The size of the composite subwidgets never
seems to be allowed to shrink.
Is this a bug in my brain or a bug in the table widget? Does anyone
have a suggested workaround?
Attatched is a resource file that, when run under Ari, will
demonstrate the problem.
Greg.
--
!
! An AD file to test table expose/resize semantics
!
Ari.wcChildren: table
*table.wcClassName: Table
*table.wcChildren: left, middle, right, one, two
*table.Layout: left 0 0 lhwHW; middle 1 0 hwHW ; right 2 0 lhwHW ; one 0 1 3 3 ; two 0 4 3 1
*left.Label: quit
*left.callback: WcExitCB(0)
*left.wcClassName: Command
*right.Label: hide two
*right.callback: WcUnmanageCB(*two)
*right.wcClassName: Command
*middle.Label: show two
*middle.callback: WcManageCB(*two)
*middle.wcClassName: Command
!
! with these definitions of one and two, it fails....
!
*one.wcClassName: Box
*one.wcChildren: onelabel
*onelabel.wcClassName: Label
*two.wcClassName: Box
*two.wcChildren: twolabel
*twolabel.wcClassName: Label
!
! With simple labels for one and two it works.
!
!*one.wcClassName: Label
!*two.wcClassName: Label
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbnazgul@alphalpha.com (Kee Hinckley) (04/09/91)
In article <1991Apr8.055237.19247@melba.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes: >I am confused about the behaviour of the table widget distributed with WCL >when some of the table contents are composite widgets. I have an app I guess I can answer this as the unofficial keeper of Table. Table has some very major and fundamental flaws in geometry management (as do a number of other widgets, unfortunately). I recently did a nearly complete rewrite of the geometry management code and will be releasing this sometime in May. This said, I'm not sure that's your problem. >correctly. I also want to be able to unmanage the 2nd layout area >and have the 1st one cover the whole window, and then re-manage the >second widget and have the area split up in the 3-1 ratio again. The new table keeps an idea of what the preferred size of the child was, so it should come back at that size, as long as the child doesn't make any stupid resize requests. >Box has the same problem), then stretching works OK, shrinkage almost >works, and unmapping/mapping fails miserably (the new window is mapped A lot of composite widgets are pretty bad about shrinking. The old Table didn't even try. The new one does, although it's not terribly smart (I'd like it to shrink proportionally). >but the first one is never resized, and you have top expand the main >window to uncover it.) The size of the composite subwidgets never >seems to be allowed to shrink. I'm not sure why mapping doesn't work. Unmapping the widget ought to leave a blank space where it was. Remapping will bring it back. There shouldn't be any geometry changes. -- 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.