Looking to Activate Custom Panels via Keyboard Shortcut + Keyboard Listeners when Panel is Active

[ETorr]

This may well a couple of feature requests, but looking forward to getting some feedback...

In the interest of building more robust and flexible custom HTML panels, we were looking for ways to achieve the following:

1 - Activate and give focus to a custom panel via keyboard shortcut.

2 - Once activated and in focus that custom panel's key listeners (keystroke, keyup, keydown) can be coded to either take precedent over PPro's keyboard shortcuts or not.

The goal is to get the above two to work in concert so as to create workflows that would allow 100% keyboard driven functionalities, along the lines of:

- Call the Custom Panel via PPro shortcut

- Run the Panel's function (or suite of functionalities) via keystrokes

- Release control back to PPro and Return to regular PPro kb by exiting Panel focus

Imagine rapid fire: keystroke to activate, use, and release.

So far we've been unable to do this.

Reasons:

A - Haven't found a way or workaround to assign the ability to open & give focus to a custom panel via keyboard shortcut

B - Haven't found a way to make custom panel key listeners reliably detect keystrokes even when they are in focus..

So far we've tried by way of the CSInterface binding listed here:

https://forums.adobe.com/thread/2250292

and via standard HTML5/JS bindings

document.body.addEventListener / document.addEventListener.

Occasionally they work, but not reliably.

We're on Mac OS

[Bruce Bullis · Accepted solution]

There is no way to make PPro (or, I think, any Adobe app other than InDesign) assign a keyboard shortcut, to open a given extension.

While registering for specific key events is possible, there is no way for a panel to override ALL of PPro's (or, again, any Adobe host app's) keyboard handling.

[ETorr]

https://forums.adobe.com/people/Bruce+Bullis  wrote

There is no way to make PPro (or, I think, any Adobe app other than InDesign) assign a keyboard shortcut, to open a given extension.

Thank you for the tip on InDesign.  It's an interesting approach: their keyboard shortcuts UI is aware of the currently-available custom extensions and makes it possible to choose one.  PPro's keyboard shortcut, overall, is much more robust -- one of the best I've seen anywhere -- but it doesn't do that the cool trick that InDesign does.  Any possibility that PPro's KB shortcut UI could be made to do the same?

https://forums.adobe.com/people/Bruce+Bullis  wrote

While registering for specific key events is possible, there is no way for a panel to override ALL of PPro's (or, again, any Adobe host app's) keyboard handling.

Good point.  You wouldn't want to override all keystrokes -- security risk.

You can always quit a browser and nowadays escape repeated JS alert();  There are limits to everything.

What I was pointing to, however, was an inconsistency between the PPro Custom Panels and standard browsers and on this particular issue.

The following JS, for instance

document.body.addEventListener("keypress",function(e){
     console.log(e);
});

...in a standard browser, will detect just about any keystroke and modifier combo available as long as the browser window is in focus.

That same code running in a PPro panel, generally will NOT capture events, even with the panel in focus.

A second attempt to use CSInterface for the same purpose...

ThisCSI=new CSInterface();
ThisCSI.addEventListener("keypress",function(e){  
     console.log(e);
});

...also didn't capture events.

[Bruce Bullis]

> Any possibility that PPro's KB shortcut UI could be made to do the same?

