Improve tray virtualization

[marmarek]

Reported by smoku on 25 Mar 2011 12:04 UTC
After docking nm-applet the tray window is black and inactive.

Migrated-From: https://wiki.qubes-os.org/ticket/134

[marmarek]

Modified by smoku on 25 Mar 2011 12:04 UTC

[marmarek]

Modified by smoku on 25 Mar 2011 12:04 UTC

[marmarek]

Modified by smoku on 28 Mar 2011 12:50 UTC

[marmarek]

Modified by smoku on 28 Mar 2011 12:50 UTC

[marmarek]

Modified by rafal on 31 Mar 2011 11:01 UTC

[marmarek]

Modified by rafal on 31 Mar 2011 11:01 UTC

[marmarek]

Comment by joanna on 31 Mar 2011 14:31 UTC
FWIW, it works without problem on netvm based on F13 template (the one I recently published). It doesn't however work on netvm based on the F14 template (again the one I published this morning)... Apparently this is nm-applet-specific thing.

A note that I'm running nm-applet as root (on F13). Perhaps if we could get it working as user it would also work in F14 (perhaps it refuses to show the icon because I start it as root?). Also, ability to run it as user might be closely related to #138.

[marmarek]

Comment by joanna on 31 Mar 2011 14:31 UTC
FWIW, it works without problem on netvm based on F13 template (the one I recently published). It doesn't however work on netvm based on the F14 template (again the one I published this morning)... Apparently this is nm-applet-specific thing.

A note that I'm running nm-applet as root (on F13). Perhaps if we could get it working as user it would also work in F14 (perhaps it refuses to show the icon because I start it as root?). Also, ability to run it as user might be closely related to #138.

[marmarek]

Comment by rafal on 31 Mar 2011 14:47 UTC
It is somehow nm-applet-specific, as other F14 applications work fine.
Even worse, once in a while F14 nm-applet just works.
Running as root is irrelevant to the display problems.

The current working hypothesis is that the problem is related to

1. the fact that in dom0 the window(s) is reparented (to plasma applet hosting DOCK), in appvm it is reparented to root. Which creates some view incoherency.
   The process_xevent_configure() has some hooks to deal with it; handle_configure_from_vm() does not. Adding hooks to the latter improves situation, e.g. mouse clicks produce effects, but the menu windows appear in wrong place (but otherwise work).

2. nm-applet creates multiple windows, one parented by other

3. the problem seems to be triggered by nm-applet resizing one of its window immediately after docking, which creates a race condition. Probably if it happens BEFORE XConfigureEvent to the relevant window arrives in dom0, all is fine; if AFTER, there is a problem.

It is a serious headache. Some solution would be probably to create "ghost" window in AppVM, mirroring the location of the plasma applet in dom0, and reparent applets in AppVM to it, instead of to root. I will try it; but there might be issues when the plasma applet in dom0 is moved/resized. Sigh.

[marmarek]

Comment by rafal on 31 Mar 2011 14:47 UTC
It is somehow nm-applet-specific, as other F14 applications work fine.
Even worse, once in a while F14 nm-applet just works.
Running as root is irrelevant to the display problems.

The current working hypothesis is that the problem is related to

1. the fact that in dom0 the window(s) is reparented (to plasma applet hosting DOCK), in appvm it is reparented to root. Which creates some view incoherency.
   The process_xevent_configure() has some hooks to deal with it; handle_configure_from_vm() does not. Adding hooks to the latter improves situation, e.g. mouse clicks produce effects, but the menu windows appear in wrong place (but otherwise work).

2. nm-applet creates multiple windows, one parented by other

3. the problem seems to be triggered by nm-applet resizing one of its window immediately after docking, which creates a race condition. Probably if it happens BEFORE XConfigureEvent to the relevant window arrives in dom0, all is fine; if AFTER, there is a problem.

It is a serious headache. Some solution would be probably to create "ghost" window in AppVM, mirroring the location of the plasma applet in dom0, and reparent applets in AppVM to it, instead of to root. I will try it; but there might be issues when the plasma applet in dom0 is moved/resized. Sigh.

[marmarek]

Modified by rafal on 1 Apr 2011 10:32 UTC

[marmarek]

Modified by rafal on 1 Apr 2011 10:32 UTC

[marmarek]

Comment by rafal on 4 Apr 2011 09:14 UTC
Current workaround, implemented in
http://git.qubes-os.org/?p=rafal/gui.git;a=commit;h=63942ae4cb87c48df5d4fa9d1d8e7efbee7305a9
(spring-merge branch) and a previous commit there, is based on:

1. not allowing a docked window to resize itself
2. recalculating the coordinates of a docked window in VM upon each configure and motion event, to compensate for the fact that a window is reparented in dom0, and not in vm.

