On Thu, 2022-08-25 at 16:06 -0700, Luiz Augusto von Dentz wrote: > Hi Bastien, > > On Thu, Aug 25, 2022 at 8:32 AM Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > > > On Thu, 2022-08-25 at 15:26 +0200, Bastien Nocera wrote: > > > This property should allow any program to show the transitional > > > state, > > > not just the one that requested the change, and will also show > > > transitional states that were the results of other system > > > changes, > > > like > > > rfkill changes. > > > > Looks like the bot doesn't like where I put those comments. > > > > If anyone can comment on the API I used, and I'll iterate the > > actual > > implementation. I'd like the API to be settled by the time GNOME 43 > > ships, so we can rely on it there. > > I wonder what are you actually after with these changes, in most > cases > I'd say the changes shall just be queued, anyway perhaps the problem > was something related to: > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=ede7b915980fbc80eff80aa189c35ca016956c61 > That helps with one of the problems I ran into (resetting the transitional state on failure), thanks. What I'm after is a transitional state when the Bluetooth adapter is being powered on, as it can take more than "an instant" (aka 200msec) to turn on, and sometimes much longer. Users in that transition period can wonder why the adapter is already on but not usable, or still off. This is even worse if the enablement doesn't work, as it could show that the device was on/available for a time before stopping being available, depending on which option the UI developer took, which is obviously not true. I updated the patch for the latest git and completed the commit message, let me know if that helps.
