mako icon indicating copy to clipboard operation
mako copied to clipboard

timeout options passed on cmdline in sway config not respected

Open kevr opened this issue 4 years ago • 1 comments

Hello mako devs and users,

Thanks a lot for maintaining this project. It is quite nice.

On to the point of this issue: I've encountered a bit of a mind boggling problem while using the --default-timeout and/or --ignore-timeout options while executing mako within sway's configuration:

exec --no-startup-id mako --default-timeout=1000 --ignore-timeout=1

Doing this inside of sway's config does not seem to respect the values I provide. However, if I configure it to do so in ~/.config/mako/config, everything works as expected.

If I execute mako within a shell after starting sway, the options do take effect.

To clarify: The notifications just stay up there forever, as would be done without the options being configured.

Just leaving this here in case it helps. I'm really not sure why using the exact same shell options within sway's config would no-op those options.

kevr avatar Sep 12 '21 02:09 kevr

If you look at the running mako process' command line, does it have the arguments? I'm wondering if the instance of mako started from sway's config is failing to start entirely and mako is later bus-activated when the first notification is received instead.

I did test locally and passing the arguments from sway's config works. Which version of sway are you running?

vilhalmer avatar Dec 04 '21 17:12 vilhalmer