Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

restart behavior is incorrect #190

Closed
gijsbers opened this issue Oct 22, 2017 · 13 comments
Closed

restart behavior is incorrect #190

gijsbers opened this issue Oct 22, 2017 · 13 comments
Labels
bug The issue exposes a bug.
Milestone
1.4.3

Comments

@gijsbers
Copy link
Collaborator

When IceWM restarts it should not exhibit different behavior then if IceWM is started before any applications.

On restart focus may change. Assume several running apps, one has focus, and a hotkey to restart IceWM. When pressing the hotkey IceWM restarts and focus shifts to a different app. Logical would be if focus remained with the same app.

When the tilda terminal is visible and active it is normally not shown on taskbar.
It has properties:

_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL

However, after IceWM restarts tilda is shown on taskbar. If tilda option Display on all workspaces is enabled then taskbar pager preview shows tilda on all workspaces.
This seems incorrect and is ugly.
@bbidulock
Copy link
Owner

If it wants to not be displayed on the pager when sticky, it needs to set _NET_WM_STATE_SKIP_PAGER, or use a window type other than "Normal", so the later behaviour is correct.

Appearing on the task bar seems to be because Ice is not reading _NET_WM_STATE when first managing a window.

@bbidulock
Copy link
Owner

No, Ice is reading _NET_WM_STATE when first managing a window. Dump those settings before and after the restart and see if there are any changes.

bbidulock added a commit that referenced this issue Oct 22, 2017
@bbidulock
try to address #190
22f29da 
- Ice was always loading _WIN_STATE after _NET_WM_STATE, which is
  incorrect.  It should only attempt to load _WIN_STATE if the
  _NET_WM_STATE does not exist.

- Ice was always setting the iconic state of the window to that
  requested for initial mapping.  This is not true when restarting
  and so it is now only checked when not starting.
@bbidulock
Copy link
Owner

That might address it. It was loading _WIN_STATE after _NET_WM_STATE when initially managing a window.

@bbidulock bbidulock added the bug The issue exposes a bug. label Oct 23, 2017
@gijsbers
Copy link
Collaborator Author

It is a bit better. After restart a mapped tilda is now only shown in the workspace pager preview on the workspace it was initially mapped on. This seems still incorrect as normally when I map tilda it is not show on the taskbar at all.

If I map tilda it has:

_WIN_STATE(CARDINAL) = 1, 1023
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR

After restart this becomes:

_WIN_STATE(CARDINAL) = 0, 1023
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR

Even though I have enabled Display on all workspaces tilda is only mapped on one.

Focus can still shift to a different app when I restart.

bbidulock added a commit that referenced this issue Oct 23, 2017
@bbidulock
correct occupy all workspaces for #190
e735002 
- IceWM was using the old WIN_STATE_STICKY incorrectly.  A sticky
  window is one that sticks to the virtual desktop, not a window
  that appears on all workspaces.  To acheive that, the workspace
  or desktop must be set to 0xFFFFFFFF.  This commit corrects the
  behaviour of _WIN_WORKSPACE, _NET_WM_DESKTOP, _WIN_STATE flag
  WIN_STATE_STICK, atom _NET_WM_STATE atom _NET_WM_STATE_STICKY.

  This should correct that part of #190.  Because the state was
  not being stored correctly, it was not being retrieved correctly
  on restart either.
@bbidulock
Copy link
Owner

Ice makes no effort to leave focus where it was before startup or on restart. The latest commit fixes losing the occupy-all-workspaces state on restart.

bbidulock added a commit that referenced this issue Oct 23, 2017
@bbidulock
remainder of fix for #190 - restore focus
0921f39 
- Uses the _NET_WM_STATE_FOCUSED state on a window to restore focused
  window on restart.  This commit also does not hide minimized windows
  on restart.
@bbidulock
Copy link
Owner

Focus is restored correctly to the last focused window on restart now.

@gijsbers
Copy link
Collaborator Author

Focus is restored correctly if it was given by clicking. Not if it was given by merely moving the mouse.

Tilda Display on all workspaces works, but after restart it is shown on all pager preview workspace buttons.

If focus was with tilda and I switch to a new workspace then tilda loses focus. If that workspace was empty (apart from tilda) then tilda still doesn't have focus and nothing has.

@bbidulock
Copy link
Owner

Show the values of _NET_WM_STATE before and after restart (with focus by clicking, and focus by moving). Also, does creating or destroying a window change the pager just after restart?

On changing workspaces, IceWM attempts to focus windows on a workspace that do not occupy all workspaces before those that do. That was intentional. Could maybe change to check for dock or desktop window type.

@gijsbers
Copy link
Collaborator Author

left to right moving

$ ./x
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) =

left to right clicking

$ ./x
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED

right to left moving

$ ./x
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = 
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED

right to left clicking

$ ./x
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) = 
xprop -id 0x1800007
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY
xprop -id 0x1c00009
_NET_WM_STATE(ATOM) =

@gijsbers
Copy link
Collaborator Author

On changing workspaces, maybe IceWM attempts to assign focus to the taskbar with a WM_TAKE_FOCUS, but the taskbar never reacts to that. The focusable-non-focusing taskbar thwarts this design.

@bbidulock
Copy link
Owner

Are you sure that is the current version? What is setting _NET_WM_STATE_STICKY?

@gijsbers
Copy link
Collaborator Author

yes. tilda. easy to check:

git clone https://github.com/lanoxx/tilda.git
grep -i -r stick tilda

@gijsbers
Copy link
Collaborator Author

ATM minimized windows are restored on icewm restart. Is annoying when after restart one has to minimize all these windows again. Problems started with commit 22f29da. That made minimized windows become hidden as well. This was fixed later, but minimization is not yet preserved.

@gijsbers gijsbers mentioned this issue Feb 4, 2018
Closed
This was referenced Mar 5, 2018
Closed
Closed
@gijsbers gijsbers mentioned this issue Mar 14, 2018
Closed
gijsbers added a commit that referenced this issue Mar 15, 2018
@gijsbers
On restart windows with _NET_WM_STATE_HIDDEN should set WinStateMinim…
5a23b1a 
…ized to keep them minimized for issues #190, #226, #241 and #254, otherwise they are restored, which is very annoying.
@bbidulock bbidulock added this to the 1.4.3 milestone Jun 5, 2018
@gijsbers gijsbers closed this as completed Sep 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug The issue exposes a bug.
Projects
None yet
Milestone
1.4.3
Development

No branches or pull requests
2 participants
@gijsbers @bbidulock