folder content as model for NSTableView

  • Any suggestion on how to create a NSTableView that shows the contents
    of a folder?

    I'd assume I would have to come up with a FolderController extending
    either NSObjectController or NSController. Or extend
    NSArrayController and fill the array from the folder.

    In general the problem I see is that the model could change
    "underneith". A file could have been deleted/added outside the
    application and not through the controller. Of course I could poll
    the directory for changes ...or is there a way to register to receive
    file modification events?

    cheers
    --
    Torsten
  • On Feb 15, 2008, at 11:30 AM, Torsten Curdt wrote:

    > I'd assume I would have to come up with a FolderController extending
    > either NSObjectController or NSController. Or extend
    > NSArrayController and fill the array from the folder.

    I wouldn't subclass these classes for that purpose. Create a class
    that represents a folder at a given path and give the instances of
    that class a "contents" property, then bind that property to the array
    controller of your table view.

    > In general the problem I see is that the model could change
    > "underneith". A file could have been deleted/added outside the
    > application and not through the controller. Of course I could poll
    > the directory for changes ...or is there a way to register to
    > receive file modification events?

    See the docs for FSEvents.

    j o a r
  • On Fri, Feb 15, 2008 at 2:30 PM, Torsten Curdt <tcurdt...> wrote:
    > I'd assume I would have to come up with a FolderController extending
    > either NSObjectController or NSController. Or extend
    > NSArrayController and fill the array from the folder.

    Or go old-school and provide a data source.  Probably easier in this situation.

    > In general the problem I see is that the model could change
    > "underneith". A file could have been deleted/added outside the
    > application and not through the controller. Of course I could poll
    > the directory for changes ...or is there a way to register to receive
    > file modification events?

    New in Leopard: FSEvents.  Tiger and below have fseventsd, but it's private.

    --Kyle Sluder
  • On 15.02.2008, at 20:56, Kyle Sluder wrote:

    > On Fri, Feb 15, 2008 at 2:30 PM, Torsten Curdt <tcurdt...>
    > wrote:
    >> I'd assume I would have to come up with a FolderController extending
    >> either NSObjectController or NSController. Or extend
    >> NSArrayController and fill the array from the folder.
    >
    > Or go old-school and provide a data source.  Probably easier in
    > this situation.

    Ehm ...I am still a newbie that basically started my first real Cocoa
    project about 1,5 weeks ago. So old-school "data source" does not
    tell me that much yet :) Care to elaborate?

    >> In general the problem I see is that the model could change
    >> "underneith". A file could have been deleted/added outside the
    >> application and not through the controller. Of course I could poll
    >> the directory for changes ...or is there a way to register to
    >> receive
    >> file modification events?
    >
    > New in Leopard: FSEvents.  Tiger and below have fseventsd, but it's
    > private.

    OK ...then I will go for polling - for now. Still waiting for the new
    MBPs to switch to Leopard ;)

    cheers
    --
    Torsten
  • On 15.02.2008, at 20:56, j o a r wrote:

    >
    > On Feb 15, 2008, at 11:30 AM, Torsten Curdt wrote:
    >
    >> I'd assume I would have to come up with a FolderController
    >> extending either NSObjectController or NSController. Or extend
    >> NSArrayController and fill the array from the folder.
    >
    >
    > I wouldn't subclass these classes for that purpose. Create a class
    > that represents a folder at a given path and give the instances of
    > that class a "contents" property, then bind that property to the
    > array controller of your table view.

    Hm... but the controller is for NSArray's only ...and the class that
    represents the folder is no NSArray. Or did you mean to subclass
    NSArray?

    cheers
    --
    Torsten
  • Le 15 févr. 08 à 23:50, Torsten Curdt a écrit :

    >
    > On 15.02.2008, at 20:56, Kyle Sluder wrote:
    >
    >> On Fri, Feb 15, 2008 at 2:30 PM, Torsten Curdt <tcurdt...>
    >> wrote:
    >>> I'd assume I would have to come up with a FolderController extending
    >>> either NSObjectController or NSController. Or extend
    >>> NSArrayController and fill the array from the folder.
    >>
    >> Or go old-school and provide a data source.  Probably easier in
    >> this situation.
    >
    > Ehm ...I am still a newbie that basically started my first real
    > Cocoa project about 1,5 weeks ago. So old-school "data source" does
    > not tell me that much yet :) Care to elaborate?
    >
    >>> In general the problem I see is that the model could change
    >>> "underneith". A file could have been deleted/added outside the
    >>> application and not through the controller. Of course I could poll
    >>> the directory for changes ...or is there a way to register to
    >>> receive
    >>> file modification events?
    >>
    >> New in Leopard: FSEvents.  Tiger and below have fseventsd, but it's
    >> private.
    >
    > OK ...then I will go for polling - for now. Still waiting for the
    > new MBPs to switch to Leopard ;)

    Have a look at kevent too (there is an Obj c wrapper for it: UKKQueue. http://www.zathras.de/angelweb/sourcecode.htm)
    .
    It's far better than polling.
  • On Feb 15, 2008, at 2:53 PM, Torsten Curdt wrote:

    >> I wouldn't subclass these classes for that purpose. Create a class
    >> that represents a folder at a given path and give the instances of
    >> that class a "contents" property, then bind that property to the
    >> array controller of your table view.
    >
    > Hm... but the controller is for NSArray's only ...and the class that
    > represents the folder is no NSArray. Or did you mean to subclass
    > NSArray?

    You're much too quick to suggest creating subclasses of the system
    provided classes - That's not how it's typically done in Cocoa, and
    that's one way where Cocoa differs from many other OOP environments
    (.NET, et.c.). There are only a handful of classes that you would
    typically subclass from: NSObject, NSWindowController, NSView, et.c.
    You'll learn more about this as you go along.

    What I meant was that the contents of your folder would be a
    collection of file system items that could be presented as an array.
    Something like this:

    @interface TCFileSystemItem : NSObject
    {
    @private

    NSString *_path;
    }

    - (id) initWithPath:(NSString *) path;

    - (NSString *) name;
    - (NSImage *) icon;

    @end

    @interface TCFolder : TCFileSystemItem
    {
    @private

    NSArray *_contents;
    }

    - (NSArray *) contents;

    @end

    At this point, if you construct the appropriate TCFolder objects, you
    can bind the array controller that serves your table view to the
    "contents" property of the folder.

    j o a r
  • On Feb 15, 2008 5:50 PM, Torsten Curdt <tcurdt...> wrote:
    > Ehm ...I am still a newbie that basically started my first real Cocoa
    > project about 1,5 weeks ago. So old-school "data source" does not
    > tell me that much yet :) Care to elaborate?

    Table views have to ways of getting their data.  One is through
    binding, which is typically done to an NSArrayController; this is the
    newer technology.  Prior to the introduction of Cocoa Bindings, you
    would use what's called a "data source", the full guide to which can
    be found here: http://developer.apple.com/documentation/Cocoa/Conceptual/TableView/Tasks/U
    singTableDataSource.html


    The gist of it is that you wire up an object that implements the
    NSTableDataSource informal protocol (read the Cocoa introductory docs
    if you don't understand what an informal protocol is) to the table
    view's dataSource outlet.  When the table needs to display a row, it
    sends a message to your data source object asking it how many rows are
    in the table, and for the data in each column.  Your data source
    replies with this information, which the table view uses to draw the
    cells and then discards.  When the underlying data set changes, some
    object (could be your data source, could be another object) sends a
    message to the table view telling it to refresh itself for a specific
    range of rows, or for the entire dataset, at which point it queries
    your data source object again.

    HTH,
    --Kyle Sluder
  • On 16.02.2008, at 03:10, Kyle Sluder wrote:

    > On Feb 15, 2008 5:50 PM, Torsten Curdt <tcurdt...> wrote:
    >> Ehm ...I am still a newbie that basically started my first real Cocoa
    >> project about 1,5 weeks ago. So old-school "data source" does not
    >> tell me that much yet :) Care to elaborate?
    >
    > Table views have to ways of getting their data.  One is through
    > binding, which is typically done to an NSArrayController; this is the
    > newer technology.  Prior to the introduction of Cocoa Bindings, you
    > would use what's called a "data source", the full guide to which can
    > be found here: http://developer.apple.com/documentation/Cocoa/
    > Conceptual/TableView/Tasks/UsingTableDataSource.html
    >
    > The gist of it is that you wire up an object that implements the
    > NSTableDataSource informal protocol (read the Cocoa introductory docs
    > if you don't understand what an informal protocol is) to the table
    > view's dataSource outlet.  When the table needs to display a row, it
    > sends a message to your data source object asking it how many rows are
    > in the table, and for the data in each column.  Your data source
    > replies with this information, which the table view uses to draw the
    > cells and then discards.  When the underlying data set changes, some
    > object (could be your data source, could be another object) sends a
    > message to the table view telling it to refresh itself for a specific
    > range of rows, or for the entire dataset, at which point it queries
    > your data source object again.

    Ah, I remember I have played with that before. Thanks Kyle!
previous month february 2008 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    
Go to today