CoverFlow

  • Is there any information available anywhere about CoverFlow patents or
    maybe information about using undocumented NSView's. I am wondering if
    it is ok or not to use a such a thing ( a CoverFlow type view ) in a
    shipping commercial application?

    thanks

    AC
  • On Nov 20, 2007, at 7:36 PM, Alexander Cohen wrote:

    > Is there any information available anywhere about CoverFlow patents
    > or maybe information about using undocumented NSView's. I am
    > wondering if it is ok or not to use a such a thing ( a CoverFlow
    > type view ) in a shipping commercial application?
    >

    Well, you certainly should not use undocumented API.  Ever.
  • 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.

    Avoiding private APIs is great in a perfect world, where Apple
    regularly pushes its private APIs to public APIs once they have been
    tested. Of course, that isn't always the case.

    That said, if you use undocumented APIs you have to have your guard up
    (unless you're a big company like Adobe or Microsoft) -- you'll get
    zero support for using private APIs and your app could well break with
    an update.

    On 11/21/07, Scott Anguish <scott...> wrote:
    >
    > On Nov 20, 2007, at 7:36 PM, Alexander Cohen wrote:
    >
    >> Is there any information available anywhere about CoverFlow patents
    >> or maybe information about using undocumented NSView's. I am
    >> wondering if it is ok or not to use a such a thing ( a CoverFlow
    >> type view ) in a shipping commercial application?
    >>
    >
    > Well, you certainly should not use undocumented API.  Ever.
    >

    --
    Mark Munz
    unmarked software
    http://www.unmarked.com/
  • 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.)

    > Avoiding private APIs is great in a perfect world, where Apple
    > regularly pushes its private APIs to public APIs once they have been
    > tested. Of course, that isn't always the case.

    Depends on what your definition of tested is. They released HUD
    windows after a few years. Those few years were well spent getting the
    OS to where HUD windows fit  better with the overall GUI environment.
    They waited until they were sure of what *they* were doing.

    > That said, if you use undocumented APIs you have to have your guard up
    > (unless you're a big company like Adobe or Microsoft) -- you'll get
    > zero support for using private APIs and your app could well break with
    > an update.

    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.

    Jaime
  • On Nov 21, 2007, at 11:21 AM, Jaime Magiera wrote:

    >> That said, if you use undocumented APIs you have to have your guard
    >> up
    >> (unless you're a big company like Adobe or Microsoft) -- you'll get
    >> zero support for using private APIs and your app could well break
    >> with
    >> an update.
    >
    > 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.
    >

    Its worse than that - it bad for the long term appearance of
    stability, and ultimately long term platform lifetime.

    Suppose a bunch of apps use a private API, and Apple needs to change
    that API to support some great new feature (or fix a critical bug).
    They can either break all those apps, or not add in the feature (or
    otherwise end up hamstringing it).  You can see how this is bad.

    Alternately, third party apps can break, which then gives the
    appearance of "don't update to x.y.z because it's buggy and breaks all
    these apps", causing people to think the OS is buggy when it's the
    fault of third party programmers (and it doesn't help that there are
    examples of programs  that used private APIs which broke when updated
    and they then whined how "Apple broke our program").  So now people
    aren't updating to the latest more stable and secure OS because of
    this misperception.

    In this particular case, however, there's an answer - take a look at
    the CovertFlow example, which shows you how to implement a coverflow
    like view without any private APIs...

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium | prime : build, mutate, evolve, animate : the next
    generation of fractal art
  • On 11/21/07, Jaime Magiera <jaime...> 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/
  • On Nov 21, 2007, at 1:48 PM, Mark Munz wrote:
    >
    > *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,

    I guess I'm missing the "only option" connotation. Only option to do
    what? Something that is not supported? Something that your app is not
    dependent on (pretty pictures)?

    In other words, where does *necessity* for the feature, particularly
    considering the private API status, come in?

    Jaime
  • On Nov 21, 2007, at 11:56 AM, Jaime Magiera wrote:

    > I guess I'm missing the "only option" connotation. Only option to do
    > what? Something that is not supported? Something that your app is
    > not dependent on (pretty pictures)?

    Something that is supported, but only certain applications that use
    the private APIs can do. For example, iCal supports canceling a
    pasteboard drag, something that is currently not possible without
    using private APIs.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • I was addressing the more generic comment that Scott made:
    > Well, you certainly should not use undocumented API.  Ever.

    And trying to give a few examples where you can't get functionality
    without diving into some undocumented territory. Mail APIs, MenuExtras
    are a couple examples.

    The Coverflow control may be possible to duplicate, but the developer
    will likely need to spend a lot of time duplicating all the behaviors
    of the control. From the user's perspective, they just want Coverflow
    functionality.

    Using a private framework may be a shortcut. I agree that it's very
    dangerous and shouldn't be done without serious contemplation of the
    consequences.

    Unfortunately, pretty pictures has taken over these days but that's a
    whole other discussion. Apple has given a lot of focus to pretty
    pictures scrolling by since they put it into Finder, iTunes and their
    iPods.

    I would love to see Apple provide a way to use some of the
    functionality it finds important enough to use in its own apps without
    having to wait another 2+ years to do so.

    On 11/21/07, Jaime Magiera <jaime...> wrote:
    >
    > On Nov 21, 2007, at 1:48 PM, Mark Munz wrote:
    >>
    >> *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,
    >
    > I guess I'm missing the "only option" connotation. Only option to do
    > what? Something that is not supported? Something that your app is not
    > dependent on (pretty pictures)?
    >
    > In other words, where does *necessity* for the feature, particularly
    > considering the private API status, come in?
    >
    > Jaime
    >

    --
    Mark Munz
    unmarked software
    http://www.unmarked.com/
  • On all of this Coverflow private api business. Do recall that
    Coverflow started as someones little project and not in apple at all.
    And in my honest review, that coverflow was uptine times better than
    this current coverflow.

    What I am getting at is that you dont have to use apples method as it
    can be done outside, if you worry about stuff breaking all the time
    with updates.

    But I for one say you should at least tinker with private frameworks,
    that where all of the cool stuff lives :D

    On 11/21/07, Nick Zitzmann <nick...> wrote:
    >
    > On Nov 21, 2007, at 11:56 AM, Jaime Magiera wrote:
    >
    >> I guess I'm missing the "only option" connotation. Only option to do
    >> what? Something that is not supported? Something that your app is
    >> not dependent on (pretty pictures)?
    >
    >
    > Something that is supported, but only certain applications that use
    > the private APIs can do. For example, iCal supports canceling a
    > pasteboard drag, something that is currently not possible without
    > using private APIs.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/
    >
  • Have you looked at the CoreAnimation example 'CovertFlow'? It's in /Developer/Examples/Quartz/CoreAnimation.

    It implements CoverFlow to display images (specifically, the desktop pictures available on your Mac.) I expect it could be easily repurposed to display anything.

    No undocumented code necessary.

    - Jon


    On Tuesday, November 20, 2007, at 07:37PM, "Alexander Cohen" <alex...> wrote:
    > Is there any information available anywhere about CoverFlow patents or
    > maybe information about using undocumented NSView's. I am wondering if
    > it is ok or not to use a such a thing ( a CoverFlow type view ) in a
    > shipping commercial application?
    >
    > thanks
    >
    > AC
    >
    >
  • On Nov 21, 2007, at 2:36 PM, Jon Hendry wrote:

    > Have you looked at the CoreAnimation example 'CovertFlow'? It's in /
    > Developer/Examples/Quartz/CoreAnimation.
    >
    > It implements CoverFlow to display images (specifically, the desktop
    > pictures available on your Mac.) I expect it could be easily
    > repurposed to display anything.
    >
    > No undocumented code necessary.

    I believe the OP's question (among others) was whether there were any
    patent issues. Note that Apple's permission to use, modify, etc. in
    each of the example source files has a specific statement that this
    permission does *not* supersede any patents.

    "Except as
      expressly stated in this notice, no other rights or licenses,
    express or
      implied, are granted by Apple herein, including but not limited to any
      patent rights that may be infringed by your derivative works or by
    other
      works in which the Apple Software may be incorporated."

    So if CoverFlow is patented, you may not be able to use coverflow in a
    product even if there is example code for it. This is the domain of
    lawyers, not software developers.

    regards,

    Ralph

    Raffael Cavallaro, Ph.D.
    <raffaelcavallaro...>
  • On Nov 21, 2007, at 12:21 AM, Scott Anguish wrote:

    > Well, you certainly should not use undocumented API.  Ever.

    If only that were possible. The complete and total lack of any way get
    an image of the cursor comes to mind...

    Not that this equates.

    --
    Seth Willits
  • Am 21.11.2007 um 01:36 schrieb Alexander Cohen:
    > Is there any information available anywhere about CoverFlow patents
    > or maybe information about using undocumented NSView's. I am
    > wondering if it is ok or not to use a such a thing ( a CoverFlow
    > type view ) in a shipping commercial application?

      I think Apple actually has sample code for a coverflow view on their
    site somewhere. Search for "CovertFlow" (note the "T").

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today