Introduce immediate view mode by idursun · Pull Request #473 · idursun/jjui

idursun · 2026-01-16T10:46:38Z

This PR is huge, but for a good reason (I hope!). I am going to squash merge it.

Context:

We had a lot of abstractions in the codebase stemming from the fact that the only way to present a UI using bubbletea is to compose it into a string. I had to define a bunch of abstractions to support specific use cases:

I added ViewNode to carry parent-child relationships and dimensions across models.
I introduced MouseAware and DragAware interfaces to support mouse events.

Even then, we currently have limited mouse support. We only support clicking and scrolling in some areas of the UI (e.g. revisions, oplog, diff, preview). In an ideal world, embedded models like details and evolog should also support mouse interactions. Unfortunately this non trivial amount of work as their positions do change based on where the viewport of the revisions view is and we don't have a clear way to support this.

To get rid of all the abstractions mentioned above, and to solve the UI problem once and for all; I made the following changes in the code base.

I replaced the common.Model and with common.ImmediateModel

type ImmediateModel interface {
	Init() tea.Cmd
	Update(msg tea.Msg) tea.Cmd
	ViewRect(dl *render.DisplayContext, box layout.Box)
}

As you can see, the view method has changed to ViewRect. (for lack of a better name for now)

ViewRect doesn't return a string, but receives a DisplayContext and a box.

The motivation behind this change is to ask models to render their content to the given area in the screen. They don't stash their Width/Height or their parent's dimensions. This is called the immediate mode. (i.e. similar how game engines render their UI)

There's another construct called DisplayContext. This is the mechanism for models queue their draw requests, and at the very end of the frame generation ui.go composes all calls into one frame.

The new approach has the following benefits:

Models can draw content at different z order. For example, revset now can draw its completion box at a higher z order so it appears on the top of the revisions view. Revisions view don't move up and down when user gets into the edit mode.
Models can annotate interactive regions in their UI so that when the user click to that area, an associated message is broadcasted.
Effects are now first-class (highlight/dim/underline/bold/strike/reverse), which lets lists paint the row under the cursor without rebuilding strings (revisions, details files, evolog).
Simplifies and unifies model signature. For example, Flash messages model is now implementing ViewRect instead of a custom View method.

With these changes, all the models (e.g. details, evolog, git, bookmarks, custom commands, etc) are clickable and scrollable.

To show the potential, I have also updated the view of the git.go so that the remotes listed in that view are also clickable.

I also replaced the old list/rendering helpers with a DisplayContext-based list renderer that supports variable-height items, consistent scrolling, and click/scroll interactions (menus, revisions, oplog, details, evolog).

On the infrastructure side, I introduced layout.Box (and new layout helpers) plus render/text builder tests to lock down the immediate-mode pipeline.

I’ve coded most of the model migration myself but also used AI to manage the rest of the tedious tasks. This migration would easily take a couple of weeks otherwise.

There are still a couple of things to be done but I am sharing it early to get some feedback.

idursun · 2026-01-16T19:17:29Z

Just to show the power of the new view system, here is a recording of a stupid pulsing and shifting gradient revisions highlight implementation:

Screen.Recording.2026-01-16.at.14.08.05.mov

idursun · 2026-01-17T23:30:26Z

The last missing piece was to make confirmation dialog buttons clickable, which is done.

I am going to merge this PR now to prevent any further conflicts.

baggiiiie · 2026-01-18T14:47:05Z

goddamn incredible work! love to see a PR like this that improves things from a fundamental level!

sounds like potentially everything now supports mouse clicks?

idursun · 2026-01-18T15:48:37Z

@baggiiiie Thanks!

sounds like potentially everything now supports mouse clicks?

Yes, pretty much everything I could think of. For stuff that's not yet clickable, they can be made clickable by using the interactions.

Tests that the description overlay renders even when using single-line log templates (like log_oneline) where there is no separate description line to trigger the overlay. Regression test for: idursun#280 Original fix: idursun@9e2b5d4 Regression introduced in: idursun#473 - Last working: e6dd7df - First broken: 8b29b21

Single-line templates produce only Line 0 with flags Revision|Highlightable. The overlay trigger condition (Highlightable && \!Revision) never matches, so the overlay was never rendered. Add fallback: if overlay content exists but was not rendered during the line loop, render it afterward at the current y position. Recovers functionality from 9e2b5d4 lost in PR idursun#473 refactor. Fixes: idursun#280