Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix/dynamically added elements #198

Merged
merged 3 commits into from
Sep 27, 2019
Merged

Conversation

bblaszkow06
Copy link
Member

@bblaszkow06 bblaszkow06 commented Sep 26, 2019

No description provided.

@bblaszkow06 bblaszkow06 force-pushed the fix/dynamically-added-elements branch from 85236bd to 66d3144 Compare September 26, 2019 15:50
@bblaszkow06 bblaszkow06 requested a review from Hajto September 26, 2019 15:51
Copy link
Contributor

@Hajto Hajto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing i would recomment to change. Just few suggestions and questions.

test/membrane/integration/sync_test.exs Show resolved Hide resolved
@@ -125,6 +128,8 @@ defmodule Membrane.Core.PlaybackHandler do
end
end

@spec unlock_target_state(pb) :: {:ok | {:error, :playback_already_unlocked}, pb}
when pb: Playbackable.t()
def unlock_target_state(playbackable) do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case is not tested (at least via ExUnit), maybe it should? (soft suggestion)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be done, but in separate PR I think

@@ -73,6 +73,7 @@ defmodule Membrane.Core.PlaybackHandler do
def state_change_callback(:prepared, :playing), do: :handle_prepared_to_playing
def state_change_callback(:prepared, :stopped), do: :handle_prepared_to_stopped

@spec change_playback_state(PlaybackState.t(), module(), Playbackable.t()) :: handler_return_t()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handler_return_t assumes that error can be any,
After a once over the file I found those as possible options:

  • playback_already_unlocked
  • invalid_current_playback_state
  • invalid_target_playback_state
  • target_and_current_states_equal

If error is not explicitly one those, maybe we could change handler_return_t and make the error reason at least an atom narrowing down the type?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't see the point of it. handler_return_t is used as a result of a callback so the returned error can have any reason and it doesn't have to be an atom (a tuple may appear for example)

lib/membrane/pipeline.ex Show resolved Hide resolved
@bblaszkow06 bblaszkow06 merged commit 25e3110 into master Sep 27, 2019
@bblaszkow06 bblaszkow06 deleted the fix/dynamically-added-elements branch September 27, 2019 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants