hub-client: "Expand markup" and "Expand preview" should hide the other pane instead of shrinking it

Đang mở
#1,037 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
72/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
frontend

Hướng nghiên cứu

Start with hub-client/src/components/ViewToggleControl.tsx and hub-client/src/components/Editor.tsx to trace how split presets reach the pane layout; then read hub-client/src/components/Editor.css and hub-client/src/components/DocumentTopBar.tsx. Check how PreviewRouter supplies diagnostics before changing pane visibility. Done means each expand button hides the other pane and divider, equal split restores both with current content, diagnostics keep updating, and files without previews remain unchanged.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Goal

In the editor's document header, "Expand markup" and "Expand preview" hide the other pane instead of shrinking it. "Split equally" is unchanged.

Today each expand button moves the pane divider to its drag limit, which leaves the other pane at 15% of the editing area's width. The markup pane is the source editor on the left. The preview pane is the rendered document on the right.

Done means:

  • After "Expand markup", only the markup pane is on screen. After "Expand preview", only the preview pane is. Nothing of the other pane remains, divider included.
  • "Split equally" brings both panes back at 50/50, and the pane that was hidden shows the current content.
  • The button for the current layout shows as active.
  • The editor's diagnostics (error markers in the markup pane) keep updating while the preview is hidden.
  • Files with no preview pane (images, plain-text files such as .yml or .css) behave as today: the buttons stay disabled and the editor stays visible.

Why

A shrunk pane is a narrow strip that only makes sense to someone who already knows what it is.

  • "Expand preview" leaves the markup as a 15% column of squashed raw text next to the rendered document. A user who knows little Markdown and works in the preview, where paragraphs can be edited in place (WYSIWYG), reads that column as noise.
  • "Expand markup" has the mirror problem: the rendered document is squeezed into a narrow 15% column.
  • A hidden pane gives the chosen pane the whole width, and the screen shows what the button says.
  • The header's fullscreen-preview action is not a substitute: it also hides the header and the sidebar.

The presets mirror the drag limits today (see the comment above SPLIT_PRESETS). This issue suggests letting the two expand buttons go past them, while a drag keeps its 15–85% limits.

References

Code pointers (main at f4a3853):

  • hub-client/src/components/ViewToggleControl.tsx: the three buttons; SPLIT_PRESETS 0.85 / 0.5 / 0.15.
  • hub-client/src/components/DocumentTopBar.tsx: renders the buttons from splitFraction, onSetSplit and splitDisabled.
  • hub-client/src/components/Editor.tsx: editorPaneFraction, handleSetSplitPreset (does not clamp), the drag handler (clamps to 0.15–0.85), each pane's flex, and the .pane-divider.
  • hub-client/src/components/Editor.css: .pane, .pane-divider, .split-animating.

One possible approach, from reading the code (not tried in a browser):

  • Have the expand buttons send 1 (markup only) or 0 (preview only) instead of 0.85 or 0.15. A drag cannot produce either value, so they can identify the collapsed state.
  • Hide the collapsed pane and the divider, for example with CSS keyed on that state.
  • Hide the preview rather than unmount it: PreviewRouter feeds the editor's diagnostics (onDiagnosticsChange).
  • The viewMode modes ('markup' and 'preview' in ViewModeContext.tsx, with the .view-mode-* rules in Editor.css) are no shortcut: nothing calls setViewMode, and those rules shrink the other pane to a strip of roughly 120–220 px instead of hiding it.
Ngôn ngữ chính
Rust
Star
293
Fork
20
Merge trung bình
12 giờ 21 phút
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của quarto-dev/q2

Tất cả issue của quarto-dev/q2

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.