Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

bot please update documentation snapshots

Documentation snapshots updated.

bot please update documentation snapshots

Documentation snapshots updated.

before by using a semantic command, if the focus switches in a console for example, some actions would still appear enabled

But is this the expected behaviour? Could these be enabled (rather than disabled) but possibly greyed out as "inactive"? My problem with the buttons being disabled is that it is now a two-step action to run a cell in another notebook (first focus the notebook, then click on the button).

Even though other UI elements e.g. the "add cell" button are always active:

I think most desktop UI does not require focusing first to click a button. As an example, the window initially in the background on the screencast has the buttons greyed out (inactive) but when I click on "X" it just works (it is not disabled):

Thanks for the feedback @krassowski - I agree with you it will be more consistent to still have the button as enabled. One possible solution would be to return true for isEnabled if the command is in the toolbar bar (we already have a argument toolbar: true for tuning the icon and label). But this is may be not a strong rule. What do you think?

Yes, I think this makes sense - subsequently we could apply a different kind of "grey out" style to all toolbar buttons by conditioning on the document not having an "active" class (we don't have a class like that on document widgets - only on tab bar, which is a related UX issue).

bot please update documentation snapshots

Documentation snapshots updated.

@meeseeksdev please backport to 4.0.x