Skip to content

feat: implement support for monitoring D-Bus signals#63

Merged
f-person merged 6 commits intof-person:masterfrom
FineFindus:feat/monitor-dbus
Mar 28, 2026
Merged

feat: implement support for monitoring D-Bus signals#63
f-person merged 6 commits intof-person:masterfrom
FineFindus:feat/monitor-dbus

Conversation

@FineFindus
Copy link
Copy Markdown
Contributor

Implements support for using dbus-monitor, which allows direct monitoring of signals, which are send when the settings changes.

This reduces the system load, as continuous polling is no longer required, as well as improving the responsiveness, as the theme is now updated immediately, instead of waiting for the next polling-cycle to complete.

If dbus-monitor is not available, the polling method will be used as a fallback.

Screencast.From.2025-08-03.10-29-43.mp4

@FineFindus FineFindus force-pushed the feat/monitor-dbus branch 3 times, most recently from 2a10a42 to e01d9c8 Compare August 3, 2025 09:25
Implements support for using `dbus-monitor`, which allows direct monitoring of
signals, which are send when the settings changes.

This reduces the system load, as continuous polling is no longer required, as
well as improving the responsiveness, as the theme is now updated immediately,
instead of waiting for the next polling-cycle to complete.

If `dbus-monitor` is not available, the polling method will be used as a
fallback.
@aliaksandr-trush
Copy link
Copy Markdown

Tested this change and it works great!

With the current implementation (using dbus-send) with default opts the plugin could consume 100% CPU (more details could be found in flatpak/xdg-desktop-portal#1416), but with moving to dbus-monitor the plugin does not use CPU resources at all.

Comment thread lua/auto-dark-mode/interval.lua Outdated
Comment thread lua/auto-dark-mode/init.lua Outdated
Comment thread lua/auto-dark-mode/interval.lua Outdated
@FineFindus
Copy link
Copy Markdown
Contributor Author

This should also solve #64.

@x1unix
Copy link
Copy Markdown

x1unix commented Mar 26, 2026

@FineFindus thanks for the solution.

I've found a bug - after neovim instance is closed, the created dbus-monitor process still exists.

The fix is here: x1unix@138a39a

For example, I restarted my neovim 3 times and got 2 orphan dbus-monitor processes left from previous instances:

image

FineFindus added a commit to FineFindus/auto-dark-mode.nvim that referenced this pull request Mar 27, 2026
Avoids the dbus-monitor process staying alive after exiting, thus leaking the
resource.

Ref: neovim/neovim#29475
Ref: f-person#63 (comment)
FineFindus added a commit to FineFindus/auto-dark-mode.nvim that referenced this pull request Mar 27, 2026
Avoids the dbus-monitor process staying alive after exiting, thus leaking the
resource.

Ref: neovim/neovim#29475
Ref: f-person#63 (comment)
FineFindus added a commit to FineFindus/auto-dark-mode.nvim that referenced this pull request Mar 27, 2026
Avoids the dbus-monitor process staying alive after exiting, thus leaking the
resource.

Ref: neovim/neovim#29475
Ref: f-person#63 (comment)
Avoids the dbus-monitor process staying alive after exiting, thus leaking the
resource.

Ref: neovim/neovim#29475
Ref: f-person#63 (comment)
@FineFindus
Copy link
Copy Markdown
Contributor Author

Thanks for the notice and the fix. This seems to be a Neovim bug, which only affects vim.system, so I've adjust the fix a bit :)

Copy link
Copy Markdown
Owner

@f-person f-person left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@f-person f-person merged commit fc572de into f-person:master Mar 28, 2026
16 checks passed
@FineFindus FineFindus deleted the feat/monitor-dbus branch March 28, 2026 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants