Bug 515383

Summary: User Story Improve Default Action Behavior in Dialog
Product: [Applications] kdenlive Reporter: Jeffrey Krebs <rockinjeff>
Component: User Interface & MiscellaneousAssignee: Jean-Baptiste Mardelle <jb>
Status: REPORTED ---    
Severity: normal CC: berndmj, luzpaz
Priority: NOR    
Version First Reported In: 25.12.1   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Example as cancel as the default dialogue in the title tool.
attachment-1875632-0.html

Description Jeffrey Krebs 2026-02-01 13:06:41 UTC
Created attachment 189133 [details]
Example as cancel as the default dialogue in the title tool.

Here is a link to my development user story in my Google Docs.
for proper formatting.
https://docs.google.com/document/d/1foVl0C7ZvcNt6VI-L2yIsLCmSOGp97zR4fhmJRIAM8g/edit?usp=sharing

Here is the direct details non-formatted
User Story
As a video editor working in Kdenlive,  
I want the default action in dialog boxes to be the affirmative option (Save/OK/Accept),  
so that pressing 
Enter confirms my work instead of Ignoring or discarding it, reducing the risk of losing changes in some cases and improving workflow efficiency.
Additionally using a manual mouse close on title tool, does not warn that you are about to lose modifications to an existing title.
Problem Statement
Pressing Enter currently triggers Cancel in some dialogs.
This leads to:
Lost work 
Confusion and frustration.
A break from expected UI behavior across KDE/Qt applications.
Reduced keyboard‑driven efficiency.

Users expect Enter to confirm, not discard their work.
Why This Matters
 Editors often work quickly and rely on muscle memory.
 Kdenlive is used in professional and semi‑professional environments where speed and reliability matter.
 Accidental cancellation is a high‑impact UX failure because it can destroy user input.
 Aligning with KDE HIG and Qt UX norms improves consistency and predictability.
Scope
This story applies to all dialog boxes where:
 There is a clear affirmative action (e.g., Save, OK, Apply, Accept).
 There is a Cancel or Close option.
 The dialog is modal and expects a user decision.
Examples include:
 Title Tool (for manual close)
 Project Settings dialogs
 Effect configuration dialogs
 Save/Discard prompts
 Any modal editor or tool with OK/Cancel buttons
Acceptance Criteria

1. Default Button Behavior
 The affirmative action button (e.g., OK, Save, Accept, Apply) must be the default button.
 Pressing Enter/Return must trigger the affirmative action.
 Pressing Esc must trigger Cancel, as expected.
2. Visual Indication
 The default button must be visually indicated according to KDE/Qt standards (e.g., highlighted or with a default focus ring).
3. Consistency Across Application
All modal dialogs must follow this rule unless there is a compelling, documented exception.
No dialog should default to Cancel unless:
The dialog is destructive by nature (rare), and
KDE HIG explicitly recommends Cancel as default (unlikely).
4. Regression Testing
 Verify that no existing workflows break due to the change.
 Confirm that keyboardonly navigation behaves predictably:
 Tab cycles through buttons.
 Enter activates the default affirmative action.
 Esc cancels.
5. Title Tool Specific Fix
The Title Tool must no longer discard user work close box is used without warning
Enter should default to update title
Esc Key should default to Cancel
Tab Key should be access save or cancel, at the moment it cycles to every function except the save or cancel
Comment 1 luzpaz 2026-02-01 13:17:50 UTC
Did you dupe https://bugs.kde.org/515383 or is this a separate ticket? Both are named very generic titles. Please distinguish between them using a more nuanced title.
Comment 2 Bernd 2026-02-01 15:18:58 UTC
(In reply to luzpaz from comment #1)
> Did you dupe https://bugs.kde.org/515383 or is this a separate ticket? Both
> are named very generic titles. Please distinguish between them using a more
> nuanced title.

Perhaps OP hit Enter or Esc by accident and Bugzilla did the exact opposite of what was expected. LOL! SCNR

I think this is a good user story and well worth implementing.
Comment 3 Jeffrey Krebs 2026-02-01 15:19:29 UTC
Created attachment 189139 [details]
attachment-1875632-0.html

Feel free to review.
I'll review deeper for nuance


On Sun, Feb 1, 2026, 8:17 AM <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=515383
>
> luzpaz@protonmail.com changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |luzpaz@protonmail.com
>
> --- Comment #1 from luzpaz@protonmail.com ---
> Did you dupe https://bugs.kde.org/515383 or is this a separate ticket?
> Both are
> named very generic titles. Please distinguish between them using a more
> nuanced
> title.
>
> --
> You are receiving this mail because:
> You reported the bug.