Ticket UUID: | 420096 | |||
Title: | Bug with mixing geometery managers | |||
Type: | Bug | Version: | obsolete: 8.3.2 | |
Submitter: | s_a_white | Created on: | 2001-04-30 10:03:51 | |
Subsystem: | 69. Other | Assigned To: | dkf | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2001-05-01 16:14:15 | |
Resolution: | Invalid | Closed By: | s_a_white | |
Closed on: | 2001-05-01 09:14:15 | |||
Description: |
Hi, During a project I'm involved in there became a need to do the following: frame .f button .b grid .f pack .b -in .f This is a much simplified version of what I was doing, but the small example above shows the problem by causing TCL to lock up. Currently were using prowish 8.3.2. Another minor inconvience with mixing managers is propagate: frame .f -bd 2 -relief sunken -width 100 -height 100 grid propagate .f 0 grid .f button .f.b pack .f.b The result is not what was intended although the fix is fairly easy: frame .f -bd 2 -relief sunken -width 100 -height 100 pack propagate .f 0 grid .f button .f.b pack .f.b The first case (which dosen't work) seems to make more sense to me. I was wondering if it should check to see what manager the parent uses and therefore obtain the correct propagate? Simon | |||
User Comments: |
s_a_white added on 2001-05-01 16:14:15:
Logged In: YES user_id=59929 Hi, Heres a simplified version of the actual code, I'm sure I could reproduce the problem in normal tcltk, but your right the above dosen't work. Warring managers it no doubt the cause :(. The project I'm working on does however have a lot of mixing depending on whats easier for that part of the screen and who wrote the particular section of the code. Copy this to a file and run it in one go. package require Iwidgets 3 #################################################################################################################### # Namespace/Class definitions #################################################################################################################### class Chdwin { inherit itk::Widget constructor {args} {} # A custom window. You must create a title and position the buttons. itk_option define -custom custom Custom 0 } proc ::chdwin {{args ""}} { uplevel ::Chdwin $args } # Object Constructor body {Chdwin::constructor} {{options ""} args} { # Create a place for the user to place his own bits # Must be created before button box! itk_component add contents { frame $itk_interior.contents } { keep -background -width -height } # Create buttons set bbox $itk_interior.bbox frame $bbox ################################# # Fix for button hightlight bug # frame $bbox.resizeB -highlightthickness 1 frame $bbox.menuB -highlightthickness 1 frame $bbox.closeB -highlightthickness 1 ################################# button $bbox.menuB.b -width 11 -height 9 -borderwidth 2 -relief raised \ -padx 0 -pady 0 -highlightthickness 0 button $bbox.resizeB.b -width 11 -height 9 -borderwidth 2 -relief raised \ -padx 0 -pady 0 -highlightthickness 0 button $bbox.closeB.b -width 11 -height 9 -borderwidth 2 -relief raised \ -padx 0 -pady 0 -highlightthickness 0 # Setup bbox to contain all our buttons grid $bbox.menuB -column 2 -row 0 grid $bbox.menuB.b grid $bbox.resizeB -column 1 -row 0 grid $bbox.resizeB.b grid $bbox.closeB -column 0 -row 0 grid $bbox.closeB.b pack $itk_component(contents) -side bottom -fill both -expand true pack $bbox -side left -fill y eval itk_initialize $options $args } configbody {Chdwin::custom} { if ($itk_option(-custom)) { pack $itk_interior.bbox -in $itk_interior.contents -side top -anchor ne -fill none } else { pack $itk_interior.bbox -in $itk_interior -side left -fill y } } # Custom moves the button box into the contents to the user # can build screens around it. chdwin .c -custom 1 grid .c -sticky nsew # Griding here kills tcl, but I really wanted the contents # of the child window to be grided. button .c.contents.b grid .c.contents.b As for your the propagate I wasn't suggesting moving the meaning of propagate to the children. It's just the since .f was grided it seems to make sense to set grid propagate .f 0 since it's the gridder thats holding the geometery information. Setting pack propagate .f 0 is a little confusing because the packer does not holding any details about the widget .f. Hence why a suggestion of when you pack .f.b, the packer would say I must check the propagate for .f. Then it could say, hang on, I don't own .f but the gridder does, perhaps I should ask the gridder for the propagate... In gerenal use though I have found no reason to be able to set propagate independently for grid and pack. When mixing, we just set them both to the same value to avoid problems. If this approach was common perhaps a single propagate could be held be the widget, and therefore be common between between all managers. The grid/pack propagate would then be a way to set this common value. dkf added on 2001-04-30 17:20:35: Logged In: YES user_id=79902 Firstly, these are not Tcl bugs, but problems with Tk. Secondly, your first script works just fine for me. Are you sure it reproduces your problem? (I suspect your problem is warring geometry managers, which is a very well known problem that is very awkward to solve without breaking a lot of existing code.) Thirdly, the 'propagate' behaviour is correct as it stands (i.e. applying to masters, not children) since it has to be that way to work correctly with nested uses of the same geometry manager. |