[Tcl-bugs] [ tktoolkit-Bugs-220839 ] several wm geometry bugs

[<no...@so...>]

Bugs item #220839, was opened at 2000-10-31 20:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=220839&group_id=12997

Category: 65. Generic Window Operations
Group: : 8.0.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Brent B. Welch (welch)
>Assigned to: Jeffrey Hobbs (hobbs)
Summary: several wm geometry bugs

Initial Comment:
OriginalBugID: 1961 Bug
Version: 8.0.5
SubmitDate: '1999-04-29'
LastModified: '1999-10-22'
Severity: MED
Status: UnAssn
Submitter: pat
ChangedBy: hobbs
OS: Other
Machine: NA


Name:
Don Libes

Extensions:
Tk 8.0.5 and Tk 8.1b3

ReproducibleScript:
Three problems:
    
    1) Documentation problem:  wm(1) says:
    
      When gridded geometry management is enabled ... interactive resizing
      is carried out in even numbers of grid units rather than pixels.
    
    As far as I can tell this is false on Windows and MacOS.  To the
    contrary, they let me interactively resize to any pixel.  I imagine
    this is simply a deficiency of the window managers on those systems,
    however the documentation should be corrected to explain that you
    cannot depend on interactive resizing working the way you describe -
    perhaps suggesting that it's necessary to fix up fractional grid units
    left by the window manager.
    
    [wm geometry] returns integral grid units, seemingly ignorant of the
    screen slop.  This means that you have to take explicit action to
    repair the defective interactive resizing.  Alas, you can't tell that
    you have to take action (since there's no query to do so) so that
    means you ALWAYS have to resize the window in response to a configure
    event if you want to prevent slop from creeping in.
    
    This wouldn't be so bad except that if you try to "fix" the geometry
    to get rid of the slop, you run into different problems ...
    
    2) This one was an attempt to fix the slop (as above).  Run it on a PC
    (to be specific, I'm using NT 4.0).  Following the instructions below,
    you will see the wm geometry returns bogus widths (such as -3939732).
    
    # To run this script, first change the socket command to point to a
    socket
    # on which someone is listening or save result to a file.
    # (You have to save it somewhere else beside the screen since this app
    #  will take over the whole screen.)
    # Then, run the app with wish (either 8.0.5 or 8.1b3 is fine).
    # Once running, hit the maximize button.  Then hit the normal-size
    button.
    # wm geom will then report totally ridiculous widths.
    
    set fid [socket host someval]
    fconfigure $fid -buffering line
    
    listbox .from -height 1 -width 80 -setgrid 1
    grid .from
    
    bind . <Configure> {
        set s [wm geometry .]
        puts $fid "geometry = $s"
        scan $s "%%dx%%d" w h
        .from configure -width $w
        wm geometry . ""
    }
    
    3) In an effort to reduce jitter, I introduced a delay before
    responding to <Configure> events.  Try this example:
    
      bind . <Configure> {
          puts "<Configure>"
          catch {after cancel $cid}
          set cid [after 500 configure]
      }
    
      proc configure {} {
          scan [wm geometry .] "%dx%d" w h
          wm geometry . [set w]x[set h]
      }
    
    When using UNIX (twm)
      3a) if you wait a little before dragging, the window stays where you
         moved it and then hops over a couple of pixels.
      3b) if you drag the window within a couple of seconds, the window
    moves
         back to where it started.  This behavior repeats if you drag within
         a couple of seconds of the previous drag.
    When using UNIX (olwm)
      3c) same behavior as (3b) above
    When using UNIX (kde)
      3d) produces infinite stream of configure events.
    When using NT
      3e) same behavior as (3d) above
    When using MacOS
      3f) works correctly!
    
    (In case you're wondering why I'm calling "wm geometry" to set the
    width/height to the value it should already be, it's because when the
    window is gridded, this will get rid of the slop (extra pixels).  When
    I add back a gridded widget to make this a real example, it misbehaves
    the same way I've described above.)
    
    By the way, to make it clear about (3b), what's going wrong is not
    just the width/height but the *position*!  And that's not even
    mentioned in the script!  So it doesn't matter how you calculate width
    and height.
    
    I doubt it has anything to do with not being updated in time.  If I
    skip the "after" delay, the configure WORKS (on UNIX).  Bottom line:
    
    - if no delay, new geometry is seen immediately
    - if delay, the old geometry returns (for a little while)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=220839&group_id=12997