While possible (hey, it's software!), that remains vanishingly unlikely. We have precious few available keyboard shortcuts, already.

Difference between panels and browsers = Yes, Adobe's apps like to usurp more key events, than do browsers.

CEP HTML Test Panel has a pane, that shows how to deal with key events.

Samples/CEPFeatures.html at master · Adobe-CEP/Samples · GitHub

[ETorr]

https://forums.adobe.com/people/Bruce+Bullis  wrote

> Any possibility that PPro's KB shortcut UI could be made to do the same?

While possible (hey, it's software!), that remains vanishingly unlikely. We have precious few available keyboard shortcuts, already.

On this one I would emphatically disagree, because I think it sells PPro's abilities short

PPro's keyboard shortcut UI is one of the most sophisticated and powerful shortcut system I've seen on any software.

Not only does it give elaborate control over keys and modifiers, thereby exploding the number of kb shortcuts available,

it also allows kb shortcut assignments to be made at the Application level, plus overrides available depending on which PPro Panel panel is active.  In that way the same kb shortcut can perform multiple tasks depending on context.

Massive control via modifier keys + context-sensitivity: That's a brilliant framework.  It takes the limited number of keys available and multiplies them out many times over, effectively eliminating the prospect of a kb shortcut shortage.

It's precisely this of PPro excellence that inspired this post.

On the PPro UI side the only change would be that the KB Shortcut UI allow users to choose from a list of currently-available Custom Panels and be able to assign them kb shortcut of their choice.  From there any additional kb-based functionality would be the responsibility of the panel developer.

[Bruce Bullis]

I'm not sure with what you're emphatically disagreeing...?

ETorr  wrote

On the PPro UI side the only change would be that the KB Shortcut UI allow users to choose from a list of currently-available Custom Panels and be able to assign them kb shortcut of their choice.

Agreed—that's precisely the change I meant to suggest was vanishingly unlikely, at least for the foreseeable future.

We understand why you'd want such behavior.

Even setting aside the impossible-to-predict context re-targeting shifts a user's path through PPro might generate (and the burgeoning test matrices such behaviors would precipitate), the competition for assignable keyboard shortcuts is already fierce just within PPro, and allowing extensions to usurp those shortcuts is not, today, a top priority.  Feel free to make your case [directly; b b b at adobe dot com], and I'll share it with the PPro team.

[ETorr]

https://forums.adobe.com/people/Bruce+Bullis  wrote

I'm not sure with what you're emphatically disagreeing...?

Ah, the emphatic disagreement (meant, btw, as an enthusiastic boost of the PPro kb shortcut UI)

... but nonetheless an emphatic disagreement.  Here's the thinking:

The keyboard-driven functionality of a Custom Panel would presumably only take precedent as long as the Custom Panel is in focus, and only if the developer chooses it to be.  So the fact of a panel being open wouldn't be sufficient for it to take precedent over the PPro UI.  The panel would have to be in focus too.

Under that logic (correct me if I'm wrong) Adobe wouldn't have to do much testing or involve itself.  It would merely be making it possible to give the Panel focus via a single user-assignable keystroke, and permit the Panel execute commands via key events for as long as it's in focus.  There's no real conflict.  An e.preventDefault() would simply prevent PPro's Shortcut UI's keyboard shortcut from being executed while the panel is in focus.

[Bruce Bullis]

You're right about focus being required.

> "Adobe wouldn't have to do much testing or involve itself."

We'd like to believe that, but this isn't our first rodeo...

e.preventDefault() works within the CEP (panel integration) level, not within PPro's internal UI handling.

The plumbing work necessary to wire up extensions (the list of which can vary with each launch, for a panoply of reasons) to PPro's own keyboard shortcuts remains formidable, and not in our near-term plans.

[ETorr]

https://forums.adobe.com/people/Bruce+Bullis  wrote

You're right about focus being required.

> "Adobe wouldn't have to do much testing or involve itself."

We'd like to believe that, but this isn't our first rodeo...

e.preventDefault() works within the CEP (panel integration) level, not within PPro's internal UI handling.

The plumbing work necessary to wire up extensions (the list of which can vary with each launch, for a panoply of reasons) to PPro's own keyboard shortcuts remains formidable, and not in our near-term plans.

Totally understood.  If you say it's complicated on your end, I hear you.

I'll feature request it.  It's always easier to propose and outline it than it is to actually develop and maintain it.

[Bruce Bullis]

Feature already requested: I've added an overview of your proposed workflow, and your vote, to B-125639, "Allow users to attach keyboard shortcuts to CEP extensions".

[ETorr]

Thanks.  BTW, what's the B-125639 pointing to?  Is there a listing of those somewhere?

[Bruce Bullis]

It's not publicly exposed.

Some months from now (I'd suggest after NAB 2018), feel free to write and ask "Hey, whatever happened to API feature request B-125639?".

[ETorr]

CEP HTML Test Panel has a pane, that shows how to deal with key events.

Samples/CEPFeatures.html at master · Adobe-CEP/Samples · GitHub

Thanks for this.  Just tested.

Questions and observations:

- Suggests the CEP environment does expect key listeners to normally.  As best as I could tell there was nothing outside of HTML 5 required to get them to work.  Line 271...

<body onkeydown="keyDownInBody(event)">

Standard HTML key listener, same as document.body.onkeydown=keyDownInBody;

Question regarding line 237:

CSLibrary.registerKeyEventsInterest(jsonString)

What is that doing?  How doesit work?  I was unable to find documentation on that.

- There is a helpful reminder on line 676

Please make sure the keyboard focus is out of any text editable or dropdown element, then hit keys.

That sets the initial value of the "KeyHitReturnObject" text area.

BUT my experience suggested the opposite. It was precisely the text area (or any text area) that required focus for, the key listener to detect.  Even forcing the document.body to be in focus didn't resolve this.  In fact, once a text area was in focus any and all key listeners functioned fine.

By contrast same code is run in a standard browser works as expected and all's well -- key listeners function just fine even when a textarea does not have focus.

[Zac Lam]

Hi ETorr,

We have some sample code for RegisterKeyEventInterest.  Here's some sample code I was working on for AE, which gets basic keystrokes working for registered key events: https://github.com/Adobe-CEP/Samples/blob/AE_Key_Events/AfterEffectsPanel/ext.js​

As you mentioned, key codes vary depending on type of keyboard.  Since you're on Mac, you can check the code for your keyboard using "Key Codes" in the Mac App Store: (https://itunes.apple.com/us/app/key-codes/id414568915?mt=12).

[ETorr]

Zac Lam Aug 7, 2017 6:17 PM

We have some sample code for RegisterKeyEventInterest.  Here's some sample code I was working on for AE, which gets basic keystrokes working for registered key events: https://github.com/Adobe-CEP/Samples/blob/AE_Key_Events/AfterEffectsPanel/ext.js

That seems to have solved the problem -- suddenly the Custom Panel can detect key events same as a standard browser window.

It's still a little mysterious (What are  csInterface.registerKeyEventsInterest / window.__adobe_cep__.registerKeyEventsInterest?), but it gets the job done.

Thanks for passing that along.

[Gianmarco5CFC]

Hello Errore 🙂 . Di you use this solution in Pr , or Just in Ae?

[Gianmarco5CFC]

Sorry, I wanted to type Etorr .... smartphone autocorrector