window on-move / move inconsistency

On my system (linux manjaro xfce gtk) move seems to treat the position as the outer window position (left-top of the decorated window). While on-move and get-x / get-y report the position of the undecorated window (the left-top of the inside of the window).

Actually on-move first reports the outer window position and immediately afterwards the inner window position. Except when the outer window position (set via move) happens to be equal to the inner window position, than it appears that move does nothing and on-move is not called.

Expected Behaviour:
calling (send frame move x1 y1)
results in a call of (on-move x1 y1)

Observed Behaviour:
calling (send frame move x1 y1)
results in a call of (on-move x1 y1) followed by (on-move x2 y2)

Proposal 1 (preferred):

• to make move more consistent it should always take inner window coordinates
• on-move only gets called once with the inner window coordinates

Proposal 2:

• add methods get-outer-x and get-outer-y which return the outer window coordinates
• ensure those coordinates are consistent with move (and remove or fix the caching that seems to happen within move)

Example:

#lang racket/gui

(define moveframe%
  (class frame%
    (super-new)

    (define/override (on-move x y)
      (displayln (format "~a ~a" x y)))))

(define (example)
  (define f (new moveframe% [label "move frame"] [width 300] [height 300]))
  (define (m msg x y)
    (displayln (~a msg " " x " " y ":"))
    (send f move x y))

  (m "init" 100 100)
  (send f show #t)
  (sleep/yield 1)
  (m "reset" 100 100)
  (sleep/yield 1)
  ;; this depends on the window decoration specific delta which is (1 24) on my system
  (m "stays the same, because x y are already" (send f get-x) (send f get-y))
  (sleep/yield 1)
  (m "window decoration delta gets added" (add1 (send f get-x)) (send f get-y))
  (sleep/yield 1)
  (m "window decoration delta gets added again" (add1 (send f get-x)) (send f get-y))
  (sleep/yield 1)
  (send f show #f))

(module+ main
  (example))

Output (Linux):

init 100 100:
100 100
101 124
reset 100 100:
100 100
101 124
stays the same, because x y are already 101 124:
window decoration delta gets added 102 124:
102 124
103 148
window decoration delta gets added again 104 148:
104 148
105 172

Output (Windows Virtual Machine):

init 100 100:
100 100
reset 100 100:
stays the same, because x y are already 100 100:
window decoration delta gets added 101 100:
101 100
window decoration delta gets added again 102 100:
102 100

The behavior on windows is as expected.

Start with the provided racket/gui example and reproduce the behavior on Linux, then compare move, on-move, get-x, and get-y with the Windows output. Done means the chosen coordinate behavior is consistent and moving the frame produces the expected single on-move result, or the outer-coordinate methods and caching behave consistently.