On 01/29/09 13:51, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
> On 29 Jan 2009, at 7:56 PM, Maxwell, Adam R wrote: > >> On 01/29/09 09:21, "Christiaan Hofman" <cmhof...@gmail.com> wrote: >> >>> Anyway, the check as it is currently shouldn't be necessary. >> >> Only for autocomplete, as I was surprised to find. > > Also when it's not appearing in the Editor? I just meant I was surprised to see that Bdsk-File fields were being added to the autocomplete dictionary, over a year after the feature was added. That was probably wasting a fair number of bytes on a large file (I think that would be the only retain on the base64 strings). >> I had to add that case >> in the parser because I'm using openssl for base64 instead of Omni's >> decoder, and it seems to be stricter about line breaks and spaces. > > Good to know, as I've also added that to Skim. Though not in any way > where this could be a problem. > >> Which >> wasn't a problem until I sent a message to myself from work using >> Entourage. >> I don't recall why I used openssl in the first place...a quick >> glance at OF >> tells me that I was probably trying to avoid temporary objects. >> >> Actually, I think it would be cool to eliminate the Omni frameworks >> entirely, although the preferences window alone makes that a really >> daunting >> task. > > Yea, there's a lot of stuff in it I really don't like. Such as > implementation overriding Leopard API and far too many swizzling. Those are exactly my complaints. Swizzling and categories are everywhere, and the combination can lead to a fair number of unpleasant surprises. I've been trying to minimize category usage in new code, and I really haven't missed them. Since NSUserDefaults is thread safe, one of the advantages of OFPreferences is eliminated. And I won't even start on OAApplication and its sheet queue or OFController and the way they've screwed up exception handling for Leopard. > But indeed it would be a lot of work to change everything. As for the > pref window, I believe there's also alternative implementation for > that alone (though I don't know how good they are). SS_PrefsController looks reasonable: http://mattgemmell.com/source Uli Kusterer has one, and Andreas Mayer has one that looks like Omni's. Maybe everyone writes his own because there are no good implementations :). > Talking about that, when I was looking into the runtime implementation > to improve method swizzling in Skim I was really surprised that the > old runtime system wasn't thread safe! Only in 10.5 did they add > locks, but not everywhere. And Omni's implementations were originally > using the thread-unsafe stuff even on Leopard (that's changed now). Interesting. I'm a bit surprised that they use locks now, since I'd expect that to be a pretty significant hit. Cocoa is still full of thread safety surprises too...like the NSTask class being unsafe to use in a background thread. Or the font server trashing its internal state and deadlocking. Speaking of runtime, I've been happy using for/in, @property and @synthesize, although I've never tried garbage collection. It's too bad zero cost exceptions and synthesized storage are only available in 64 bit, since there are still a lot of G4 systems out there. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop