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

Support a "fixed" size constraint that corresponds to the size of Image #82

Open
iogrt opened this issue Apr 12, 2024 · 3 comments
Open
Assignees

Comments

@iogrt
Copy link

iogrt commented Apr 12, 2024

Why

Current options make it so that rendering fixed size TUI images requires us to know the size they'll take up.

It seems to me that it's possible to compute this size by using imageHeight and imageWidth from vty.

I believe this is how brick does it.

Proposed solution:

Add Constraint_Fit and corresponding fit function.

@iogrt
Copy link
Author

iogrt commented Apr 16, 2024

I believe I was almost able to implement this:

sizeOfRegion o imgs =
  fmap Constraint_Fixed
    <$> mapDynM
      ( \r -> do
          a <- sample imgs
          let direction = (if r == Orientation_Column then V.imageHeight else V.imageWidth)
          pure $
            foldr
              ( \y x ->
                  direction y + x
              )
              0
              a
      )
      o

fit child = do
  ori <- askOrientation
  (_, images) <- listenImages child
  c <- sizeOfRegion ori images
  grout c child

listenImages being an listen implementation for the ImageWriter
Unfortunately this hangs. I believe it's due to the fact that I'm samping the Behavior t [Image]. Is there any way I could get around?

@ali-abrar
Copy link
Member

Making sure I understand: is the idea here to do something like fixed but having the size part of the constraint computed by the actual size of the child?

@iogrt
Copy link
Author

iogrt commented May 26, 2024

yes exactly

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

No branches or pull requests

3 participants