|Version 10 (modified by damato, 19 months ago) (diff)|
- User Interface
- Why does the "Colored text" gadget in the Read configuration looks wrong …
- Menu shortcuts don't work while context sensitive menus are enabled, why?
- The gauge in the mail transfer window looks wrong, why?
- Why is keyboard selection of multiple mails not working?
- I use AmigaOS 3.9 and activated the AISS theme. Unfortunately some of the …
- The graphical attachment list is displayed truncated and does not reflect …
- Why is the mail preselection/transfer window sometimes active by default …
- The menu of the write window contains strange "ramiga X", "ramiga C" …
- I changed the shortcut definition of TextEditor.mcc to use a non-default …
- The attachment icon sometimes suddenly disappears in main mail listview, …
- When I use the up/down arrows keys, the scrollbar of the main mail list …
- Redrawing of the folder listtree is so slow that I can see every single …
- Can I permanently save the position and size of a window?
- Why are some columns of the mail listview always resizing automatically?
- The toolbar buttons and other graphics are displayed in wrong colors. Why?
- The toolbar buttons don't fit in the window, the rightmost buttons can't …
- The layout of the prefs window doesn't adapt properly when reducing its …
- Language Support
- Mail reading
Why does the "Colored text" gadget in the Read configuration looks wrong the first time I open this sheet?
This is a bug in MUI 3.8 and can't unfortunately be worked around in any form. However, it is already fixed in MUI versions >= 3.9. So please update your MUI installation, if possible.
Menu shortcuts don't work while context sensitive menus are enabled, why?
Unfortunatly, the context menus for the folder & message lists may get in your way and prevent you from using the usual menu item shortcuts unless you move the pointer outside the list. Unfortunately this is a bug in MUI <=3.8, which can only worked around by disabling the context menus themselves or upgrading MUI to at least 3.9.
The gauge in the mail transfer window looks wrong, why?
Due to a bug in MUI 3.8, the gauge in the mail transfer window may "overflow" its container when representing very high values, typically around 8 MB and beyond. This bug is harmless, but an updated MUI (3.9 or better) is necessary to properly address this problem. No such update are available for m68k Amigas at the time of writing this article.
Why is keyboard selection of multiple mails not working?
According to the documentation and the configuration GUI of the NList.mcc class (which is used in YAM for displaying the mail list) one should be able to select multiple entries in a Listview by using the CTRL+Up/Down keys. However, when I use these keys the listview scrolls to the beginning or end rather than allowing to select multiple entries. The reason for this problem is, that the default keybindings of NList.mcc and the default keybindings of MUI itself clash. So when you use CTRL+Up/Down the default MUI keybindings will have preference over the NList settings and thus won't trigger the correct functions in NList itself. The solution is to either upgrade to NList release 0.108 or later as the default keybinding have been changed to use ALT+Up/Down rather than CTRL. Just make sure that you reset the keybinding settings in the MUI configuration pane of the NList classes after you have installed 0.108+ of the NList classes. Another solution (for older NList versions) would be to manually change the keybinding settings in the MUI configuration to use the ALT key rather than CTRL key (see all the "Select XXX" entries in the example screenshot below).
I use AmigaOS 3.9 and activated the AISS theme. Unfortunately some of the icons display an ugly black background. Why?
The AISS icons are PNG icons which use alpha channels. With AmigaOS 3.9 the transparency can not be displayed correctly because of some incompatibilities between the datatypes.library.
The graphical attachment list is displayed truncated and does not reflect all available attachments. Anything to prevent that?
For mails with lots of single attachments, the graphical display of attachments in a read window might be displayed truncated. This happens in case the attachment list object cannot enlarge itself to the required size (e.g. because the window is to small). Unfortunately it is even not possible to display/use a scrollbar for those cases due to technical reasons.
But as the attachment list is virtual group object you should be able to use the virtual scrolling capabilities of MUI for that case. Please consult the MUI configuration for setting the scroll action hotkey/mouse button. But per default, MUI should allow you to hold down the middle mouse button while moving your mouse. This should then allow you to scroll the attachment list and view the other attachments that are normally hided. Another way for displaying all attachments of a mail is, of course to use the respective toolbar buttons (Display, Print, etc.) which will present you a full list of the attachments.
Why is the mail preselection/transfer window sometimes active by default and sometimes not?
YAM can be configured to show the preselection/transfer window for downloading new mails only if certain conditions are met, for example always, never or only if very large mails are to be downloaded. Since mails can be fetched in the background while you continue your work with YAM it would be very inconvenient if the preselection window would steal the focus from the currently active window (i.e. a write window to compose a new mail). Just imagine that you press "C" in that very moment the preselection window opens. This would immediately cancel the transfer, even if you were just going to type in the word "Commodore"...
To avoid such unwanted abortions YAM will open the preselection/transfer window in inactive state for automatically initiated mail transfers (i.e. timed mail fetch or mail transfers initiated by an ARexx script). For all user initiated transfers (import, export, get/send mail) the window will be activated, because this is an action that was explicitly triggered by the user and not some automechanism triggered by YAM itself.
The menu of the write window contains strange "ramiga X", "ramiga C" shortcut definitions. Why is the typical Amiga image not used instead?
The reason for this shortage has already been adressed in version 2.5 of YAM. However, please find explainations for earlier versions and why there the menuitems couldn't use the typical 'Amiga' images to signal the shortcut: The point is, that the configuration of these shortcuts was up to the user. In fact, TextEditor.mcc provided a configuration management where a user could specify himself which key shortcuts he want to use. The "ramiga X" display was just a placeholder for that - it even was't a real shortcut definition. It should have only pointed out which default key combinations are normally used for these operations. So it was more cosmetical. But as said, in YAM 2.5 the behaviour changed and now the typical Amiga image should be used as expected.
I changed the shortcut definition of TextEditor.mcc to use a non-default shortcut for the Cut&Paste operations. However, YAM still shows e.g. "Amiga+C" in the window.
Since YAM 2.5, the behaviour for the shortcuts of the default Edit actions like Copy&Paste have been changed. This means, that like explained in the previous FAQ item, YAM now always uses the standard shortcuts according to common StlyeGuides. E.g. a Copy operation will always be mapped to "Amiga+C" whereas the Paste operation will be mapped to "Amiga+V" no matter what you have configured in the TextEditor.mcc configuration itself.
For YAM versions prior to 2.5, the situation is slightly different. There, the shortcut which is configured in TextEditor.mcc will always be used and the shown e.g. "ramiga X" placeholder in a window menu is just to show the default if you have TextEditor.mcc set to the default.
The attachment icon sometimes suddenly disappears in main mail listview, why?
In the main mail listview where all your mails in a folder are listed, the Attachment status icon (normally a paper-clip icon) is sometimes shown, but suddenly disappears as soon as you click on that mail for viewing its content. Even if that may look a bit strange and may lead to the impression that attachments are being lost when viewing the mail, this behaviour is normal and correct.
The reason why this is happening is that unfortunately some broken (old) mail clients tend to send out emails where the main content-type is set to "multipart/mixed" or "multipart/related" even if that email just contains one main mail text part without a real attachment. This is clearly incorrect according to the RFCs and can be considered a bug in those email programs. However, the reason why YAM is first showing the attachment status icon is that it just analyzes the main mail header due to performance reasons and as soon as you click on the message a depper (more time consuming) analyze is performed where it automatically recognizes that the mail doesn't really contain any binary or text attachment, but just the main normal mail text.
So the behaviour of YAM is fully correct and in line what the RFCs suggests.
When I use the up/down arrows keys, the scrollbar of the main mail list moves instead of the highlighted mail to be changed. Why?
The cause for this behaviour might be, that you have selected the main mail list via the "Tab" key gadget activation feature of MUI. MUI has a so-called CycleChain feature which allows to cycle through all existing gadgets in a window via the Tab key. In such a case, the main mail list of YAM can be activated via a numerous amount of Tab-key uses.
And as the NList-based main mail list changes it behaviour when it is directly activated via the CycleChain, this is the reason why the scrollbar scrolls when you use the up/down arrows. If an NList class is activated in such a way it will scroll down instead of changing the selection.
However, there is an easy way of solving such a situation. You just have to press "Ctrl+Tab" to signal MUI to unselect all currently active gadget and as such you will find yourself back being able to change the selection in the mail list via the Up/Down arrow keys.
Redrawing of the folder listtree is so slow that I can see every single folder getting redrawn separately. Why?
The reason for the problem you are facing in YAM is, that YAM uses the NListtree.mcc class for rendering the folder list. This class is a subclass of the NList classes and highly depends on the internals of the NList.mcc class itself.
As a matter of fact, the NListtree class is known to be somewhat unoptimized in the fields of redrawing entries. Somehow it seems to massivly redraw items if there is any other window in front of the list it wants to redraw. So, this is a known issue of the NListtree class and will hopefully be adressed in one of the future versions of NListtree.mcc itself.
However, you can perfectly try to avoid that slow redrawing situation by making sure that no other window is in front of the folder listtree in YAM as soon as it requires redrawing.
Can I permanently save the position and size of a window?
Yes, via the normal MUI 'snapshot' feature....
...start the MUI settings interface by selecting 'Settings/MUI'. Select the 'Windows' section and make sure the third of the little system gadget buttons there is activated. After saving the settings every window will have an additional system gadget in the upper right corner. One click on this gadget will snapshot the actual size and position of the window for future sessions. This is a general MUI feature and if you use it on the YAM window you should be able to "snapshot" the window size of YAM permanently.
Why are some columns of the mail listview always resizing automatically?
In fact, this behaviour is very common for NList-based listviews. The 'problem' is, that NList is per default automatically adjusting the size of each column depending on their content width. So if you have a mail with e.g. very long subject lines or if the status column contains a changing amount of status icons, it may happen that NList automatically decided to resize the columns automatically.
While this can be very annoying during normal work, it can also proof quite usefull in some cases. However, there is also the possibility to force NList not to automatically resize a column. For this to happen, you have to drag the vertical separator to the desired size (you actually have to drag it at all) and use the MUI 'snapshot' feature you can normally access via one of the top-right border buttons in the YAM main window.
The toolbar buttons and other graphics are displayed in wrong colors. Why?
This usually happens due to a bug in the 'ilbm.datatype' and only happens if YAM is running on a hicolor or truecolor screen. An update of the ILBM.datatype can be found on Aminet.
The toolbar buttons don't fit in the window, the rightmost buttons can't be accessed. How can I fix this?
Some users think that the graphics are too large, but in fact the button labels are eating so much space. If you're using topaz/8 as the label font, then some of the buttons become invisible on a 640 pixel wide screen. Solution: select 'Settings/MUI' and go to the 'Toolbar' section. Now you can either choose a thinner font (helvetica/9 works well) or switch off the labels completely ('image only' mode).
The layout of the prefs window doesn't adapt properly when reducing its size, any solution available to it?
Yes, we know about it and have already fixed the issues in newer YAM versions. In fact, it was a bug in the layouting of the prefs window of YAM versions <= 2.4p1. Any newer version shouldn't contain that issue anymore.
There seems to be no translation available for my language?
Well, as you might know. YAM is open source and as such is highly dependent on on the users (community) - especially when it comes to locale translation. Even if there are organisations like the ATO who are trying to organize a global and free translation service for Amiga applications, we are trying to give individual the chance to contribute their translation.
So if you find that YAM isn't yet fully translated for your language, please have a look at the http://yam.ch/Development/HowToContribute document at our main support site. There you should find information on how to generate your own translation file and also contribute to us.
We are looking forward to receive your translations.
Why are some mails displayed without any text content which got displayed properly some weeks ago?
Mails may contain several "streams", like the normal text and attachments. The text however may also exist in more than just one variant. The standard allows plain text and HTML text to coexist within one mail, but in this case both parts must contain the same text, even if they are displayed differently.
Now some very smart companies, but this also applies for spam mails, decide to fill only the HTML part with their message and leave the alternative text part empty. Most mail clients on other systems prefer to display HTML text this goes unnoticed by the masses and nobody complains. Since YAM still prefers plain text over other alternatives and hence will display a mail with no body at all.
However, this can be worked around. Open the config window, go to the "Read" page and activate the options "Display all texts" and "Show alternative parts". This will let YAM display the alternative HTML part as an attachment and additionally will show this HTML part converted to text.
When displaying an email with embedded soft-styles such as bold/italic, etc. the mail will be displayed with the style markers '*' as well, why?
In versions previous to YAM 2.5+, email messages were displayed with the soft style markers in a mail. However, this cause severe trouble in case a style marker was incorrectly recognized so that text was mixed up. Especially for formatted text like stylished ASCII-art signatures or documentations this ended up in a completly mixed up display of the email. In addition, other mainstream email programs also didn't strip the soft-style markers for the very same reasons.
Example: Considering that an author of an email wrote a short ASCII-art documentation in an email to e.g. explain a bit mask that he used and where he wanted to highlight the first bit as important in bold:
0 1 0 1 1 | | | | | | | | | bit5 *bit1* | | bit4 | bit3 bit2
Due to the used '*' bold-style characters this may have ended up looking like the following in YAM < 2.5 because the '*' chars were completly replaced by the bold style only:
0 1 0 1 1 | | | | | | | | | bit5 bit1 | | bit4 | bit3 bit2
As can be seen in that example, the ASCII-art here is completly mixed up due to the removed "*" bold-style characters.
However, now with YAM 2.5+ these kind of problems were fixed by keeping those soft-style characters in the showed mail text so that the above example now perfectly ends up being display correctly with the bold style and its markers:
0 1 0 1 1 | | | | | | | | | bit5 *bit1* | | bit4 | bit3 bit2
In addition to that fix, it is now more easily possible to spot which character can be used to start writing a word in bold style rather than having to always use the corresponding toolbar button.