I spent 4 and 5 October taking Cutwise in two directions: turning longer recordings into portrait clips, and finding out why the Windows application could pass its automated tests but still fail during ordinary use.
In the previous post, I described adding direct control over the timeline, captions and extra media. The next feature builds on that work. Cutwise can now suggest short excerpts, let me adjust their framing and export them as separate vertical videos.
The Windows work was less visible, but just as important. A disappearing accessibility tree and a frozen Save As dialog initially looked like parts of the same stability problem. Reducing them to smaller examples exposed two separate defects, with different fixes and different amounts of work still outstanding.
Finding a short inside a longer recording
I added a Shorts workspace beside Main video. After transcription, I can ask the configured AI model to suggest excerpts from either the original recording or the current edited video, with a target length and instructions about what to look for.
Each suggestion includes a title, an explanation and boundaries tied to actual transcript words. The model receives transcript text and timing information after the cloud disclosure; the audio and video stay local.
The boundary checks matter as much as the suggestions. A model can return a plausible description with a word reference that does not exist, or choose a passage longer than requested. Cutwise validates those references locally, skips unusable candidates individually and flags otherwise usable excerpts that need trimming. One bad suggestion does not discard the valid ones beside it.
I also kept the requested number of clips as an upper limit. Fewer suggestions, including none, are valid outcomes, and repeating an analysis avoids substantially overlapping excerpts from the same edit basis, including suggestions already dismissed.
That keeps the workflow consistent with the rest of Cutwise: AI proposes something worth reviewing, and I decide whether it works as a piece of video.
Making portrait framing a decision
A landscape screen recording does not automatically become useful when cropped into a vertical rectangle. Keeping the whole screen can make text small; filling the frame can remove the part of the demonstration that matters.
I added two explicit choices. Fit keeps the complete picture on a dark portrait canvas. Fill crops the picture, with position and zoom controls and a draggable preview for adjusting the framing.
The preview renders at 360 × 640, using the same composition as the final 1080 × 1920 MP4. Rebuilding it is an explicit action after changing timing or framing, so the saved settings and the rendered preview need to be judged together.
Captions reflow for the narrower frame and reduce their font size when needed. Existing caption corrections carry through; when there is no caption track, Cutwise can build compact captions from the audible words. An optional two-second end card adds a closing message, within the overall three-minute limit.
The narrower player also needed smaller controls. I added a compact layout based on the preview's available width and text size, with a volume menu instead of a control that expands sideways across the picture.
Keeping the short separate from the main edit
A saved short needs to remain predictable when I return to the longer video. I made Shorts retain a snapshot of the transcript, edits, transitions, media sequence, overlays, audio settings and captions used for their analysis.
Later changes to the main timeline therefore do not move the saved short's content underneath it. The original recording and imported assets still need to remain available; the snapshot preserves the decisions, rather than making another copy of every media file.
I can adjust and export one short or select several for separate MP4 exports. Batch filenames avoid overwriting existing files, and completed exports remain recorded if a later item is cancelled.
There are deliberate limits to this first version. It selects continuous excerpts, including cuts already made within them. It does not assemble distant moments into a montage, follow a speaker around the frame, predict views or upload to YouTube. Saving Shorts also moves a project to a newer format that older Cutwise builds cannot open, with a backup of the previous metadata created on first save.
The tests cover saved projects, malformed model responses, cancellation and real FFmpeg output, including crop placement, captions, audio duration and source integrity. Whether the model consistently picks a compelling excerpt still needs editorial and listening checks with real recordings.
Fixing the defects I could prove
The Windows investigation began with failures in the installed application: an earlier native crash, an intermittent Save As freeze and accessibility controls disappearing after fullscreen playback.
I found two concrete application defects during the first pass. Creating captions could append an overlay snapshot with an identifier already in the project history, causing reopening to fail with Duplicate overlay revision. I changed that path to reconcile overlays only when the edit revision actually changes, and checked caption creation, save and reopen without altering the existing snapshots.
Adjacent help tooltips had a separate problem. Their accessibility anchors could merge, leaving one tooltip referring to a parent that was no longer represented correctly. Giving each tooltip its own accessibility boundary fixed the regression while retaining its description and keyboard actions.
Those were useful fixes, but the installed Windows candidate still lost its accessibility controls after leaving fullscreen. The visible editor continued to respond while Windows could no longer inspect its controls properly.
That distinction stopped me treating a successful playback test as proof that the application was healthy.
Reducing the accessibility failure to a slider
The next investigation removed most of Cutwise from the problem. A small Flutter application with no plugins could reproduce the failure simply by opening a screen containing a slider: the slider appeared visually, while the native accessibility tree remained on the previous screen.
That tree is the structure Windows uses to expose controls to assistive technology and inspection tools. If it stops following the visible interface, the application can look normal while becoming inaccessible.
The reduction exposed a framework problem in how nodes were serialised when their traversal parent was absent, including during opacity changes. An experimental Flutter source patch skipped the orphaned node and marked it for an update when it rejoined the tree.
With that patch, the small controls passed and the full Cutwise editor regained its native accessibility tree after fullscreen. In the experimental installed build at 150% display scaling, the tree survived 21 fullscreen round trips, 20 maximise-and-restore cycles and 20 activation cycles.
That was strong evidence for this particular fix. It was still an experimental framework patch, with no production SDK change, and it did not explain the earlier native crash.
Then Save As froze again.
Why the file dialog was a different problem
This time I captured the application while it was hung. The main window was disabled, no save dialog appeared, and the live dump showed Windows threads waiting on one another during the native dialog call.
The trace pointed to player disposal. After preview players were replaced, the video library, libmpv, made unmatched cleanup calls against COM, the Windows component system used by the file dialog. Cleanup associated with audio-device monitoring was happening on the wrong thread and disturbed the main thread's setup for opening the dialog.
I reduced that too. A small C++ program using the installed player library reproduced the faulty teardown without Flutter, Cutwise, a video file or any interface. Creating and destroying a player was fine; observing the audio-device list before destruction exposed the problem.
A separate instrumented run showed the same valid window and owner thread before both a successful dialog and a later failed one. What changed was the thread's COM state after player disposal. That gave the investigation a much firmer explanation than blaming fullscreen, display scaling or a badly timed window animation.
The defect was identified, but a corrected player library was not promoted. The historical native access violation also remained unresolved: these were hang captures and accessibility results, not evidence that the earlier crash had been fixed.
Where these three commits leave Cutwise
Cutwise now has a local testing workflow for finding, framing, captioning and exporting portrait shorts, alongside fixes for duplicate overlay history and tooltip accessibility. The Windows investigation has also produced much smaller reproductions of two problems that were difficult to understand inside the complete editor.
The recorded checks finished with 781 Flutter tests passing and three skipped on both the original and experimental SDKs. The worker, packaging and native regression suites passed too. The installed experimental application still hung during Save As, so Windows remained a failed qualification.
The next Windows step is a player teardown fix that keeps initialisation and cleanup on the correct native thread, followed by the complete installed workflow and display-scaling checks. Any eventual shared Flutter upgrade also needs its own Mac rebuild, signing and notarisation checks.
The Shorts feature gives me more to try with real recordings. The Windows work gives me a clearer account of what still prevents a release, and concrete reproductions to test the next fixes against.
