When using synchronization a recipient system does not receive &clipboard content into clipboard

[ylluminate]

Describe the bug
I have a test scenario set up using SyncThing between two macOS systems. I have the sync set up as follows:

The contents appear fine on both systems and the receiving system sync's up quite quickly and nicely, but the new inbound clipboard clipping does not insert itself into the remote clipboard's contents. I do have the System Settings → Privacy & Security → Accessibility set on for CopyQ on each system.

What am I missing here?

Expected behavior
The inbound clipboard contents into CopyQ should populate the current clipboard.

Version, OS and Environment

• Application Version: 9.0.0 (brew install --cask copyq)
• OS: macOS Sonoma 14.6

[hluk]

This is not a bug, since it was never the intended behavior for the synchronization (which is meant only to sync items in specific tabs).

I've created a command that would help with the clipboard synchronization: Top Item to Clipboard (see README.md for details on how to add the command)

Let me know how that works.

[ylluminate]

Thank you very much for the explanation. I was obviously not aware of that and this does seem to work. I now only need to figure out why the CopyQ tab is not being updated until I activate/click CopyQ. I suspect that SyncThing is waiting for local filesystem access to retrieve vs the source system pushing an update to initiate the transfer since it's based on file node activity.

[ylluminate]

@hluk I've noticed a side effect of this new functionality that I'm not sure how to deal with. I use Clop to optimize images automatically, which is very useful, but I've found that with this functionality enabled now with CopyQ it will strip out some of the clip/pasteboard contents on macOS and only allow the textual file location to be available and not the image itself.

As far as I understand it, macOS has multiple encodings that can be available per paste/clip and subsequently some of this data is somehow stripped out by this action.

Additionally, I really like Pastebot and use it on macOS systems, but its synchronization mechanism via iCloud is horrible. The reason I've turned to CopyQ is to facilitate clipboard sharing between both various macOS, Windows and Linux systems I use regularly. I would still like to use Pasteboard, but what I have noticed is that also now enabling this action causes multiple copies of entries to frequently show up in Pasteboard, which I think is an evidence of being related to the issue that Clop is also facing.

Do you perceive of a way to improve this situation or to revise the command script to overcome this / these problem(s)?

Nevermind, this and various permutations still didn't work:
EDIT: I may have figured out a solution, please let me know what you think. The following implements consideration for MIME types in the command:

[Command]
Command="
    // This script ensures all MIME types are preserved when syncing the top clipboard item,
    // particularly useful for maintaining rich data like images processed by Clop.

    // Preserve the original onItemsAdded function
    var onItemsAdded_ = onItemsAdded;
    onItemsAdded = function() {
        // Call the original function to maintain existing behavior
        onItemsAdded_();

        // Early return if we're not in the clipboard tab
        if (selectedTab() !== config('clipboard_tab')) return;

        var sel = ItemSelection().current();
        const topItemIndex = sel.rows().indexOf(0);
        
        // Early return if there's no top item
        if (topItemIndex === -1) return;

        const item = sel.itemAtIndex(topItemIndex);
        var mimeData = {};
        
        // Get all MIME types for the item
        var mimeTypes = itemMimeTypes(topItemIndex);
        
        // Build the mimeData object
        mimeTypes.forEach(function(mimeType) {
            // Only copy non-empty data to avoid unnecessary empty fields
            var data = item[mimeType];
            if (data && data.length > 0) {
                mimeData[mimeType] = data;
            }
        });

        // Only perform the copy operation if we have data to copy
        if (Object.keys(mimeData).length > 0) {
            copy(mimeData);
        } else {
            // Not sure if this will do anything, but anyway:
            print('Warning: No valid data found in top clipboard item');
        }
    }"
Icon=
IsScript=true
Name=Enhanced Top Item to Clipboard with MIME Types

Seems that somehow we have to consider MIME type data, but not sure how to do that in context of CopyQ and macOS' pasteboard.

[hluk]

Not sure if it would help, but you can also override onItemsChanged so that the clipboard changes when the first item changes:

[Command]
Command="
    var onItemsAdded_ = onItemsAdded;
    onItemsAdded = function() {
        onItemsAdded_();
        syncClipboard();
    }

    var onItemsChanged_ = onItemsChanged;
    onItemsChanged = function() {
        onItemsChanged_();
        syncClipboard();
    }

    function syncClipboard() {
        if (selectedTab() != config('clipboard_tab'))
            return;

        var sel = ItemSelection().current(); 
        const i = sel.rows().indexOf(0);
        if (i == -1)
            return;

        const item = sel.itemAtIndex(i);
        copy(mimeItems, pack(item));
    }"
Icon=
IsScript=true
Name=Top Item to Clipboard

[hluk]

One downside is that the refresh of synchronized tabs is delayed (optimized so it does not happen unnecessarily) and is triggered mainly when the tab is displayed again. This would postpone adding new items and synchronizing the clipboard.

[hluk]

I will drop the Top Item to Clipboard command from the command repository since it is very unreliable due to the sync-refresh delay.

An alternative could be to write clipboard content to a special file to the shared folder whenever the clipboard changes, and monitor the file (regularly or with a utility).