Utilize clipboard contents as well as set them.

[Aptronymist]

Is your feature request related to a problem? Please describe.
There's a way to put data into the clipboard, but no way to read the clipboard and use the values in it inside the menus, such as strings of text that were copied, or even file/directory paths, of file contents, such as a .jpg image.

Describe the solution you'd like
create ${clip} that accesses the current clipboard contents. Potentially this could interact with the windows 10+ multi-entry clipboard history as well, or other more complex clipboard replacements such as Ditto or CopyQ (which I use).

[Antoine Beauchamp]

Thank you for your interest in Shell Anything. Could you elaborate on different use case that you have in mind ?
I am not familiar with Ditto or CopyQ but...

Most use cases can now be implemented using a custom plugin. For example: reading the clipboard and using the value in Visibility / Validity fields such as exprtk attribute, istrue attribute or isfalse attribute can be implemented as a plugin. When the selection changes, the plugin reads the clipboard as text and set the clip attribute.

[Aptronymist]

Thank you for your interest in Shell Anything. Could you elaborate on different use case that you have in mind ? I am not familiar with Ditto or CopyQ but...

Most use cases can now be implemented using a custom plugin. For example: reading the clipboard and using the value in Visibility / Validity fields such as exprtk attribute, istrue attribute or isfalse attribute can be implemented as a plugin. When the selection changes, the plugin reads the clipboard as text and set the clip attribute.

Well as an example, and how I noticed this wasn't possible, was when writing a menu item to automatically install github repos from a context menu, I'm creating extensive menus to help with github/python/pip management as I'm working with ML a lot, example: git clone ${clip} . && python -m venv venv && venv\scripts\activate.bat && pip install -r requirements.txt.

At the moment I use CopyQ but I do a lot of cut and pasting so it helps to have a good tool with history, especially since I can pin things to it, and I often have to give out support info for SD.Next. If you check here you'll see what I've worked up just for that so far to make things easier on the less knowledgeable users that want to use stable diffusion. The advanced clipboard tools aren't that important other than providing potentially hundreds of saved contents, but ${clip} would be useful, since there's already a method to write to it.

Love ShellAnything btw! Saved my entire idea from being relegated to the recycle bin!

[Antoine Beauchamp]

I think that your concern for such a feature is legitimate. However, I feel that creating a "permanent" clip property (that could be used like ${clip}) might be an unnecessary security risk. ShellAnything logs property changes in its log files. I do not think its would be a good idea to have this feature "always on". Many people copy and paste passwords or other sensitive data in their clipboard and I would not like to have something compromising security in a log file.

If I do implement this feature, it would be as a "plugin" so that people implicitly specify to use this feature. I would also need to add a warning of something similar to let people know that clipboard content may end up in a log file.

I have looked at your example configuration file and noticed that you do not seem to require to use ${clip} as a menu validator. This is good news because I think you could "hack" you way to get what you need:

You could modify your actions to

1. Run a command that output the clipboard content into a file. For example powershell get-clipboard > "${temp}\clipboard.txt".
2. Read the content as an environment variable. The set command of the Windows Command Prompt can help you do this. See https://stackoverflow.com/questions/8767017/how-to-set-environment-variable-from-file-contents for help.
3. Prefix your exec actions with something like set && real command.

For example:

<actions>
  <exec path="cmd.exe" arguments="/C powershell get-clipboard&gt;&quot;${temp}\clipboard.txt&quot;" />
  <exec path="cmd.exe" arguments="/C set /p &quot;GITURL=&quot;<&quot;${temp}\clipboard.txt&quot; &amp;&amp; git clone &quot;%GITURL%&quot; . &amp;&amp; python -m venv venv &amp;&amp; venv\scripts\activate.bat &amp;&amp; pip install -r requirements.txt" />
</actions>

(note, I did not tried this but it should be working).

If the exec command gets too complicated, move it to a batch file and simply call the batch file from ShellAnything.

I hope this is actually helping.

[Aptronymist]

(note, I did not tried this but it should be working).

If the exec command gets too complicated, move it to a batch file and simply call the batch file from ShellAnything.

I hope this is actually helping.

