1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • winfo gives me wrong geometry

    From Luc@21:1/5 to All on Mon May 15 00:11:56 2023
    wm attributes $::w -zoomed 1
    update idletasks
    regsub {([0-9]+)x.+} [winfo geometry $::w] {\1} ::WholeAppWidth

    The whole app width I'm getting is 600 - out of 600x381+817+515.

    But 600 is incorrect. I am making sure the application always runs
    maximized, and my screen is 1920px wide.

    The height can't be 381px either.

    The x/y coordinates are also wrong. If the application is maximized,
    they should be 0+0 (or maybe 1+1).

    What am I doing wrong this time?


    --
    Luc


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Luc on Mon May 15 03:57:40 2023
    Luc <[email protected]d> wrote:
    wm attributes $::w -zoomed 1
    update idletasks
    regsub {([0-9]+)x.+} [winfo geometry $::w] {\1} ::WholeAppWidth

    The whole app width I'm getting is 600 - out of 600x381+817+515.

    But 600 is incorrect. I am making sure the application always runs
    maximized, and my screen is 1920px wide.

    The height can't be 381px either.

    The x/y coordinates are also wrong. If the application is maximized,
    they should be 0+0 (or maybe 1+1).

    What am I doing wrong this time?

    Does the window become maximized on your system (on mine, it grows to
    full height, but the width does not change from it's default.

    Three things to try:

    1) try an update instead of an update idletasks

    2) because window resizing on Linux is the responsibility of the window manager, you may need to put in a bit of a delay to let the window
    manager complete the resize before you ask for the size. I.e., your
    code above might be obtaining the size before the wm has actuall
    resized anything.

    So try adding something like:

    after 500 [list set ::forever 1]
    vwait ::forever

    3) bind to the <Configure> event on $::w and don't ask for its size
    until after you get the configure event firing (this should be the most reliable as it avoids needing to "wait" for a fixed time, and it avoids
    doing a full update (or update idletasks). But it does require you
    restructure your code to work with the event.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Mon May 15 08:06:40 2023
    Am 15.05.2023 um 05:11 schrieb Luc:
    wm attributes $::w -zoomed 1
    update idletasks
    regsub {([0-9]+)x.+} [winfo geometry $::w] {\1} ::WholeAppWidth

    The whole app width I'm getting is 600 - out of 600x381+817+515.

    But 600 is incorrect. I am making sure the application always runs
    maximized, and my screen is 1920px wide.

    The height can't be 381px either.

    The x/y coordinates are also wrong. If the application is maximized,
    they should be 0+0 (or maybe 1+1).

    What am I doing wrong this time?



    If the state is zoomed, the last state normal geometry is returned.
    I would check the winfo height/width of "." to get current zoomed size.

    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luc@21:1/5 to Harald Oehlmann on Mon May 15 14:08:49 2023
    On Mon, 15 May 2023 08:06:40 +0200, Harald Oehlmann wrote:

    If the state is zoomed, the last state normal geometry is returned.
    I would check the winfo height/width of "." to get current zoomed size.

    Harald


    That is worse. "." gives me 1x1+0+0.

    --
    Luc


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luc@21:1/5 to Rich on Mon May 15 14:06:49 2023
    On Mon, 15 May 2023 03:57:40 -0000 (UTC), Rich wrote:

    1) try an update instead of an update idletasks

    That works, but I will have to look into the <Configure> option too
    because the window may be resized by the user and the application will
    have to self adjust accordingly.


    and it avoids
    doing a full update (or update idletasks).

    You say that like it's a bad thing. Is it? What is the problem with
    "a full update"?


    --
    Luc


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Heller@21:1/5 to [email protected] on Mon May 15 17:38:07 2023
    At Mon, 15 May 2023 14:06:49 -0300 Luc <[email protected]d> wrote:


    On Mon, 15 May 2023 03:57:40 -0000 (UTC), Rich wrote:

    1) try an update instead of an update idletasks

    That works, but I will have to look into the <Configure> option too
    because the window may be resized by the user and the application will
    have to self adjust accordingly.


    and it avoids
    doing a full update (or update idletasks).

    You say that like it's a bad thing. Is it? What is the problem with
    "a full update"?

    In *some* cases "a full update" could result in a race condition. Doing a a full update while in the process of doing a full update can be problematical. Eg if some event script does a "update", and this causes another event script to run which also calls "update"... (Yes this is a bit contrived, but you should get the point.)

    *Generally* you should only need to "update idletasks" -- this catches any
    lazy eval / defered updates and gets everything essential up-to-date, but *rarely* you may have to do a full update.




    --
    Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
    Deepwoods Software -- Custom Software Services
    http://www.deepsoft.com/ -- Linux Administration Services
    [email protected] -- Webhosting Services

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Luc on Mon May 15 18:38:34 2023
    Luc <[email protected]d> wrote:
    On Mon, 15 May 2023 03:57:40 -0000 (UTC), Rich wrote:

    1) try an update instead of an update idletasks

    That works, but I will have to look into the <Configure> option too
    because the window may be resized by the user and the application will
    have to self adjust accordingly.

    In this case, you *will* want to bind to the <Configure> event, because
    if you have need to know what size the user resized things to, binding
    to <Configure> is the only reliable way to do so.

    and it avoids doing a full update (or update idletasks).

    You say that like it's a bad thing. Is it? What is the problem with
    "a full update"?

    It can interact badly with other modules that themselves use vwait for
    pauses, and/or interact badly with event driven code (either yours or
    other modules doing event driven work).

    Update idletasks is somewhat safer, but it can also cause some
    irritating interactions with vwait/event driven code (just less than a
    full update).

    Now, for 'startup' where you are not yet running and are still
    initializing, you can get away with either without too much worry.

    For more indepth details read:

    Update considered harmful https://wiki.tcl-lang.org/page/Update+considered+harmful

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ralf Fassel@21:1/5 to All on Tue May 16 12:13:09 2023
    * Rich <[email protected]d>
    | Luc <[email protected]d> wrote:
    | > On Mon, 15 May 2023 03:57:40 -0000 (UTC), Rich wrote:
    | >
    | >> 1) try an update instead of an update idletasks
    | >
    | > That works, but I will have to look into the <Configure> option too
    | > because the window may be resized by the user and the application will
    | > have to self adjust accordingly.

    | In this case, you *will* want to bind to the <Configure> event, because
    | if you have need to know what size the user resized things to, binding
    | to <Configure> is the only reliable way to do so.

    Note that the <Configure> event will also trigger the first time the
    window appears on the screen and is mapped to it's first 'real' size:

    % cat t.tcl
    proc showgeom {msg} {
    puts "$msg: geom [winfo geometry .] w [winfo width .] h [winfo height .]"
    }
    showgeom "at start"
    bind . <Configure> [list showgeom "via Configure"]
    % wish t.tcl
    at start: geom 1x1+0+0 w 1 h 1
    via Configure: geom 200x200+0+0 w 200 h 200
    via Configure: geom 200x200+148+372 w 200 h 200
    via Configure: geom 200x200+148+372 w 200 h 200

    R'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)