Modify ↓
#188 closed bug (fixed)Active/Inactive status of mail and folder list breaks keyboard usage (e.g. Del key)
Description
Since the changes in the course of the NList 0.106+ release, which fixes an important bug in the active/inactive display status of NList/NListview objects, the keyboard management of YAM 2.6 seems to got broken somehow. Under certain circumstances the Del key or the cursor up/down keys stop working even if the mail list is displayed as being the "active" object of the main window.
The following procedure should demonstrate the problem when NList 0.106+ is used together with YAM 2.6:
With YAM 2.7-dev or NList 0.105 everythings seems to work again. So the problem is the combination of YAM 2.6+NList 0.106+ Attachments (3)Change History (20)comment:1 Changed 3 years ago by damato
comment:2 Changed 3 years ago by thboeckel
comment:3 follow-up: ↓ 5 Changed 3 years ago by anonymous
The fix (http://trac.yam.ch/changeset/5004) should go comment:4 Changed 3 years ago by thboeckel
All changes I did to the bugfix-2.6 branch were in fact taken from the main trunk. comment:5 in reply to: ↑ 3 Changed 3 years ago by damato
Replying to anonymous:
This is non-sense. The main trunk is already fixed. Of course! comment:6 Changed 3 years ago by opiopi
Sorry it was me who wrote comment 3 but i was not looged in.
I wrote that because yesterday i saw that the cursor keys in
I use the latest MCC_NList-0.107 archive and YAM 2.7-dev
I'm sure in a previous version of YAM and/or NList it was
I just load the build from today (27.08.2010) and it still
Resetting the prefs to the default values doensn't help.
BTW: i don't use the embedded read pane but if i do so comment:7 Changed 3 years ago by damato
That's very strange as we thought that everything is fine with the latest nightly build and NList 0.107. So can you please elaborate further and tell us more about your system? I guess you are using OS3/m68k, right? Which MUI version? MUI 3.8? And can you please give us a step-by-step explaination like the one I wrote above how to reproduce it, or do you use the same procedure to show the problem? And have you tried resetting the NList settings to their defaults? We should really get that nailed down because otherweise we cannot release 2.6p1. comment:8 Changed 3 years ago by thboeckel
I suppose you are still using MUI3.8. This one has some severe bugs when it come to keyboard handling. Under certain conditions the classes are not triggered for every key press.
I added some workarounds for this issue in NListtree.mcc and NListview.mcc. Please try the attached versions. If they fix the issue for you then we must release a fixed version of NList along with YAM 2.6p1. comment:9 follow-up: ↓ 10 Changed 3 years ago by opiopi
Yes of course i rum MUI 3.8 on a A2000 (68k060) AOS3.9 BB2.
Here is my step by step:
The attached NListtree.mcc.18.33.new NListview.mcc.19.81.new
But i can't mark the mails using the ctrl key - seems the
Using ctrl + up/down keys scroll to the begin or end of the list.
Alt + ctrl mark all mails from the current active up to the
Maybe i must reset my settings?
BTW: Yesterday i saw that in the MUI prefs program the
See also attached pic Mui-Prefs.png. Changed 3 years ago by opiopicomment:10 in reply to: ↑ 9 Changed 3 years ago by thboeckel
Replying to opiopi:
This is due how you configured the standard MUI keys. These definitely clash with NList's default settings. MUI uses ctrl+up/down to go the first/last entry of a list. NList will handle these special keys first, before it handles its own key definitions. This is why ctrl+up/down does not mark any entry.
I tried this on several systems now (OS3 and OS4), using different versions of MUI (3.8 and 3.9), and all behave in the same way now. Although none of them can mark entries with ctrl+up/down this is no bug, but just a "buggy" configuration.
To make it short, I will close this bug because from my point of view there is nothing to fix, neither in YAM, nor in NList (except the workaround for MUI3.
The only thing I can offer is to change NList's default key bindings. Do you have any suggestion which does not collide with some other key setting?
Do you have the latest NBitmap.mcc installed? This one is used to display truecolor images. If it is missing or too old (15.8+ is needed) you will see the old color mapped image. comment:11 Changed 3 years ago by opiopi
Hmm if i read the 'Keybindings' page in MUI config i see this entries:
control up = Select up
so either your desription or the description on this page is wrong.
Additional i think it was possible with earlier version to hold the
But all that should go to the correct place e.g. the Nlist bugtracker.
Yes i have NBitmap.mcc 15.11 [OS3/m68k] (18.08.2010) installed comment:12 follow-up: ↓ 14 Changed 3 years ago by damato
Hi, I have to support the observations from Thore here. In fact, I downgraded my system to YAM 2.6 and the NList version that it distributed. And here the same happens. Control+up/down just changes the view and does NOT select anything in NList. In addition, also Shift+up/down does only scroll down/up side-wise.
After having checked the keybinding configuration of NListviews and MUI it really seems that the default settings for selection of entries with the keyboard clashes with the default keyboard settings in the MUI keybinding. I was also able to get rid of the problem by either clearing the "Up/Down" and "Page Up/Down" settings in keybinding in MUI and afterwards NList was able to use Control+Up/Down and Shift+Up/Down. Another possibility is also to change the keybinding in NListviews to use the following mapping:
shift alt up = Page up selection
So instead of using the "Control" key in NList it would be IMHO better to use the "Alt" key for keyboard selection as this won't clash with the internal defaults of the MUI keybindings.
However, why Frank seems to recall that this was working before isn't clear. Either he mixes something up or some recent changes finally fixed some problems in regard with MUI 3.8 which might now show the correct behaviour. So Frank, can you please downgrade to YAM 2.6 and install the NList versions it comes with. And then please check how this versions behave.
Regarding the with Ctrl+Mousekey. This also does not work here. However, the correct combination to select several entries separately seems to be Shift+Mousekey here.
So please let us clear this thing up so that we can release a new NList version quickly before we are going to finish up 2.6p1. comment:13 Changed 3 years ago by damato
BTW: I also checked the behaviour on MOS and there Ctrl+Up/Down also scrolls instead of providing an entry collection.
So perhaps this missunderstanding shows that we need a new FAQ entry in faq.yam.ch? In addition, I think we should change the default keybindings in NListviews to use ALT rather than CONTROL. comment:14 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 3 years ago by thboeckel
Replying to damato:
To be consistent with the global AmigaOS style it was always the Shift key to trigger multi selection.
Of course one could change this to his preferred likings and thus a specific combination might have worked at some point in time. comment:15 in reply to: ↑ 14 Changed 3 years ago by damato
Replying to thboeckel:
Please note that I just changed the default NList keybindings in the recent sources to use the ALT key rather than CONTROL to select entries via the keyboard. This should hopefully fix the clashing keybinding settings between MUI and NList. comment:16 Changed 3 years ago by damato
I just added an entry to our online-FAQ. So please check the following URL for information on how to configure NList until 0.108 has been released:
http://faq.yam.ch/content/1/62/en/why-is-keyboard-selection-of-multiple-mails-not-working.html comment:17 Changed 3 years ago by opiopi
I'm sure i select last week mails using the CTRL + up/down key.
The problem should be fixed with damatos changes.
For multi select with the mouse i'm not sure if it was Note: See
TracTickets for help on using
tickets. | This list contains all users that will be notified about changes made to this ticket. These roles will be notified: Reporter, Owner, Subscriber
| ||||||||||||||||||||||||||||



The fixed tickets #1 and #14 plus some additional fixes finally close this one.