ReAction clicktab.gadget key activation

This forum is for general developer support questions.
Post Reply
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

ReAction clicktab.gadget key activation

Post by trixie »

ReAction's clicktab gadget allows key activation of the individual tabs. Assigned keys work fine and bring the respective tab page to view as expected - but the clicktab also shows the following behaviour. If you press the particular key for the second time, the first gadget in the tab page may get activated. To see what I mean, look at the "Notifications" editor in SYS:Prefs. If you move to the Preferences tab by pressing "p" and then press the key again, the "Global Theme" chooser will open up.

I was offered an explanation that this is intended behaviour, in other words, a feature. The logic behind it is that if you can select a tab via the keyboard, pressing the same key again automatically activates the first gadget on that page. Any further gadgets defined with GA_TabCycle, TRUE can then be navigated from the keyboard even if no keyboard short-cuts are defined for them.

I am sorry but this reasoning is fundamentally flawed. I present the following arguments against this "feature":

1. It's unreliable. The user cannot rely on this behaviour because it will not always work. If the top gadget in the tab page is a space.gadget or a listbrowser, he will not be able to activate them and get to the other gadgets. In the user's eyes, this feature will suddenly "stop working". (And what if the gadgets have no GA_TabCycle set at all?) So an explanation that the "feature" will enable or improve keybord navigation in tab layouts does not hold, it's simply not true.

2. It's illogical. If a tab is designed to be activated by a key, this shortcut "belongs" to the tab, NOT to the first gadget in the page! If I wanted a shortcut for the first gadget in the page, I would use GA_ActivationKey, wouldn't I?

3. It's too enforcing. So far the practice has been that it is the programmer who decides which gadgets will have hotkeys and which will not. (Quite logically: the user's fingers are fast, and a careless implementation of keyboard shortcuts may lead to confusion or loss of data.) What I don't like is that the current clicktab behaviour forces my gadget to have a hotkey although I have decided not to have one!

4. It's possibly borked anyway. In certain correctly programmed gadget configurations the "feature" may cause layouting errors. I can provide a test program for anyone interested.

Having said all that, I hope that the dev team's attitude to the clicktab behaviour will be reconsidered. Most likely, this behaviour is a long-standing bug for which someone just found reasons to call it a feature.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Post Reply