Hi @destinationunknown, this is intentional and by design.

The plugin implements a minimal server/client interface with communication happening through a socket.
When you run polypomo without arguments, a "server" is started. This is what happens when you add it to a polybar.
If you run multiple bars, you would be running multiple "servers" of polypomo and so they fight with each other when taking ownership of said socket.
I suggest you add polypomo to only one of the displays and use a different configuration for the others.

Technically, it's possible to add an additional command-line argument to identify each client/server to support running multiple independent polypomo instances, but this was never something I felt necessary. In the pomodoro technique you are supposed to focus on a single task at a time and therefore have only one timer running.

To have two widgets accessing a single "server" a completely different interface would be necessary and I found this would complicate the use of the plugin too much.

A workaround is to use:

[module/polypomo]
exec = tail -f /tmp/polypomo.status
tail = true

and then manually launch polypomo > /tmp/polypomo.status.
You will have to ensure this polypomo process is running through some other means.

This approach has the problem that the polypomo.status file will get larger the longer the process runs.
You could alternatively use a linux named pipe with mkfifo /tmp/polypomo.status and use cat /tmp/polypomo.status instead of tail -f. The caveat in this case is that the output will be sent to each client in an alternating fashion, so the widgets will be phased by 1 second for every additional client.

Hope this clarifies why the plugin works the way it does and why this limitation exists.

Does not work with multiple bars #3

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions