Closed GoogleCodeExporter closed 8 years ago
Below is the output of xprop on the detached skype icon. It is interesting
that wmii still sees the detached icon as part of witray (wmiir read
/client/.../props says "witray:witray:witray" whereas xprop says
WM_CLASS(STRING) = "skype", "Skype").
_NET_WM_ICON_NAME(UTF8_STRING) =
WM_ICON_NAME(STRING) =
_NET_WM_DESKTOP(CARDINAL) = 3
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_WMII_TAGS(UTF8_STRING) = "work"
_NET_FRAME_EXTENTS(CARDINAL) = 5, 5, 21, 5
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_FULLSCREEN
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 39992485
_NET_WM_USER_TIME(CARDINAL) = 7637165
_NET_WM_ICON(CARDINAL) = Icon (48 x 48):
░░░░
░░░░░░░░░░░░░░
░░░░░░░ ░ ░ ░░░░░░░
░░░░░ ░░░░░
░░░░ ░░░░
░░░ ░░░
░░░░ ░░░
░░░░ ░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░
░░░░░░░░░░░░░ ░░░░░░░░░░░░░
░░░░░░░░░░░░ ░░░░░░░░░░░░
░░░░░░░░░░░░ ░░░░░░░░░░░░
░░░░░░░░░░░ ░░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░░░ ░░░░░░░░░░░
░░░░░░░░░░▒ ░░░░░░░░░░░░░░ ▒░░░░░░░░░░
░░░░░░░░░░░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░░░
░░░░░░░░░░░ ░░░░░░░░░░░
░░░░░░░░░░░░ ░░░░░░░░░░░░
░░░░░░░░░░░░░ ░░░░░░░░░░░░░
░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░
░░░░░░░░
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0xf6,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3e, 0xf7, 0x10, 0x0, 0x0, 0x0
_NET_WM_NAME(UTF8_STRING) = "Mystery Mocks - Skype™ Chat"
WM_CLIENT_LEADER(WINDOW): window id # 0x260000b
_NET_WM_PID(CARDINAL) = 3419
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING,
_NET_WM_SYNC_REQUEST
WM_NAME(COMPOUND_TEXT) = "Mystery Mocks - Skype™ Chat"
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLASS(STRING) = "skype", "Skype"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x2623dc5
window id # of group leader: 0x260000b
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 1410, 853
program specified location: 1410, 853
user specified size: 500 by 300
program specified size: 500 by 300
program specified minimum size: 500 by 300
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "ratham"
WM_COMMAND(STRING) = { "/usr/bin/skype" }
Original comment by sunaku
on 23 Feb 2011 at 7:25
Also, I run skype under a different (less priviledged) user account and allow
it to display on my X session via `xhost +local:` command. Perhaps witray is
treating the skype tray icon differently because it comes from a foreign user?
Original comment by sunaku
on 23 Feb 2011 at 7:28
Hmm, I may have caused this bug due to a misconfiguration.
My /rules file previously had:
/^witray:witray:witray$/ -> !
I just updated it to the new format:
/^witray:witray:witray$/ tags=/./
I'll see if the bug still occurs tomorrow.
Original comment by sunaku
on 24 Feb 2011 at 8:35
The bug still occurs. Changing my /rules to use "tags=/./" did not help.
Original comment by sunaku
on 24 Feb 2011 at 10:59
Did you try without any rules for witray? I don't understand why you need this
rule.
Original comment by skwi...@googlemail.com
on 25 Feb 2011 at 8:11
Thanks for your suggestion. I'm now trying witray without a rule; will report
back if the bug occurs.
Original comment by sunaku
on 25 Feb 2011 at 8:17
I just saw a similar thing with Opera's tray icon. When trying to respawn
wmiirc (see current thread on the mailing list), the icon went to the upper
left of the managed area and stayed there even after killing witray.
Original comment by skwi...@googlemail.com
on 25 Feb 2011 at 9:31
The bug still occurs with skype after I removed the witray rule. I concur with
comment 7.
Original comment by sunaku
on 25 Feb 2011 at 7:47
Original comment by sunaku
on 19 Sep 2011 at 8:25
Comment #7 on issue 228 by skwi...@googlemail.com
> I just saw a similar thing with Opera's tray icon. When trying to respawn
> wmiirc (see current thread on the mailing list), the icon went to the upper
> left of the managed area and stayed there even after killing witray.
Respawing wmiirc launches a new witray. If Opera doesn't support
attaching to tray managers spawned after it launches then it's
likely a Qt bug (Opera and Skype both use Qt to my knowledge).
Original comment by maglion...@gmail.com
on 19 Sep 2011 at 9:09
Thanks, that makes sense, and gives me a workaround to the problem:
pgrep witray || witray &
Only run witray upon wmiirc respawn if it's not already running.
Closing this issue.
Original comment by sunaku
on 19 Sep 2011 at 10:50
The odd thing about this is that Skype seems to work fine for me
if you replace witray by launching a new instance, but not if
you forcibly kill the old one first.
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 12:35
Nevermind. Seems pretty hit or miss either way.
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 12:36
I found a problem with my workaround:
When my screen resolution changes (switching from laptop screen to external
monitor), the wmii bar will not expand to fit the larger resolution unless I
restart witray.
And upon restarting witray, I lose the skype icon just like before. :-(
Original comment by sunaku
on 20 Sep 2011 at 3:16
Comment #14 on issue 228 by sun...@gmail.com
> And upon restarting witray, I lose the skype icon just like before. :-(
Have you tried revision b3911f39ceda?
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 3:22
Yes, that revision helps a little bit, but doesn't solve the problem entirely:
1. Start witray.
2. Start skype and wait for its icon to appear in witray at the right-most end.
3. Run witray. Observe that skype icon is still attached, but its position
moves from the right-most end to the left-most end of witray.
4. Run witray again. Observe that skype icon is detached.
5. Repeat step 4 a few times; no change in observation.
Thanks.
Original comment by sunaku
on 20 Sep 2011 at 4:57
Well, the order that tray icons appear in is undefined.
Unfortunately, it looks like if another tray manager is not
available the instant the old one dies, Qt destroys its old
window, creates a new one, and completely breaks its XEmbed
implementation in the process.
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 5:34
Ah. It appears that I have this backwards and Qt's system tray
implementation is more broken than I thought.
1) It doesn't actually implement XEmbed at all, it just relies
on system tray managers not caring. My last hack worked
around this bug.
2) If a new system tray owns the selection when the old one
dies, it attaches to the new one, but never selects
StructureNotify events from it. It only decides that the old
system tray is dead when it receives a destroy notify event,
which it only gets if it's selected the StructureNotify mask.
It completely ignores MANAGER messages if it doesn't think
the old system tray has died, so if a new system tray is
running when the old one dies, it'll associate with it, but
never disassociate from it.
*So* if you kill the old witray before launching the new one,
you're golden... I'll see if I can work out a hack for this.
Ugh.
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 6:27
This issue was closed by revision 746394dc7615.
Original comment by maglion...@gmail.com
on 20 Sep 2011 at 6:50
Hurray, it works! :) Thank you.
Original comment by sunaku
on 20 Sep 2011 at 5:44
Original issue reported on code.google.com by
sunaku
on 23 Feb 2011 at 5:14