[Bug 766898] player: Add a message queue API in addition to the signals

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766898

--- Comment #8 from Stephan Hesse <tchakabam at gmail.com> ---
fyi our branch has now fixes for the urgent issues functionnality-wise: a
getter method for the bus, fixing the log leak and registering a Gtype for the
player-message enum, and of course unrefing the bus on disposal.

currently we have thus the api message bus in functional state, while keeping
backwards compatibility with the current API.

we should definitely use gst_structure_set instead of the current
implementation when creating data structures in order to avoid the whole
verbosity around GValue stuff, as you suggested. also, create everything ad-hoc
instead of caching transient values in player state. is there anything else
left in order to have the api message bus itself ready? 

before continuing on this: we were discussing that as we remove the signal
dispatcher and signals of GstPlayer, we would create a proxy object that has
the same signals, which would get emitted as it consumes messages from the bus
and emits the corresponding signals. so, first of all I assume then that we
would consume from the bus in sync mode. so we then emit the signals
corresponding to player-messages directly from the thread from which the
player-message got posted, so just connect to sync-message and re-emit in the
same thread? or should the proxy object dispatch the emitter onto some injected
context, like the current main-context-signal-dispatcher?

also: how would you want to call this object? GstPlayerSignalProxy?
GstPlayerMessageProxy? :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.