|Version 7 (modified by 5 years ago) (diff),|
- User Interface
- Why does the "Colored text" gadget in the Read configuration looks …
- 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 graphical attachment list is displayed truncated and does not …
- Why is the mail preselection/transfer window sometimes active by …
- The menu of the write window contains strange "ramiga X", "ramiga C" …
- I changed the shortcut definition of TextEditor.mcc to use a …
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.