-
-
Notifications
You must be signed in to change notification settings - Fork 655
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List signals and remove signals without label #458
Comments
Not sure if I see the point in this. I don't think "permanent" signals should be manually queried and modified in a running session. If you are still in a prototyping stage, labels are just as simple to utilize in my opinion. If you are modifying signals during runtime, I would also suggest labeling them. |
I have the same feeling that something is missing in the signal labelling feature.
However the API is asymmetric that cuz we can add but remove only those with label. |
I’m not trying to be difficult here, but I still don’t see any actual gain in usability by making these changes. Signals are not meant to be modified by a user manually at runtime. The label only exists because it is useful for a script to recognize a signal it automatically created, so that it can later be removed or rewritten from the same script.
…Sent from my iPhone
On 21 Apr 2020, at 14:34, Jonathan Huot <[email protected]> wrote:
I have the same feeling that something is missing in the signal labelling feature.
May I propose alternatives:
* add a "-m signal clear" action to remove all signals
* make "label" mandatory
* if "label" is missing, randomly generate one (however still need a "-m signal list" feature
However the API is asymmetric that cuz we can add but remove only those with label.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#458 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABPDZVZM4P6X5YZYZKKPLEDRNWHEVANCNFSM4LT4IVDA>.
|
If someone can come up with a practical problem they are trying to solve, that require changes to the signal system, or is tedious to do because of limitations of the current system, please let me know and we can discuss viable solutions from that point. |
Having a function to list existing signals would let users inspect this hidden state, making it easier to set up new signal handlers. When I created signal handlers, it was quite confusing because at some point I ended up with multiple handlers registered to the same signal and no way to query this information, so I had to restart yabai often. |
Implemented on master. |
sample output:
Remove by using the index from the output: |
It would be nice to see a list of registered signals and remove them without having to reload yabai.
For example, list the signals (not sure if JSON output would be more consistent):
Then delete them by index:
The text was updated successfully, but these errors were encountered: