Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

On Thu, Jul 5, 2012 at 2:29 AM, Charles Srstka <
bas...@ch...> wrote:

> On Jul 5, 2012, at 12:39 AM, Alexei Svitkine wrote:
>
> if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
>> ... new API
>> else
>> ... old API
>>
>
> Is your new implementation strictly better than the clip_macosx.cpp one?
> Can you give a brief overview comparing them in terms of what works and
> what doesn't? This will help make it clear whether it makes sense to always
> prefer to use the new API code when running on 10.6 for 32-bit builds. (And
> hence whether it makes sense to consolidate them now like this.)
>
>
> Well, it’s definitely better than the clip_macosx.cpp in that the latter
> doesn’t run on 64-bit systems. I’ve also added a couple of features to it:
>
> 1. copy/paste styled text into and out of the emulator
>
> 2. copy/paste international text using non-Roman scripts into and out of
> the emulator
>
> As for the 10.6+ pasteboard API, that adds two features:
>
> 1. The ability to just say “lemme read/write an NSAttributedString off the
> pasteboard!” and have the OS do the conversion for you to and from whatever
> internal representation it’s using, instead of saying “Gimme some data of
> kUTTypeRTF and I hope that’s what OS X still uses!”
>
> 2. The fact that the API is just more current and is a complete
> replacement for the old one, and although the old API isn’t deprecated yet,
> you know how Apple is (Exhibit A: the fact that the implementation in
> clip_macosx.cpp no longer works). Basically, this is for future-proofing.
>

Okay, but clip_macosx.cpp would still be able to handle scrap types that
exist both under Classic and Mac OS X transparently (at least, on PPC or if
there is no byteswapping needed), correct? Ones that wouldn't get handled
without explicit support in clip_macosx64.mm. That's the big difference,
still, right?

I think there will also be problems compiling this combined file on 10.4,
for example, since it wouldn't have headers for the new APIs. That can be
worked around with additional ifdefs, but that gets hairy fast.

 Let's leave merging these off for now, but we can revisit that later.



>  Still, if you do think the autorelease pools are really required, I
>> suggest making a C++ scoped object that will alloc an autorelease pool in
>> its ctor and release it in its dtor, which will eliminate the need for
>> draining the pool at all the early return points.
>>
>>
>> Yeah, that could work.
>>
>
> Could you make that change? I think it would be much cleaner than all the
> early-return cleanup in your current patch.
>
>
> Sure thing. I think I’ll put the wrapper object in a header file so that
> it can be used elsewhere if people want to. This’ll be an Objective-C++
> header file and will only be includable by Objective-C++ code; do you have
> any preference whether to put #ifdef guards around it or just use #import?
>

My preference would be to still have ifdef guards. Thanks.


> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>