Re: [ARMini-support] UniControl: UniClip question

  • From: Fred Graute <fjgraute@xxxxxxxxx>
  • To: armini-support@xxxxxxxxxxxxx
  • Date: Tue, 18 Jul 2017 21:56:01 +0200

In message <gemini.otainx00dh1zf01zw.alan@xxxxxxxxxxxxxxx>
          Alan Wrigley <alan@xxxxxxxxxxxxxxx> wrote:

Fred Graute <fjgraute@xxxxxxxxx> wrote:

It seems that this due to applications (in my case StrongED and Edit)
that hold the global clipboard only keeping a single state for requests
for the global clipboard contents (I know it's true in StrongED's case).

Clipboard Holder and presumably also Clipboard work by grabbing back
ownership as soon as another app takes it, so they effectively remain the
sole owner at all times.

Clipboard Holder does, UniClip does, Clipboard doesn't (see below).

The reason why ClipboardHolder does it is because of a flaw in the RISC
OS clipboard protocol. If an application already holds the global
clipboard and the user copies new data to it, the application should not
claim the global clipboard again.

This cuts down on the number of messages send through the system which
probably made sense when the protocol was designed in the early 90's.

It does create a problem for applications that want to keep a copy of
the clipboard data in that they cannot see when the clipboard data is
changed within the same application.

The only way around this is to always claim the global clipboard back
when another application has claimed it. Otherwise there's a risk of
ClipboardHolder or UniClip serving up old clipboard data.


The problem with Clipboard highlights another problem with the RISC OS
clipboard protocol. There is no proper way to inspect what's on the
global clipboard.

The only way to do this is to broadcast a DataRequest message. Note what
comes back and then bow out of the DataSave protocol. So that's what
Clipboard does.

When UniClip and Clipboard are both running each will send a DataRequest
message. Most applications are not capable of handling this, which isn't
surprising as normally only one application will be requesting the data
so that it can be pasted.

When the clipboard owner receives the DataRequest from UniClip it will
note the details and send a DataSave message back. When the clipboard
owner gets the DataRequest from Clipboard it will do the same but as
only one state is kept the details from UniClip will be lost, and the
DataSave to UniClip fails. Consequently the clipboard data held by
UniClip is not updated.

The proper fix for this would be to update the clipboard protocol and
add a message to inspect the global clipboard without having to enter
the DataSave protocol. However there's probably too many unmaintained
applications to make this a viable option.

-- 
Fred Graute
http://www.stronged.iconbar.com/
---
To alter your preferences or leave the group, 
visit //www.freelists.org/list/armini-support
List-related queries to info@xxxxxxxxxxxx

Other related posts: