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 1 of 3  [1] 2 3  Next page →

#1595 — Clipboard

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

[toc] | [next] | [standalone]

#1596

On 12 Apr, Alan Wrigley wrote in message
    <gemini.m2dzv7006i384009c.alan@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/

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

#1600

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

Alan

-- 
RISC OS - you know it makes cents

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

#1614

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

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

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

#1597

In message <gemini.m2dzv7006i384009c.alan@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. 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
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

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

#1599

In message <870e797f52.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <gemini.m2dzv7006i384009c.alan@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
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/

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

#1603

Fred Graute <fjgraute@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
control of the clipboard in the way that the Select ClipboardHolder does.

Alan

-- 
RISC OS - you know it makes cents

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

#1602

Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> Have I got that right?

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:

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

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

Alan

-- 
RISC OS - you know it makes cents

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

#1604

I myself wrote:

> Matthew Phillips <spam2011m@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.

Alan

-- 
RISC OS - you know it makes cents

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

#1605

In message <gemini.m2evr3002zcui031g.spamhater@keepyourfilthyspamtoyourself.co.uk>
 on 13 Apr 2012 Alan Wrigley  wrote:

> I myself wrote:
> 
> > Matthew Phillips <spam2011m@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.

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

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

#1607

Matthew Phillips <spam2011m@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
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

-- 
RISC OS - you know it makes cents

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

#1610

Alan Wrigley <spamhater@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?

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

#1611

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

> Alan Wrigley <spamhater@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

-- 
RISC OS - you know it makes cents

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

#1612

In message <gemini.m2f6o200beko0031g.spamhater@keepyourfilthyspamtoyourself.co.uk>
 on 13 Apr 2012 Alan Wrigley  wrote:

> Matthew Phillips <spam2011m@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
> 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.

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

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

#1617

Matthew Phillips <spam2011m@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
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.

Alan

-- 
RISC OS - you know it makes cents

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

#1606

In message <gemini.m2ev1a002ffsg031g.spamhater@keepyourfilthyspamtoyourself.co.uk>
 on 13 Apr 2012 Alan Wrigley  wrote:

> Matthew Phillips <spam2011m@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

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

#1608

Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message
<gemini.m2ev1a002ffsg031g.spamhater@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.

Alan

-- 
RISC OS - you know it makes cents

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

#1613

In message <gemini.m2f6tv00bj20d031g.spamhater@keepyourfilthyspamtoyourself.co.uk>
 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
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

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

#1609

In message <d28ac57f52.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <gemini.m2ev1a002ffsg031g.spamhater@keepyourfilthyspamtoyou
> rself.co.uk>
>  on 13 Apr 2012 Alan Wrigley  wrote:

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

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

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

#1598

In message <gemini.m2dzv7006i384009c.alan@alanwrigley.com>
          Alan Wrigley <alan@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
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.

-- 
Fred Graute
http://www.stronged.iconbar.com/

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web