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

Separate Details pane if screen width is large enough #334

Open
keyserj opened this issue Feb 15, 2024 · 2 comments · May be fixed by #442
Open

Separate Details pane if screen width is large enough #334

keyserj opened this issue Feb 15, 2024 · 2 comments · May be fixed by #442
Assignees
Labels
convenient makes the tool easier to use enhancement New feature or request ok first issue Clear & narrow scope but tougher than "good first issue" QoL small change the improves the feel of using the tool
Milestone

Comments

@keyserj
Copy link
Collaborator

keyserj commented Feb 15, 2024

Is your feature request related to a problem? Please describe.
Right now, the Topic Pane consists of Details and Views tabs:
image
But it's slightly annoying to have to click between these two tabs if I have enough screen real estate to show both.

Describe the solution you'd like
If I have a high enough resolution (mine is 1920px width), there's more than ample space to see both panes at once (similar to Figma):
image

Notes:

  • We currently put the Topic Pane on the bottom of the screen for portrait screens (e.g. mobile); we should still keep one pane in this situation (even if we have a large portrait screen)

Describe alternatives you've considered

Additional context

  • naming: Topic Pane with Details tab and Views tab if combined, Views Pane and Details Pane if separate

Technical ideas

  • How to make Primary vs Secondary Pane, depending on screen size, become open after clicking Details indicator? Right now, is controlled by isTopicPaneOpen via pane store
    • need a variable for each toggle action - so still need isPaneOpen for the expand/collapse button, but that could be localized to the Pane; then we just need isDetailsPaneOpen for the Details Indicator click. Whether Topic Pane or Details Pane uses this would be based on screen size
  • MUI breakpoints should be helpful
    • we're already using them here too (probably show double panes if above MUI's xl width, i.e. 1536 pixels)
@keyserj keyserj added enhancement New feature or request needs tech design Technical solution should be figured out before implementing needs review Hasn't been reviewed by a maintainer yet labels Feb 15, 2024
@keyserj keyserj added ok first issue Clear & narrow scope but tougher than "good first issue" QoL small change the improves the feel of using the tool convenient makes the tool easier to use and removed needs tech design Technical solution should be figured out before implementing needs review Hasn't been reviewed by a maintainer yet labels Feb 21, 2024
@alextilot alextilot self-assigned this Jun 3, 2024
@alextilot
Copy link
Collaborator

alextilot commented Jun 6, 2024

It might be nice to have 2 configuration options.

  1. Force split/combine, allow user to change preference
  2. Allow the user to swap the 2 pane's information with each other details <-> views.

Thoughts?

@keyserj
Copy link
Collaborator Author

keyserj commented Jun 6, 2024

It might be nice to have 2 configuration options.

  1. Force split/combine, allow user to change preference
  2. Allow the user to swap the 2 pane's information with each other details <-> views.

Thoughts?

Hmm. I agree that these two would probably be nice, but I don't think are necessary. I think it's likely that most users will prefer double pane with > 1500px monitor, and probably won't have much preference which side details/views are on.

I suppose you could probably get away with a simple config for both (like alwaysOnePane: boolean and detailsOnLeftPane: boolean. That might also create some awkwardness with the situation when one pane is true and detailsOnLeftPane is false. Potentially we could go with a flexible tab-docking setup, but that seems like way more effort than it's worth (and complexity might be too much as well if the abstraction isn't well-organized).

@alextilot alextilot linked a pull request Jun 14, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
convenient makes the tool easier to use enhancement New feature or request ok first issue Clear & narrow scope but tougher than "good first issue" QoL small change the improves the feel of using the tool
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants