Skip to content

[Feature]: Discuss keeping original browser-drop bytes without a conversion #821

Closed

Description

@1644ye

What would you like Filee to do?

Offer a clear way to keep the original file from a browser drag without re-encoding it. This discussion responds to #814; that implementation remains draft pending design agreement.

Why / when would you use it?

My workflow is collecting website images/SVG for design work. Sometimes I want a conversion; sometimes I want exactly the original bytes, with an editable file name and a convenient destination. For linked image cards (for example on dagnedover.com), a normal drag can also represent a product link instead of the picture; identifying the picture itself is a separate companion-extension concern and is not a requirement of this desktop proposal.

I understand that Filee already saves browser inputs, has Ask every time (#521), and supports output folders. The remaining UX question is how to intentionally retain only the original, without selecting a conversion or relying on an intermediate file that may be removed by Save only converted files. Re-encoding to the same format is not equivalent to preserving bytes. If the existing UI already covers this intent directly, please point me to it and I can drop or narrow the proposal.

Ideas for how it could work

Prefer reusing existing output-folder and Ask every time settings. The draft's separate Download settings are not a hard requirement. A minimal save-original/identity action could use the existing save dialog, allow renaming, remember the last directory, and do nothing when cancelled.

No site crawling or video extraction is requested here. Could this fit the current browser-drop workflow without creating a second, overlapping save-settings system? I will revise #814 around the agreed design.

Activity

  1. KnifeLemon commented on Oct 30, 2026

    @KnifeLemon
    Owner

    Thanks, @1644ye. Talking it through, we'd like to take this, but broader than "keep the original": a "Copy to folder" tool. The case that convinced us: someone sorting downloads and files into many folders (projects, references, icons…) can't keep a dozen Explorer/Finder windows open to drag into, and the donut is a good place for those destinations.

    Shape

    • A new preset kind, "Copy to folder": no conversion. The file is copied byte for byte into the preset's folder. It works for:
      • browser drops: the original is saved there;
      • your own files: copied (no move, to avoid accidents; a per-slice "move" can be discussed later);
      • several files and folders: all copied, folders as folders.
    • Destination: a fixed folder, or Ask every time ([Feature]: 转换后的文件保存 #521), which opens the save dialog. That covers your "pick the place and rename" case. No separate download settings: reuse the existing output folder and Ask every time.
    • Name clashes: the existing rule (add a number, never overwrite).
    • Edge cases:
      • destination missing (unplugged drive) or not writable → the file fails with a clear message, and the folder isn't created;
      • destination is the file's own folder → nothing to do;
      • a watched folder as destination is fine: it then converts on its own.
    • On the donut: it's a tool, so it goes on the back face ([Feature]: A rule for what Filee shows by default, before more formats are added #806: front converts, back edits). With many folders, users put several "Copy to folder" presets in a group slice, which fans them out. Nothing is added to the default donuts; users create their folder slices themselves.
    • Every donut: a folder slice should accept any file type, like the existing type-independent tools.

    Tests

    • browser drop → bytes identical to the download;
    • local file → copied and the original untouched;
    • name clash → numbered;
    • a missing destination → failed with a message;
    • Ask every time cancelled → no job.

    Please rework #814 to this scope (and drop its own Download settings). Mark it ready when dotnet format and dotnet test pass. Screenshots of the preset editor and a group of folder slices would help the review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions