Anchor is not a style parameter and cannot be redefined in criteria section

[TLogiviere]

Hello, thank you for making this software! It would be great to allow notifications to be displayed in different places depending on the application generating them. For example, one could very much like to make sound and brightness notifications to display at bottom-centre ; chat at centre-left ; system info at top-right and e-mails at top-centre. Moreover it would further reduce the risk that a given notification gets cleared out by others appearing at the same time. What do you think about it?

[emersion]

I'm not a big fan of this. It becomes unclear what the last notification is, and would make the code a lot more complex.

[disruptek]

An alternative might be to run a separate mako instance for each area of the screen on which you wish to see notifications. Does that sound easier to implement?

I worked around the issue by using varied offsets, but I wished that most of the "global" options could be applied differently according to application.

[vilhalmer]

It's impossible to run more than one D-Bus notification client, only one can have the name on the bus at a given time.

[disruptek]

So, harder, then. :wink:

[TLogiviere]

@emersion : Ah. Let me add that the principle of the last (or more depending on max visible) notification being displayed would not change, but there would be as many as there is criteria section redefining --anchor, but also --default-timeout to a sensible value. @disruptek : I tried a similar workaround using --margin definition but without success because it uses pixels so it can't play well with multihead setup and --output="". @emersion @vilhalmer Allowing usage of value in % of the screen resolution for --margin could solve this issue though !

[vilhalmer]

I think the implication wasn't that it was going to fundamentally change what last means, just that it will make it much harder to visually (or even logically) determine which notification is last. This would make it hard to control notifications with makoctl, for example.

[TLogiviere]

Oh ok... So defining pseudo zones by means of redefining margin in criteria sections would be an easier solution... But it breaks with dual+ screens setups with different resolutions :scream: ! One solution would be to enable margin to use values in % of the resolution of the (focused or defined) output. Can I hope for it ? :grinning:

Following this idea, max-visible would then be more useful if redefinable inside a criteria section, to reduce the risk of competition for display slots between defined pseudo zones. But it would be a bonus as I guess it would hit the same caveats as with anchor ?

[joefiorini]

I'm still somewhat new to dbus notifications, clients, etc, but I have a similar wish of having some notifications in the center (mainly brightness and volume as mentioned in @TLogiviere's original post) and some in the top-right. This is very similar to how macOS displays overlays as well. Since I'm still new, I don't know the ecosystem as well as others. Is there some other tool we could call from a script to display brightness/volume level overlays besides dbus/mako? That would solve this problem (for me at least) without any changes to mako.

[vilhalmer]

There's a new one called wob designed for this sort of thing, though the visual style may or may not be what you're looking for: https://github.com/francma/wob

[donnex]

I really would like to be able to define anchor in a criteria match as well. My idea is to create large text, centered and short lived notifications. For example when my YubiKey needs authentication or when I switch keyboard layout.

[akobel]

+1 for @joefiorini A prime example would be for notifications like brightness change, volume change or keyboard switch, which are meant to be triggered by immediate user action and are typically extremely short-lived (probably, the same ones that would use #270).

@emersion I could imagine that such feature comes in handy even at the price of those notifications not even being acknowledged by makoctl commands (dismiss being the prime example).

@disruptek Had the same idea of two instances. For a really hacky workaround:

sed -i -e 's/\(org.freedesktop.\)Notifications/\1CenteredNotif/g' /usr/bin/mako > mako-centered
sed -i -e 's/\(org.freedesktop.\)Notifications/\1CenteredNotif/g' /usr/bin/makoctl > makoctl-centered
chmod a+x mako{,ctl}-centered
./mako-centered --anchor center

And suddenly you have a different instance of mako listening on a different bus. (Make sure that the user-defined CenteredNotif has exactly the same lenght as Notifications, to not break the binary any more than necessary.) Then, send messages not with notify-send and the like, but passing directly to a specified bus via arcane invocations like

busctl -j --user call org.freedesktop.CenteredNotif /org/freedesktop/CenteredNotif org.freedesktop.CenteredNotif Notify 'susssasa{sv}i' \
  appname 0 icon subject body \
  4 action-name1 action-exec1 action-name2 action-exec2 \
  2 value i 10 synchronous s tagname 1000

The 0 is the id of a notification to be replaced; should be 0 if it's a new notification. The 4 is twice the number of actions, followed by pairs of action name and command. The 2 is the number of hints, followed by triples of key (a string), type-id of the corresponding value, and the value itself.

Not thoroughly tested, but it seems to work better than I expected, to be honest...

[vilhalmer]

This is going to be solved by #228.

[emersion]

Implemented in #228