Window moved to too far when moved programmatically and Window partially out of screen.

[DumbHawk]

If a Window is moved outside the Screen and then moved programmatically to another position in this case using the QT API the window is positioned entirely inside the Screen instead of the Position it is supposed to. This results in a “pop-In” of the Window instead of a move. It looks like the window snaps to the border of the screen.

Use Case. iceWM is used in a “Kioskmode manner” with a touch screen, the Window position is controlled by the software. Windows moved too far out of screen are moved to a certain limit position by the software.

Version “2.9.7” “icewm-2.9.7-4.el8“ OS RHEL 8.6 /etc/icewm/preferences: SnapMove=0 LimitPosition=0 LimitSize=0 …

[gijsbers]

Thanks for reporting this. However, sofar I'm unable to reproduce it. I tried with two different methods:

1. use the _NET_MOVERESIZE_WINDOW client message.
2. use the XMoveWindow library call.

Both allow me to set and move windows outside of the screen dimensions fine. For example:

icesh -f move 2700 -3000 ; sleep 2 ; icesh -f move -1600 2000 ; sleep 2 ; icesh -c xterm top left

To make progress, you need to discover if there is a different way your API moves windows. One thing which could help is to use the icesh spy command. Also spy on root. Provide a tiny Qt demo application.

[DumbHawk]

The Problem is not the move of the Window out of the screen.

The Window is moved/draged out of the Screen by the User ( TouchScreen ) at a certain point our Software sees the Window Moved to to far ( A Border is defined ) an will move it slightly back so it can still easily grabbed using the touch screen.

At this point the window snaps back into the screen aligned with the border of the screen.

This did not happen in earlier Versions of iceWM. But since we were forced to Upgrade the plattform we ran into this issue.

thank you for reply.

EDIT: I will provide more info as soon as I can.

[DumbHawk]

I attached the icesh spy result: The Problem occurs when the Message "Visibility Unobscured" is shown

icewmLog.txt

[gijsbers]

What version were you upgrading from? The one which still worked for you.

[gijsbers]

Thanks for the spy log. It shows that your app uses the WM_NORMAL_HINTS property to move the window around. If you look at the manpage for XSizeHints and scroll down a bit for the structure you will see this:

       typedef struct {
               long flags;     /* marks which fields in this structure are defined */
               int x, y;       /* Obsolete */
               int width, height;      /* Obsolete */

In other words, don't write new code which uses the positions fields x and y in the XSizeHints structure.

The ICCCM says in section 4.1.2.3. WM_NORMAL_HINTS Property on page 23:

To indicate that the size and position of the window (when a transition from the Withdrawn state
occurs) was specified by the user, the client should set the USPosition and USSize flags

In other words, the positional information was meant for transitions from the Withdrawn state, not to move a window around. Hence your app has a peculiar non-standard way of doing something trivial for which more appropriate means have been defined elsewhere.

[DumbHawk]

thank you for this hint.

The Software uses the "motif" framwork. ( Very old ) With a Very old version of QT. ( Both ion the same Application )

I do not know if this can be changed without too much of an afford.

The iceWM Version on the old Client is "<1.2.10>

[gijsbers]

Your initial description mentions two ways the window is moved: "the Window position is controlled by the software." and: "Windows moved too far out of screen are moved to a certain limit position by the software."

This is also what your spy log shows. The lines with "Configure ... Send" show incremental moves, while the line s with WM_NORMAL_HINTS show the coars adjustments. Your software uses two different methods of moving the window. Why the difference? If you would stick with just one you would be fine.

[gijsbers]

It could be that something is missing from the spy log, because the root window is not included. If you look at the icesh man page you'll see it mentions +r for including the root window.

[gijsbers]

1.2.10 is from 2003. 90 releases since.

[DumbHawk]

Like mentioned the Software is very old and combines QT and Motif Frameworks.

Is there a Way to not have the Window blob back into screen by iceWM config ? Another curious thing. Moving the Window out of the Screen to the Left There is no issue. the window is moved to the right the desired amount.

[gijsbers]

There is no such configuration option at the moment. Can you try and see if an older version works for you, like 1.4.2? I could make a fix for the upcoming version, but then I would be helped if you could give me an extended spy log, as I still can't reproduce it.

[DumbHawk]

I will create a testprogramm. Which can reproduce this issue.

Thank you for your support.

[DumbHawk]

Sorry for the late reply but this issue had to wait because of some more pressing issues. I have created a very simple testapp as requested.

This application only consists of a QMainWindow which constructs a QDialog. The Dialog is moved to “1230, 300” using the QT “move” method ( move(1230, 300 ); ) every 4 seconds. You can see on the first move the window is placed wrong. It should be placed to the right and partially out of the screen. If it is already partially out of screen the “PopIN” effect can be observed

The Screen resolution of the Testsetup is 1280x1024 dpi 86 using “xrandr --output eDP-1 --mode 1280x1024 --dpi 86” Running RHEL 8.6 and IceWM 2.9.9-2.el8 and qt-x11-3.3.6

iceWMMoveTestApp.tar.gz

[DumbHawk]

The Spy log for the testapplication captured on the effected system

icespy.txt

[DumbHawk]

For testing I changed the Call to the Xlib within the QT lib From "XMoveResizeWindow" to just "XMoveWindow"

the Popin Effect is gone. And the Dialog is on the desired position.

I am not sure about the implications and side effects this would cause and also if this is an IceWM or QT issue.

[gijsbers]

Looks like icewm is differentiating a resize from a move. Expect that the 3.0.1 release has an antidote for this.

[DumbHawk]

Thank you very much for your help.

[DumbHawk]

I just tested it with the Koji Build https://koji.fedoraproject.org/koji/buildinfo?buildID=2075074

The issue seems to be resolved. The Window is not jumping into the screen anymore.

Thank you