My apologies for the delayed response!

Yes, actually it is helping!

In fact I've started doing a little coding in vscode so I might just look at doing an extension though if it's not too difficult, thankfully there's tons of AI assistance around these days! A lot of my new menus are for using AI tools, even firing up llama.cpp and feeding it a prompt with one click. (actually can't recall if I ever finished this)

		<menu name="LLM">
		  <menu name="Explain-Doc Code">
			<actions>
			  <exec path="cmd.exe" arguments="/K pushd &amp;&amp; copy H:\explain-code-prompt.txt+${selection.path} explaincode-${selection.filename.noext}.tmp &amp;&amp; H:\Apps\llama.cpp-clblast\main.exe -m %INSTRUCT_MODEL1% --prompt-cache llmcache --mirostat 2 --color -ins --keep 10000 -ngl 500 -c 32768 --temp 0.5 -f &quot;explaincode-${selection.filename.noext}.tmp&quot;" />
			</actions>
		  </menu>
		</menu>

Though I am wondering if the text input box and string length could be bigger, I created a menu item to execute edge-tts but the length of what I can put in is limited by Shellanything's small area for text since it's just a little strip rather than something more like a text input area.

Example for edge-tts:

      <menu name="Edge-TTS">
        <actions>
		  <prompt name="texttospeech" title="Enter tts:" />
          <prompt name="filename" title="Enter filename:" />
		  <exec path="cmd" arguments="/c edge-tts -t &quot;${texttospeech}&quot; --rate=-15% -v en-GB-MaisieNeural --write-media &quot;h:\tmp\edge-tts-dump\${filename}.mp3&quot;" />
        </actions>
      </menu>

Also curious what you think about adding in more than just "yesno" and "ok" as buttons?
Say custom buttons to extend that functionality a lot further so you could almost have a little control panel if there are a lot of options in what you're tying it to.

Or potentially allowing shellanything to execute python code as a plugin? that would vastly expand it's abilities.

[Arath Burgos]

Hi there,

Idk if you already knew but there is a "Windows Clipboard" integrated from WIn10. To call it the shortcut is "Win+V". I know that it is basic. Maybe you can re-use that API for your purposes with ShellAnything.

Also you can complement your clipboard developing using advanced commands with this repo https://github.com/Slackadays/Clipboard

Regards.

[Aptronymist]

Hi there,

Idk if you already knew but there is a "Windows Clipboard" integrated from WIn10. To call it the shortcut is "Win+V". I know that it is basic. Maybe you can re-use that API for your purposes with ShellAnything.

Also you can complement your clipboard developing using advanced commands with this repo Slackadays/Clipboard

Regards.

Yes, actually I did find Clipboard not too long after I originally wrote this, but I do appreciate your helpfulness, if I hadn't, it would be just the thing! I haven't had a chance to get back into things and test it, much less integrate it with my menus, sadly.

This was originally just a sort of no-brainer FR, as only setting the clipboard and not reading it seemed... half done.

[Antoine Beauchamp]

I am not ready to give up on this requested feature. I said previously that it seems like a legitimate use case. I also think that positive feedback and positive criticism should be considered.

I still need to figure out a way to implement this. My main concern is about security. I do not want to leak a password in the logs or something like that. One idea that I am exploring is to bind this feature with #109. For example, only when verbose logging would be enabled that full "property change events" would be logged.

TODO:

• Find a method for updating properties without having value leaking into the logs.
• Decouple clipboard management from sa.core.dll. Create an IClipboard interface in the core. Have another dll provide an implementation that matches the current clipboard management code. Use a similar design to #137.
• Implement clipboard property to reference current clipboard content. The property name shall be clipboard to match <clipboard> action.
• Provide an implementation of IClipboard which uses Windows 10 new clipboard APIs. Not required. Legacy clipboard API is sufficient.
• Have a way to switch between the two implementations of IClipboard (native, new win10 apis). Leave the legacy implementation active. Find a way to switch to the new implementation. Not required. There is only a single clipboard implementation.

Also... @Aptronymist, your issue about the input prompt:

Though I am wondering if the text input box and string length could be bigger

is now fixed in #127.

