[wm deiconify] does not bring up window in linux

[tombert]

The following code:

toplevel .main
wm iconify .main
wm deiconify .main


does not pop-up the window tested in Ubuntu 14, TCL 8.5. Whereas it works in Windows.
Also the tricks mentioned in the manual (do a [raise], [update] etc.) don't work. I remember that this has worked some (long) time ago.

Sidenote: I noticed that [wm iconify .main] takes two seconds to execute. Is this known?

Could this be a bug?

thx

[Rich]

Yes, but more likely in Ubuntu 14's window manager than in Tk.

Here is what I get on Slackware using Fvwm2:

$ wish
% toplevel .main
.main
% time {wm iconify .main} 1
2100 microseconds per iteration
% time {wm deiconify .main} 1
2724 microseconds per iteration
%

And both the iconify and the deiconify happen properly.

But under X11, iconfication and deiconification are handled by the
window manager that is running. The applicantion merely request the
window manager do one or the other, and then it is up to the window
manager to carry through (or ignore the request).

Sounds like Ubuntu 14's window manager may be ignoring the deiconify
request for some reason.

[tombert]

I repeated the test in U14 and U16 with both TCL 8.5.19 and 8.6.7 (fresh from repository sources) and get same results:

% time {wm iconify .main}

2002944 microseconds per iteration

And window does not deiconify ...

I can workaround using [wm forget .main] and then [wm manage .main]. This makes the window popup on different locations.

damn ....

[Gerald Lester]

On 09/20/2017 09:16 AM, tombert wrote:
> The following code:
>
> toplevel .main
> wm iconify .main
> wm deiconify .main

Putting the above in a file named foo.tcl then doing (from a bash shell):
gerald:~$ wish foo.tcl

Causes both . and .main to display.

Also happens instantly.

This was with 8.6.6 and Ubutu 17 running Unity WM.

> does not pop-up the window tested in Ubuntu 14, TCL 8.5. Whereas it works in Windows.
> Also the tricks mentioned in the manual (do a [raise], [update] etc.) don't work. I remember that this has worked some (long) time ago.
>
> Sidenote: I noticed that [wm iconify .main] takes two seconds to execute. Is this known?
>
> Could this be a bug?

Not likely.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[tombert]

Verified that it works in U12

[tombert]

... and I switched the window manager to gdm in U14. The bug is still there ...

[Robert Heller]

I just did a test with Ubuntu 14.04:

wm iconify .;wm deiconify .

indeed does not work.

BUT

wm withdraw .;wm deiconify .

DOES WORK.

This is strange. And yes, it is likely a bug of some sort in Ubuntu's window
manager...

(*I* don't use Ubuntu's window normally -- I did this test in a VM, which I
generally only even login to via ssh from a CentOS 6 system using fvwm2 as a
window manager.)

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Gerald Lester]

On 09/20/2017 01:20 PM, Robert Heller wrote:
> At Wed, 20 Sep 2017 09:32:16 -0700 (PDT) tombert <tomber...@live.at> wrote:
>
>>
>> I repeated the test in U14 and U16 with both TCL 8.5.19 and 8.6.7 (fresh from repository sources) and get same results:
>>
>> % time {wm iconify .main}
>> 2002944 microseconds per iteration
>>
>> And window does not deiconify ...
>>
>> I can workaround using [wm forget .main] and then [wm manage .main]. This makes the window popup on different locations.
>>
>> damn ....
>
> I just did a test with Ubuntu 14.04:
>
> wm iconify .;wm deiconify .
>
> indeed does not work.
>
> BUT
>
> wm withdraw .;wm deiconify .
>
> DOES WORK.
>
> This is strange. And yes, it is likely a bug of some sort in Ubuntu's window
> manager...
>
> (*I* don't use Ubuntu's window normally -- I did this test in a VM, which I
> generally only even login to via ssh from a CentOS 6 system using fvwm2 as a
> window manager.)

Remember any [wm] command is a request to the window manager -- which
the window manager is totally free to ignore.

[Robert Heller]

At Wed, 20 Sep 2017 13:58:55 -0500 Gerald Lester <Gerald...@KnG-Consulting.net> wrote:

>
> On 09/20/2017 01:20 PM, Robert Heller wrote:
> > At Wed, 20 Sep 2017 09:32:16 -0700 (PDT) tombert <tomber...@live.at> wrote:
> >
> >>
> >> I repeated the test in U14 and U16 with both TCL 8.5.19 and 8.6.7 (fresh from repository sources) and get same results:
> >>
> >> % time {wm iconify .main}
> >> 2002944 microseconds per iteration
> >>
> >> And window does not deiconify ...
> >>
> >> I can workaround using [wm forget .main] and then [wm manage .main]. This makes the window popup on different locations.
> >>
> >> damn ....
> >
> > I just did a test with Ubuntu 14.04:
> >
> > wm iconify .;wm deiconify .
> >
> > indeed does not work.
> >
> > BUT
> >
> > wm withdraw .;wm deiconify .
> >
> > DOES WORK.
> >
> > This is strange. And yes, it is likely a bug of some sort in Ubuntu's window
> > manager...
> >
> > (*I* don't use Ubuntu's window normally -- I did this test in a VM, which I
> > generally only even login to via ssh from a CentOS 6 system using fvwm2 as a
> > window manager.)
>
> Remember any [wm] command is a request to the window manager -- which
> the window manager is totally free to ignore.

So I guess the default window manager Ubuntu 14.04 is somehow "broken" or
something.

[tombert]

>
> So I guess the default window manager Ubuntu 14.04 is somehow "broken" or
> something.
>
> >
>

I installed Gnome WM and got the same behaviour.
Interesting that it works with U17. I wonder what I need to update to get it working ...

[Robert Heller]

Window Manager or Desktop Manager? These are *different* things.

[Brad Lanam]

On Wednesday, September 20, 2017 at 11:21:04 AM UTC-7, Robert Heller wrote:

> At Wed, 20 Sep 2017 09:32:16 -0700 (PDT) tombert <tombert> wrote:
>
> >
> > I repeated the test in U14 and U16 with both TCL 8.5.19 and 8.6.7 (fresh from repository sources) and get same results:
> >
> > % time {wm iconify .main}
> > 2002944 microseconds per iteration
> >
> > And window does not deiconify ...
> >
> > I can workaround using [wm forget .main] and then [wm manage .main]. This makes the window popup on different locations.
> >
> > damn ....
>
> I just did a test with Ubuntu 14.04:
>
> wm iconify .;wm deiconify .
>
> indeed does not work.
>
> BUT
>
> wm withdraw .;wm deiconify .
>
> DOES WORK.

wm iconify is supposed to iconify the window and put an icon on the desktop. Not many window managers do this any more. There's even a way to set the icon
picture.

wm withdraw is the proper command to use. I use this on Linux and Windows
and Mac OS X and it works.

I don't think there is a bug, it is just that wm iconify is old and was used
for a different purpose.

[Brad Lanam]

On Thursday, September 21, 2017 at 8:18:13 AM UTC-7, Brad Lanam wrote:
> wm iconify is supposed to iconify the window and put an icon on the desktop. Not many window managers do this any more. There's even a way to set the icon
> picture.
>
> wm withdraw is the proper command to use. I use this on Linux and Windows
> and Mac OS X and it works.
>
> I don't think there is a bug, it is just that wm iconify is old and was used
> for a different purpose.

The part that is confusing is that there is no 'wm restore' corresponding to 'wm withdraw'. You have to use 'wm deiconify' for that purpose.

[Robert Heller]

At Thu, 21 Sep 2017 08:22:06 -0700 (PDT) Brad Lanam <brad....@gmail.com> wrote:

>
> On Thursday, September 21, 2017 at 8:18:13 AM UTC-7, Brad Lanam wrote:
> > wm iconify is supposed to iconify the window and put an icon on the desktop. Not many window managers do this any more. There's even a way to set the icon
> > picture.

Right. With the advent of GUI file managers and the use of the Desktop for
*file* and *folder* icons, the use of the Desktop for *application window*
icons has fallen out of "favor". Having "transient" *application window* icons
mixed in with "fixed" *file* and *folder* icons would likely be very
confusing for users.

> >
> > wm withdraw is the proper command to use. I use this on Linux and Windows
> > and Mac OS X and it works.
> >
> > I don't think there is a bug, it is just that wm iconify is old and was used
> > for a different purpose.
>
> The part that is confusing is that there is no 'wm restore' corresponding to
> 'wm withdraw'. You have to use 'wm deiconify' for that purpose.

Yes, this is probably confusing...

[tombert]

>
> wm withdraw is the proper command to use. I use this on Linux and Windows
> and Mac OS X and it works.
>
> I don't think there is a bug, it is just that wm iconify is old and was used
> for a different purpose.

I do not agree. [wm withdraw] removes the window from the taskbar as well. [wm iconify] should minimize the window.
Also if the user minimizes the window (manually) into the taskbar, there is not proper way of getting the window up again (at least not in U14 and U16) - this is a bug.

[tombert]

I do not know what this is about? The application is not moved onto the "desktop" but on to the taskbar. The taskbar shows active/running applications.
Fixed application icons with "transient" icons (that is running applications) is de facto standard in Windows world and in Ubuntu. One can have the file explorer on the taskbar even when it's not running. I have never found that confusing.

[Rich]

