Skip Menu |

This queue is for tickets about the Clipboard CPAN distribution.

Report information
The Basics
Id: 33786
Status: resolved
Worked: 30 min
Priority: 0/
Queue: Clipboard

People
Owner: KING [...] cpan.org
Requestors: wyant [...] cpan.org
Cc: upload [...] pause.perl.org
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 0.09
Fixed in: (no value)



CC: upload [...] pause.perl.org
Subject: Mac OS X clipboard info without shelling out
I have just registered module Mac::Pasteboard, and the registrar suggested that I let you know, so that you can consider using this module instead of (or in addition to, as the case may be) shelling out to pbcopy and pbpaste under Mac OS X. The advantage to using this module is that you will not need to shell out. There is other functionality, but a basic clipboard module won't need it. You _should_ be able to get what you want just by calling pbcopy() or pbpaste() as the case may be. There are also disadvantages to this module: The first is that it's an XS module, and therefore requires the user to install the X Code toolkit. The second is that it uses an interface that did not exist until Mac OS 10.3 (Panther). We're up to 10.5 now, but you may wish to support older operating systems anyway. The code I'm currently using to detect OS version is: no warnings qw{uninitialized}; my $osvers = +sprintf '%d.%03d', split '\.', `sw_vers -productVersion`; use warnings qw{uninitialized}; $? and die "OS unsupported -- sw_vers failed with exit code $?\n"; $osvers >= 10.003 or die "OS unsupported -- we need at least Mac OS X 10.3 (Panther)\n"; This is my favorite of the ones discussed on perl5-porters a couple months ago. Thanks, Tom Wyant
Do you know how to make a dependency only apply for a certain OS? I could try hacking around on it, but I don't want to make a(nother) mess. If we can figure out the Makefile.PL incantation I'll do the dependency for sure.
On Wed Oct 06 22:04:36 2010, KING wrote: Show quoted text
> If we can figure out the Makefile.PL incantation I'll do the dependency > for sure.
What am I talking about? I'm already doing this for Win32::Clipboard. v0.11 is going to just be shifting dependencies (taking out IO::All and Spiffy, even though I like them they aren't important for this context), and I'll do this one, too.
Version 0.11 should be as you requested. I don't know if the automated builds are going to be passing tests, and I also don't know how smoothly it goes for regular users, but I made a stab at it.
Subject: Re: [rt.cpan.org #33786] Mac OS X clipboard info without shelling out
Date: Sun, 10 Oct 2010 22:12:21 +0000 (UTC)
To: bug-Clipboard [...] rt.cpan.org
From: harryfmudd [...] comcast.net
----- "KING via RT" <bug-Clipboard@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=33786 > > > Version 0.11 should be as you requested. > > I don't know if the automated builds are going to be passing tests, > and I > also don't know how smoothly it goes for regular users, but I made a > stab > at it.
Thanks. A couple tweaks appear in order; it's the pits to work on OS-specific code when you don't have access to the OS. The universal diffs are attached. In Clipboard.pm, the only thing was that Mac::Pasteboard does not support MacOS, which (in Perl land) means OS 9 or less. Neither do pbcopy and pbpaste, since Mac OS 9 has no shell to shell out to. In MacPasteboard.pm, there were three things. First, by default (for better or worse) it's an error to try to fetch data from an empty clipboard. Fortunately this is a default, and can be changed. This is what 'set( missing_ok => 1 )' is about. Second, under Mac OS X you can't put anything on the pasteboard until you take ownership, which you do by clearing it. Again for better or worse, Mac::Pasteboard is a fairly low-level interface, and the copy() method assumes you already own the pasteboard. That's what the call to clear() is about. Third, the Mac::Pasteboard paste() method is sensitive to context. I believe you did not intend your paste() method to be so. That's what the 'return scalar ...' is about. I confess I spent a bunch of time trying to understand what was going on here, because I myself had forgotten that in list context it returns some flags as well. Thank you again for your attention to this. If you like, I will be glad to look at a pre-release of the next Clipboard. Tom

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

1) So, previously I had Clipboard.pm trying to bind 'darwin' to Xclip, even though it also bound it to MacPasteboard (which took precedence). Other than that I just applied your diff to remove 'macos'. MacOS isn't even in the CPAN test matrix, so phooey on it. Might as well support Windows 3.1. 2) I applied the MacPasteboard.pm diffs with no change. 3) Do you have any idea how we can do a "smart dependency" scheme for the different OSs? I thought of a couple options: a) Find out the right way to say, "When on OS Z, pull in Z::Clipboardz" b) Include a distro of all the dependencies for all the OSs. So, like Module::Install gets its own copy within the tarball, I could just toss them all in. Bandwidth is not a problem---nonworkingness is. 4) If you want to take this even further, we could add t/darwin.t and guard it against running for other OSs. Issues here are: a) I'm not sure what will happen on the CPAN test servers. I know for Linux it can't run much because it doesn't have an X server. Maybe it should also have a guard for when there is no X server running? Without an OSX machine handy these little glitchy bits are hard to get figured out. b) I'm not sure what all should be tested. c) I want to guarantee that the tests won't nuke any user's clipboard data just for running the tests. I went ahead and uploaded the new version, 0.13. I figured your patches are more likely to work than what was in 0.12, so it's better to put it out there and let you look at it from there. Thank you for your time, expertise, and help. I feel all open-sourcey inside. -rjk
On Wed Oct 13 00:47:24 2010, KING wrote: Show quoted text
> 1) So, previously I had Clipboard.pm trying to bind 'darwin' to Xclip, > even though it also bound it to MacPasteboard (which took precedence). > Other than that I just applied your diff to remove 'macos'. MacOS isn't > even in the CPAN test matrix, so phooey on it. Might as well support > Windows 3.1.
I missed the Xclip/MacPasteboard thing. You can run X Windows under Mac OS X, but I know nothing about whether the clipboards are unified or distinct. Show quoted text
> > 2) I applied the MacPasteboard.pm diffs with no change.
Thanks glad it worked. Show quoted text
> > 3) Do you have any idea how we can do a "smart dependency" scheme for > the different OSs? I thought of a couple options: > a) Find out the right way to say, "When on OS Z, pull in Z::Clipboardz"
Adam Kennedy does this for File::HomeDir. It's a matter of having Makefile.PL (or Build.PL, or whoever) figure out what it's running under and tweak things appropriately. You're supposed to set dynamic_config true so that people will know that the requirements recorded in META.yml are _not_ the last word on the subject. Show quoted text
> b) Include a distro of all the dependencies for all the OSs. So, like > Module::Install gets its own copy within the tarball, I could just toss > them all in. Bandwidth is not a problem---nonworkingness is.
Mac::Pasteboard is an XS module, which may be a problem. I suspect the Windows stuff is too, though it comes with ActivePerl. There would also be keeping up to date with the included modules. And I think CPAN tries to keep up with this kind of thing, and plasters a big red "Unofficial release" across anything it does not like. Show quoted text
> > 4) If you want to take this even further, we could add t/darwin.t and > guard it against running for other OSs. Issues here are:
This could certainly be done. Just skip all the tests if you're not on the right operating system. Test::More makes this easy, though I'm not sure how their mechanism will play out with your Test::Clipboard. You might have to drop the 'no_plan' in Test::Clipboard and call plan() explicitly when you know whether you are going to run the tests. Show quoted text
> a) I'm not sure what will happen on the CPAN test servers. I know for > Linux it can't run much because it doesn't have an X server. Maybe it > should also have a guard for when there is no X server running? Without > an OSX machine handy these little glitchy bits are hard to get figured > out.
In a way, that's why there are CPAN testers. One of the things you can do is put out a developer release (with an underscore in the version, say '0.13_01', which will have to be quoted). This means that it's available, but the CPAN and CPANPLUS clients won't (by default) try to upgrade to it. But the CPAN testers run development releases, so you can find out if anything is wrong before it goes out into the wide world. Show quoted text
> b) I'm not sure what all should be tested.
I'm _never_ sure of this. A wise man once said that untested code was buggy code. If it's a matter of code coverage, Devel::Cover will measure this. Whenever I run this for the first time, I'm always shocked at how low the coverage is. Show quoted text
> c) I want to guarantee that the tests won't nuke any user's clipboard > data just for running the tests.
Ah. Cautious. Mac::Pasteboard allows you to create your own unique pasteboard name, but it appears that the system-supplied pbcopy and pbpaste utilities can't access an arbitrary pasteboard. I'm afraid Mac::Pasteboard just nukes the clipboard. It should probably say so, though. Or maybe I can think of a way to put it back when I'm done. Show quoted text
> > I went ahead and uploaded the new version, 0.13. I figured your patches > are more likely to work than what was in 0.12, so it's better to put it > out there and let you look at it from there.
Thanks. Version 0.13 not only passes the tests, it actually works. Show quoted text
> > Thank you for your time, expertise, and help. I feel all open-sourcey > inside. > > -rjk
You know what an expert is, right? An ex- is a has-been, and a spurt is a big drip. Tom
On Wed Oct 13 00:47:24 2010, KING wrote: Show quoted text
> 1) So, previously I had Clipboard.pm trying to bind 'darwin' to Xclip, > even though it also bound it to MacPasteboard (which took precedence). > Other than that I just applied your diff to remove 'macos'. MacOS isn't > even in the CPAN test matrix, so phooey on it. Might as well support > Windows 3.1.
I missed the Xclip/MacPasteboard thing. You can run X Windows under Mac OS X, but I know nothing about whether the clipboards are unified or distinct. Show quoted text
> > 2) I applied the MacPasteboard.pm diffs with no change.
Thanks glad it worked. Show quoted text
> > 3) Do you have any idea how we can do a "smart dependency" scheme for > the different OSs? I thought of a couple options: > a) Find out the right way to say, "When on OS Z, pull in Z::Clipboardz"
Adam Kennedy does this for File::HomeDir. It's a matter of having Makefile.PL (or Build.PL, or whoever) figure out what it's running under and tweak things appropriately. You're supposed to set dynamic_config true so that people will know that the requirements recorded in META.yml are _not_ the last word on the subject. Show quoted text
> b) Include a distro of all the dependencies for all the OSs. So, like > Module::Install gets its own copy within the tarball, I could just toss > them all in. Bandwidth is not a problem---nonworkingness is.
Mac::Pasteboard is an XS module, which may be a problem. I suspect the Windows stuff is too, though it comes with ActivePerl. There would also be keeping up to date with the included modules. And I think CPAN tries to keep up with this kind of thing, and plasters a big red "Unofficial release" across anything it does not like. Show quoted text
> > 4) If you want to take this even further, we could add t/darwin.t and > guard it against running for other OSs. Issues here are:
This could certainly be done. Just skip all the tests if you're not on the right operating system. Test::More makes this easy, though I'm not sure how their mechanism will play out with your Test::Clipboard. You might have to drop the 'no_plan' in Test::Clipboard and call plan() explicitly when you know whether you are going to run the tests. Show quoted text
> a) I'm not sure what will happen on the CPAN test servers. I know for > Linux it can't run much because it doesn't have an X server. Maybe it > should also have a guard for when there is no X server running? Without > an OSX machine handy these little glitchy bits are hard to get figured > out.
In a way, that's why there are CPAN testers. One of the things you can do is put out a developer release (with an underscore in the version, say '0.13_01', which will have to be quoted). This means that it's available, but the CPAN and CPANPLUS clients won't (by default) try to upgrade to it. But the CPAN testers run development releases, so you can find out if anything is wrong before it goes out into the wide world. Show quoted text
> b) I'm not sure what all should be tested.
I'm _never_ sure of this. A wise man once said that untested code was buggy code. If it's a matter of code coverage, Devel::Cover will measure this. Whenever I run this for the first time, I'm always shocked at how low the coverage is. Show quoted text
> c) I want to guarantee that the tests won't nuke any user's clipboard > data just for running the tests.
Ah. Cautious. Mac::Pasteboard allows you to create your own unique pasteboard name, but it appears that the system-supplied pbcopy and pbpaste utilities can't access an arbitrary pasteboard. I'm afraid Mac::Pasteboard just nukes the clipboard. It should probably say so, though. Or maybe I can think of a way to put it back when I'm done. Show quoted text
> > I went ahead and uploaded the new version, 0.13. I figured your patches > are more likely to work than what was in 0.12, so it's better to put it > out there and let you look at it from there.
Thanks. Version 0.13 not only passes the tests, it actually works. Show quoted text
> > Thank you for your time, expertise, and help. I feel all open-sourcey > inside. > > -rjk
You know what an expert is, right? An ex- is a has-been, and a spurt is a big drip. Tom
Marking as RESOLVED since patch was applied.