Command state


#1

Is it possible to add conditional command? Meaning command would be active only when certain conditions are met. For example, a file with certain extension is selected in project panel.

Right now I can think of listening to select/unselect file event, checking file name, and if match my criteria, than create command, if unselected than disposing it. But wait, there is no remove for command…

Maybe simpler way is to check file selection in activation of command and if nothing selected, show error banner? If this is the only way, than can this post be considered a feature request, for command to have status. Associated menus would be disabled and shown in gray or hid away. This would help with menu pollution problem too.


#2

Have you a specific use case in mind?
Because AFAIK the tree-view items can’t get focus, which means you can’t target them using the command selector (which could have been a way around your issue). Except if you plan to work with the text editor corresponding to the selected tree-view entry, in that case you can probably use the editor scope as the command selector.
Also, I think most commands in Atom just do nothing when the conditions aren’t met. Have you considered this option?


#3

Well, I think what I was looking for was atom.workspace.addOpener, which can discriminate by file extension.

But initial thought still is valid, fora example graying out Edit/Cut when there is no selection would be nice.


#4

There is a remove for commands … and it is disposing it. If you refer to the documentation of the add() method, it states that it:

Returns a Disposable on which .dispose() can be called to remove the added command handler(s).

Emphasis added. This is the way that removes are implemented throughout the Atom API.

If you want your command to show an error banner, you can show it yourself. There is no need for commands to return a status. Personally, I think that showing an error banner when the user didn’t do anything wrong is a bit egregious. About Face has these things to say about error dialogs in Chapter 25: “Errors, Alerts and Confirmation”:

  • Error message boxes stop the proceedings with idiocy and should be avoided
  • Make errors impossible
  • Users get humiliated when software tells them they failed

And also, the thing that helps most with menu pollution … is to not have menu items in the first place. I’m not suggesting banning all menus, but the things in the menu should be what is going to be needed by a beginning user. Menus are training wheels that help a new user discover what the software can do. I think by the time they’ve installed a package … they’re at least approaching intermediate. And there’s always the Command Palette for discovery.