Feature: Introduce a proper CLI

[Lamparter]

What feature or improvement do you think would benefit Files?

Files would benefit from proper CLI integration and launch activation, using the powerful System.CommandLine APIs. This would allow for better activation and integration, and control of settings from outside Files.

A .NET console project Files.App.CLI or Files.App.Console and register it as an alias files.exe of Files.App

<uap3:Extension
    Category="windows.appExecutionAlias"
    Executable="files-cli.exe"
    EntryPoint="Windows.FullTrustApplication">
    <uap3:AppExecutionAlias>
        <desktop:ExecutionAlias Alias="files.exe" />
    </uap3:AppExecutionAlias>
</uap3:Extension>

Sample usage

C:\> files --help

Copyright (c) 2024 Files Community
Licensed under the MIT License.

files [[<drive>:]<path>] [-s|--select] [-f|--folder] [-v|--version] [-h|--help]

  -h, --help                Display usage of this CLI.
  -s, --select              Select one or more file(s) and folder(s) on folder view.
  -f, --folder              Go to a folder specified.
  -v, --version             Display current version of this CLI.

C:\> files --version

Copyright (c) 2024 Files Community
Licensed under the MIT License.

Files version: 3.5.25

C:\> files .

Launching Files on current folder...

C:\>

This console project should be called Files.CommandLine.

Semi-related matters

With this introduction, we'll have a strong power for FileOpenDialog and FileSaveDialog implementations. Current technical issue with those overridden dialogs is where the project (Files.App.OpenDialog and .SaveDialog) cannot pass information of the dialog (dialog caller can modify footer content of the dialog, adding a button for example) to Files app via command-line (truly difficult because passing as string would require serialization and deserialization. If we introduced our own COM interfaces as IPC in Files app this issue could be fixed.

<com:Extension Category="windows.comServer">
    <com:ComServer>
        <com:ExeServer Executable="$targetnametoken$.exe" DisplayName="Files">
            <com:Class Id ="4B115281-32F0-11cf-AC85-444553540000" DisplayName="..." ProgId="Files.Commandline.1" VersionIndependentProgId="Files.Commandline">
            </com:Class>
        </com:ExeServer>
        <!– ProgId –>
        <com:ProgId Id="Files.Commandline" CurrentVersion="Files.Commandline.1" />
        <com:ProgId Id="Files.Commandline.1" Clsid="4B115281-32F0-11cf-AC85-444553540000" />
    </com:ComServer>
</com:Extension>

<com:Extension Category="windows.comInterface">
    <com:ComInterface>
    <!– Interfaces –>
    <!– IID_FilesCommandLineReciever –>
    <com:Interface Id="0BDD0E81-0DD7-11cf-BBA8-444553540000" UseUniversalMarshaler="true">
        <com:TypeLib Id="4B115284-32F0-11cf-AC85-444553540000" VersionNumber="1.0" />
    </com:Interface>
    <!– TypeLib –>
    <com:TypeLib Id="4B115284-32F0-11cf-AC85-444553540000">
        <com:Version DisplayName = "..." VersionNumber="1.0" LocaleId="0" LibraryFlag="0">
            <com:Win32Path Path="..." />
        </com:Version>
    </com:TypeLib>
</com:Extension>

[ComImport(...)]
public interface FilesFileOpenDialogReciever
{
    void Advise(IFileDialogClosedSink *pfdcs);

    void Launch(FileDialogInformation *pfdi);
}

[ComImport(...)]
public interface IFileDialogClosedSink
{
    void PostSelected(string path);
}

Requirements

• Add .NET console project
• Write code to get and set data from CLI
  • Change app settings
  • Set theme
  • Open a folder
  • Open different views in Files
  • Display version
  • Update Files

Files Version

3.8.5.0

Windows Version

10.0.22631.4391

Comments

I'm a big fan of this idea and @0x5bfa too. I use APIs like System.CommandLine's in many of my apps and would really like to work on this feature.

---

More information coming after the holidays!

[yaira2]

Merging with #13021