I think we should keep this in dbus_objects.integration.jeepney. This was what I originally had in mind, hence the BlockingDBusServer and not DBusServer, and it would make it easier to refactor out the Jeepney specific code into a base class.

I wondered if that was what you were going for, but that means you would need trio installed in order to import the combined module, which doesn't seem right. Unless you prefer to hide all of the trio & jeepney.io.trio imports inside the methods that use them?

Hey thank you so much for this, and thank you for making it easy to follow for a noob like me! Im just wondering if the accel/decel feature the steelseries engine has will ever be added? I have a Rival 300 series.

Thanks!

Extra thought: once it supports async handler methods, it's also conceivable that you'd want multiple tasks handling messages from the same D-Bus connection. I think this should mostly work with several tasks calling await server.listen() on the same server object, but there might be some wrinkles with the auto-reset functionality.

Copy/paste the blocking backend, scatter some async and await around, and it basically seems to work. :-)

Tests equivalent to the blocking backend, using pytest-trio to help write tests with Trio.

This doesn't yet know about async methods on the objects, though I don't think it would be hard to add. I think the backends could also share some code, in particular the bits of _handle_msg that deal with looking up the method and validating the signature. But I wanted to do it the easy way first before getting clever.

I'm not really asking you to merge this as is, it's more for discussion at the moment.

Just using an old open ticket instead of creating a new one: Logitech M590 connected via Bluetooth:

$ ratbagctl list
singing-gundi:       M585/M590 

$ ratbagctl M585/M590 info
singing-gundi - M585/M590
             Model: bluetooth:046d:b01b:0
 Number of Buttons: 8
    Number of Leds: 0
Number of Profiles: 1
Profile 0: (active)
  Name: n/a
  Report Rate: 0Hz
  Resolutions:
  Button: 0 is mapped to 'button 1'
  Button: 1 is mapped to 'button 2'
  Button: 2 is mapped to 'button 3'
  Button: 3 is mapped to 'button 4'
  Button: 4 is mapped to 'button 5'
  Button: 5 is mapped to 'wheel-left'
  Button: 6 is mapped to 'wheel-right'
  Button: 7 is mapped to UNKNOWN

dmesg shows:

[43606.943522] input: M585/M590 Keyboard as /devices/virtual/misc/uhid/0005:046D:B01B.0003/input/input18
[43606.943758] input: M585/M590 Mouse as /devices/virtual/misc/uhid/0005:046D:B01B.0003/input/input19
[43606.944709] hid-generic 0005:046D:B01B.0003: input,hidraw1: BLUETOOTH HID v0.11 Keyboard [M585/M590] on 6c:6a:77:3d:03:c8
[43645.455573] input: M585/M590 Keyboard as /devices/virtual/misc/uhid/0005:046D:B01B.0004/input/input21
[43645.456355] input: M585/M590 Mouse as /devices/virtual/misc/uhid/0005:046D:B01B.0004/input/input22
[43645.456721] hid-generic 0005:046D:B01B.0004: input,hidraw1: BLUETOOTH HID v0.11 Keyboard [M585/M590] on 6c:6a:77:3d:03:c8

In Piper I only see Buttons overview, nothing else. I am missing Resolution, Sensitivity.

How would people override for all instances? Overriding a public method is essentially the same as overriding a public callback property.

I meant that print_info should be passed as an argument to the ProjectBuilder's constructor, so that people wouldn't be enticed to overwrite the method on the class instead of the instance: ProjectBuilder(print_info=...).

get_dependencies should also print a message before calling get_requires_for_build_x.

I think that would make sense for a debug message, not a standard info message. Users do not need to know when/if we are fetching the dependencies.

The backend (e.g. setuptools) might print to stdout when building without isolation, when we call get_dependencies as part of checking if dependencies are satisfied, so there might be a block of text which will precede * Building .... This confused me when I tried it out, hence my suggestion.

This allows people to either overwrite the class method or the instance method.

I'm generally averse to mutating things in Python unless it's done for performance reasons. My preference would be to pass a callback to __init__ which would default to print_info from build. Consumers would be able to use functools.partial or a wrapper to override the default for all instances of the class if that's what they want.

we can totally change the prefix there to something like [build]

I think that'd help with making our output stand out.