So far ci maintains the same layout regardless of size. Although it uses a Flex layout with some static components, the basic layout is the same regardless of size. This has the effect of cutting off text in the directory list with a narrow screen, since that component does not scroll horizontally. In this case, the directory list should be situated on top of the details pane. There should also be a minimum size requirement for ci such that the user understands that they will not have proper usage of the app at that size or below.
Summary:
- Change layout of
ci on smaller screen sizes
- Define minimum screen dimensions for proper usage
- Consider overlapping the directory list and the details pane on smaller screen sizes (like a stack of cards)
- Dynamically change the size of the title pane when the current directory wraps
- Consider different layouts when the vertical dimension is larger than the horizontal
There is already some dynamic resizing capability built into tview, in particular via the Flex primitive. We can take the resize event from tview to extend the resizing capabilities of the app to implement a few of the above points.
One thing to keep in mind is that we can possibly store the alternative layouts in memory and assign the main app components to those as well. That way, we would only need to switch out the root primitive in the Application instance. Be wary of how this could affect input capture and event propagation.
So far
cimaintains the same layout regardless of size. Although it uses aFlexlayout with some static components, the basic layout is the same regardless of size. This has the effect of cutting off text in the directory list with a narrow screen, since that component does not scroll horizontally. In this case, the directory list should be situated on top of the details pane. There should also be a minimum size requirement forcisuch that the user understands that they will not have proper usage of the app at that size or below.Summary:
cion smaller screen sizesThere is already some dynamic resizing capability built into
tview, in particular via theFlexprimitive. We can take the resize event fromtviewto extend the resizing capabilities of the app to implement a few of the above points.One thing to keep in mind is that we can possibly store the alternative layouts in memory and assign the main app components to those as well. That way, we would only need to switch out the root primitive in the
Applicationinstance. Be wary of how this could affect input capture and event propagation.