nect

> I am rather concerned over the fact that 'main.c' isnt simply just the `dunst_main` function from `dunst.c`, seems complicated for no good reason that i know of currently.. I...

> > Probably main.c could be removed altogether by putting main in dunst.c? > > Other code in the test suites depend on code from dunst.c. I've tried to move...

> Moving main.c to dunst.c, while dunst.c is required by the test suite causes problems, as the test suite depends on dunst's code too. Some simple meta programming can fix...

I was wondering, why remove outright the makefile when they can coexist afaik? Shouldn't the option to use meson be added alongside of makefiles? Then, after some time (to get...

Yes, but it is still an additional dependency that is really not that required. I mean, it doesn't seem to add any value to what the makefiles can already do....

This is an interesting idea. As a future reference: It can be done by defining a new dbus method similar to `NotificationCloseLast` that accepts a string and matches against that....

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...

> @bynect some questions and observations about your ideas: > > ### Observations > - Getting the individual counts you want is easy, but all this piled up is a...

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...

Everything looks fine. Maybe you could add dunstctl rules to the manpage. > NB: Completion for bash and zsh will be adjusted when this approach is considered okay. Also, I'd...