Eliminate "Apply to..."

[zvezdochiot]

Hi @vigri , @pablogventura .

The existing "Apply to..." dialogs in ST are an abnormal story. All these dialogs need to be eliminated and all functionality transferred to the content menu of "Thumbnails". As a result of the migration, the functionality will only select the necessary pages (as it should in all normal programs). And the "Apply to..." button will be replaced by the "Apply to selected" button without any extremely strange dialogs.

[FriedrichFroebel]

Does this really make sense? While I understand that other application might make it different, it feels like especially patterns like "every second page" (which I tend to use very often for fixing the initial orientation) will become rather complex to do with your proposal.

[pablogventura]

Thanks @FriedrichFroebel — your concern is valid.

Patterns like “every second page” (and other non-contiguous selections) are easy to express with today’s Apply to… dialogs, but they still need a clear story in any “thumbnails + context menu only” design: users must be able to build the same page sets without more steps than today.

@zvezdochiot’s proposal is a large UX migration; before code, it would help to sketch how those workflows map to thumbnail selection (including odd/even, ranges, and current-page-only). Otherwise we risk trading one awkward UI for another.

@vigri — when you have time, your product call on direction for this issue would move it from discussion to something implementable.

[zvezdochiot]

@pablogventura say:

before code, it would help to sketch how those workflows map to thumbnail selection (including odd/even, ranges, and current-page-only).

The Thumbnail content menu is divided into two groups: Files and Select. Functionality from stupid dialog boxes is being transferred to the Select group. The result of selecting menu items should be the selection of pages according to the appropriate template. The user should see his choice and be able to adjust it manually via Ctrl and Shift. After that, clicking "Apply" without dialogs leads to "Apply to.."->"Selected pages". This is how normal programs work.

[pablogventura]

Thanks @zvezdochiot for the detailed UX proposal.

Replacing all Apply to… dialogs with thumbnail selection menus is a large migration (every filter, page-set semantics, odd/even pages, etc.). We are not starting implementation until there is a maintainer product decision.

Related deskew/oblique parameter work is tracked in #117; partial deskew/oblique separation is already on master via #114. Please continue design discussion here; implementation will follow once scope is agreed (cc @vigri).

[pablogventura]

Status: holding — large UX migration, no work started.

@vigri — @zvezdochiot’s proposal (move Apply to… semantics into thumbnail Select menus + Apply on selected pages) would touch every filter step. Before anyone invests in a spike or PR:

• Do you want this on the roadmap now, or defer in favour of smaller fixes (e.g. fix: P0 bundle — Wayland, menus, content box, spread order, deskew/oblique (reopens #133) #152 P0, threshold defaults Uniq threshold widget #150)?
• If yes later: should the first slice be one filter as proof (e.g. deskew), or a cross-cutting thumbnail API first?

We are waiting for a maintainer call; no implementation until then.

[vigri]

My take: defer the Apply to… migration for now. PR #152 (now merged) and #150 are concrete, scoped, and actively needed. We should ship those first.

The Apply to… proposal is valuable but as you said @pablogventura it's a large cross-cutting change. This one should be definitely on our roadmap when we fix the "more problematic" issues.

[SplendidSwifter]

i vote against. sure, it makes logical sense. yet for me that means crossing the screen back and forth when i have the apply button right below the section. if anything it would be nice to have the apply menu next to the button and not in the middle of the screen