Hi Cristofaro,
Thank you for the report, I took the time to read it and thank you for the
explanation. You did exactly what I
wanted you to do and you gave me the information I needed.
I appreciate you taking the time to write this report, it is a useful
information that I'm sure will benefit us
some other day.
I'm forwarding your report to the mailing list in order for it to be archived.
Thanks again,
KaKaRoTo
----- Forwarded message from Cristofaro Del Prete <[EMAIL PROTECTED]> -----
From: Cristofaro Del Prete <[EMAIL PROTECTED]>
To: Youness Alaoui <[EMAIL PROTECTED]>
Subject: Tray icon fix - the report
X-Enigmail-Version: 0.94.0.0
Hi... I've looked at that trayicon stuff, and I've written this report.
The problem:
If you activated boss mode while using the tray icon, the tray icon
simply disappeared, and never come back, except for an empty zero-sized
window.
The expected behavior:
The tray icon should have changed to an icon of two keys, and should
have changed back to the proper amsn icon when exiting boss mode.
What caused the problem:
the newti procedure is a C function exported from the libtray library
(utils/linux/traydock). The function takes as parameters the path of a
window, a tooltip text, an image and a command.
Example:
newti $icon -tooltip $text -pixmap icon_image_res -command
"::trayicon_callback icon_image icon_image_res"
Should be noticed that icon_image_res is an empty image; the real icon
is stored in icon_image.
The function calls back the command specified, adding the height and the
width that the tray icon should have, and the trayicon_callback
procedure resizes the image to that height and width.
I think that this operation could (and should) be done inside the newti
function
Looking in the code of the function, looks like a Tk window is created
at the specified path ($icon) and then, depending on the window manager,
a request to "traydock" that window is issued.
Now, what has this to do with the boss mode?
When activating boss mode, all windows are withdrawn, except those who
have the override-redirect flag set to true.
The windows used to create the tray icon haven't this flag set, so they
are withdrawn. But this is very bad, as they're not supposed to be
withdrawn, and when exiting boss mode they are unwithdrawn as normal window.
The solution is to set the override-redirect flag to the $icon window.
This is also the most logical thing, as $icon is not a true window, and
then should not be managed by the window manager.
What has the .trayiconwin to do with all of this?
My bad. In the beginning, I thought that the .trayiconwin was a
"container" in which the icons were drawed, so I thought that the icon
windows should be its children. I thought of this because the popup meno
we have when we right-click on the tray icon is "attached" to .trayiconwin.
The truth is that .trayiconwin has been created to work around a Windows
bug (related to the popup not unposting). For some reason, this
workaround has not been made inside the "if { [WinDock] }", but outside;
then the workaround is active also under linux, where .trayiconwin
shouldn't even exist. In fact, all the other occurrences of .trayiconwin
are in windows-only code.
Then, in addition to the change I described above, I put the
.trayiconwin inside that if, removing in this way from the linux code,
and resumed the old code (which was commented) that was used before of
the workaround.
Whew! It has been easier to fix the issue than writing all of this!
I hope you will have the strenght to read it :D
Bye
----- End forwarded message -----
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
