Sync prod with master #107
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Media Player + Ramayanam Scraper
Dynamic Admin Controls
Also: - cleans up the pattern for adding new seeders - groups seed functions within SourceSeeders
There's an odd behaviour with translations. tldr; 1. I create chapter properly 2. I create translation for chapter properly 3. i query chapter, then preload the translations for the chap, then i get both the one I actually inserted + the gita chap 1 translation
Observations: 1. Reminder about the case where if the user has multiple browser tabs open pointing to our application, then the handshake will get messed up, the player views will crash -- it's even more apparent when there are more than one voices 2. the player still does the pre-load behaviour, where the playback continues until the player is interacted with, when I navigate from one chapter to another. Steps: 1. play hanuman chalisa chapter's audio 2. instead of a refresh, navigate to gita::chapter1 3. observe that the playback for chalisa continues (but the player is actually in a !playing? state [as seen by the play button being displayed]) 4. observe that the new handshake actually is handled properly 5. the audio player only starts playing the gita chapter's audio once the user interacts with the player and clicks on the play button
Conflicts: - lib/vyasa/written.ex: minor, kept the sensible one
This commit finally made me feel that I understood the lang & the framework to a working-degree of familiarity. Really happy with myself. The seeking by clicking works well !!!
Co-authored-by: Ritesh Kumar <ritesh@emerald.pink> Signed-off-by: a/vivekbala <avivekbala@gmail.com>
* Cleanups: rm old .livemds * Update migrator script's save() to preload video * fix imprt stmt & add guard to hoverrune * Wire up voice metadata note: because of this, the PR requires the deployment to use a fresh json file this prepares for the info needed by media sessions does some linting using the latest elixir-ls * Use og image for artwork Not sure why it doesn't display when using the emulator. I think it's better if I test it on the deployed version directly, not sure if the testing method is accurate. * Minor cleanups * Meta cleanup encode * Add comma * Simple changes * Revert use of Map.from_struct * Shift guarding to playback.ex instead of encoder * Add nil clause for meta::Jason encode() * @derive * except artwork * Handle nil case for artwork better w better guard * Minor changes * Use dummy metadata example * Revert dummy example * iAnother dummy attempt * Another attempt * test dict creation * test use of extra key in media metadata * Test: use geenrated artwork * minor change * Change MIME type for generated_artwork jpeg -> png * Minor change * Use createMediaMetadataPayload() * Server Logging to Console & Image Lib Update * Init media session @ metadata load Init functions don't have action handlers yet * Guard against null playback * Shift mediaSession update to before play * Attempt earlier update of metadata * Use waiting spinner to prevent early play triggers * clear source title index * [WIP]: basic DM, demo state & assigned components Still have no idea how the VyasaWeb.SourceLive.Chapter.Index is supposed to be rendered as @inner_content within the new display_manager.html.heex * Rename CommandGroup -> ControlPanel * Initial Wire up %UserMode{} to Control Panel * Switch modes, add user_mode.ex to tw config * Prevent full page-reloads via push_navigate() This prevents the socket from being killed at every navigation, so the overlay's states is still managed without any issue. Actually, currently, there's a issue with definitions on the router-side problem: if I do a push_navigate to the path matching =/explore/:source_title/:chap_no= from =/explore/:source_title/=, it will trigger a socket error: =phx-F-vfg0fv3-NR4yFB error: unauthorized live_redirect. Falling back to page request -= Hunch: it's because of the router defining two different live_session scopes (anon vs sangh) so it's not allowing a =push_navigate()= and hence it's reverting to a full page reload. Do you know a quick fix to this? live_session :gen_anon_session, on_mount: [{VyasaWeb.Session, :anon}] do live "/explore/", SourceLive.Index, :index live "/explore/:source_title/", SourceLive.Show, :show #live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index live "/explore/:source_title/:chap_no/:verse_no", SourceLive.Chapter.ShowVerse, :show end live_session :gen_sangh_session, on_mount: [{VyasaWeb.Session, :sangh}] do live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index end * [temp] shift all from anon session to sangh sess * Minor changes * [WIP, Attempt] Shift from layout to heex template Still the thing dies on me * Trigger DIFF * persistent marks * Use DM @ router actions, load data :show_sources * Add data load for :show_chapters action on DM * Use push_patch() @ :show_sources -> :show_chapters * Handle data load & nav:show_chapters->:show_verses * Create VyasaWeb.Content.Verses live_component * Wire up handshakes successfully, shift to patches Also done: 1. use maybe_stream_configure/3 (see note in definition) 2. change backlinks from navigate -> patch so that a full-page reload is NOT done. This is also what allows the state of ControlPanel and ActionBar to be maintained despite going back and forth content. 3. actually wiring up the event handlers and stuff that allowed the handshakes to happen TODOs: 1. fix css nonsense with how the content is being displayed. 2. future iteration needs a cleanup, this module is too fat. * Fix css issues * More minor css fixes * handle empty events payload * migrator restore * fix voice non existo with guard clause * Vyas Font * Script Support * Add fallthrough to devanagari for lang2script --------- Signed-off-by: a/vivekbala <avivekbala@gmail.com> Co-authored-by: ks0m1c_dharma <sakiyamuni@sams.ara> Co-authored-by: a/vivekbala <avivekbala@gmail.com>
This PR establishes the pattern on how we may define individual user_modes that determine what's presented to the user.
there are the following things that can be slotted into:
control panel -- which has its own components
hoverune
typically for quick actions that are context specific (e.g. quick drafts)
action_bar
for common actions like navigation through an ordered list
content
for determining what content is to be displayed. This shall be user_mode-agnostic for now
When switching user modes from A to B, the DM will be able to switch what actions the user can do based on what's defined in the %UserMode{}
* Cleanups: rm old .livemds
* Update migrator script's save() to preload video
* fix imprt stmt & add guard to hoverrune
* Wire up voice metadata
note: because of this, the PR requires the deployment to use a fresh json file
this prepares for the info needed by media sessions
does some linting using the latest elixir-ls
* Use og image for artwork
Not sure why it doesn't display when using the emulator.
I think it's better if I test it on the deployed version directly, not
sure if the testing method is accurate.
* Minor cleanups
* Meta cleanup encode
* Add comma
* Simple changes
* Revert use of Map.from_struct
* Shift guarding to playback.ex instead of encoder
* Add nil clause for meta::Jason encode()
* @derive
* except artwork
* Handle nil case for artwork better w better guard
* Minor changes
* Use dummy metadata example
* Revert dummy example
* iAnother dummy attempt
* Another attempt
* test dict creation
* test use of extra key in media metadata
* Test: use geenrated artwork
* minor change
* Change MIME type for generated_artwork jpeg -> png
* Minor change
* Use createMediaMetadataPayload()
* Server Logging to Console & Image Lib Update
* Init media session @ metadata load
Init functions don't have action handlers yet
* Guard against null playback
* Shift mediaSession update to before play
* Attempt earlier update of metadata
* Use waiting spinner to prevent early play triggers
* clear source title index
* [WIP]: basic DM, demo state & assigned components
Still have no idea how the VyasaWeb.SourceLive.Chapter.Index is supposed
to be rendered as @inner_content within the new
display_manager.html.heex
* Rename CommandGroup -> ControlPanel
* Initial Wire up %UserMode{} to Control Panel
* Switch modes, add user_mode.ex to tw config
* Prevent full page-reloads via push_navigate()
This prevents the socket from being killed at every navigation, so the
overlay's states is still managed without any issue.
Actually, currently, there's a issue with definitions on the router-side
problem: if I do a push_navigate to the path matching =/explore/:source_title/:chap_no= from =/explore/:source_title/=,
it will trigger a socket error:
=phx-F-vfg0fv3-NR4yFB error: unauthorized live_redirect. Falling back to page request -=
Hunch: it's because of the router defining two different live_session scopes (anon vs sangh) so it's
not allowing a =push_navigate()= and hence it's reverting to a full page reload.
Do you know a quick fix to this?
live_session :gen_anon_session,
on_mount: [{VyasaWeb.Session, :anon}] do
live "/explore/", SourceLive.Index, :index
live "/explore/:source_title/", SourceLive.Show, :show
#live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index
live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index
live "/explore/:source_title/:chap_no/:verse_no", SourceLive.Chapter.ShowVerse, :show
end
live_session :gen_sangh_session,
on_mount: [{VyasaWeb.Session, :sangh}] do
live "/explore/:source_title/:chap_no", SourceLive.Chapter.Index, :index
end
* [temp] shift all from anon session to sangh sess
* Minor changes
* [WIP, Attempt] Shift from layout to heex template
Still the thing dies on me
* Trigger DIFF
* persistent marks
* Use DM @ router actions, load data :show_sources
* Add data load for :show_chapters action on DM
* Use push_patch() @ :show_sources -> :show_chapters
* Handle data load & nav:show_chapters->:show_verses
* Create VyasaWeb.Content.Verses live_component
* Wire up handshakes successfully, shift to patches
Also done:
1. use maybe_stream_configure/3 (see note in definition)
2. change backlinks from navigate -> patch so that a full-page reload is
NOT done. This is also what allows the state of ControlPanel and
ActionBar to be maintained despite going back and forth content.
3. actually wiring up the event handlers and stuff that allowed the
handshakes to happen
TODOs:
1. fix css nonsense with how the content is being displayed.
2. future iteration needs a cleanup, this module is too fat.
* Fix css issues
* More minor css fixes
* handle empty events payload
* migrator restore
* fix voice non existo with guard clause
* Vyas Font
* Script Support
* Add fallthrough to devanagari for lang2script
* Cleanup: extract components into different files
* Kill source_live/
@ks0m1c this is no longer needed since we're doubling down on the explorer paradigm
because I unintentionally made the mistake of editing these files while
testing something, I realise that leaving this in here may be confusing.
As such I'm making this commit just for removal of source_live/
* [WIP]: partial impl browser hist popstate handler
* Add missing file for BrowserNavInterceptor hook
* LiveAdmin unblock
* Gettext Update Backends
* Change tag->ref, Vyasa.Gettext->VyasaWeb.Gettext
* Rm use of BrowserNavInterceptor
Initially this was supposed to be an attempt at a workaround, but now
that we've bumped up the version number for live_view, the navigation
state handling based on the back button works okay.
To be honest, the state management is still a little flakey but I have
spent too long investigating this, will move on first.
* Minor cleanup of unused code
* Define slotting pattern, let DM handle hoverune
- CLOSING NOTE <span class="timestamp-wrapper"><span class="timestamp">[2024-08-26 Mon 00:37] </span></span>
Nice, this gives a pattern that the control panel stuff can follow as well.
- intent:
Hoverune should be universal, if kept, and shouldn’t be specific to the verses only.
Additionally, action buttons within it need to be determinable by the user<sub>mode</sub>.
We can do this by defining what buttons the user-mode should be rendering. The rendering can be deferred till later, and use a rendering function from elsewhere within the VyasaWeb namespace.
This is essentially how we “slot” in the buttons we want.
- pre-req understanding:
- understand how the binding actions work for hoverrune
- interesting: [this](file:///Users/rtshkmr/Projects/vyasa/lib/vyasa/draft.ex) seems like a way to do a multi-step parsing of sorts for a single function
- Learning: so for the slotting behaviour, the user<sub>mode.ex</sub> is not in within vyasa<sub>web</sub> and is purely server side. Therefore, we shall just use atoms to id what kind of button we want to render, and we can define them within components
So we can define the buttons like this:
# Vyasa.Display.UserMode @ lib/vyasa/display/
"read" => %{
mode: "read",
mode_icon_name: "hero-book-open",
action_bar_component: VyasaWeb.MediaLive.MediaBridge,
control_panel_component: VyasaWeb.ControlPanel,
quick_action_buttons: [:mark_quote, :bookmark]
}
And we can define the how to render based on these ids:
def render_hoverune_button(:bookmark, assigns) do
~H"""
<button class="text-gray-600 hover:text-red-600 focus:outline-none">
<.icon name="hero-bookmark-mini" class="w-5 h-5 hover:text-black hover:cursor-pointer" />
</button>
"""
end
and we can just call these functions from within a live<sub>component</sub>:
attr :quick_action_buttons, :list_of, type: :atom, default: []
@impl true
def render(assigns) do
~H"""
<div
id="hoverune"
phx-update="ignore"
class="absolute hidden top-0 left-0 max-w-max group-hover:flex items-center space-x-2 bg-white/80 rounded-lg shadow-lg px-4 py-2 border border-gray-200 transition-all duration-300 ease-in-out"
>
<div :for={button_id <- @quick_action_buttons}>
<%= VyasaWeb.Display.UserMode.Components.render_hoverune_button(button_id, %{}) %>
</div>
</div>
"""
end
* Minor change
* Support slots for control panel modes to switch to
This handles the button UI flow for the major user-mode changes (e.g. :read
-> :draft).
We need to just define the modes to display when currently in a
particular mode and then we can display buttons for those modes from there.
* Change specific render fns -> generic fn component
* Cleanup: rm remnants of BrowserNavInterceptor
* Minor changes
* Shift MediaBridge to be everpresent, improve style
* Add :show_media_bridge_default?, hides MediaBridge
* Add VyasaWeb.Hook.UserAgentHook to do ua_parsing
[Attempt] display topbar only if non-mobile
Not sure if the ua_parsing actually works correctly
Minor change
* Fix ua_parsing issues
Now, we do a check using the family values and doing a regex.
I suspect we'd need to keep updating this if the parsing breaks in
thefuture. but should be good enough for now.
also the different versions of the ua_parser lib seem to be giving
different output
* Minor changes
* [UI]: hide MediaBridge if keyboard open on :mobile
Primarily for quick drafts
on mobile,
1. the mediabridge will be hidden (animated away by right)
2. once done typing, it should be visible again
It corresponds to:
1. if phone keyboard is open, hide the media player,
else show it
so that more screen space is given for mobile devices
* [Attempt] handle capture of enter button press
* [WIP] prepare user_mode to inject action_bar slots
This should be the "interface" to judge what the DM displays.
time to toh for now
* Stream of Marks
* Add Slottable ActionBar, cohere w MediaBridge
Similar to the hoverune implementation, this action_bar.ex live_component also takes in an array of actions, which the user_mode defines and then renders buttons that trigger click events specific to the mode and action_name.
This allows the DM to be the one with the necessary handlers to act on these events.
******* 1. Bars are soft appearing / disappearing
This means that we don't mount / destroy nodes, simply hide and make them appear as and when we need.
This means that we need to make some things "equivalent" and work the same way as it does on MediaBridge and ActionBar.
Suppose there are nav buttons (the left and right stuff) which are generic.
They will DEFINITELY appear on the MediaBridge.
They may or may not appear on the ActionBar.
This means that any button click on the nav buttons on MediaBridge may just be relayed to a optionally present button on the actionbar, along with other buttons on the action bar.
******* 2. Maintain equivalence in UI buttons b/w action-bar and media bridge by relaying button clicks
This will Shim / Relay the nav button click from the media bridge to the corresponding action bar via hooks
Essentially, clicking the nav buttons on the mediabridge will relay to the nav buttons on the action bar, which is mode-specific
Here's some logs to show that the wire-up looks okay (have left the functions empty first).
%Vix.Vips.Image{ref: #Reference<0.3949460734.1140719640.214139>}
[debug] HANDLE EVENT "read::nav_back" in VyasaWeb.DisplayManager.DisplayLive
Parameters: %{"value" => ""}
TRACE: TODO handle nav_event @ action-bar region: %{"event" => "nav_back", "mode" => "read"}
[debug] Replied in 430µs
TRACE: TODO handle nav_event @ action-bar region: %{"event" => "nav_fwd", "mode" => "read"}
[debug] HANDLE EVENT "read::nav_fwd" in VyasaWeb.DisplayManager.DisplayLive
Parameters: %{"value" => ""}
[debug] Replied in 375µs
TRACE handle event for toggle_show_control_panel: false
[debug] HANDLE EVENT "toggle_show_control_panel" in VyasaWeb.DisplayManager.DisplayLive
Component: VyasaWeb.ControlPanel
Parameters: %{"value" => ""}
[debug] Replied in 342µs
[debug] HANDLE EVENT "change_mode" in VyasaWeb.DisplayManager.DisplayLive
Parameters: %{"current_mode" => "read", "target_mode" => "draft", "value" => ""}
[debug] Replied in 162µs
[debug] HANDLE EVENT "draft::nav_fwd" in VyasaWeb.DisplayManager.DisplayLive
Parameters: %{"value" => ""}
TRACE: TODO handle nav_event @ action-bar region: %{"event" => "nav_fwd", "mode" => "draft"}
[debug] Replied in 562µs
TRACE: TODO handle nav_event @ action-bar region: %{"event" => "nav_back", "mode" => "draft"}
[debug] HANDLE EVENT "draft::nav_back" in VyasaWeb.DisplayManager.DisplayLive
Parameters: %{"value" => ""}
[debug] Replied in 573µs
iex(test@127.0.0.1)1>
* Fixed Dupe
Acked-by: ks0m1c_dharma <sakiyamuni@sams.ara>
* Hygiene eq_verse_binding guard
* Style the control panel with glass ui
* Create VerseMatrix live_component
Just comitting this while I make some UI mods next to that.
The reason why a live_component works here is that I expect to use some
collapsible state.
* Minor cleanups / rearranging of code
---------
Signed-off-by: a/vivekbala <avivekbala@gmail.com>
Co-authored-by: ks0m1c_dharma <sakiyamuni@sams.ara>
Co-authored-by: a/vivekbala <avivekbala@gmail.com>
Conflicts: (kept all HEAD) assets/js/app.js assets/js/hooks/index.js lib/vyasa/draft.ex lib/vyasa/written/verse.ex lib/vyasa_web/components/action_bar.ex lib/vyasa_web/components/contexts/read/verse_matrix.ex lib/vyasa_web/components/control_panel.ex lib/vyasa_web/components/hoverune.ex lib/vyasa_web/components/source_content/verses.ex lib/vyasa_web/components/user_mode_components.ex lib/vyasa_web/live/display_manager/display_live.ex lib/vyasa_web/live/display_manager/display_live.html.heex lib/vyasa_web/live/media_live/media_bridge.html.heex lib/vyasa_web/router.ex mix.exs mix.lock
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.