Generic framework for handling reparenting would be nice, but is nontrivial (currently we check window parent upon XCreateWindow only).

[marmarek]

Comment by rafal on 4 Apr 2011 09:14 UTC
Current workaround, implemented in
http://git.qubes-os.org/?p=rafal/gui.git;a=commit;h=63942ae4cb87c48df5d4fa9d1d8e7efbee7305a9
(spring-merge branch) and a previous commit there, is based on:

1. not allowing a docked window to resize itself
2. recalculating the coordinates of a docked window in VM upon each configure and motion event, to compensate for the fact that a window is reparented in dom0, and not in vm.

Generic framework for handling reparenting would be nice, but is nontrivial (currently we check window parent upon XCreateWindow only).

[marmarek]

Comment by joanna on 4 Apr 2011 22:32 UTC
Now, the icon for Getting Things Gnome (GTG) is displayed incorrectly (it's too small). Interestingly it worked fine with the previous version (1.2.1).

[marmarek]

Comment by joanna on 4 Apr 2011 22:32 UTC
Now, the icon for Getting Things Gnome (GTG) is displayed incorrectly (it's too small). Interestingly it worked fine with the previous version (1.2.1).

[marmarek]

Comment by joanna on 4 Apr 2011 22:33 UTC
To install GTG (on F14):

yum install gtg

[marmarek]

Comment by joanna on 4 Apr 2011 22:33 UTC
To install GTG (on F14):

yum install gtg

[marmarek]

Comment by joanna on 4 Apr 2011 23:15 UTC
Actually for most other Apps it works pretty good, and even for GTG most of the time it works fine. So, I'm moving this to Beta2.

[marmarek]

Comment by joanna on 4 Apr 2011 23:15 UTC
Actually for most other Apps it works pretty good, and even for GTG most of the time it works fine. So, I'm moving this to Beta2.

[marmarek]

Comment by joanna on 11 Apr 2011 12:08 UTC
Ok, the problem that still remains is that the tray icon is somehow displayed incorrectly immediately after the app start. Once the app updates the tray icon (e.g. in response to use hovering mouse courser over the icon, or when some other tray icons appear in the tray) then the icon is fixed, and displayed correctly since then.

Example of apps that display incorrect icons at the beginning:

1. nm-applet
2. gtg

[marmarek]

Comment by joanna on 11 Apr 2011 12:08 UTC
Ok, the problem that still remains is that the tray icon is somehow displayed incorrectly immediately after the app start. Once the app updates the tray icon (e.g. in response to use hovering mouse courser over the icon, or when some other tray icons appear in the tray) then the icon is fixed, and displayed correctly since then.

Example of apps that display incorrect icons at the beginning:

1. nm-applet
2. gtg

[marmarek]

Modified by joanna on 11 Apr 2011 12:10 UTC

[marmarek]

Modified by joanna on 11 Apr 2011 12:10 UTC

[marmarek]

Modified by smoku on 12 Apr 2011 12:01 UTC

[marmarek]

Modified by smoku on 12 Apr 2011 12:01 UTC

[marmarek]

Comment by rafal on 12 Apr 2011 15:22 UTC
It looks like in the problem case, there is never a MSG_CONFIGURE sent, neither from VM, nor from xside. I can reproduce the problem by running NetworkManeger stop/start in netvm.
Still, not sure why then a problem exists. If no better idea arises, the following workaround:
After docking a window, send configure request to vmside
should help.

[marmarek]

Comment by rafal on 12 Apr 2011 15:22 UTC
It looks like in the problem case, there is never a MSG_CONFIGURE sent, neither from VM, nor from xside. I can reproduce the problem by running NetworkManeger stop/start in netvm.
Still, not sure why then a problem exists. If no better idea arises, the following workaround:
After docking a window, send configure request to vmside
should help.

[marmarek]

Comment by smoku on 20 Apr 2011 23:07 UTC
Fixed in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=299d850d1dbd9d5d8239ab56a2802dd4527aa10f
It was a nasty issue in clipping mask generation. See the commit message for details.

I also modified a bit trayicon position fixing in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=4aa12afeaab2a3d97ffefb53709fe12730ff50eb
Checking it every mouse move seems like an overkill.

[marmarek]

Comment by smoku on 20 Apr 2011 23:07 UTC
Fixed in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=299d850d1dbd9d5d8239ab56a2802dd4527aa10f
It was a nasty issue in clipping mask generation. See the commit message for details.

I also modified a bit trayicon position fixing in http://git.qubes-os.org/?p=smoku/gui;a=commit;h=4aa12afeaab2a3d97ffefb53709fe12730ff50eb
Checking it every mouse move seems like an overkill.