Re: CoverFlow

FROM : Mark Munz
DATE : Wed Nov 21 19:48:50 2007

On 11/21/07, Jaime Magiera <<email_removed>> wrote:
> On Nov 21, 2007, at 12:11 PM, Mark Munz wrote:
>
> > Of course if we followed that line of thinking, we would never have
> > any Mail plug-ins. Six years (5 major revisions) and counting with no
> > public Mail plug-in APIs.
>
> Maybe there is a reason for that (i.e. security, user experience
> consistency, etc.)


The reason could also be that it just isn't a high priority (we don't
know because Apple doesn't give us that info). The issues of Mail's
feature focus (capsule buttons, to-do lists) seems to come up with
every major release. There is a private plug-in API, has been for
years and with each release, developer hack the new API to reduce the
limitations of Mail. I am now logging a new bug against the problem
with each major release.

> I've spent the past two months replacing/updating/etc. third-party,
> non-standard and private API code in an app that I recently took over.
> It has been nothing short of a nightmare. Relying on private API seems
> to be a *bad* thing.
>


To clarify, I'm not saying that using private APIs is ideal. Far from
it. If you decide to use it, you need to code very defensively, and
you have to always been on alert with updates.

My objection was to the use of "Ever." Sometimes there is no other way
to do something in the current release of OS X. You should definitely
try to avoid it, if you can.

In the case of the Coverflow control. The sample code is a starting
point, but there is a lot of work that still has to go into making it
similar to the Coverflow control. And we know that there is almost
zero chance of it showing up in a public framework before 10.6 (and
even then, there are no guarantees we won't see something until 10.7).

*Sometimes*, private APIs are the only option. As I said, you have to
have your guard up. I try to avoid private APIs when I can.. but
sometimes you aren't given a choice.

--
Mark Munz
unmarked software
http://www.unmarked.com/