tombert <tomber...@live.at> wrote:
> On Thursday, 21 September 2017 18:35:43 UTC+2, Robert Heller wrote:
>> At Thu, 21 Sep 2017 08:22:06 -0700 (PDT) Brad Lanam <brad....@gmail.com> wrote:
>>
>> >
>> > On Thursday, September 21, 2017 at 8:18:13 AM UTC-7, Brad Lanam wrote:
>> > > wm iconify is supposed to iconify the window and put an icon on the desktop. Not many window managers do this any more. There's even a way to set the icon
>> > > picture.
>>
>> Right. With the advent of GUI file managers and the use of the Desktop for
>> *file* and *folder* icons, the use of the Desktop for *application window*
>> icons has fallen out of "favor". Having "transient" *application window* icons
>> mixed in with "fixed" *file* and *folder* icons would likely be very
>> confusing for users.
>>
>> > >
>> > > wm withdraw is the proper command to use. I use this on Linux and Windows
>> > > and Mac OS X and it works.
>> > >
>> > > I don't think there is a bug, it is just that wm iconify is old and was used
>> > > for a different purpose.
>> >
>> > The part that is confusing is that there is no 'wm restore' corresponding to
>> > 'wm withdraw'. You have to use 'wm deiconify' for that purpose.
>>
>> Yes, this is probably confusing...
>>

> I do not know what this is about? The application is not moved onto
> the "desktop" but on to the taskbar. The taskbar shows
> active/running applications.

> Fixed application icons with "transient" icons (that is running
> applications) is de facto standard in Windows world and in Ubuntu.
> One can have the file explorer on the taskbar even when it's not
> running. I have never found that confusing.

I suspect the OP for the comment is referring to the pre-win95 days and
pre "desktop environment" days of Unix machines where the only things
that were on the desktop background were:

1) an optional wallpaper

2) icons of *currently running*, but iconified, applications

There were no "task bars" into which an application could "iconify" in
these days. In the Unix world, if there were no running apps at all,
the desktop background would be just the wallpaper and nothing more.

One (usually) accessed ones menu by clicking on the desktop background,
upon which a menu would appear to allow one to open whatever apps one
had configured into the menu.

The "task bar" concept of having a reserved area of the screen where
there was a fixed button to access a menu of apps to launch, and a
fixed area where small icons of running applications would appear, was
a later concept. It existed (somewhat) as a possibility in a few Unix
window managers (when I first saw the Win95 taskbar it looked to me
like a direct ripoff of the "iconbar" from either twm or tvtwm, I
forget which now), but the overall concept was popularized, and very
much locked down, by Win95 which was the masses first exposure to a
"taskbar/start button" concept.

But all of this history is of no help in determining why "wm iconify"
does not actually iconify the window into the Ubuntu task bar like it
should. But given that "wm iconify" is merely a request to the current
window manager (which is not your Tcl/Tk application) to iconify the
Tcl/Tk app window, the fact that it fails implies some issue with
Ubuntu's window manager (whatever WM it is that is running).

[Rich]

tombert <tomber...@live.at> wrote:
>
>>
>> wm withdraw is the proper command to use. I use this on Linux and
>> Windows and Mac OS X and it works.
>>
>> I don't think there is a bug, it is just that wm iconify is old and
>> was used for a different purpose.
>
> I do not agree. [wm withdraw] removes the window from the taskbar as
> well. [wm iconify] should minimize the window.

Correct. "wm withdraw" and "wm iconify" are two very different
operations from the window managers perspective.

> Also if the user minimizes the window (manually) into the taskbar,
> there is not proper way of getting the window up again (at least not
> in U14 and U16) - this is a bug.

Do you mean if they use the mouse to click the "minimize" button of the
window, then it iconifies into the task bar properly, but that then if
they use the mouse to try to use the icon in the taskbar to bring the
window back, it won't come back?

If yes, then this really points to something *very* wrong with whatever
window manager it is that is running in that Ubuntu system.

[Brad Lanam]

I am corrected.

Seems to work fine w/Ubuntu 15.10 and mate.

So it appears you have a few choices:
- Don't iconify your windows programatically.
- Upgrade Ubuntu to version 17.
- Use wm withdraw and make your own toolbar with window icons.
- Use a window manager that doesn't have this bug.

[Robert Heller]

