Tue Mar 10 17:05:36 2009: Request 43889 was acted upon.
Transaction: Correspondence added by kwittr...@web.de
Queue: Win32-Clipboard
Subject: Re: [rt.cpan.org #43889] Win32::Clipboard::GetText() doesn't
convert newlines
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: kwittr...@web.de
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=43889 >
----- Original Message -----
From: "j...@activestate.com via RT" <bug-win32-clipbo...@rt.cpan.org>
To: <kwittr...@web.de>
Sent: Monday, March 09, 2009 7:51 PM
Subject: RE: [rt.cpan.org #43889] Win32::Clipboard::GetText() doesn't convert
newlines
<URL: https://rt.cpan.org/Ticket/Display.html?id=43889 >
>> K. Wittrock via RT wrote:
>> > Perl developers are often anxious about backward compatibility. Ok,
>> > go ahead.
>>
>> Go ahead and what ? I'm not the maintainer - just another user.
>>
>> All I'm saying is that the maintainer should document the newline
>> behavior and possibly make an addition as you requested for an option
>> to convert them.
>
> I'm maintaining Win32::Clipboard, and I'll eventually make some changes
> as indicated. I find it very useful to see these changes discussed a
> little in public first, which is why I've set up the RT queues to copy
> all these messages to libwin32@perl.org as well.
>
> I think the libwin32 modules are so old that they should not be changed
> in incompatible ways, even if their interfaces (and implementations) are
> sometimes quite gross. But they are a product of their time, have been
> "documented" in published books and sample code all over the net, so we
> should not break this body of existing code/knowledge.
>
> Win32::Clipboard is especially hard to change as it has taken up a lot
> of syntactic space that otherwise could be used to extend the
> functionality in a compatible way (it uses both object and function
> interfaces, and has already up a lot of the obvious method names).
>
> One other area that needs addressing is the CF_UNICODETEXT support,
> which currently also just returns the raw data, and not a Perl string
> with the correctly set up Unicode characters instead. There is then
> another issue about Perl's internal encoding schizophrenia, that
> sometimes it treas 8-bit data as being CP_ANSI encoded, and sometimes as
> Latin1, but I don't want to go into that here.
>
> Any update to the Win32::Clipboard interface should take these issues
> into account and allow for further extensibility in the future.
>
> My current way of thinking would be to leave the functional interface
> alone, but add additional options to the constructor of the
> Win32::Clipboard object. That should completely solve the backwards
> compatibility issue and still provide a more perlish interface for new
> code (you could mix the old and the new APIs in the same program, which
> is important if you use modules, which in turn use Win32::Clipboard).
Thank you for your explanations. I admit that there are aspects of backward
compatibility that I'm not aware with the small Perl
scripts which I write.
>
> I won't get around to actually *doing* anything about this until later
> in April, .....
As I stated earlier, the conversion of line end markers isn't a high priority
matter, particulary since I know how to do it
afterwards. So April is more than I could expect.
Greetings
Klaus
