dunst-project / dunst

Lightweight and customizable notification daemon
https://dunst-project.org
Other
4.44k stars 338 forks source link

Proposal: Show action count in notifications #1218

Open elamperti opened 9 months ago

elamperti commented 9 months ago

Users want to know how many actions a notification has so they can choose how to intreract with it (see #509, #1150 and #1216).

We could add a setting show_actions, configurable to one of these four settings:

For all these configurations, when there are no actions available no text is added to the notification.

bynect commented 9 months ago

Following the discussion in #1126 I would like to propose a way to give the users the ability to customize indicators in a backwards compatible way.

Disclaimer: I know that this is a more complicated proposal, but please read till the end for considerations.

We can add a few settings for different situations:

These values are themselves formattable and the user can customize them however they want. Then they will be added to the notification via format as they see fit. Note that the values for the format will be empty if the situation is not applicable, so only the right string is printed.

To improve things even further we can add few format options that describe the current notification. For example

Up to this point everything is very easy to implement and although it adds a bit of variants to format strings it simply replaces things to integer values.

Note: format names are to decide


Now I will propose another improvement to format that will make a lot of things easier. Note that this doesn't need to be linked to this particular discussion and shouls probably be moved to its own issue and pr.

We can also add a way to conditionally include text depending on the situation. For example we could use this syntax %(I love icons)i (print only if there is an icon). While this may look like complicated to implement it really isn't.

This allows the user to customize the format even more. But it has also a practical effect. We can now implement show_indicators with our new system.

Here's how:

action_indicator = "A"
url_indicator = "U"
context_indicator = "%(A)m%(U)u"
default_indicator = "%d"

(Then we prepend "(%A%U%C%D)" to format)

Even if this proposal is discarded I hope that my idea might be useful to improve the current indicators system.✌️

elamperti commented 9 months ago

@bynect some questions and observations about your ideas:

Observations

Questions

bynect commented 9 months ago

@bynect some questions and observations about your ideas:

Observations

  • Getting the individual counts you want is easy, but all this piled up is a significant effort for a side project.
  • On that note, this action counter is required because we don't have a proper way to show actions (i.e. buttons). It may be worth focusing our effort on a simple solution here and look for ways to implement buttons (or even take small steps towards them, like #879).
  • If the values of the strings were formattable themselves, we should add a safeguard for recursivity.
  • Adding several indicators combining conditions will probably confuse casual users.
  • Conditional tags in the format string are a nice idea that should be discussed separately. If implemented, this should probably include other tags as well (title, summary, etc) or use a different syntax to make them easier to identify in code.

Questions

  • How would we handle the transition of the current format to this?
  • What would be the practical use of default_indicator? Why would someone use an indicator for no actions?
  • What's the point of having a count of URLs + actions combined?

Hello, first of all thanks for your quick response.

I will start by saying that if we implement the conditional printing, we don't reallu need the creation of the different indicator string. In fact we can create a single indicator_format or something similar that will be always formatted in all cases. Then, inside this the user adds conditional rules to print based on the varius formatting options.

Obviously inside the indicator format we disable the expansion of itself to avoid recursion.

So now we still have a format option for indicators (like %D).

Then we have the other options:

This obviously get defined only when the situation allows them (furthermore we may think about restricting their usage in indicator_format).

So now the show_indicators would simply prepend this to format "%(\())d%d%(\))d" (escaping () only inside %()). This piece simply prints "(X)" where X is the action indicator only when this is defined.

Practically this would be

indicator_format = "%(A)m%(U)u%d"

That replaces the behavior of show_indicators.

Regarding your questions:

bynect commented 9 months ago

Also, regarding the event rule you mentioned, I don't see the format indicator idea conflicting. If anything we could make the format_indicator change based on an event rule.

And for your idea to keep it simple and don't add to much now. I know that it makes sense to do so. However I think that if we are going to deprecate show_indicators we should add a proper alternative that allows customization.

Actually, for your idea to add none, full, minimal levels: why not add it to show_indicators as a temporary measure? So we could add for the time being (until indicator_format) a full value to show_indicators (none is no, minimal is yes).

fwsmit commented 9 months ago

And for your idea to keep it simple and don't add to much now. I know that it makes sense to do so. However I think that if we are going to deprecate show_indicators we should add a proper alternative that allows customization.

Actually, for your idea to add none, full, minimal levels: why not add it to show_indicators as a temporary measure? So we could add for the time being (until indicator_format) a full value to show_indicators (none is no, minimal is yes).

Yeah, I like that idea. It keeps backward compatibility, is simple and allows for more options. More styles like an emoji style could be added later if people want it