[Aptronymist]

I am not ready to give up on this requested feature. I said previously that it seems like a legitimate use case. I also think that positive feedback and positive criticism should be considered.

I still need to figure out a way to implement this. My main concern is about security. I do not want to leak a password in the logs or something like that. One idea that I am exploring is to bind this feature with #109. For example, only when verbose logging would be enabled that full "property change events" would be logged.

TODO:

• Find a method for updating properties without having value leaking into the logs.
• Decouple clipboard management from sa.core.dll. Create an IClipboard interface in the core. Have another dll provide an implementation that matches the current clipboard management code. Use a similar design to Library independent logging support  #137.
• Implement clipboard property to reference current clipboard content. The property name shall be clipboard to match action.
• Provide an implementation of IClipboard which uses Windows 10 new clipboard APIs.
• Have a way to switch between the two implementations of IClipboard (native, new win10 apis). Leave the legacy implementation active. Find a way to switch to the new implementation.

Also... @Aptronymist, your issue about the input prompt:

Though I am wondering if the text input box and string length could be bigger

is now fixed in #127.

Crap, I'm sorry, I didn't even mean to close it! Those buttons seem particularly enticing to my mouse cursor for some reason!
That's great to hear about the change to the text entry though! I was actually poking around in the source code for this with some AI assistance in vscode, while I can tinker with python a bit, C and C++ are beyond me.

[Antoine Beauchamp]

@arathburgos05 Could you clarify your idea about the new Windows Clipboard in Windows 10 ? From what I see, it is not a new "Clipboard API". It is a clipboard history where the latest values of the clipboard are saved. They can quickly be restored using "Win+V" and clicking on an element. Using the "old" (a.k.a. legacy win32 api) are producing new entries in the clipboard history.

I have enabled the history feature on my side and ran ShellAnything's unit tests.
My tests are indeed changing the history:

There are probably functions to query the history. For example get the previous clipboard entry instead of the last (current) one. I could implement special properties to access the history. For example, the property clipboard.history.2 could refer to the entry Luke. But to be honest, I do not really see a clear use case for that. Is that such a feature you had in mind?

Regarding https://github.com/Slackadays/Clipboard, I think the product is mainly targeted for console/terminal usage. There might be some API that I could use to set/get values to this application. However, this would create a hard dependency to Slackadays/Clipboard for ShellAnything. I do not ideally think this would be appropriate.

As of today, the latest commit d02fe6a from branch feature-issue129 provide a generic clipboard interface for setting/getting values in/out of any clipboard implementations. I could create a special clipboard implementation that delegate this task to external executables. For example sa.clipboard.set.exe and sa.clipboard.get.exe. Users could then supply their own executables which sends messages to their desired clipboard framework (including, but not limited to, Slackadays/Clipboard).

Waiting for your clarifications.

[Arath Burgos]

@end2endzone

Hello, from my side I shared the Windows Clipboard just like possible stuff that could be useful.

I read all the thread again, certainly I neither see a useful case use about checking the last n-elements (only the first one is useful to see but not the others).

Windows Clipboard is a useful tool for me to check and re-use the last n-elements copied. It also works with pictures and it keeps the format of specific text (like bold, color, size, etc.). I don't think that ShellAnything and Windows Clipboard can be merged or integrated together. I only shared it to access the last n-elements copied in a normal usage.

I agree about accessing/reading the last element copied in ShellAnything. Also I saw your workaround using PoweShell and I think that is a good way to solve the requested feature by @Aptronymist

I'll be reading the new comments of this thread but for the moment i don't have anything to share/support.

Good job as always 👍

[Antoine Beauchamp]

The feature is implemented and integrated into the master branch. You can now use the clipboard's content with the clipboard property.

You can safely copy/paste password or secure values in the clipboard without risking ShellAnything to leak the value in the logs. The content shall not be printed in the logs unless you use ${clipboard} value in an action.

To be clear, it is compatible with Windows Clipboard History feature. If you enable Sync across devices (sharing), ShellAnything will have access to text copied from another device. If a user presses Win+V and click on a previous entry, ShellAnything will have access to this previous entry through ${clipboard} property.