Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1595 > unrolled thread

Clipboard

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Clipboard Alan Wrigley <alan@alanwrigley.com> - 2012-04-12 23:01 +0100
    Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-12 23:32 +0100
      Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 09:50 +0100
        Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-13 22:11 +0100
    Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-12 23:46 +0100
      Re: Clipboard Fred Graute <fjgraute@casema.nl> - 2012-04-13 02:19 +0200
        Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 10:16 +0100
      Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 10:15 +0100
        Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 10:30 +0100
          Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-13 13:35 +0100
            Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 14:26 +0100
              Re: Clipboard Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-04-13 16:42 +0100
                Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 17:04 +0100
              Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-13 21:43 +0100
                Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 23:21 +0100
        Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-13 13:41 +0100
          Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 14:29 +0100
            Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-13 21:52 +0100
          Re: Clipboard Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-13 16:13 +0200
    Re: Clipboard Fred Graute <fjgraute@casema.nl> - 2012-04-13 02:19 +0200
      Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 09:57 +0100
        Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-13 22:21 +0100
          Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-13 23:06 +0100
            Re: Clipboard Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-14 00:33 +0200
              Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 09:15 +0100
                Re: Clipboard Martin Wuerthner <spamtrap@mw-software.com> - 2012-04-14 16:18 +0200
                  Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 17:02 +0100
                    Re: Clipboard Fred Graute <fjgraute@casema.nl> - 2012-04-15 02:12 +0200
                      Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-15 11:46 +0100
                        Re: Clipboard "John Williams (News)" <UCEbin@tiscali.co.uk> - 2012-04-15 13:09 +0200
                  Re: Clipboard Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-04-14 21:08 +0100
                    Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 21:22 +0100
            Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-13 23:54 +0100
              Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 09:17 +0100
                Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-14 10:48 +0100
                  Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 11:07 +0100
                    Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-14 11:31 +0100
                      Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 12:14 +0100
                        Re: Clipboard Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2012-04-14 12:53 +0100
                        Re: Clipboard Steve Fryatt <news@stevefryatt.org.uk> - 2012-04-14 14:30 +0100
    Re: Clipboard Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> - 2012-04-17 18:46 +0100
    Re: Clipboard Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-04-20 05:52 +0200
      Re: Clipboard Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-04-20 23:15 +0100
      Re: Clipboard Vince M Hudd <vinceh@softrock.co.uk> - 2012-04-21 11:01 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1601

Fred Graute <fjgraute@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
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

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1615

On 13 Apr, Alan Wrigley wrote in message
    <gemini.m2eu7v001sqn5031g.spamhater@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.

Er, why?  Surely this can work just fine, if:

- 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.

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?

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.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1616

Steve Fryatt <news@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.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1618

In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou 
rself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> 
wrote:

> Steve Fryatt <news@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.m2eu7v001sqn5031g.spamhater@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.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1620

Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou 
> rself.co.uk>
>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> 
> wrote:
> 
> > Steve Fryatt <news@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..]

> Great, so at that moment, UniClip *claims* A's clipboard, so that 
> removes precisely the problem you describe in your next paragraph:

We're talking at cross-purposes, Martin. I was responding to Steve's
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

[toc] | [prev] | [next] | [standalone]

#1628

In message <gemini.m2gmxv0004eox02ds.spamhater@keepyourfilthyspamtoyou 
rself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> 
wrote:

> Martin Wuerthner <spamtrap@mw-software.com> wrote:

>> In message <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyou
>> rself.co.uk>
>>           Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk>
>> wrote:
>> 
>>> Steve Fryatt <news@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..]

>> Great, so at that moment, UniClip *claims* A's clipboard, so that
>> removes precisely the problem you describe in your next paragraph:

> We're talking at cross-purposes, Martin. I was responding to Steve's
> original question, which was why UniClip needed to claim the clipboard, and
> explaining what the situation would be if it didn't do so.

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.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1629

Martin Wuerthner <spamtrap@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.

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.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1632

In message <gemini.m2h8kr001leq90274.spamhater@keepyourfilthyspamtoyourself.co.uk>
          Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> wrote:

> Martin Wuerthner <spamtrap@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
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/

[toc] | [prev] | [next] | [standalone]

#1633

Fred Graute <fjgraute@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.

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?

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1634

In article
<gemini.m2ioky006bog200eg.spamhater@keepyourfilthyspamtoyourself.co.uk>,
   Alan Wrigley <spamhater@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!

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/

[toc] | [prev] | [next] | [standalone]

#1630

Martin Wuerthner <spamtrap@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
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?

-- 
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".  

[toc] | [prev] | [next] | [standalone]

#1631

Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk> wrote:

> 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
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?

Enabling UniClip explicitly kills any concept of a local keyboard. UniClip
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.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1619

On 13 Apr, Alan Wrigley wrote in message
    <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyourself.co.uk>:

> Steve Fryatt <news@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.  That way,
Uniclip may not know exactly what is on the clipboard, but it will always
know exactly where it can be found.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1621

Steve Fryatt <news@stevefryatt.org.uk> wrote:

> On 13 Apr, Alan Wrigley wrote in message
>    
<gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyourself.co.uk>:
> 
> > Steve Fryatt <news@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
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.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1622

On 14 Apr, Alan Wrigley wrote in message
    <gemini.m2gn1k000791y02ds.spamhater@keepyourfilthyspamtoyourself.co.uk>:

> Steve Fryatt <news@stevefryatt.org.uk> wrote:
> 
> > On 13 Apr, Alan Wrigley wrote in message
> >    
> <gemini.m2fur300tzko1031g.spamhater@keepyourfilthyspamtoyourself.co.uk>:
> > 
> > > Steve Fryatt <news@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 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.

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.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1623

Steve Fryatt <news@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).

> I really can't see why Uniclip
> must behave in such an antisocial manner

No-one is forced to use it. You use it if you need its functionality and can
live with the consequences.

I'm sick of this discussion. If anyone thinks they can do it better, please
contact R-Comp.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1624

On 14 Apr, Alan Wrigley wrote in message
    <gemini.m2gs3x0043ypu02ds.spamhater@keepyourfilthyspamtoyourself.co.uk>:

> Steve Fryatt <news@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).

When I Googled the problem yesterday, I found this:

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.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1625

Steve Fryatt <news@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.

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

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1626

I wrote:

> Steve Fryatt <news@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:

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.

Alan

-- 
RISC OS - you know it makes cents

[toc] | [prev] | [next] | [standalone]

#1627

On 14 Apr, Alan Wrigley wrote in message
    <gemini.m2gv7y006ieod02ds.spamhater@keepyourfilthyspamtoyourself.co.uk>:

> Steve Fryatt <news@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.

Assuming that I've understood the possibilities of the Windows API
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.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web