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.

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

Problems with attachment mime icons in read window #653

ElenaXX opened this issue Feb 22, 2017 · 2 comments

Problems with attachment mime icons in read window #653

ElenaXX opened this issue Feb 22, 2017 · 2 comments


Copy link

ElenaXX commented Feb 22, 2017

YAM 2.9p1 + MorphOS 3.9 and Ambient (but this problem affected older YAM versions too, also with MorphOS 1.4.5 and Amiga Workbench)
When reading a mail with attachments, at the bottom of the read window they are displayed as ugly 4 colors icons saying "Ambient PNG", even if I have set up my Ambient with fully working mime types and default icons.
But the annoying thing is another one: everytime I pass with the mouse pointer over that area (this happens with some randomness) sometimes the mouse pointer "attracts" one of those icons, as though I were supposed to drag them somewhere, but WITHOUT me pressing the LMB ! I have to press the RMB to get rid of the sticky icon.
To me, it looks like it's a strange behaviour or interference with handling events caused by the balancing bar situated between the text area and the attachments area: the bar gets activated everytime I pass over with the mouse (no need to click), and when that happens, 9 out of 10 times I get some attachment icon stuck to the pointer.
Also, when I double click on one of said icons to display the attachment, often I see the screen flashing (DisplayBeep).

Keep in mind that I don't feel responsible in case the bug I'm reporting is already known: I had posted this topic in the forum but nobody cared to reply, so I now feel legitimated to report the bug here. Thanks.

Copy link

YAM uses the function GetIconTags() of icon.library V44+ to obtain a suitable icon. If that fails YAM eventually falls back to using GetDefDiskObject() to obtain the default "project" icon. If Ambient's icon.library fails to return a colorful icon like it displays itself then this is no bug of YAM, but a bug of Ambient.

You can check yourself which of YAM's attempts to obtain an icon finally succeeds by running the debug version of YAM and creating a "GUI" log.

Details about YAM's debug version can be found in the FAQ.

Regarding the "automatic" dragging, I never experienced something like this myself. All this stuff is handled by MUI internally. YAM does absolutely nothing itself in this respect. All it does is acting on the final drop action, which of course might cause a DisplayBeep() in case something did not work out successfully. Your description very much sounds like a faulty mouse.

Copy link

ElenaXX commented Feb 23, 2017

Thanks for replying.
As for the icon issue, unfortunately I have no time to investigate on the root right now, but I think I shall then report this fact to Ambient developers (a waste of time though, cos Ambient development seems stopped since many years and it's litereally full of never fixed bugs).
As for the auto-dragging, LOL, forget about my mouse being faulty, sorry :) Rather, I think I now can replicate the behaviour a bit better... To be more precise, this strange thing happens ONLY AFTER I double click on an attachment icon to display it (with the default configured viewer, MultiView, but I checked and the same happens if I configure MysticView). So, I double click on the icon, MultiView is opened. At this point, if I return with the mouse pointer in the Yam read window and move it over any icon, voilà: I get it attached. My personal suspect is, when one double clicks on an icon, the second mouse click event is not replied by ReplyMsg to Intuition (or perhaps the LMB UP event is not handled properly ?), therefore when I return to that window, Yam (or MUI ?) thinks the button is still pressed, hence it activates the dragging. But perhaps this is MUI fault, not YAM's (I have no skills with MUI developing, so I can't predict the exact boundary between app's fault and MUI's fault)
What I found strange is that nobody apparently ever noticed and/or reported these issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants