Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Clipboard
16 views
Skip to first unread message
Alan Wrigley
Apr 12, 2012, 6:01:55 PM4/12/12
to
There's been a discussion in the last couple of days on c.s.a.misc about
problems with UniClip and the global clipboard. I want to raise the issue
here to get some feedback from others.
The basic problem is this: UniClip (which attempts to share the clipboard
between more than one machine running either RISC OS or Windows) can only
operate properly by taking continual ownership of the 'global' clipboard in
RISC OS on non-Select machines. UniClip also currently only shares text data
and so it will not handle formatted data such as that produced by Ovation
Pro, EasiWriter etc. UniClip's claiming of the clipboard apparently loses
the formatting when a copy/paste operation is performed within one of these
apps.
The global clipboard (which is of course not a real clipboard at all) was
created to enable apps to share clipboard data with each other, which is a
feature built into Windows but not into RO. Editors on RO have known how to
move their own data around within themselves long before the global
clipboard protocol was devised.
So my view at the moment is that when an editor is asked for a clip in text
format only, it should supply it in text only - which most if not all
currently do. But if it is an editor such as EasiWriter or OPro whose data
has a more complex format should keep that data to themselves and not rely
on the global clipboard to supply anything other than it asked for in the
first place. After all, the whole purpose of the global clipboard was to
allow apps to share data, not for apps to pass data around internally.
In other words, IMO a request for TEXT data from the clipboard should not
cause an app to rely on this for later pasting if its own internal format is
more complex. It should be able to move formatted data around internally
without reliance on the clipboard if, and only if, the clipboard has not
requested the data in the app's format.
Alan
problems with UniClip and the global clipboard. I want to raise the issue
here to get some feedback from others.
The basic problem is this: UniClip (which attempts to share the clipboard
between more than one machine running either RISC OS or Windows) can only
operate properly by taking continual ownership of the 'global' clipboard in
RISC OS on non-Select machines. UniClip also currently only shares text data
and so it will not handle formatted data such as that produced by Ovation
Pro, EasiWriter etc. UniClip's claiming of the clipboard apparently loses
the formatting when a copy/paste operation is performed within one of these
apps.
The global clipboard (which is of course not a real clipboard at all) was
created to enable apps to share clipboard data with each other, which is a
feature built into Windows but not into RO. Editors on RO have known how to
move their own data around within themselves long before the global
clipboard protocol was devised.
So my view at the moment is that when an editor is asked for a clip in text
format only, it should supply it in text only - which most if not all
currently do. But if it is an editor such as EasiWriter or OPro whose data
has a more complex format should keep that data to themselves and not rely
on the global clipboard to supply anything other than it asked for in the
first place. After all, the whole purpose of the global clipboard was to
allow apps to share data, not for apps to pass data around internally.
In other words, IMO a request for TEXT data from the clipboard should not
cause an app to rely on this for later pasting if its own internal format is
more complex. It should be able to move formatted data around internally
without reliance on the clipboard if, and only if, the clipboard has not
requested the data in the app's format.
Alan
Steve Fryatt
Apr 12, 2012, 6:32:39 PM4/12/12
to
On 12 Apr, Alan Wrigley wrote in message
<gemini.m2dzv70...@alanwrigley.com>:
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard
> in RISC OS on non-Select machines.
I don't follow that logic. I'm assuming, from what you've said over on
csa.a, that the wider Uniclip protocol results in each machine claiming the
clipboard in a similar way to the RISC OS global clipboard. In which case:
- When RISC OS Uniclip sees a message from another machine posting new data,
it should take a copy and claim the global clipboard.
- When RISC OS Uniclip sees another RISC OS application claim the global
clipboard, it should release its ownership and ask the new owner for the
current contents whenever another machine requires to paste data.
> UniClip also currently only shares text data and so it will not handle
> formatted data such as that produced by Ovation Pro, EasiWriter etc.
> UniClip's claiming of the clipboard apparently loses the formatting when a
> copy/paste operation is performed within one of these apps.
>
> The global clipboard (which is of course not a real clipboard at all) was
> created to enable apps to share clipboard data with each other, which is a
> feature built into Windows but not into RO. Editors on RO have known how
> to move their own data around within themselves long before the global
> clipboard protocol was devised.
Yes, but the global clipboard protocol requires that they defer this to the
global clipboard whenever appropriate.
> So my view at the moment is that when an editor is asked for a clip in
> text format only, it should supply it in text only - which most if not all
> currently do. But if it is an editor such as EasiWriter or OPro whose data
> has a more complex format should keep that data to themselves and not rely
> on the global clipboard to supply anything other than it asked for in the
> first place. After all, the whole purpose of the global clipboard was to
> allow apps to share data, not for apps to pass data around internally.
If Uniclip always takes ownership of the clipboard, then apps like
EasiWriter have no option but to cut and paste via Uniclip because as far as
they are concerned, when they come to paste they don't own the clipboard.
If Uniclip strips the formatting, then there's nothing that they can do
about it.
EasiWriter and O-Pro can't just say, "Oh, Uniclip owns the clipboard but
I'll ignore that and assume that my last cut or copied data is what the user
wants me to use." They *have* to use the global clipboard, because that's
how it works.
> In other words, IMO a request for TEXT data from the clipboard should not
> cause an app to rely on this for later pasting if its own internal format
> is more complex. It should be able to move formatted data around
> internally without reliance on the clipboard if, and only if, the
> clipboard has not requested the data in the app's format.
How does the app know that what Uniclip is about to send back is still the
unformatted version of what it still holds in its own memory? It doesn't,
and can't.
What you're asking for is a significant deviation from the defined protocol,
and as such is never going to happen now -- even if it were desirable.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
<gemini.m2dzv70...@alanwrigley.com>:
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard
> in RISC OS on non-Select machines.
csa.a, that the wider Uniclip protocol results in each machine claiming the
clipboard in a similar way to the RISC OS global clipboard. In which case:
- When RISC OS Uniclip sees a message from another machine posting new data,
it should take a copy and claim the global clipboard.
- When RISC OS Uniclip sees another RISC OS application claim the global
clipboard, it should release its ownership and ask the new owner for the
current contents whenever another machine requires to paste data.
> UniClip also currently only shares text data and so it will not handle
> formatted data such as that produced by Ovation Pro, EasiWriter etc.
> UniClip's claiming of the clipboard apparently loses the formatting when a
> copy/paste operation is performed within one of these apps.
>
> The global clipboard (which is of course not a real clipboard at all) was
> created to enable apps to share clipboard data with each other, which is a
> feature built into Windows but not into RO. Editors on RO have known how
> to move their own data around within themselves long before the global
> clipboard protocol was devised.
global clipboard whenever appropriate.
> So my view at the moment is that when an editor is asked for a clip in
> text format only, it should supply it in text only - which most if not all
> currently do. But if it is an editor such as EasiWriter or OPro whose data
> has a more complex format should keep that data to themselves and not rely
> on the global clipboard to supply anything other than it asked for in the
> first place. After all, the whole purpose of the global clipboard was to
> allow apps to share data, not for apps to pass data around internally.
EasiWriter have no option but to cut and paste via Uniclip because as far as
they are concerned, when they come to paste they don't own the clipboard.
If Uniclip strips the formatting, then there's nothing that they can do
about it.
EasiWriter and O-Pro can't just say, "Oh, Uniclip owns the clipboard but
I'll ignore that and assume that my last cut or copied data is what the user
wants me to use." They *have* to use the global clipboard, because that's
how it works.
> In other words, IMO a request for TEXT data from the clipboard should not
> cause an app to rely on this for later pasting if its own internal format
> is more complex. It should be able to move formatted data around
> internally without reliance on the clipboard if, and only if, the
> clipboard has not requested the data in the app's format.
unformatted version of what it still holds in its own memory? It doesn't,
and can't.
What you're asking for is a significant deviation from the defined protocol,
and as such is never going to happen now -- even if it were desirable.
--
Steve Fryatt - Leeds, England Wakefield Acorn & RISC OS Show
Saturday 28 April 2012
http://www.stevefryatt.org.uk/ http://www.wakefieldshow.org.uk/
Matthew Phillips
Apr 12, 2012, 6:46:22 PM4/12/12
to
In message <gemini.m2dzv70...@alanwrigley.com>
with bit 2 set (e.g. EasiWriter claiming the clipboard when the user has
pressed Ctrl-C in a document) UniClip immediately requests the data in text
format using Message_DataRequest, and then claims the clipboard itself. It
claims the clipboard because otherwise it might receive no notification if
the same editor (e.g. EasiWriter) subsequently changed the contents of the
clipboard. This is because of the unfortunate recommendation in AppNote 240
where Acorn suggested that the application owning the clipboard should spot
that it already owned it, and not send round a further Message_ClaimEntity.
UniClip needs to know the current clipboard content all the time as it has to
share it with other computers so that the content is present and ready to be
pasted on each other machine. It cannot fetch on demand as Windows doesn't
work that way.
Have I got that right?
> The global clipboard (which is of course not a real clipboard at all) was
> created to enable apps to share clipboard data with each other, which is a
> feature built into Windows but not into RO. Editors on RO have known how to
> move their own data around within themselves long before the global
> clipboard protocol was devised.
>
> So my view at the moment is that when an editor is asked for a clip in text
> format only, it should supply it in text only - which most if not all
> currently do. But if it is an editor such as EasiWriter or OPro whose data
> has a more complex format should keep that data to themselves and not rely
> on the global clipboard to supply anything other than it asked for in the
> first place. After all, the whole purpose of the global clipboard was to
> allow apps to share data, not for apps to pass data around internally.
>
> In other words, IMO a request for TEXT data from the clipboard should not
> cause an app to rely on this for later pasting if its own internal format
> is more complex. It should be able to move formatted data around internally
> without reliance on the clipboard if, and only if, the clipboard has not
> requested the data in the app's format.
But how is EasiWriter to know whether to paste from an internal copy of the
data or from the global clipboard? As far as EasiWriter is concerned,
UniClip's behaviour is indistinguishable from the following sequence of
events:
1. User sends data to clipboard in EasiWriter by copying a selection.
2. Another application (e.g. Zap) requests the clipboard in text format.
3. Zap claims the clipboard (perhaps user has made a selection in Zap and
copied to the clipboard from that? Easiwriter cannot tell.)
4. User presses Ctrl-V in EasiWriter document. EasiWriter goes to external
application to ask for the data back. Zap (or UniClip) does not offer
anything richer than text, so that's what EasiWriter gets.
Possible solutions that come to mind, that don't require an alteration to the
protocol and all the applications:
A.
When EasiWriter loses the clipboard, it could remember what it had had on
it, including a hash of the version of the data supplied to the requester
(e.g. text). When it does a paste and fetches the text back, it could
calculate a hash and note that the text version of the file is unchanged, and
then use its own internal rich copy instead.
Problems with that: it's messy, and the requesting content from EasiWriter
and the claiming of the clipboard are two separate operations which might not
be linked at all.
B.
Instead of claiming the clipboard all the time, UniClip could note when it
does not own the clipboard, and request a text version of the data from the
owner every tenth of a second, or at a suitable interval determined by the
user. UniClip could then compare before transmitting to the other machines.
Could have performance problems if there is a high cost to the application
providing text.
C.
UniClip could request the data in formats other than text and store all of
them ready to send back.
Problems: memory. And there's no easy way to find out what filetypes are
actually available from the clipboard owner: you just provide your own
preferred list and the owner responds with a single version. You would have
to send 4096 Message_DataRequest messages to work out which filetypes were
available, if you were doing a thorough job!
What would happen if another application running on the same machine acted
like UniClip? They would continually be bouncing clipboard claims between
them!
You mention non-Select machines. Can you explain what the difference is with
Select? Could that solution be ported to RO5, and is it a real solution that
is fully compatible with the protocol in AppNote 240?
--
Matthew Phillips
Durham
on 12 Apr 2012 Alan Wrigley wrote:
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard in
> RISC OS on non-Select machines. UniClip also currently only shares text
> data and so it will not handle formatted data such as that produced by
> Ovation Pro, EasiWriter etc. UniClip's claiming of the clipboard apparently
> loses the formatting when a copy/paste operation is performed within one of
> these apps.
As far as I have followed this, when UniClip receives a Message_ClaimEntity
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard in
> RISC OS on non-Select machines. UniClip also currently only shares text
> data and so it will not handle formatted data such as that produced by
> Ovation Pro, EasiWriter etc. UniClip's claiming of the clipboard apparently
> loses the formatting when a copy/paste operation is performed within one of
> these apps.
with bit 2 set (e.g. EasiWriter claiming the clipboard when the user has
pressed Ctrl-C in a document) UniClip immediately requests the data in text
format using Message_DataRequest, and then claims the clipboard itself. It
claims the clipboard because otherwise it might receive no notification if
the same editor (e.g. EasiWriter) subsequently changed the contents of the
clipboard. This is because of the unfortunate recommendation in AppNote 240
where Acorn suggested that the application owning the clipboard should spot
that it already owned it, and not send round a further Message_ClaimEntity.
UniClip needs to know the current clipboard content all the time as it has to
share it with other computers so that the content is present and ready to be
pasted on each other machine. It cannot fetch on demand as Windows doesn't
work that way.
Have I got that right?
> The global clipboard (which is of course not a real clipboard at all) was
> created to enable apps to share clipboard data with each other, which is a
> feature built into Windows but not into RO. Editors on RO have known how to
> move their own data around within themselves long before the global
> clipboard protocol was devised.
>
> So my view at the moment is that when an editor is asked for a clip in text
> format only, it should supply it in text only - which most if not all
> currently do. But if it is an editor such as EasiWriter or OPro whose data
> has a more complex format should keep that data to themselves and not rely
> on the global clipboard to supply anything other than it asked for in the
> first place. After all, the whole purpose of the global clipboard was to
> allow apps to share data, not for apps to pass data around internally.
>
> In other words, IMO a request for TEXT data from the clipboard should not
> cause an app to rely on this for later pasting if its own internal format
> is more complex. It should be able to move formatted data around internally
> without reliance on the clipboard if, and only if, the clipboard has not
> requested the data in the app's format.
data or from the global clipboard? As far as EasiWriter is concerned,
UniClip's behaviour is indistinguishable from the following sequence of
events:
1. User sends data to clipboard in EasiWriter by copying a selection.
2. Another application (e.g. Zap) requests the clipboard in text format.
3. Zap claims the clipboard (perhaps user has made a selection in Zap and
copied to the clipboard from that? Easiwriter cannot tell.)
4. User presses Ctrl-V in EasiWriter document. EasiWriter goes to external
application to ask for the data back. Zap (or UniClip) does not offer
anything richer than text, so that's what EasiWriter gets.
Possible solutions that come to mind, that don't require an alteration to the
protocol and all the applications:
A.
When EasiWriter loses the clipboard, it could remember what it had had on
it, including a hash of the version of the data supplied to the requester
(e.g. text). When it does a paste and fetches the text back, it could
calculate a hash and note that the text version of the file is unchanged, and
then use its own internal rich copy instead.
Problems with that: it's messy, and the requesting content from EasiWriter
and the claiming of the clipboard are two separate operations which might not
be linked at all.
B.
Instead of claiming the clipboard all the time, UniClip could note when it
does not own the clipboard, and request a text version of the data from the
owner every tenth of a second, or at a suitable interval determined by the
user. UniClip could then compare before transmitting to the other machines.
Could have performance problems if there is a high cost to the application
providing text.
C.
UniClip could request the data in formats other than text and store all of
them ready to send back.
Problems: memory. And there's no easy way to find out what filetypes are
actually available from the clipboard owner: you just provide your own
preferred list and the owner responds with a single version. You would have
to send 4096 Message_DataRequest messages to work out which filetypes were
available, if you were doing a thorough job!
What would happen if another application running on the same machine acted
like UniClip? They would continually be bouncing clipboard claims between
them!
You mention non-Select machines. Can you explain what the difference is with
Select? Could that solution be ported to RO5, and is it a real solution that
is fully compatible with the protocol in AppNote 240?
--
Matthew Phillips
Durham
Fred Graute
Apr 12, 2012, 8:19:27 PM4/12/12
to
In message <870e797f5...@sinenomine.freeserve.co.uk>
probably one of the reasons why so few applications support it. To make
life easier Select introduced the ClipboardHolder module, which provides
SWIs to copy data to/from the clipboard. Alleviating developers from the
effort of having tp implement the entire protocol themselves.
> Could that solution be ported to RO5, [..]
RISC OS 5 already has it's own support module (called Clipboard) which
also simplifies things through SWIs. See also:
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20Clipboard
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20GetClip
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20PutClip
--
Fred Graute
http://www.stronged.iconbar.com/
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message <gemini.m2dzv70...@alanwrigley.com>
> on 12 Apr 2012 Alan Wrigley wrote:
>
> > There's been a discussion in the last couple of days on c.s.a.misc about
> > problems with UniClip and the global clipboard. I want to raise the issue
> > here to get some feedback from others.
> >
> > The basic problem is this: UniClip (which attempts to share the clipboard
> > between more than one machine running either RISC OS or Windows) can only
> > operate properly by taking continual ownership of the 'global' clipboard in
> > RISC OS on non-Select machines.
>
> In message <gemini.m2dzv70...@alanwrigley.com>
> on 12 Apr 2012 Alan Wrigley wrote:
>
> > There's been a discussion in the last couple of days on c.s.a.misc about
> > problems with UniClip and the global clipboard. I want to raise the issue
> > here to get some feedback from others.
> >
> > The basic problem is this: UniClip (which attempts to share the clipboard
> > between more than one machine running either RISC OS or Windows) can only
> > operate properly by taking continual ownership of the 'global' clipboard in
> > RISC OS on non-Select machines.
>
> You mention non-Select machines. Can you explain what the difference is with
> Select?
Implementing support for the global clipboard is quite involved which is
> Select?
probably one of the reasons why so few applications support it. To make
life easier Select introduced the ClipboardHolder module, which provides
SWIs to copy data to/from the clipboard. Alleviating developers from the
effort of having tp implement the entire protocol themselves.
> Could that solution be ported to RO5, [..]
RISC OS 5 already has it's own support module (called Clipboard) which
also simplifies things through SWIs. See also:
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20Clipboard
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20GetClip
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20PutClip
--
Fred Graute
http://www.stronged.iconbar.com/
Fred Graute
Apr 12, 2012, 8:19:17 PM4/12/12
to
In message <gemini.m2dzv70...@alanwrigley.com>
work correctly without affecting other applications.
Lets say we have 4 machines (A,B,C,D) each with UniClip installed. When
an application on C claims the clipboard C's UniClip sends a message to
the other 3 machines saying that C now owns the clipboard. The UniClips
on A,B,D claim their clipboards upon reception and note that C now owns
the 'universal' (I'm assuming that's what Uni stands for) clipboard.
When an application on A requests the clipboard contents the request is
handled by A's UniClip which passes the request to C along with the list
of preferred filetypes. The UniClip on C requests the contents from the
application that has the 'universal' clipboard using the supplied list.
(If the request comes from a Windows machine the list may have to be
forced to allow only text format.)
The application sends the contents, in the most appropriate format, back
to UniClip on C which passes the data back to UniClip on A which in turn
sends it to the application that issued the initial request.
Please note that it doesn't matter which application holds the clipboard
we only need to know on which machine it is. It also doesn't matter that
the contents may change without notification (if the application already
owned the clipboard) as we don't fetch the data until it is requested.
Requests on C are handled outside of UniClip so should work as per
normal, at least until another machine claims the universal clipboard.
Lots of glossing over the nitty-gritty but the above seems sound to me.
The only thing I'm not sure about is Windows as I don't know how its
clipboard works internally but if there's some notification when its
contents changes then it should be okay.
Alan Wrigley <al...@alanwrigley.com> wrote:
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard in
> RISC OS on non-Select machines.
Why? Unless I'm missing something the following should allow UniClip to
> There's been a discussion in the last couple of days on c.s.a.misc about
> problems with UniClip and the global clipboard. I want to raise the issue
> here to get some feedback from others.
>
> The basic problem is this: UniClip (which attempts to share the clipboard
> between more than one machine running either RISC OS or Windows) can only
> operate properly by taking continual ownership of the 'global' clipboard in
> RISC OS on non-Select machines.
work correctly without affecting other applications.
Lets say we have 4 machines (A,B,C,D) each with UniClip installed. When
an application on C claims the clipboard C's UniClip sends a message to
the other 3 machines saying that C now owns the clipboard. The UniClips
on A,B,D claim their clipboards upon reception and note that C now owns
the 'universal' (I'm assuming that's what Uni stands for) clipboard.
When an application on A requests the clipboard contents the request is
handled by A's UniClip which passes the request to C along with the list
of preferred filetypes. The UniClip on C requests the contents from the
application that has the 'universal' clipboard using the supplied list.
(If the request comes from a Windows machine the list may have to be
forced to allow only text format.)
The application sends the contents, in the most appropriate format, back
to UniClip on C which passes the data back to UniClip on A which in turn
sends it to the application that issued the initial request.
Please note that it doesn't matter which application holds the clipboard
we only need to know on which machine it is. It also doesn't matter that
the contents may change without notification (if the application already
owned the clipboard) as we don't fetch the data until it is requested.
Requests on C are handled outside of UniClip so should work as per
normal, at least until another machine claims the universal clipboard.
Lots of glossing over the nitty-gritty but the above seems sound to me.
The only thing I'm not sure about is Windows as I don't know how its
clipboard works internally but if there's some notification when its
contents changes then it should be okay.
Alan Wrigley
Apr 13, 2012, 4:50:07 AM4/13/12
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> Yes, but the global clipboard protocol requires that they defer this to
> the global clipboard whenever appropriate.
Is this documented anywhere? Or is it an assumption that programmers have
> Yes, but the global clipboard protocol requires that they defer this to
> the global clipboard whenever appropriate.
made in the erroneous belief that the global clipboard works like a true
integrated system-wide clipboard?
Alan
--
RISC OS - you know it makes cents
Alan Wrigley
Apr 13, 2012, 4:57:31 AM4/13/12
to
Fred Graute <fjgr...@casema.nl> wrote:
> Requests on C are handled outside of UniClip so should work as per
> normal, at least until another machine claims the universal clipboard.
And herein lies the problem. If a selection is made within the application
> Requests on C are handled outside of UniClip so should work as per
> normal, at least until another machine claims the universal clipboard.
that already holds the clipboard, no claim is made.
For example, suppose you have two machines, A running RISC OS and B running
windows.
The user makes a selection in MyApp on A. MyApp claims the clipboard,
UniClip picks this up, asks for the clip and sends it to B, which puts it on
its clipboard.
The user makes a selection in DuffApp on Windows. UniClip does the same as
above in reverse.
Now the user makes another selection in MyApp, which this time doesn't make
a claim because it already holds the clipboard. The user goes to paste this
clip into DuffApp but Windows has no idea the clip exists and so supplies
the previous Windows clip instead.
Windows UniClip can't request machine A to fetch the latest clip because it
has no idea which machine holds the latest clip, unless UniClip on RO claims
the clipboard itself each time to force apps to claim it back themselves
each time a selection is made.
Alan Wrigley
Apr 13, 2012, 5:15:10 AM4/13/12
to
In a nutshell.
> But how is EasiWriter to know whether to paste from an internal copy of
> the data or from the global clipboard?
Well, this is why I put this out for discussion. I've already discovered a
flaw in my reasoning. My thought was that when EW is asked to supply a clip
in Text format, it should know that this is not its native format and should
therefore keep an internal copy of the native data. When it subsequently
asks for the clip back, and gets back a selection in Text format, it should
know that it can't use this to replace native format data.
BUT... I wasn't thinking clearly, as your subsequent example illustrates
clearly.
> Possible solutions that come to mind, that don't require an alteration to
> the protocol and all the applications:
comparing the data on every pass. There's no reason why a clip can't be very
large. A simple compare of the file sizes would go some way but if the sizes
are identical it would still be necessary to compare the contents. However,
on thinking about it some more, the larger the clip, the less likely it is
that two clips would be exactly the same size and so for the sake of very
occasional (or possibly never) having to compare the entire contents of a
large block of text, this might be worth doing.
> UniClip could request the data in formats other than text and store all of
> them ready to send back.
>
> Problems: memory. And there's no easy way to find out what filetypes are
> actually available from the clipboard owner: you just provide your own
> preferred list and the owner responds with a single version. You would
> have to send 4096 Message_DataRequest messages to work out which filetypes
> were available, if you were doing a thorough job!
Not quite - you can fit 52 filetypes into one Wimp message block. But this
is still out of the question and I don't see any point at all in doing it if
it isn't thorough since this problem will come up again one day
> What would happen if another application running on the same machine acted
> like UniClip? They would continually be bouncing clipboard claims between
> them!
Yes, though this is unlikely, and in that event the developers would need to
work together. The Select ClipboardHolder does this, and in this case
UniClip defers its claim to the CH because it no longer needs to do the job
itself.
> But how is EasiWriter to know whether to paste from an internal copy of
> the data or from the global clipboard?
flaw in my reasoning. My thought was that when EW is asked to supply a clip
in Text format, it should know that this is not its native format and should
therefore keep an internal copy of the native data. When it subsequently
asks for the clip back, and gets back a selection in Text format, it should
know that it can't use this to replace native format data.
BUT... I wasn't thinking clearly, as your subsequent example illustrates
clearly.
> Possible solutions that come to mind, that don't require an alteration to
> the protocol and all the applications:
> Instead of claiming the clipboard all the time, UniClip could note when it
> does not own the clipboard, and request a text version of the data from
> the owner every tenth of a second, or at a suitable interval determined by
> the user. UniClip could then compare before transmitting to the other
> machines.
Yes, I've considered that. The thing that put me off was the necessity of
> does not own the clipboard, and request a text version of the data from
> the owner every tenth of a second, or at a suitable interval determined by
> the user. UniClip could then compare before transmitting to the other
> machines.
comparing the data on every pass. There's no reason why a clip can't be very
large. A simple compare of the file sizes would go some way but if the sizes
are identical it would still be necessary to compare the contents. However,
on thinking about it some more, the larger the clip, the less likely it is
that two clips would be exactly the same size and so for the sake of very
occasional (or possibly never) having to compare the entire contents of a
large block of text, this might be worth doing.
> UniClip could request the data in formats other than text and store all of
> them ready to send back.
>
> Problems: memory. And there's no easy way to find out what filetypes are
> actually available from the clipboard owner: you just provide your own
> preferred list and the owner responds with a single version. You would
> have to send 4096 Message_DataRequest messages to work out which filetypes
> were available, if you were doing a thorough job!
is still out of the question and I don't see any point at all in doing it if
it isn't thorough since this problem will come up again one day
> What would happen if another application running on the same machine acted
> like UniClip? They would continually be bouncing clipboard claims between
> them!
work together. The Select ClipboardHolder does this, and in this case
UniClip defers its claim to the CH because it no longer needs to do the job
itself.
Alan Wrigley
Apr 13, 2012, 5:16:28 AM4/13/12
to
Fred Graute <fjgr...@casema.nl> wrote:
> RISC OS 5 already has it's own support module (called Clipboard) which
> also simplifies things through SWIs. See also:
I can't recall exactly how this works now, but it doesn't take continual
> RISC OS 5 already has it's own support module (called Clipboard) which
> also simplifies things through SWIs. See also:
control of the clipboard in the way that the Select ClipboardHolder does.
Alan Wrigley
Apr 13, 2012, 5:30:39 AM4/13/12
to
I myself wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > You would
> > have to send 4096 Message_DataRequest messages to work out which
>> filetypes were available, if you were doing a thorough job!
>
> Not quite - you can fit 52 filetypes into one Wimp message block. But this
> is still out of the question
Oops. I just re-read the specification, and if you supply a null list of
filetypes you get the data back in native format. So UniClip could indeed
store the native data and supply it on demand. I haven't tried this yet but
I think I've just seen a glimmer of light.
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > You would
> > have to send 4096 Message_DataRequest messages to work out which
>> filetypes were available, if you were doing a thorough job!
>
> Not quite - you can fit 52 filetypes into one Wimp message block. But this
> is still out of the question
filetypes you get the data back in native format. So UniClip could indeed
store the native data and supply it on demand. I haven't tried this yet but
I think I've just seen a glimmer of light.
Matthew Phillips
Apr 13, 2012, 8:35:27 AM4/13/12
to
In message <gemini.m2evr3002z...@keepyourfilthyspamtoyourself.co.uk>
But if you get given the clipboard contents in EasiWriter format, how on
earth are you going to make that useful to a Windows machine, or indeed to
any other RISC OS application that doesn't know how to handle such data?
Or are you, perhaps, going to ask EasiWriter for the clipboard contents "for
real" when another task asks for the contents from you? Except you cannot do
this because you have claimed the clipboard and EasiWriter may have thrown
away its information on what the selection was.
I can't see how that can work.
--
Matthew Phillips
Durham
earth are you going to make that useful to a Windows machine, or indeed to
any other RISC OS application that doesn't know how to handle such data?
Or are you, perhaps, going to ask EasiWriter for the clipboard contents "for
real" when another task asks for the contents from you? Except you cannot do
this because you have claimed the clipboard and EasiWriter may have thrown
away its information on what the selection was.
I can't see how that can work.
--
Matthew Phillips
Durham
Matthew Phillips
Apr 13, 2012, 8:41:48 AM4/13/12
to
In message <gemini.m2ev1a002f...@keepyourfilthyspamtoyourself.co.uk>
on 13 Apr 2012 Alan Wrigley wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Instead of claiming the clipboard all the time, UniClip could note when
> > it does not own the clipboard, and request a text version of the data
> > from the owner every tenth of a second, or at a suitable interval
> > determined by the user. UniClip could then compare before transmitting
> > to the other machines.
>
> Yes, I've considered that. The thing that put me off was the necessity of
> comparing the data on every pass. There's no reason why a clip can't be
> very large. A simple compare of the file sizes would go some way but if the
> sizes are identical it would still be necessary to compare the contents.
> However, on thinking about it some more, the larger the clip, the less
> likely it is that two clips would be exactly the same size and so for the
> sake of very occasional (or possibly never) having to compare the entire
> contents of a large block of text, this might be worth doing.
That sounds quite a good solution then. Except, of course, that the
clipboard content size in the Message_DataSave may only be an estimate. If
the clipboard owner has to do a lot of processing to work out the size, you
may find it always reports the size as some arbitrary number, like 2K.
> > UniClip could request the data in formats other than text and store all
> > of them ready to send back.
> >
> > Problems: memory. And there's no easy way to find out what filetypes are
> > actually available from the clipboard owner: you just provide your own
> > preferred list and the owner responds with a single version. You would
> > have to send 4096 Message_DataRequest messages to work out which
> > filetypes were available, if you were doing a thorough job!
>
> Not quite - you can fit 52 filetypes into one Wimp message block.
Yes, but if you list 52 filetypes in your request the clipboard owner will
only give you the in one format it prefers out of those 52, a format which
you and other applications may not understand at all, and you will never know
it could also have given the data in an open standard format which you
happened to list further down the same filetype list. I don't think this
could ever be made to work properly!
--
Matthew Phillips
Durham
on 13 Apr 2012 Alan Wrigley wrote:
> Matthew Phillips <spam...@yahoo.co.uk> wrote:
>
> > Instead of claiming the clipboard all the time, UniClip could note when
> > it does not own the clipboard, and request a text version of the data
> > from the owner every tenth of a second, or at a suitable interval
> > determined by the user. UniClip could then compare before transmitting
> > to the other machines.
>
> Yes, I've considered that. The thing that put me off was the necessity of
> comparing the data on every pass. There's no reason why a clip can't be
> very large. A simple compare of the file sizes would go some way but if the
> sizes are identical it would still be necessary to compare the contents.
> However, on thinking about it some more, the larger the clip, the less
> likely it is that two clips would be exactly the same size and so for the
> sake of very occasional (or possibly never) having to compare the entire
> contents of a large block of text, this might be worth doing.
clipboard content size in the Message_DataSave may only be an estimate. If
the clipboard owner has to do a lot of processing to work out the size, you
may find it always reports the size as some arbitrary number, like 2K.
> > UniClip could request the data in formats other than text and store all
> > of them ready to send back.
> >
> > Problems: memory. And there's no easy way to find out what filetypes are
> > actually available from the clipboard owner: you just provide your own
> > preferred list and the owner responds with a single version. You would
> > have to send 4096 Message_DataRequest messages to work out which
> > filetypes were available, if you were doing a thorough job!
>
> Not quite - you can fit 52 filetypes into one Wimp message block.
only give you the in one format it prefers out of those 52, a format which
you and other applications may not understand at all, and you will never know
it could also have given the data in an open standard format which you
happened to list further down the same filetype list. I don't think this
could ever be made to work properly!
--
Matthew Phillips
Durham
Alan Wrigley
Apr 13, 2012, 9:26:26 AM4/13/12
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> But if you get given the clipboard contents in EasiWriter format, how on
> earth are you going to make that useful to a Windows machine, or indeed to
> any other RISC OS application that doesn't know how to handle such data?
The main purpose of UniClip is to share data between machines that can be
> But if you get given the clipboard contents in EasiWriter format, how on
> earth are you going to make that useful to a Windows machine, or indeed to
> any other RISC OS application that doesn't know how to handle such data?
shared. Management of the RO clipboard is a by-product. Currently UniClip
only supports text sharing but I have always intended to expand this to
other shareable types in the future.
Obviously I need to think my next move through but I imagine what I will do
is to get clip data in both text and native formats, share the text with
Windows and offer the native when requested by a RO app.
Alan Wrigley
Apr 13, 2012, 9:29:55 AM4/13/12
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message
<gemini.m2ev1a002f...@keepyourfilthyspamtoyourself.co.uk>
> on 13 Apr 2012 Alan Wrigley wrote:
>
> > Yes, I've considered that. The thing that put me off was the necessity
of
> > comparing the data on every pass. There's no reason why a clip can't be
> > very large. A simple compare of the file sizes would go some way but if
the
> > sizes are identical it would still be necessary to compare the contents.
> > However, on thinking about it some more, the larger the clip, the less
> > likely it is that two clips would be exactly the same size and so for
the
> > sake of very occasional (or possibly never) having to compare the entire
> > contents of a large block of text, this might be worth doing.
>
> That sounds quite a good solution then. Except, of course, that the
> clipboard content size in the Message_DataSave may only be an estimate.
If
> the clipboard owner has to do a lot of processing to work out the size,
you
> may find it always reports the size as some arbitrary number, like 2K.
Wait until Message_DataLoad and check the size of the actual file.
> In message
<gemini.m2ev1a002f...@keepyourfilthyspamtoyourself.co.uk>
> on 13 Apr 2012 Alan Wrigley wrote:
>
> > Yes, I've considered that. The thing that put me off was the necessity
of
> > comparing the data on every pass. There's no reason why a clip can't be
> > very large. A simple compare of the file sizes would go some way but if
the
> > sizes are identical it would still be necessary to compare the contents.
> > However, on thinking about it some more, the larger the clip, the less
> > likely it is that two clips would be exactly the same size and so for
the
> > sake of very occasional (or possibly never) having to compare the entire
> > contents of a large block of text, this might be worth doing.
>
> That sounds quite a good solution then. Except, of course, that the
> clipboard content size in the Message_DataSave may only be an estimate.
If
> the clipboard owner has to do a lot of processing to work out the size,
you
> may find it always reports the size as some arbitrary number, like 2K.
Martin Wuerthner
Apr 13, 2012, 10:13:14 AM4/13/12
to
In message <d28ac57f5...@sinenomine.freeserve.co.uk>
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message <gemini.m2ev1a002ffsg031g.spamhater@keepyourfilthyspamtoyou
Things are not that bad - in practice, there is little point in
checking for anything but a handful of standard formats. In
particular, you are very unlikely to find any application that
supplies data in more than one non-standard (i.e., "native") format,
so there is no need to check for any unknown type. The usual situation
is that either the data is in a standard format already (e.g., Text),
or it is native (e.g., EasiWriter), plus one or more alternative
standard formats. So, if you request the native data and then Text,
Sprite, Draw, HTML and CSV you have covered pretty much all of them.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> In message <gemini.m2ev1a002ffsg031g.spamhater@keepyourfilthyspamtoyou
checking for anything but a handful of standard formats. In
particular, you are very unlikely to find any application that
supplies data in more than one non-standard (i.e., "native") format,
so there is no need to check for any unknown type. The usual situation
is that either the data is in a standard format already (e.g., Text),
or it is native (e.g., EasiWriter), plus one or more alternative
standard formats. So, if you request the native data and then Text,
Sprite, Draw, HTML and CSV you have covered pretty much all of them.
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
Jeremy Nicoll - news posts
Apr 13, 2012, 11:42:52 AM4/13/12
to
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
>Obviously I need to think my next move through but I imagine what I will do
>is to get clip data in both text and native formats, share the text with
>Windows and offer the native when requested by a RO app.
What about instances where 'native' formats are understood on both
>Obviously I need to think my next move through but I imagine what I will do
>is to get clip data in both text and native formats, share the text with
>Windows and offer the native when requested by a RO app.
platforms, eg Ovation Pro data between RO OP and OPW?
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".
Alan Wrigley
Apr 13, 2012, 12:04:07 PM4/13/12
to
Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk> wrote:
> Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
>
> >Obviously I need to think my next move through but I imagine what I will
do
> >is to get clip data in both text and native formats, share the text with
> >Windows and offer the native when requested by a RO app.
>
> What about instances where 'native' formats are understood on both
> platforms, eg Ovation Pro data between RO OP and OPW?
Read the rest of my post.
> Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
>
> >Obviously I need to think my next move through but I imagine what I will
do
> >is to get clip data in both text and native formats, share the text with
> >Windows and offer the native when requested by a RO app.
>
> What about instances where 'native' formats are understood on both
> platforms, eg Ovation Pro data between RO OP and OPW?
Matthew Phillips
Apr 13, 2012, 4:43:19 PM4/13/12
to
In message <gemini.m2f6o200be...@keepyourfilthyspamtoyourself.co.uk>
I thought of this solution on my way back to work a few minutes after making
the posting! The behaviour of UniClip would be much improved by this change.
Users may still notice a change in behaviour: for example if you copy to the
clipboard in EasiWriter then paste into Zap's HTML mode, you normally get
HTML. With UniClip in the way, Zap would get text (unless you fetched the
clipboard in a few other formats as per Martin's recent post).
Mind you, one EasiWriter user is currently complaining about this aspect, as
he's wanting to paste text from EasiWriter into a file in Zap's HTML mode,
and doesn't appreciate all the mark-up coming through!
(The best solution to this, I think, would be for Zap to offer a "plain text
paste" option.)
--
Matthew Phillips
Durham
on 13 Apr 2012 Alan Wrigley wrote:
the posting! The behaviour of UniClip would be much improved by this change.
Users may still notice a change in behaviour: for example if you copy to the
clipboard in EasiWriter then paste into Zap's HTML mode, you normally get
HTML. With UniClip in the way, Zap would get text (unless you fetched the
clipboard in a few other formats as per Martin's recent post).
Mind you, one EasiWriter user is currently complaining about this aspect, as
he's wanting to paste text from EasiWriter into a file in Zap's HTML mode,
and doesn't appreciate all the mark-up coming through!
(The best solution to this, I think, would be for Zap to offer a "plain text
paste" option.)
--
Matthew Phillips
Durham
Matthew Phillips
Apr 13, 2012, 4:52:04 PM4/13/12
to
In message <gemini.m2f6tv00bj...@keepyourfilthyspamtoyourself.co.uk>
clipboard could be a drain on processing power! At least with only going as
far as the Message_DataSave the clipboard owner will probably not have
written stuff to disc yet.
I think your proposal to fetch the native format and also text looks the most
promising.
--
Matthew Phillips
Durham
on 13 Apr 2012 Alan Wrigley wrote:
> Wait until Message_DataLoad and check the size of the actual file.
Doing that frequently really for what could potentially be a very large
> Wait until Message_DataLoad and check the size of the actual file.
clipboard could be a drain on processing power! At least with only going as
far as the Message_DataSave the clipboard owner will probably not have
written stuff to disc yet.
I think your proposal to fetch the native format and also text looks the most
promising.
--
Matthew Phillips
Durham
Steve Fryatt
Apr 13, 2012, 5:11:11 PM4/13/12
to
On 13 Apr, Alan Wrigley wrote in message
<gemini.m2etvi001j...@keepyourfilthyspamtoyourself.co.uk>:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > Yes, but the global clipboard protocol requires that they defer this to
> > the global clipboard whenever appropriate.
>
> Is this documented anywhere? Or is it an assumption that programmers have
> made in the erroneous belief that the global clipboard works like a true
> integrated system-wide clipboard?
No, it's a fundamental requirement of how the protocol works: I'd assumed
that you'd read the spec.
Consider:
- Application claims the clipboard following a Ctrl-C.
- Uniclip claims it back.
... time passes ...
- Application needs to paste for a Ctrl-V
Even if the application stored its own version of the clipboard, how does it
know that Uniclip hasn't changed its own copy. It can't, so all it can do
is ask the current owner (Uniclip) for a copy of what it (Uniclip) thinks is
the current contents.
This is exactly the same situation, but in reverse, to the one that you're
apparently unhappy with in Uniclip.
<gemini.m2etvi001j...@keepyourfilthyspamtoyourself.co.uk>:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > Yes, but the global clipboard protocol requires that they defer this to
> > the global clipboard whenever appropriate.
>
> Is this documented anywhere? Or is it an assumption that programmers have
> made in the erroneous belief that the global clipboard works like a true
> integrated system-wide clipboard?
that you'd read the spec.
Consider:
- Application claims the clipboard following a Ctrl-C.
- Uniclip claims it back.
... time passes ...
- Application needs to paste for a Ctrl-V
Even if the application stored its own version of the clipboard, how does it
know that Uniclip hasn't changed its own copy. It can't, so all it can do
is ask the current owner (Uniclip) for a copy of what it (Uniclip) thinks is
the current contents.
This is exactly the same situation, but in reverse, to the one that you're
apparently unhappy with in Uniclip.
Steve Fryatt
Apr 13, 2012, 5:21:30 PM4/13/12
to
On 13 Apr, Alan Wrigley wrote in message
<gemini.m2eu7v001s...@keepyourfilthyspamtoyourself.co.uk>:
> For example, suppose you have two machines, A running RISC OS and B
> running windows.
>
> The user makes a selection in MyApp on A. MyApp claims the clipboard,
> UniClip picks this up, asks for the clip and sends it to B, which puts it
> on its clipboard.
>
> The user makes a selection in DuffApp on Windows. UniClip does the same as
> above in reverse.
>
> Now the user makes another selection in MyApp, which this time doesn't
> make a claim because it already holds the clipboard. The user goes to
> paste this clip into DuffApp but Windows has no idea the clip exists and
> so supplies the previous Windows clip instead.
- When the uni clipboard is owned by a RISC OS application, that application
holds the RISC OS global clipboard, but
- When the uni clipboard is owned by an application on another machine (say
Windows), the RISC OS global clipboard is held by RISC OS Uniclip.
RISC OS Uniclip doesn't need to know whenever the global clipboard contents
changes; all it needs to know is whether *something* *else* owns it at the
current moment in time.
> Windows UniClip can't request machine A to fetch the latest clip because
> it has no idea which machine holds the latest clip, unless UniClip on RO
> claims the clipboard itself each time to force apps to claim it back
> themselves each time a selection is made.
Uniclip for the current contents whenever a paste is required?
I've never worked with it, but quickly glancing at the API suggests that it
also has a concept of "owner", and that the "owner" gets asked for data
whenever another application wants to paste.
Alan Wrigley
Apr 13, 2012, 6:06:39 PM4/13/12
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> So, are you saying that the problem is that Windows can't be made to *ask*
> Uniclip for the current contents whenever a paste is required?
Yes it can ask UniClip to get the current contents of the RO clipboard, but
> So, are you saying that the problem is that Windows can't be made to *ask*
> Uniclip for the current contents whenever a paste is required?
it has no way of knowing whether that clip is older or newer than whatever
clip is on the Windows clipboard.
Alan Wrigley
Apr 13, 2012, 6:21:10 PM4/13/12
to
Matthew Phillips <spam...@yahoo.co.uk> wrote:
> I thought of this solution on my way back to work a few minutes after
making
> the posting! The behaviour of UniClip would be much improved by this
change.
> Users may still notice a change in behaviour: for example if you copy to
the
> clipboard in EasiWriter then paste into Zap's HTML mode, you normally get
> HTML. With UniClip in the way, Zap would get text (unless you fetched the
> clipboard in a few other formats as per Martin's recent post).
I doubt if there is any one perfect solution. UniClip is trying to do
> I thought of this solution on my way back to work a few minutes after
making
> the posting! The behaviour of UniClip would be much improved by this
change.
> Users may still notice a change in behaviour: for example if you copy to
the
> clipboard in EasiWriter then paste into Zap's HTML mode, you normally get
> HTML. With UniClip in the way, Zap would get text (unless you fetched the
> clipboard in a few other formats as per Martin's recent post).
something the system wasn't designed for. Both R-Comp and I recognise that,
and users need to decide if the functionality it provides is worth the
quirks. For me, and for a good few other people, it's very much worth it.
Martin Wuerthner
Apr 13, 2012, 6:33:04 PM4/13/12
to
In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou
rself.co.uk>
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk>
wrote:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>> So, are you saying that the problem is that Windows can't be made to *ask*
>> Uniclip for the current contents whenever a paste is required?
> Yes it can ask UniClip to get the current contents of the RO clipboard, but
> it has no way of knowing whether that clip is older or newer than whatever
> clip is on the Windows clipboard.
It does know, and that is what Steve tried to point out in his reply.
He did not make it clear at which exact point your reasoning failed,
so let us go back to what you wrote in
<gemini.m2eu7v001s...@keepyourfilthyspamtoyourself.co.uk>:
> And herein lies the problem. If a selection is made within the
> application that already holds the clipboard, no claim is made.
That is correct, but it is not a problem in this scheme.
> For example, suppose you have two machines, A running RISC OS and B
> running windows.
> The user makes a selection in MyApp on A. MyApp claims the clipboard,
> UniClip picks this up, asks for the clip and sends it to B, which puts
> it on its clipboard.
> The user makes a selection in DuffApp on Windows. UniClip does the
> same as above in reverse.
Great, so at that moment, UniClip *claims* A's clipboard, so that
removes precisely the problem you describe in your next paragraph:
> Now the user makes another selection in MyApp, which this time doesn't
> make a claim because it already holds the clipboard.
No, because at that point, MyApp no longer owns the clipboard. So, it
does send a message and things work as expected.
There is never a question of which clipboard is the latest because in
response to a COPY operation on any machine UniClip claims the
clipboard on all *other* machines, so any subsequent COPY operations
on these other machines will generate a message and will hence be
noticed by UniClip. There is no need to claim the clipboard on the
machine where the COPY was made, it is enough for the local UniClip to
know that its machine currently holds the most recent clipboard in the
network. Any subsequent COPY operations in the same application on the
local machine go unnoticed as far as UniClip is concerned, but that is
not a problem.
rself.co.uk>
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk>
wrote:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>> So, are you saying that the problem is that Windows can't be made to *ask*
>> Uniclip for the current contents whenever a paste is required?
> Yes it can ask UniClip to get the current contents of the RO clipboard, but
> it has no way of knowing whether that clip is older or newer than whatever
> clip is on the Windows clipboard.
He did not make it clear at which exact point your reasoning failed,
so let us go back to what you wrote in
<gemini.m2eu7v001s...@keepyourfilthyspamtoyourself.co.uk>:
> And herein lies the problem. If a selection is made within the
> application that already holds the clipboard, no claim is made.
> For example, suppose you have two machines, A running RISC OS and B
> running windows.
> The user makes a selection in MyApp on A. MyApp claims the clipboard,
> UniClip picks this up, asks for the clip and sends it to B, which puts
> it on its clipboard.
> The user makes a selection in DuffApp on Windows. UniClip does the
> same as above in reverse.
removes precisely the problem you describe in your next paragraph:
> Now the user makes another selection in MyApp, which this time doesn't
> make a claim because it already holds the clipboard.
does send a message and things work as expected.
There is never a question of which clipboard is the latest because in
response to a COPY operation on any machine UniClip claims the
clipboard on all *other* machines, so any subsequent COPY operations
on these other machines will generate a message and will hence be
noticed by UniClip. There is no need to claim the clipboard on the
machine where the COPY was made, it is enough for the local UniClip to
know that its machine currently holds the most recent clipboard in the
network. Any subsequent COPY operations in the same application on the
local machine go unnoticed as far as UniClip is concerned, but that is
not a problem.
Steve Fryatt
Apr 13, 2012, 6:54:31 PM4/13/12
to
On 13 Apr, Alan Wrigley wrote in message
<gemini.m2fur300tz...@keepyourfilthyspamtoyourself.co.uk>:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > So, are you saying that the problem is that Windows can't be made to
> > *ask* Uniclip for the current contents whenever a paste is required?
>
> Yes it can ask UniClip to get the current contents of the RO clipboard,
> but it has no way of knowing whether that clip is older or newer than
> whatever clip is on the Windows clipboard.
Uniprint claims the clipboard on all the other machines by proxy. That way,
Uniclip may not know exactly what is on the clipboard, but it will always
know exactly where it can be found.
Alan Wrigley
Apr 14, 2012, 4:15:32 AM4/14/12
to
Martin Wuerthner <spam...@mw-software.com> wrote:
> In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou
> rself.co.uk>
> Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk>
> wrote:
>
> > Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> >> So, are you saying that the problem is that Windows can't be made to
*ask*
> >> Uniclip for the current contents whenever a paste is required?
>
> > Yes it can ask UniClip to get the current contents of the RO clipboard,
but
> > it has no way of knowing whether that clip is older or newer than
whatever
> > clip is on the Windows clipboard.
>
> It does know, and that is what Steve tried to point out in his reply.
> [..snip..]
> In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou
> rself.co.uk>
> Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk>
> wrote:
>
> > Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> >> So, are you saying that the problem is that Windows can't be made to
*ask*
> >> Uniclip for the current contents whenever a paste is required?
>
> > Yes it can ask UniClip to get the current contents of the RO clipboard,
but
> > it has no way of knowing whether that clip is older or newer than
whatever
> > clip is on the Windows clipboard.
>
> It does know, and that is what Steve tried to point out in his reply.
> Great, so at that moment, UniClip *claims* A's clipboard, so that
> removes precisely the problem you describe in your next paragraph:
original question, which was why UniClip needed to claim the clipboard, and
explaining what the situation would be if it didn't do so.
Alan
Alan Wrigley
Apr 14, 2012, 4:17:44 AM4/14/12
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 13 Apr, Alan Wrigley wrote in message
>
<gemini.m2fur300tz...@keepyourfilthyspamtoyourself.co.uk>:
>
> > Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> >
> > > So, are you saying that the problem is that Windows can't be made to
> > > *ask* Uniclip for the current contents whenever a paste is required?
> >
> > Yes it can ask UniClip to get the current contents of the RO clipboard,
> > but it has no way of knowing whether that clip is older or newer than
> > whatever clip is on the Windows clipboard.
>
> Yes it does. Whenever an application on one system claims the clipboard,
> Uniprint claims the clipboard on all the other machines by proxy.
Yes, but if UniClip does NOT claim the RO clipboard, which was the point of
> On 13 Apr, Alan Wrigley wrote in message
>
<gemini.m2fur300tz...@keepyourfilthyspamtoyourself.co.uk>:
>
> > Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> >
> > > So, are you saying that the problem is that Windows can't be made to
> > > *ask* Uniclip for the current contents whenever a paste is required?
> >
> > Yes it can ask UniClip to get the current contents of the RO clipboard,
> > but it has no way of knowing whether that clip is older or newer than
> > whatever clip is on the Windows clipboard.
>
> Yes it does. Whenever an application on one system claims the clipboard,
> Uniprint claims the clipboard on all the other machines by proxy.
my reply to your original question, then the app that does claim it is free
to process future selections without a further claim, leaving UniClip
unaware of the action.
Steve Fryatt
Apr 14, 2012, 5:48:45 AM4/14/12
to
On 14 Apr, Alan Wrigley wrote in message
<gemini.m2gn1k0007...@keepyourfilthyspamtoyourself.co.uk>:
Yes, but you've still not explained *why* Uniclip "needs" to know this. It
knows that another application owns the global clipboard, and therefore that
it must ask for the data when it need it. That's all which is required.
You've confirmed above that Windows can ask for the data when it needs to
paste. If a RISC OS app owns the clipboard, Uniclip then issues a
Message_DataRequest and passes the result back to Windows for its clipboard.
Maybe I'm missing something, but at present I really can't see why Uniclip
must behave in such an antisocial manner in order to work.
<gemini.m2gn1k0007...@keepyourfilthyspamtoyourself.co.uk>:
knows that another application owns the global clipboard, and therefore that
it must ask for the data when it need it. That's all which is required.
You've confirmed above that Windows can ask for the data when it needs to
paste. If a RISC OS app owns the clipboard, Uniclip then issues a
Message_DataRequest and passes the result back to Windows for its clipboard.
Maybe I'm missing something, but at present I really can't see why Uniclip
must behave in such an antisocial manner in order to work.
Alan Wrigley
Apr 14, 2012, 6:07:09 AM4/14/12
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> You've confirmed above that Windows can ask for the data when it needs to
> paste.
I phrased that badly. I meant that there's no technical reason why UniClip
> You've confirmed above that Windows can ask for the data when it needs to
> paste.
(Win) can't ask UniClip (RO) for the current clip, but there doesn't appear
to be any way for UniClip (Win) to know when the user wants to paste. I
imagine (though I haven't looked into it) that it could claim the Windows
clipboard in the same way, but that just shifts the problem elsewhere and
probably opens up other cans of worms.
In other words, in order to function at all, it has to be pro-active rather
than reactive (meaning that somewhere along the line it has to push clips
out rather than wait to pull them in).
> I really can't see why Uniclip
> must behave in such an antisocial manner
live with the consequences.
I'm sick of this discussion. If anyone thinks they can do it better, please
contact R-Comp.
Steve Fryatt
Apr 14, 2012, 6:31:31 AM4/14/12
to
On 14 Apr, Alan Wrigley wrote in message
<gemini.m2gs3x0043...@keepyourfilthyspamtoyourself.co.uk>:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > You've confirmed above that Windows can ask for the data when it needs
> > to paste.
>
> I phrased that badly. I meant that there's no technical reason why UniClip
> (Win) can't ask UniClip (RO) for the current clip, but there doesn't
> appear to be any way for UniClip (Win) to know when the user wants to
> paste. I imagine (though I haven't looked into it) that it could claim the
> Windows clipboard in the same way, but that just shifts the problem
> elsewhere and probably opens up other cans of worms.
>
> In other words, in order to function at all, it has to be pro-active
> rather than reactive (meaning that somewhere along the line it has to push
> clips out rather than wait to pull them in).
http://msdn.microsoft.com/en-us/library/windows/desktop/ms649014%28v=vs.85%29.aspx#_win32_Delayed_Rendering
which implies that Uniclip (win) could say "I've put data on the clipboard,
but ask me for it when you need to paste". I'm not a Windows API expert,
and you might have already investigated this, but my reading of it would
suggest that it would help integrate what you're doing into the RISC OS API.
Alan Wrigley
Apr 14, 2012, 7:14:22 AM4/14/12
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> implies that Uniclip (win) could say "I've put data on the clipboard,
> but ask me for it when you need to paste". I'm not a Windows API expert,
> and you might have already investigated this, but my reading of it would
> suggest that it would help integrate what you're doing into the RISC OS
> API.
My brain is now totally fried with this so I may no longer be seeing the
> implies that Uniclip (win) could say "I've put data on the clipboard,
> but ask me for it when you need to paste". I'm not a Windows API expert,
> and you might have already investigated this, but my reading of it would
> suggest that it would help integrate what you're doing into the RISC OS
> API.
wood for the trees (if I ever did), but at first glance this would not help.
The purpose of UniClip is to create a virtual clipboard between two or more
machines and ensure the latest selection is pasted when required. So if a
Windows user hits Ctrl-V, using your scenario above it looks as though
UniClip (Win) can ask UniClip (RO) to request the latest clip, but unless
UniClip (RO) has taken control of the RO clipboard, neither end of the
application knows whether the resulting clip is older or newer than whatever
is on the Windows clipboard if the RO selection was made without reclaiming
the clipboard.
Alan Wrigley
Apr 14, 2012, 7:53:54 AM4/14/12
to
I wrote:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > implies that Uniclip (win) could say "I've put data on the clipboard,
> > but ask me for it when you need to paste". I'm not a Windows API
expert,
> > and you might have already investigated this, but my reading of it would
> > suggest that it would help integrate what you're doing into the RISC OS
> > API.
>
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > implies that Uniclip (win) could say "I've put data on the clipboard,
> > but ask me for it when you need to paste". I'm not a Windows API
expert,
> > and you might have already investigated this, but my reading of it would
> > suggest that it would help integrate what you're doing into the RISC OS
> > API.
>
> unless UniClip (RO) has taken control of the RO clipboard, neither end of
> the application knows whether the resulting clip is older or newer than
> whatever is on the Windows clipboard if the RO selection was made without
> reclaiming the clipboard.
One way I could see this might work is as follows:
> the application knows whether the resulting clip is older or newer than
> whatever is on the Windows clipboard if the RO selection was made without
> reclaiming the clipboard.
App A on Windows puts a selection on the clipboard. UniClip (Win)
immediately asks UniClip (RO) to grab the current clip and keep it.
User performs a paste on Windows. UniClip (Win) notifies UniClip (RO) which
grabs the current clip again and compares it to the former. If it's the
same, the Windows clip is newer.
However, this seems like a very significant overhead for a user who hits
Ctrl-V and expects text to appear immediately at the cursor. Add more
machines into the mix and it becomes even more complicated. And what about
sharing a clipboard between two RO machines only? How would that work
without at least one of them taking control of its clipboard? On Windows you
can be sure of being notified whenever data is put on the clipboard. On RO
you can't.
The way UniClip is implemented, the current selection is always available
instantly on any shared machine the moment a paste is done. If I make the
change suggested by Martin and store both native and text data, I don't see
why it needs to be antisocial at all.
Steve Fryatt
Apr 14, 2012, 9:30:00 AM4/14/12
to
On 14 Apr, Alan Wrigley wrote in message
<gemini.m2gv7y006i...@keepyourfilthyspamtoyourself.co.uk>:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > implies that Uniclip (win) could say "I've put data on the clipboard,
> > but ask me for it when you need to paste". I'm not a Windows API
> > expert, and you might have already investigated this, but my reading of
> > it would suggest that it would help integrate what you're doing into the
> > RISC OS API.
>
> My brain is now totally fried with this so I may no longer be seeing the
> wood for the trees (if I ever did), but at first glance this would not
> help.
correctly, then it seems to be fairly straight-forward:
- For any copy of Uniclip (Windows, RISC OS, whatever), when an application
on its machine claims the clipboard it tells Uniclip on all the other
machines to claim the clipboard there.
- As a result, all but one of the active copies of Uniclip will own their
"local" global clipboard at any given time. The one that doesn't knows that
its machine is the one where the most recent clipboard content resides.
- When a paste occurs and Uniclip is the owner of the relevant "local"
global clipboard, it must ask the only copy of Uniclip *not* owning its
clipboard to request the current contents and feed it back over the network.
Assuming that the Windows API which I quoted really does mean that
applications can "render" the clipboard contents on demand, the data can
then be supplied to the pasting application.
- When a paste occurs and Uniclip doesn't own the relevant "local" global
clipboard, it can safely ignore the issue because it isn't required to get
involved.
Even better, it should also be possible to negotiate different data types
across Windows and RISC OS, although that isn't necessary to fix the problem
that Uniclip currently causes for apps like *Writer and O-Pro.
Martin Wuerthner
Apr 14, 2012, 10:18:24 AM4/14/12
to
In message <gemini.m2gmxv0004eox02ds.spamhater@keepyourfilthyspamtoyou
No, not at all. I am referring to exactly the same issue. The crucial
point is that only the *local* claim of the clipboard is disputed
(i.e, the claim on the machine where the COPY happened). See below.
Steve's proposal is viable, but it would work very differently from
the existing UniClip approach, so that might not be feasible in
commercial terms.
The priority should be to fix the current issues, and as we have
established that can be done without changing the existing approach
too much. UniClip can still continue claiming the local clipboard as
long as it makes sure that the native data is still present on the
local clipboard in addition to the text data. That change would solve
almost all issues.
It can be done in a much better way though, which would not only solve
the existing RISC OS clipboard problems, but would also have massively
improved performance (in particular with a view to extending the
system to other data types, most notably bitmaps, which can huge):
The problem with the current approach is that UniClip claims the local
clipboard on the machine where the most recent copy happened, i.e.,
the machine that owns the current clipboard. The question was why that
is necessary because that local claim (in its current form) is
harmful. In the alternative approach that Steve proposed the local
claim would be avoided, but UniClip would still claim the clipboard on
all *other* machines. These other claims are not harmful and they are
required to make the mechanism work.
You can make the Windows clipboard work in exactly the same way as the
RISC OS clipboard, i.e., the data is pulled from the owning
application at the moment a paste happens, so there is no need to push
the data to all the other machines in advance. When a copy happens on
a machine, it is enough for the local UniClip to remember that it is
the holder of the universal clipboard and to send messages around that
make the other UniClip instances claim the clipboard on all the
*other* machines. When a paste happens the data is pulled from the
clipboard owner. If the paste happned on the machine that owns the
universal clipboard the owner is the original application that claimed
the clipboard, not UniClip, so the existing RISC OS protocol works
perfectly. If a paste happens on one of the other machines, UniClip is
the owner and it pulls the data via the network from the UniClip
instance on the machine that owns the universal clipboard.
Apart from fixing all RISC OS clipboard issues, that approach would
have another huge benefit: It would save lots of memory and processing
time because no data would ever be transferred unless it is actually
needed for a paste operation. At the moment, any copy operation
anywhere in the network prompts UniClip to retrieve and transfer the
data to all other machines in the network, which is very wasteful
because most of the transferred data will never be needed.
point is that only the *local* claim of the clipboard is disputed
(i.e, the claim on the machine where the COPY happened). See below.
Steve's proposal is viable, but it would work very differently from
the existing UniClip approach, so that might not be feasible in
commercial terms.
The priority should be to fix the current issues, and as we have
established that can be done without changing the existing approach
too much. UniClip can still continue claiming the local clipboard as
long as it makes sure that the native data is still present on the
local clipboard in addition to the text data. That change would solve
almost all issues.
It can be done in a much better way though, which would not only solve
the existing RISC OS clipboard problems, but would also have massively
improved performance (in particular with a view to extending the
system to other data types, most notably bitmaps, which can huge):
The problem with the current approach is that UniClip claims the local
clipboard on the machine where the most recent copy happened, i.e.,
the machine that owns the current clipboard. The question was why that
is necessary because that local claim (in its current form) is
harmful. In the alternative approach that Steve proposed the local
claim would be avoided, but UniClip would still claim the clipboard on
all *other* machines. These other claims are not harmful and they are
required to make the mechanism work.
You can make the Windows clipboard work in exactly the same way as the
RISC OS clipboard, i.e., the data is pulled from the owning
application at the moment a paste happens, so there is no need to push
the data to all the other machines in advance. When a copy happens on
a machine, it is enough for the local UniClip to remember that it is
the holder of the universal clipboard and to send messages around that
make the other UniClip instances claim the clipboard on all the
*other* machines. When a paste happens the data is pulled from the
clipboard owner. If the paste happned on the machine that owns the
universal clipboard the owner is the original application that claimed
the clipboard, not UniClip, so the existing RISC OS protocol works
perfectly. If a paste happens on one of the other machines, UniClip is
the owner and it pulls the data via the network from the UniClip
instance on the machine that owns the universal clipboard.
Apart from fixing all RISC OS clipboard issues, that approach would
have another huge benefit: It would save lots of memory and processing
time because no data would ever be transferred unless it is actually
needed for a paste operation. At the moment, any copy operation
anywhere in the network prompts UniClip to retrieve and transfer the
data to all other machines in the network, which is very wasteful
because most of the transferred data will never be needed.
Alan Wrigley
Apr 14, 2012, 12:02:51 PM4/14/12
to
Martin Wuerthner <spam...@mw-software.com> wrote:
> You can make the Windows clipboard work in exactly the same way as the
> RISC OS clipboard, i.e., the data is pulled from the owning
> application at the moment a paste happens, so there is no need to push
> the data to all the other machines in advance. When a copy happens on
> a machine, it is enough for the local UniClip to remember that it is
> the holder of the universal clipboard and to send messages around that
> make the other UniClip instances claim the clipboard on all the
> *other* machines. When a paste happens the data is pulled from the
> clipboard owner. If the paste happned on the machine that owns the
> universal clipboard the owner is the original application that claimed
> the clipboard, not UniClip, so the existing RISC OS protocol works
> perfectly. If a paste happens on one of the other machines, UniClip is
> the owner and it pulls the data via the network from the UniClip
> instance on the machine that owns the universal clipboard.
I'm sorry, but I STILL don't see it.
> You can make the Windows clipboard work in exactly the same way as the
> RISC OS clipboard, i.e., the data is pulled from the owning
> application at the moment a paste happens, so there is no need to push
> the data to all the other machines in advance. When a copy happens on
> a machine, it is enough for the local UniClip to remember that it is
> the holder of the universal clipboard and to send messages around that
> make the other UniClip instances claim the clipboard on all the
> *other* machines. When a paste happens the data is pulled from the
> clipboard owner. If the paste happned on the machine that owns the
> universal clipboard the owner is the original application that claimed
> the clipboard, not UniClip, so the existing RISC OS protocol works
> perfectly. If a paste happens on one of the other machines, UniClip is
> the owner and it pulls the data via the network from the UniClip
> instance on the machine that owns the universal clipboard.
Machine A: Windows
Machine B: RISC OS
10.01
User hits Ctrl-C on B while using MyApp. UniClip B takes the clip and
notifies UniClip A, which grabs the current clip on its own machine.
B is now the holder of the clipboard. A & B both have clips timed 10.01.
10.02
User hits Ctrl-C on A. UniClip A takes the clip and notifies UniClip B,
which grabs its own clip. A is now the holder of the clipboard. A & B both
have clips timed 10.02.
10.03
User continues using MyApp on B and hits Ctrl-C on a new selection. Because
MyApp already owns the RO clipboard it doesn't claim it. UniClip B knows
nothing whatsoever about it and so A continues to believe it is the holder
of the clipboard. A & B both still have clips timed at 10.02.
10.04
User hits Ctrl-V on A and gets the 10.02 clip from UniClip A which is not
the most recent.
If there are more machines on the network, particularly if two or more of
them are RISC OS, the situation gets even more chaotic.
AFAICS the only way round this is the method I suggested earlier whereby the
paste operation at 10.04 triggers UniClip A to ask UniClip B for its latest
clip. It then has to do a byte-by-byte comparison of the two clips to
ascertain whether its current clip is more recent than the 10.02 clip. I
would suggest this is far more of a potential performance hit than the
current situation.
Jeremy Nicoll - news posts
Apr 14, 2012, 4:08:26 PM4/14/12
to
Martin Wuerthner <spam...@mw-software.com> wrote:
> When a copy happens on a machine, it is enough for the local UniClip to
> remember that it is the holder of the universal clipboard and to send
> messages around that make the other UniClip instances claim the clipboard
> on all the *other* machines.
Something puzzles me about this. What happens if more than one copy happens
> When a copy happens on a machine, it is enough for the local UniClip to
> remember that it is the holder of the universal clipboard and to send
> messages around that make the other UniClip instances claim the clipboard
> on all the *other* machines.
on (several) machines at the same time (or at least before the messages sent
by the first copy that Uniclip is telling other machines about is processed
everywhere else)?
Does this whole process only work on the assumption that a human user
instigated a copy at a keyboard and hasn't had time to press Ctrl-C anywhere
else yet?
But keyboard automation packages etc can be using copy & paste without human
intervention. Or do they only use local clipboards?
Alan Wrigley
Apr 14, 2012, 4:22:36 PM4/14/12
to
> Does this whole process only work on the assumption that a human user
> instigated a copy at a keyboard and hasn't had time to press Ctrl-C
> anywhere else yet?
That is the assumption behind the app, yes. UniClip is designed primarily to
> instigated a copy at a keyboard and hasn't had time to press Ctrl-C
> anywhere else yet?
enable you to work on two computers at the same time without having to
resort to a long-winded way of transferring selections between them.
> But keyboard automation packages etc can be using copy & paste without
> human intervention. Or do they only use local clipboards?
is a tool - use it if it does the job you want to do and doesn't interfere
with other things, don't use it otherwise.
Fred Graute
Apr 14, 2012, 8:12:42 PM4/14/12
to
In message <gemini.m2h8kr001l...@keepyourfilthyspamtoyourself.co.uk>
that I proposed earlier. Hopefully this will make it clear how it works
and how it gets round the limitations that UniClip currently has.
10.01
User hits Ctrl-C on B. UniClip B notes that universal clipboard is owned
by B, sends message to UniClip A. The message tells A that the universal
clipboard is on B and that A should claim its local clipboard.
B does not request current clip nor does it claim the local clipboard.
10.02
User hits Ctrl-C on A while using MyApp. UniClip A notes that universal
clipboard is owned by B, sends message to UniClip B. The message tells B
that the universal clipboard is on A and that B should claim its local
clipboard.
A does not request current clip nor does it claim the local clipboard.
10.03
User hits Ctrl-V on B. UniClip B sends message to A requesting the clip.
UniClip A requests clip from MyApp and sends it to UniClip B which in
turn passes the 10.02 clip to the requesting application.
10.04
User hits Ctrl-C again on A while still using MyApp. Nothing happens as
universal clipboard is already owned by A and local clipboard stays with
MyApp. Only the local clipboard's contents is changed.
10.05
User hits Ctrl-V again on B. UniClip B sends message to A requesting the
clip. UniClip A requests clip from MyApp and sends it to UniClip B which
in turn passes to the requesting application. The clip send will be the
newer 10.04 clip.
This is what Steve, Martin and I have been getting at;
1) On the machine that holds the universal clipboard, the local
clipboard is owned by the application that (last) claimed it.
On all other machines the local clipboard is owned by their
copy of UniClip.
2) The current clip is only send to another machine when it is
requested on that machine. And this is done every time the clip
is requested thus ensuring that the pasting application always
gets the latest contents.
3) As the actual clip remains with the application that stored it
the clip can be delivered in any format that the application can
convert it to.
The above should work fine on a network with only RISC OS machines.
The uncertain factor is Windows. Does it allow for UniClip to claim the
local clipboard but with pasting still under its control. Steve's found
something that suggests that this may be possible.
If it is, then it should be technically possible to avoid the problem
that started this thread. As Martin says, it's a lot of work so may not
be commercially viable but that's for you and R-Comp to decide.
--
Fred Graute
http://www.stronged.iconbar.com/
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
> Martin Wuerthner <spam...@mw-software.com> wrote:
>
> > You can make the Windows clipboard work in exactly the same way as the
> > RISC OS clipboard, i.e., the data is pulled from the owning
> > application at the moment a paste happens, so there is no need to push
> > the data to all the other machines in advance. When a copy happens on
> > a machine, it is enough for the local UniClip to remember that it is
> > the holder of the universal clipboard and to send messages around that
> > make the other UniClip instances claim the clipboard on all the
> > *other* machines. When a paste happens the data is pulled from the
> > clipboard owner. If the paste happned on the machine that owns the
> > universal clipboard the owner is the original application that claimed
> > the clipboard, not UniClip, so the existing RISC OS protocol works
> > perfectly. If a paste happens on one of the other machines, UniClip is
> > the owner and it pulls the data via the network from the UniClip
> > instance on the machine that owns the universal clipboard.
>
> I'm sorry, but I STILL don't see it.
Below I've described how your timed sequence would look under the scheme
> Martin Wuerthner <spam...@mw-software.com> wrote:
>
> > You can make the Windows clipboard work in exactly the same way as the
> > RISC OS clipboard, i.e., the data is pulled from the owning
> > application at the moment a paste happens, so there is no need to push
> > the data to all the other machines in advance. When a copy happens on
> > a machine, it is enough for the local UniClip to remember that it is
> > the holder of the universal clipboard and to send messages around that
> > make the other UniClip instances claim the clipboard on all the
> > *other* machines. When a paste happens the data is pulled from the
> > clipboard owner. If the paste happned on the machine that owns the
> > universal clipboard the owner is the original application that claimed
> > the clipboard, not UniClip, so the existing RISC OS protocol works
> > perfectly. If a paste happens on one of the other machines, UniClip is
> > the owner and it pulls the data via the network from the UniClip
> > instance on the machine that owns the universal clipboard.
>
> I'm sorry, but I STILL don't see it.
that I proposed earlier. Hopefully this will make it clear how it works
and how it gets round the limitations that UniClip currently has.
10.01
User hits Ctrl-C on B. UniClip B notes that universal clipboard is owned
by B, sends message to UniClip A. The message tells A that the universal
clipboard is on B and that A should claim its local clipboard.
B does not request current clip nor does it claim the local clipboard.
10.02
User hits Ctrl-C on A while using MyApp. UniClip A notes that universal
clipboard is owned by B, sends message to UniClip B. The message tells B
that the universal clipboard is on A and that B should claim its local
clipboard.
A does not request current clip nor does it claim the local clipboard.
10.03
User hits Ctrl-V on B. UniClip B sends message to A requesting the clip.
UniClip A requests clip from MyApp and sends it to UniClip B which in
turn passes the 10.02 clip to the requesting application.
10.04
User hits Ctrl-C again on A while still using MyApp. Nothing happens as
universal clipboard is already owned by A and local clipboard stays with
MyApp. Only the local clipboard's contents is changed.
10.05
User hits Ctrl-V again on B. UniClip B sends message to A requesting the
clip. UniClip A requests clip from MyApp and sends it to UniClip B which
in turn passes to the requesting application. The clip send will be the
newer 10.04 clip.
This is what Steve, Martin and I have been getting at;
1) On the machine that holds the universal clipboard, the local
clipboard is owned by the application that (last) claimed it.
On all other machines the local clipboard is owned by their
copy of UniClip.
2) The current clip is only send to another machine when it is
requested on that machine. And this is done every time the clip
is requested thus ensuring that the pasting application always
gets the latest contents.
3) As the actual clip remains with the application that stored it
the clip can be delivered in any format that the application can
convert it to.
The above should work fine on a network with only RISC OS machines.
The uncertain factor is Windows. Does it allow for UniClip to claim the
local clipboard but with pasting still under its control. Steve's found
something that suggests that this may be possible.
If it is, then it should be technically possible to avoid the problem
that started this thread. As Martin says, it's a lot of work so may not
be commercially viable but that's for you and R-Comp to decide.
--
Fred Graute
http://www.stronged.iconbar.com/
Alan Wrigley
Apr 15, 2012, 6:46:11 AM4/15/12
to
Fred Graute <fjgr...@casema.nl> wrote:
> Below I've described how your timed sequence would look under the scheme
> that I proposed earlier. Hopefully this will make it clear how it works
> and how it gets round the limitations that UniClip currently has.
Thank you for this very clear explanation.
> Below I've described how your timed sequence would look under the scheme
> that I proposed earlier. Hopefully this will make it clear how it works
> and how it gets round the limitations that UniClip currently has.
I was so focused on people not liking the idea of UniClip claiming the
clipboard that I overlooked the fact that it is perfectly legitimate for it
to do so when the clipboard holder is another machine.
In other words, although I designed UniClip as an integrated concept, my
brain was still looking at the components as co-operating rather than
interlocking.
This of course would also solve at a stroke the problem of UniClip not
retaining native data, as I'm sure Martin must have said at some point.
My apologies for dragging this discussion out for so long. Now, where should
I go for a holiday?
John Williams (News)
Apr 15, 2012, 7:09:38 AM4/15/12
to
In article
<gemini.m2ioky006b...@keepyourfilthyspamtoyourself.co.uk>,
John
--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/
<gemini.m2ioky006b...@keepyourfilthyspamtoyourself.co.uk>,
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
> My apologies for dragging this discussion out for so long. Now, where
> should I go for a holiday?
I'm free!
> My apologies for dragging this discussion out for so long. Now, where
> should I go for a holiday?
John
--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/
Jeremy Nicoll - news posts
Apr 17, 2012, 1:46:43 PM4/17/12
to
Alan Wrigley <al...@alanwrigley.com> wrote:
>There's been a discussion in the last couple of days on c.s.a.misc about
>problems with UniClip and the global clipboard.
For anyone who cares and doesn't know of it or an equivalent, there's a
Windows utility which displays the contents of the Windows clipboard (ie
what types of data are stored and what each of their values are, in ascii
and hex) available at:
http://www.nirsoft.net/utils/inside_clipboard.html
(I had cause today to read through the whole list of utilities available on
this site, and this caught my eye.)
>There's been a discussion in the last couple of days on c.s.a.misc about
>problems with UniClip and the global clipboard.
For anyone who cares and doesn't know of it or an equivalent, there's a
Windows utility which displays the contents of the Windows clipboard (ie
what types of data are stored and what each of their values are, in ascii
and hex) available at:
http://www.nirsoft.net/utils/inside_clipboard.html
(I had cause today to read through the whole list of utilities available on
this site, and this caught my eye.)
Rick Murray
Apr 19, 2012, 11:52:10 PM4/19/12
to
On 13/04/2012 00:01, Alan Wrigley wrote:
> Editors on RO have known how to move their own data around within
> themselves long before the global clipboard protocol was devised.
The task-to-task save protocol. Works well, but is totally alien to
those used to ^C and ^V. There are times when a cut/copy-paste is less
cumbersome, such as quoting bits of something (you can save selection,
but it is less easy than ^C/^V; providing the application supports
saving just a selection).
>After all, the whole purpose of the global clipboard was to allow
> apps to share data, not for apps to pass data around internally.
In which case, sorry, I have no need for a "global clipboard". If it is
going to make distinctions as to what it will support and require
applications with more complex layout to provide their own clipboard
(with, perhaps, their own features and/or quirks), then frankly the
global clipboard would be:
a. Not "global"
and:
b. Stands to get in the way
> without reliance on the clipboard if, and only if, the clipboard has not
> requested the data in the app's format.
Why is a clipboard REQUESTING? Surely an app should paste something into
the clipboard tagged with a "this is <blah> data", and then the
clipboard can say "I have <blah> available" if something asks it?
Best wishes,
Rick.
> Editors on RO have known how to move their own data around within
> themselves long before the global clipboard protocol was devised.
The task-to-task save protocol. Works well, but is totally alien to
those used to ^C and ^V. There are times when a cut/copy-paste is less
cumbersome, such as quoting bits of something (you can save selection,
but it is less easy than ^C/^V; providing the application supports
saving just a selection).
>After all, the whole purpose of the global clipboard was to allow
> apps to share data, not for apps to pass data around internally.
In which case, sorry, I have no need for a "global clipboard". If it is
going to make distinctions as to what it will support and require
applications with more complex layout to provide their own clipboard
(with, perhaps, their own features and/or quirks), then frankly the
global clipboard would be:
a. Not "global"
and:
b. Stands to get in the way
> without reliance on the clipboard if, and only if, the clipboard has not
> requested the data in the app's format.
Why is a clipboard REQUESTING? Surely an app should paste something into
the clipboard tagged with a "this is <blah> data", and then the
clipboard can say "I have <blah> available" if something asks it?
Best wishes,
Rick.
Matthew Phillips
Apr 20, 2012, 6:15:09 PM4/20/12
to
In message <4f90dd6a$0$12508$ba4a...@reader.news.orange.fr>
Keeping the clipboard content under the control of the original application
allows that application to serve it up in various formats as requested, when
a paste occurs. Otherwise the clipboard might have to store versions in
EasiWriter format, DDF, RTF, HTML, Text, CSV, and whatever else a versatile
application might be able to offer.
It's very neat, and can work beautifully. It's just a pity AppNotes 240 and
241 appeared relatively late in the history of RISC OS.
--
Matthew Phillips
Durham
on 20 Apr 2012 Rick Murray wrote:
> > without reliance on the clipboard if, and only if, the clipboard has not
> > requested the data in the app's format.
>
> Why is a clipboard REQUESTING? Surely an app should paste something into
> the clipboard tagged with a "this is <blah> data", and then the
> clipboard can say "I have <blah> available" if something asks it?
If you read AppNote 240 you'll probably understand why.
> > without reliance on the clipboard if, and only if, the clipboard has not
> > requested the data in the app's format.
>
> Why is a clipboard REQUESTING? Surely an app should paste something into
> the clipboard tagged with a "this is <blah> data", and then the
> clipboard can say "I have <blah> available" if something asks it?
Keeping the clipboard content under the control of the original application
allows that application to serve it up in various formats as requested, when
a paste occurs. Otherwise the clipboard might have to store versions in
EasiWriter format, DDF, RTF, HTML, Text, CSV, and whatever else a versatile
application might be able to offer.
It's very neat, and can work beautifully. It's just a pity AppNotes 240 and
241 appeared relatively late in the history of RISC OS.
--
Matthew Phillips
Durham
Vince M Hudd
Apr 21, 2012, 6:01:57 AM4/21/12
to
Rick Murray <heyrickma...@yahoo.co.uk> wrote:
> > without reliance on the clipboard if, and only if, the clipboard has not
> > requested the data in the app's format.
> Why is a clipboard REQUESTING? Surely an app should paste something into
> the clipboard tagged with a "this is <blah> data", and then the clipboard
> can say "I have <blah> available" if something asks it?
Because that method requires that the clipboard only ever store the copied
> > without reliance on the clipboard if, and only if, the clipboard has not
> > requested the data in the app's format.
> Why is a clipboard REQUESTING? Surely an app should paste something into
> the clipboard tagged with a "this is <blah> data", and then the clipboard
> can say "I have <blah> available" if something asks it?
data in a lowest common denominator format*, and that apps only ever receive
the pasted data in that format.
* Or holds a copy in every format the originating app can offer it - which
brings with it both a memory and speed disadvantage. Memory because that
approach means the clipboard would need to hold a copy in every conceivable
format the originating app can use to output the copied data, and speed
because the process would involve a data transfer to the clipboard for each
of those formats.
The current approach caters to that problem in a very neat, simple way.
--
Soft Rock Software: http://www.softrock.co.uk
Vince M Hudd: http://misc.vinceh.com/about-vinceh/
RISCOSitory: http://www.riscository.com
0 new messages