Solve the sequencer client unregistering problem

[derselbst]

This is the second solution to the problem of #609.

The difference is that responsibility for calling fluid_sequencer_unregister_client() in case of FLUID_SEQ_UNREGISTERING events has been moved to fluid_sequencer_send_now(). In other words, a FLUID_SEQ_UNREGISTERING event now really unregisters the client, no matter how the client's callback function looks like. I'm afraid that technically this is a breaking change. This is also the reason why the unit test test_seq_event_queue_sort currently fails. (I'll fix the test if we decide to move forward with this approach.)

Opinions?

[mawe42]

I think I like this approach better than #609.

To solve the problem with custom callbacks not receiving the FLUID_SEQ_UNREGISTERING event anymore, how about introducing another internal event FLUID_SEQ_UNREGISTER (or similar). That new event is used in all places where we currently use FLUID_SEQ_UNREGISTERING. But before we actually unregister the client in fluid_sequencer_send_now, we send a FLUID_SEQ_UNREGISTERING event to the callback to inform it of the upcoming unregister.

Also a breaking change, as custom clients can no longer be unregistered by sending a FLUID_SEQ_UNREGISTERING event. But as the explicit unregister is no longer necessary for those clients anyway it feels like a more consistent API.

And IMHO, unregistering clients via an event feels fine as an internal implementation detail, but slightly weird as part of a public API.

[mawe42]

I think this comment would need to be updated (remove reference to seqbind structure)?

[derselbst]

Ok, thanks. I also prefer this solution.

To solve the problem with custom callbacks not receiving the FLUID_SEQ_UNREGISTERING event anymore,

Misunderstanding (I guess the new if-clause in fluid_sequencer_send_now() confused you):

Clients will still receive the unregistering event (this is done in fluid_sequencer_unregister_client()). ...Just that no matter what clients do with that event, they will have been unregistered afterwards. Previously it was the responsibility of the clients callback to unregister itself when it received an unregistering event. To pacify my initial "breaking change" thought, you can also put it differently and say: It's actually a bug if clients are not being unregistered after they have received the event. This would make things easier, would you agree?

[mawe42]

I guess the new if-clause in fluid_sequencer_send_now() confused you

Yes, and I didn't notice that fluid_sequencer_unregister_client sends the event.

To pacify my initial "breaking change" thought, you can also put it differently and say: It's actually a bug if clients are not being unregistered after they have received the event. This would make things easier, would you agree?

Yes, that sounds much better :-) And I totally agree that this is a bug that needs to be fixed, not just a changed feature/behaviour.