You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a method to change a property and it has a boolean to avoid sending signals, but it is likely not leveraged by many applications and is slightly cumbersome. The current expections of an application are:
The default implementations of an application, if it has properties it needs to change beyond the constructor is:
1. Call constructor with defer_emit.
2. Set N properties with signal=false.
3. Call object->emit_interface_added when done.
I think you're proposing there are two problems.
a. #2 should default to signal=false automatically at least in this sequence.
b. #2 and #3 should do nothing when service name isn't claimed.
We should come up with something better to give object-level control on property signals to avoid signal floods for typical use cases. Whatever is implemented we need to be careful to not break signals on existing applications that might be creating objects dynamically.
The text was updated successfully, but these errors were encountered:
Conversation with @bradbishop : https://discord.com/channels/775381525260664832/775381525260664836/784509529832292363
There is a method to change a property and it has a boolean to avoid sending signals, but it is likely not leveraged by many applications and is slightly cumbersome. The current expections of an application are:
We should come up with something better to give object-level control on property signals to avoid signal floods for typical use cases. Whatever is implemented we need to be careful to not break signals on existing applications that might be creating objects dynamically.
The text was updated successfully, but these errors were encountered: