jpunie

Resolving image paths which are defined as constant/static in Scenic on Raspberry PI with Nerves

Hello,

While testing the scenic example in combination with Nerves on a RPi3 with a touchscreen, it became clear that the images where not rendering. At first I thought it would be related to the Scenic RPI driver, but this was not the case. Debugging of the path variables resulted in a clear path resolving issue at compile time.

When looking a the default splash.ex the parrot image is loaded as follows:

 @parrot_path :code.priv_dir(:scenic_example)
               |> Path.join("/static/images/scenic_parrot.png")
 @parrot_hash Scenic.Cache.Support.Hash.file!(@parrot_path, :sha)

:code.priv_dir(:scenic_example) will result with a path on my local file system, not on the target.

I had to fix/change this path issue with a config, but maybe this can be done in a more elegant way. My current workaround:

config/config.exs:

config :scenic_example, :priv_dir, "./_build/dev/lib/scenic_example/priv/"

config/rpi3.exs:

config :scenic_example, :priv_dir, "/srv/erlang/lib/scenic_example-0.1.0/priv"

splash.ex:

@parrot_file "/static/images/scenic_parrot.png"
@parrot_path Application.get_env(:scenic_example, :priv_dir)
               |> Path.join(@parrot_file)
@parrot_hash_path :code.priv_dir(:scenic_example)
               |> Path.join(@parrot_file)
@parrot_hash Scenic.Cache.Support.Hash.file!(@parrot_hash_path, :sha)

The hash has to be calculated at compile time using the file on my local filesystem, hence the double paths.

What would be a more elegant solution to solve this?
Also when the application will be versioned, the path in rpi3.exs has to be changed also, which could be an issue in the future.
Removing the static definitions is always an option, but I think in general the static definitions will work better and easier in the future.

3 comments

/nerves /scenic #scenic-nerves #nerves-questions

3 1032 3

2021-08-04 08:04:16 UTC

Most Liked

axelson

Scenic Core Team

Hi @jpunie, indeed that is a known issue/annoyance when working with Scenic, especially when also using Nerves. I wouldn’t worry too much about an elegant way to solve this because Scenic 0.11 is coming soon and how assets work is being re-written, in part because of this specific issue.

Here’s some relevant info:

scenic/guides/upgrading_to_v0.11.md at v0.11 · ScenicFramework/scenic · GitHub
Refactor: new ideas welcome · Issue #207 · ScenicFramework/scenic · GitHub
Comments on the Plan for the big upcoming Scenic update · Issue #210 · ScenicFramework/scenic · GitHub
Recent message in scenic channel of Elixir Slack:

Hey all. Just pushed an update to v0.11 that refactors the way static assets are built. The main change you will need to make is that most of the config is now moved into the assets.ex module itself.The main benefit is that you can now have multiple asset sources that are merged into the final library. This allows deps to have assets that get pulled into the final application. While I was there, the library format is now a struct and accessing the contents has simplified and has more descriptive function names. The main one you will need to update is that Static.fetch is now Static.meta, which is a better name since it retrieves the metadata. Fetch was ambiguous.Now that we can have multiple asset sources, roboto.ttf and roboto_mono.ttf are moved back into scenic itself and don’t need to be carried by the apps.
defmodule Example.Assets do
  use Scenic.Assets.Static,
    otp_app: :poncho_scenic,
    sources: [
      "assets",
      {:scenic, "apps/scenic/assets"}
    ],
    alias: [
      parrot: "images/parrot.jpg"
    ]
end
The sources: list above will point to your local assets folder and the scenic assets by default if you don’t include it.The required config is now just
config :scenic, :assets, module: PonchoScenic.Assets

I believe @boydm is also actively looking for feedback on the assets setup for 0.11, although he may almost be ready to wrap up that portion of work.

Post #2