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!
