Skip to content

Phase B.5c followup — Backend::draw_dialog needs dual-Pango-layout handling #267

Description

@JDonaghy

Goal

Add `Backend::draw_dialog` to round out the trait coverage from #259.

What's blocking

The lifted rasteriser `quadraui::gtk::draw_dialog` takes two `pango::Layout` handles — `body_layout` for the dialog body text (monospace, editor font) and `ui_layout` for the title + buttons (sans-serif, UI font). Vimcode's call site builds both at draw time.

`GtkBackend` only stashes one Pango layout in its frame scope (`current_layout_ptr`). The trait method needs either:

  1. Backend stashes both layouts. Add a second `current_ui_layout_ptr` and a setter on `GtkBackend`. Trait method derefs both, calls rasteriser. Cleanest but extends the frame-scope contract.
  2. Trait method param. Pass the secondary Pango layout as a trait method param. Couples the trait to GTK-specific font handling — no good for cross-backend.
  3. Rasteriser refactor. Replace the `ui_layout` arg with `ui_font_description` and have the rasteriser swap fonts on the single layout. Same approach the tab_bar lift used.

Option (3) is the most aligned with the existing pattern — that's how `quadraui::gtk::draw_tab_bar` handles its UI-font swap (caller sets the UI font before the call).

Suggested signature

```rust
fn draw_dialog(
&mut self,
dialog: &Dialog,
layout: &DialogLayout,
) -> Vec; // Per-button rect for click dispatch.
```

Returns per-button bounds in visible-button order (caller indexes by position).

Surfaced during

#259 stage 6 (B5c.6). Tooltip and context_menu trait methods landed in that stage; dialog deferred for the dual-layout sorting-out.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions