https://bugs.kde.org/show_bug.cgi?id=503896

            Bug ID: 503896
           Summary: Render dialog: improve output file name input.
    Classification: Applications
           Product: kdenlive
           Version: unspecified
          Platform: Other
                OS: Other
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: User Interface & Miscellaneous
          Assignee: j...@kdenlive.org
          Reporter: gabcor...@gmail.com
  Target Milestone: ---

Created attachment 181042
  --> https://bugs.kde.org/attachment.cgi?id=181042&action=edit
Render Dialog output file name proposal

I often feel there could be some improvements in the way this information is
presented to the user, and in the way of interaction with it.

Currently we have a text field that holds, in a single string, the whole
relevant data to determine the output file characteristics, name and path.
Each time I'm faced with having to enter the name for the new file, I realize I
have to carefully focus on deleting the text that's between the path and the
file extension, so to enter the desired new name.
Moreover, I realize that if, for any reason, the user deletes the whole string
and just type a name (i.e. my_video) and proceeds to render the file, the
generated file gets saved in the "Kdenlive\bin\" folder, without any file
extension. Of course, most probably, nobody wants that...

What I think could be an improvement is having:
- an output path field (with a folder browser button next to it), to select the
output folder.
- an output file name field, to enter the name of the file to be generated.
- a file extension info text, next to the output file field (showing which type
of file it will be created, based on the selected preset).

Benefits of this new approach:
- less unexpected outcomes (i.e. a file without extension or in an
unknown/unexpected folder).
- improved workflow (i.e. less stress, easier name input), just click inside
the field, hit Ctrl+A and start typing a new name.

Downside of this new approach:
- two rows needed in the UI to accommodate this new layout.

Of course, perhaps another (better) approach at it is possible and welcome too.
I've attached a mockup of what I imagine it could be...


Thanks for listening!

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to