[#41531] - [5.3] Add support for alternative buttons on modifier key pressed.
- Pending
- Medium
- Build: 4.3-dev
- # 41531
- HLeithner:5.0/feature/toolbar-alt-key
Summary of Changes
Add the possibility for toolbars (and theoretically any html element) to hide and unhide if a modifier key is pressed.
Supported modifier keys:
- AltLeft
- AltRight
- ControlLeft
- ControlRight
- CapsLock
- ShiftLeft
- ShiftRight
- MetaLeft
- MetaRight
- Alt Extends to AltLeft and AltRight and AltGraph
- AltGraph Extends to AllRight and Alt
- Control Extends to ControlLeft and ControlRight
- Shift Extends to CapsLock and ShiftLeft and ShiftRight
- Meta Extends to MetaLeft and MetaRight
2 new accessors has been added to the toolbar buttons:
- alternativeGroup - Holds a unique identifier for linked buttons
- alternativeKeys - Holds a comma separated list
Example usage:
$toolbar->trash('articles.trash')
->listCheck(true)
->alternativeGroup('trash')
->alternativeKeys('Default');
$toolbar->delete('articles.delete', 'JTOOLBAR_DELETE')
->alternativeGroup('trash')
->alternativeKeys('Shift')
->message('JGLOBAL_CONFIRM_DELETE')
->listCheck(true);The example above creates a Trash button which is shown when no modifier is pressed and a Delete button which is only shown when one of the both Shift (Left or Right) is pressed or the CapsLock as been activated.
The change happens only when the relevant browser window has the focus.
Possible additional functionally
- Support for buttons
RollandNum - Support button combinations
Testing Instructions
As example I created a Trash/Delete switch in articles overview and a switch for the Save button in articles edit view.
- open articles overview
- click new article
- add title
- press the Shift key -> Save Button changes to "Save & New" (That's only an example, maybe removed)
- save the article
- at the article overview select the created article
- click on the "action" toolbar dropdown
- pressing the
Shiftwill change theTrashbutton to anDeletebutton
Actual result BEFORE applying this Pull Request
Trash and Save of articles work
Expected result AFTER applying this Pull Request
Trash and Save of articles still work, but additional with pressed Shift button you can directly deleted an article.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
Pull Request link for manual.joomla.org:
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content Repository NPM Change JavaScript Layout Libraries |
Pressing CapsLock works as you expect (not holding), all other buttons work like everywhere else with keeping it pressed and mouse click. We will not use this in code of course, so only "Shift" will work for us.
So impossible to use without a mouse then
nope works also without a mouse, not perfect because the focus is not set to the unhidden button which is a bit uncool with shift pressed (because moves backward) but works, also if you press CapsLock normal tapping works.
For all other keys the operating system has Sticky Keys functionality which holds the pressed for you.
| Labels |
Added:
Feature
NPM Resource Changed
PR-5.0-dev
|
||
now the focus should be preserved
Really not a fan of this.
-
When using the caps lock as the modifier this only works when you turn on the caps lock. If you already have caps lock on then you have to turn it off and then turn it back on to work. perhaps a bug that can be fixed?
-
For it to be implemented then every component model and view needs to be updated - you would want the delete/trash functionality consistently available otherwise its bad ux
-
The save example is really confusing as its only active on a NEW article and not an existing article. Without this PR saving the article only adds buttons to the toolbar. With this PR it changes the buttons. That is both confusing and an accessibility fail
-
You lose the ability to just save an article with the caps lock on - perhaps a bug that can be fixed?
-
When I said can't be used without a mouse I should have been more explcit and said almost impossible to use on a touch device
-
The list of modifier keys is confusing as it implies they are all different keys but in reality many of them are pairs (or at least they are on a uk windows keyboard layout) where for example there is no difference between controlLeft and controlRight
Really not a fan of this.
- When using the caps lock as the modifier this only works when you turn on the caps lock. If you already have caps lock on then you have to turn it off and then turn it back on to work. perhaps a bug that can be fixed?
That might be possible the question if needed. Would need a periodic check but maybe there is an event for it @Fedik @dgrammatiko ?
- For it to be implemented then every component model and view needs to be updated - you would want the delete/trash functionality consistently available otherwise its bad ux
of course
- The save example is really confusing as its only active on a NEW article and not an existing article. Without this PR saving the article only adds buttons to the toolbar. With this PR it changes the buttons. That is both confusing and an accessibility fail
Yeah the save example was only a quick shot, wasn't the best idea tbh but already invested way too much time in this feature.
- You lose the ability to just save an article with the caps lock on - perhaps a bug that can be fixed?
as said only a prove of concept and need to be done much better
- When I said can't be used without a mouse I should have been more explcit and said almost impossible to use on a touch device
different devices needs different input paradigmatic so I don't see that as a problem, we also have things for mobil devices which are useless for desktop systems.
- The list of modifier keys is confusing as it implies they are all different keys but in reality many of them are pairs (or at least they are on a uk windows keyboard layout) where for example there is no difference between controlLeft and controlRight
you don't have 2 control keys? The reason for the "control" and "shift" names I used to have it simple for the developer but still be possible to do special things if needed. Of course that's not things for core, here I would stick to Shift and Ctrl, the rest is a bit fishy.
you don't have 2 control keys?
yes I do but they both issue the same keycode
The Browser nows the difference ;)
FWIW Web Components/Custom Elements are a better fit here. Pass the methods, labels, etc and do everything in the JS, it doesn't need to prerender the actual buttons server side (also I don't think the approach of 2 buttons, one hidden is reflecting best practices).
My 2c
No real difference when I look at the toolbarbutton htmlmarkup then i See it's mostly rendered in the layout file. Beside that, in the current form it's agnostic and could be used for every element. But of course I'm not the js master
I have made a PR with litle changes, check your clone.
This pull request has been automatically rebased to 5.1-dev.
This pull request has been automatically rebased to 5.2-dev.
| Title |
|
||||||
This pull request has been automatically rebased to 5.3-dev.
| Title |
|
||||||
| Labels |
Added:
PR-5.3-dev
|
||
ah - now I understand your earlier question. Not quite what I understood before.
For clarification can you confirm that this is not modifer + keypress but modifier +mouseclick
The former is accessible - the latter is probably not.