The environment *I* run is almost exactly like on a VAXStation 2000 (VMS +
DecWindows) or a DECStation 3000 (Ultrix + DecWindows) -- this is vintage
mid-late 1980s to early 1990s VMS/UNIX X-Windows environments (DECWindows was
DEC's branding of X11 + Motif). I use FVWM2 in "MWM" mode. I *never* have
*any* icons (of any sort) on my desktop backgrounds. Only active windows. I
use FVWM2 as my window manager, with the FVWM IconBox for all of my running
app icons. I have NO GUI file manager (I detest point-and-click /
drag-and-drop file management). On my CentOS 6 systems, GNome 2 is somewhere
in the background, with a simple GNome Panel. I have a Tcl/Tk coded "Menu
Manager" that does just what DEC's original "Session Manager" did. It has a
simple menu system that I control that has NOTHING to do with the freedesktop
nonsense -- I make no use of "*.desktop" files. (Note: *I* NEVER used any
sort of MS-Windows or MacOS system as my personal desktop or laptop -- I went
from using VMS with a VT<whatever> to using VMS on a VAXStation to using
Ultrix on a DECStation to using Linux on a "PC".

>
> One (usually) accessed ones menu by clicking on the desktop background,
> upon which a menu would appear to allow one to open whatever apps one
> had configured into the menu.
>
> The "task bar" concept of having a reserved area of the screen where
> there was a fixed button to access a menu of apps to launch, and a
> fixed area where small icons of running applications would appear, was
> a later concept. It existed (somewhat) as a possibility in a few Unix
> window managers (when I first saw the Win95 taskbar it looked to me
> like a direct ripoff of the "iconbar" from either twm or tvtwm, I
> forget which now), but the overall concept was popularized, and very
> much locked down, by Win95 which was the masses first exposure to a
> "taskbar/start button" concept.
>
> But all of this history is of no help in determining why "wm iconify"
> does not actually iconify the window into the Ubuntu task bar like it
> should. But given that "wm iconify" is merely a request to the current
> window manager (which is not your Tcl/Tk application) to iconify the
> Tcl/Tk app window, the fact that it fails implies some issue with
> Ubuntu's window manager (whatever WM it is that is running).

With Ubuntu 14.04, there isn't exactly a separate task. The is the
"Launcher". Running programs add a icon of sorts to the Launcher, but only if
there isn't already a launcher button for that partitular program. A little
white triangle is included next to the launcher/icon if there is an active
program involved. Actually really cruddy from my POV.

[tombert]

> Do you mean if they use the mouse to click the "minimize" button of the
> window, then it iconifies into the task bar properly, but that then if
> they use the mouse to try to use the icon in the taskbar to bring the
> window back, it won't come back?
>
> If yes, then this really points to something *very* wrong with whatever
> window manager it is that is running in that Ubuntu system.

Manually open the window works, but [deiconify] after a manual iconfiy it doesn't.

[Brad Lanam]

All of the gnome-3 variants have this bug.
The work around is to use some other window manager.

This appears to be the relevant bug, but it has not been addressed:

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1502370

[tombert]

Ubuntu 18.04.2 LTS

Now going into this again, I don't think it's a gnome bug. It is simply the evolution of the window manager.

The test one can do is using [xwininfo -all] on a visible terminal:
...
Map State: IsViewable
...

Now minimize the terminal and call again [xwininfo -all -id <0x????>]
...
Map State: IsViewable
...
Window state:
Hidden
...


It also seems not possible to [bind] a toplevel to such an event getting notified when a window is minimized (I tried all possible bind combinations without success).
For the time being I believe this is due to the fact that TK only supports mapped and unmapped states.

This worked for old window managers, but is not sufficient for window manager that require updates in iconified state.

One can read the definition here:
(http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap3-2.html)
"3.4.2.5 Iconify and Deiconify
A top-level window that is not Withdrawn will be in the Normal state if it is mapped and in the Iconic state if it is unmapped. This will be true even if the window has been reparented; the window manager will unmap the window as well as its parent when switching to the Iconic state.
The client can elect to be notified of these state changes by selecting for StructureNotify events on the top-level window. It will receive a UnmapNotify event when it goes Iconic and a MapNotify event when it goes Normal."

So it's also not a TK bug in itself, but simply the evolution that TK did not catch up with.

Question is, how to fix that. At least as a patch ...

Any ideas?

thx

[tombert]

... and [xwininfo] does it using XCB calls: https://www.systutorials.com/docs/linux/man/3-xcb_intern_atom/

[tombert]

... [xprop] is not using XCB but XInternAtom() from xlib and also returns a correct "iconified" state.

But TK uses a "simulated" XInternAtom function !?

Does that ring a bell?

[tombert]

I am pretty sure that there is something wrong, so I went further filing bug-reports:

https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1827738
https://gitlab.gnome.org/GNOME/mutter/issues/589
https://core.tcl.tk/tk/tktview/3131699cb421ec1de2b6fa08ff0835dd34eff3cb

[Donal K. Fellows]

On 04/05/2019 23:36, tombert wrote:
> But TK uses a "simulated" XInternAtom function !?

Not when it can talk to a real X server it doesn't.

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[tombert]

Follow up: https://core.tcl-lang.org/tk/tktview/ee3361a3ad36260b4eedbbf3fa920bf38b570c1f