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
>>

Luc <luc@sep.invalid> 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.

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

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
>>

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
>>

At Mon, 15 May 2023 14:06:49 -0300 Luc <luc@sep.invalid> 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
heller@deepsoft.com -- Webhosting Services

Luc <luc@sep.invalid> 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

* Rich <rich@example.invalid>
| Luc <luc@sep.invalid> 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'