[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 #4 from Stephan Hesse <tchakabam at gmail.com> ---
> +create_message_data_from_state (GstPlayer *self, GstPlayerMessage message_type) {
> I think I would prefer separate functions for each type that just takes as 
> parameter the specific fields, instead of polluting the instance struct with them


This is something we can maybe discuss if you like. I am not too attached to
it, we can of course go for what you propose. Just want to explain the reasons
of my choice here :)

The approach I chose satisfies that anything that is posted as a message is
part of the values within the player struct itself. Rather than seeing that as
polution I rather see the fact we keep the actual player state clearly defined
and centralized here as a conceptual decision that makes sense if applied
consistently like this. Since the messages should really reflect the "state of
playback" (position/duration/video-width/height and maybe more) at the moment
the messages are created. Imo this state should also be readable from the
player API at any moment in the same way if applications decide that is how
they want to use it. Generally I think it is better having an explicit state
(holding track of current position and duration values in our own members). The
state changes of the playback (position and duration are also state) which we
reflect here with the message bus is transparent, rather than reflecting a
state that is somehow nested and implicit but not accessible elsewhere from the
API than through the messages.

Furthermore, it centralizes all of the message creation in one place and makes
it easy to post a message from either place. And finally, caching
position/duration or current video dimensions will allow to read those with
less overhead if the application decides to read it via getters.

On the other hand you may of course argue that the messages collected from the
bus will deliver an equivalent representation anyway :) As I said, not a big
deal in the end, but a choice still.

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