microsoft
Peek a file using command line and named pipe. (#26422)
This is a PoC. It adds the ability to peek a file using a named pipe and a command line.
Usage/testing before this gets merged and released:
- Build release configuration of Peek.UI and Peek.CLI.
- Terminate PowerToys.Peek.UI.exe if running.
- Back up and replace PowerToys.Peek.UI[.dll;.exe;.pdb;.pri]. Use Everything to find the source and destination folders.
- Call
PowerToys.Peek.CLI.exe <path>or send the path to peek to thePeekPipenamed pipe.
If this solution is OK, documentation and installer need to be updated and a follow-up issue needs to be filed to support navigation.
@check-spelling-bot Report
:red_circle: Please review
See the :open_file_folder: files view, the :scroll:action log, or :memo: job summary for details.
Unrecognized words (1)
wgis
These words are not needed and should be removed
APPICONREFERENCE APPPUBLISHER cdn CREATETHREAD CREATEWINDOW DDEAPPLICATION DDECOMMAND DDEIFEXEC DDETOPIC DEFAULTTOFOLDER DEFAULTTOSTAR DELEGATEEXECUTE DROPTARGET flaticon fpvm gifv HSSH IGNOREBASECLASS INVALIDCALL INVALIDINDEX libraryincludes mdpvm NOFIXUPS NOOPEN NOREMAPCLSID NOTRUNCATE NOUSERSETTINGS QUICKTIP REGISTERCLASSEX REMAPRUNDLL searchtext SHELLEXTENSION SHELLNEWVALUE SHNAMEMAPPING sourced TILEINFO TMPVAR videourl WANTMAPPINGHANDLE xdoc youtubeTo accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands
... in a clone of the [email protected]:prochan2/PowerToys.git repository
on the feature/Peek.CLI branch (:information_source: how do I use this?):
curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.24/apply.pl' |
perl - 'https://github.com/microsoft/PowerToys/actions/runs/14398578077/attempts/1'
Warnings (1)
See the :open_file_folder: files view, the :scroll:action log, or :memo: job summary for details.
| :warning: Warnings | Count |
|---|---|
| :warning: no-newline-at-eof | 1 |
See :warning: Event descriptions for more information.
If the flagged items are :exploding_head: false positives
If items relate to a ...
-
binary file (or some other file you wouldn't want to check at all).
Please add a file path to the
excludes.txtfile matching the containing file.File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.
^refers to the file's path from the root of the repository, so^README\.md$would exclude README.md (on whichever branch you're using). -
well-formed pattern.
If you can write a pattern that would match it, try adding it to the
patterns.txtfile.Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@prochan2 , thanks for raising up this PR. One question that I also think about support this in the past. Should we just make PowerToys.Peek.UI.exe able to accept file as parameter, instead of creating a new CLI on it? Since it is normal to have an app to activated with command line as well.
@lei9444 as FYI on the thinking.
@yeelam-gordon : That makes sense. The logic would then go to the App constructor to eliminate any initialization in case the process should just pass the path via the pipe, right? O is there a nicer place before the App object instatiation starts?
I like this cml experience, and I'm thinking how we enable the experience from a large group of module. Here is my imagination:
"powertoys -list"
> peek, powerrename, filelocksmith...
"powertoys.exe -m(odule) peek -f(ile) <file>"
"powertoys.exe -m(odule) filelocksmith -f(ile) <file>"
"powertoys -m imageresizer -f <file> -size 200 200"
In this sense, what about we move activation logic in runner and delegate activation through the existing 'moduleInterface'?
That makes sense. The logic would then go to the App constructor to eliminate any initialization in case the process should just pass the path via the pipe, right? O is there a nicer place before the App object instatiation starts?
So, it's not trivial to make an exe seamlessly work in both "Windows" and "Console" scenarios. If you do that, then it's likely that the user's shell (cmd.exe, powershell, etc) will return to the prompt before you output any text.
Fortunately, we did put a change out to the console subsystem to let you make your exe behave sanely in both scenarios. @dhowett can find those docs.
My bigger thought however, is that calling PowerToys.Peek.UI.exe on the CLI is verbose. Shorter is better. Heck, I'd just call it peek.exe if it were me. So multiple different exes seems like the easiest solution to me.
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
I like @vanzue 's idea — we could then enable other modules like ImageResizer to support CLI launch as well.
@crutkas @cinnamon-msft do you think we should merge this PR first?
@prochan2 and @lei9444, given this is still "launching Peek's UI", we should still consider to "activate" it directly with command line to original Peek exe. That's what commonly as WinUI app will do as its app activation way. (When I see Copilot reminds us on security fix for NamedPipeServerStream, that strength my suggestion to reduce non-necessary new security boundary)
For what Kai talked about, I will not suggest to make runner even more complicated to know all the command line <=> IPC call object if not necessary. Runner is complicated enough even just for launching and understand all kind of IPC and setting's json already.
For @lei9444 , for Image resizer, If it is just launch the UI, it should not have another CLI exe as well. BUT if it directly process the image with parameter (i.e. no UI), then it make sense to have a seperate CLI, and just load shared library (instead of load resizer's UI) for that case.