Open bynect opened 2 months ago
For reference
msg_urgency
& msg_urgency
-> set_urgency
& match_urgency
override_dbus_timeout
-> set_dbus_timeout
new_icon
& icon
-> set_icon
& match_icon
...etc
Ideally this new names can be parsed automatically as "set"/"match" + prop_name
Yeah, sounds good. I think it would also be good to write some documentation about this. Rules are added one by one and it might go wrong again in the future
Making it work programmatically would also be a solution to force it to be consistent
Making it work programmatically would also be a solution to force it to be consistent
That was the idea, like creating an enum with the rule property (urgency, color, ...) and one with actions (set, match, ...maybe we'll add more...) and programmatically parse them.
This seems like a nice qol goal for v2
I found that an old issue proposed the same thing #349 🤦🏻
I am undecided about using match_property
or has_property
like it was proposed in #349. Mostly for brevity and symmetry (3 letters like set).
@fwsmit @zappolowski what do you think about this ^^^^
If I could I would make a poll, but I don't think it is possible.
I'm not sure either. Making a poll is a good idea
I'm not sure either. Making a poll is a good idea
I made it in discussions. I don't know how much reach it will have unfortunately. Maybe I can add a link to the poll to the website??
I propose a more consistent syntax for filters and rules following the good example of
match_transient/set_transient
. We can add for every notification property amatch_*
and aset_*
value for filtering and modifying respectively. This is much more consistent than the currently somewhat confusing names (msg_urgency/urgency
, etc).Obviously for backwards compatibility the current name will still work (as an alias for the appropriate new name).
If I get to implement this I will also probably change the rules internal representation (see #607).
If you have any ideas about this let me know 👍🏻