Table View Blues

  • The table view (NSTableView) is, in my humble opinion, one of the
    most important of all GUI controls. When you start interfacing with
    databases, its use becomes vital. But there seems to be a lack of
    flexibility with regard to the Cocoa NSTableView. Let me explain by
    first explaining what I am used to, and then by explaining what I
    perceive as the issues with the Cocoa implementation.

    [I am sure I would find the answers to many things if I just "kept
    at it" - that goes without saying - but if someone with the
    experience I do not have would like to comment, I would be most
    grateful.]

    * * * * *

    In the world of Windows, the corresponding control, the listview,
    can be used in one of two ways. First, it can itself hold onto all
    the strings put into it. There are messages that can be sent to it
    to retrieve data for any row at any column. This method is not often
    used, as sorting becomes impossible other than by column 0, the
    default. Second, the program itself can hang onto the data, and upon
    request give the data to the listview. And if the program itself
    hangs onto the data, then the program itself can arbitrarily
    determine how the various columns are to be sorted - and not just
    according to currency, date, and the like. The program can truly
    determine the sorting order itself.

    The key here is that with each "list view item", i.e. complete row,
    i.e. record, one may associate an arbitrary 32-bit value, and this
    32-bit value can be used to store a pointer to a dynamic allocation
    which holds the actual record.

    The MO is therefore elementary. Read in a record from disk, allocate
    memory for it, inform the list view there is yet another record, and
    so forth. And this affords me the necessity (hardly a luxury) of
    using a platform-independent format (which NSData and coding would
    not) such as CSV or TSV. Read a new record, hit the first comma,
    that's the end of the first field, hit the next comma, and so forth,
    until I've reached a newline or EOF - end of record. Can't be
    simpler.

    Things get better. Because of the way "heaps" were organized by Dave
    Cutler (something this good would hardly have come from the
    Microsofties), it takes a single function call - a very low overhead
    duh - to completely destroy (completely free) an entire heap. If you
    have thousands of records/items pouring into a list view / table
    view, it is going to take time to populate the view; if it takes
    almost as long to vacate it, you're in trouble. Some programs I run
    can count on 20,000 or more records which the user expects the
    programs to load in under a second in real time. Switching between
    one file and another becomes problematic if the former file's memory
    cannot be cleared "in a flash". Fortunately, the "heap" thing comes
    to the rescue. Each time a new file is started, the heap used for
    all allocations is destroyed (in one API call), a new heap is
    created, and all new allocations begin there. Easy peasy.

    An added treat is that a single call to the list view can tell it to
    completely destroy all items (records). As I no longer need any
    associated data - as I can just destroy the heap all the data was
    allocated on - this is no mess; in fact it's the call before the
    call to destroy the heap, "just in case".

    Moreover, I can make sure this does not look ugly to the user. I can
    set a "redraw" flag off for the listview while I am doing this - and
    because the listview knows it is temporarily freed from the
    responsibility of drawing everything on screen, unloading and
    loading again goes hundreds of times faster.

    So in an effectively infinitesimal period of time, with two API
    calls, I can completely destroy all records in any list view / table
    view, no matter how many there be therein, and free the associated
    memory too. "In a flash, they're gone." And I suggest this becomes
    vital when dealing with data arrays even more bulky, such as
    customer databases et al.

    * * * * *

    With the NSTableView, the delegate idea requires my program - my
    controlling class - to maintain a mutable array with all the
    records. (This is how I was taught at any rate.) It is perhaps not
    going to take any longer to create these record instances for each
    record I read in from file, but I think it is definitely going to
    take a longer time to dealloc them when the user switches files. I
    am going to get separate messages sent for every record in my table
    view - with populations exceeding 20,000 records, this is a lot of
    CPU, a WHOLE lot.

    Even if I could associate data - without creating a class, something
    I would prefer, as this is just cold data to me and it's going to
    have to be formatted as CSV or TSV - with each record in a table
    view, I would still be stuck - or so I think - with individual calls
    to free() whenever my user wanted to start a new file.

    * * * * *

    I could attack the problem by using the "zone" functions.

    NSCreateZone
    Creates a new zone.
    NSZone *NSCreateZone(unsigned int startSize, unsigned int
    granularity, BOOL canFree)

    This would give me somewhere to put my record allocations. But the
    converse call:

    NSRecycleZone
    Frees memory in a zone.
    void NSRecycleZone(NSZone *zone)

    Has this caveat:

    Discussion
    Frees zone after adding any of its pointers still in use to the
    default zone. (This strategy prevents retained objects from being
    inadvertently destroyed.)

    Meaning I am still stuck with deallocating everything myself -
    otherwise I am going to get one monstrous (and continually growing)
    memory leak.

    And NSZoneFree, as I understand it, is not what I am after either...

    And even if there were a way to get all the memory freed in one fell
    swoop, I would still need a way of vacating the table view in the
    same short period of time...

    Unless it's just a question returning "no rows in table view" and
    making sure the question is asked... But I don't know, that just
    sounds wrong, "sloppy" - but I just don't know...

    As things stand, it seems like the NSTableView is shooting
    butterflies with a cannon...
    Everything you'll ever need on one web page
    from News and Sport to Email and Music Charts
    http://uk.my.yahoo.com
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Sunday, November 17, 2002, at 10:28  PM, Rixstep wrote:

    > The table view (NSTableView) is, in my humble opinion, one of the
    > most important of all GUI controls. When you start interfacing with
    > databases, its use becomes vital. But there seems to be a lack of
    > flexibility with regard to the Cocoa NSTableView. Let me explain by
    > first explaining what I am used to, and then by explaining what I
    > perceive as the issues with the Cocoa implementation.

    I have no actual experience programming with very  large # of rows in
    NSTableView or on Windows, but it's an interesting question so what the
    heck...

    I think your question could be recast as "How do I implement a very
    fast NSTableDataSource in Objective-C without the bottleneck of
    alloc-ing and dealloc-ing thousands or millions of records and stuffing
    them into a NSMutableArray?"

    Here are some other thoughts:

    NSTableView will be perfectly happy, and quick, (I think I haven't
    tried it) if at one moment, the data source says  -
    numberOfRowsInTableView: = 100,000, and then you do

    /* suppose loadAnotherRecord deallocs 100K records and loads another
    500K */
    [dataSourceObj loadAnotherRecord];
    [tableViewOutlet reloadData];

    The bottleneck in the above two lines is going to be how fast your
    dataSourceObj can do the unload & reload, not how fast the
    tableViewOutlet reload.  In the worst case the NSTableView is releasing
    (just a retain count, not dealloc-ing anything) all the objects it has
    gotten from tableView:objectValueForTableColumn:row: and then
    NSTableView is redrawing itself. So the bottleneck would still be with
    the data source, not the NSOutlineView.

    The NSTableDataSource protocol cleanly separates the data and the
    tableview using the MVC pattern (model, view, controller). Maybe that's
    what you meant by "MO"; model object?

    NSTableDataSource doesn't say anything about how the data source should
    be implemented, just that the data source object implementing
    NSTableDataSource must respond to those messages. So your data source
    object need not internally use a NSMutableArray for records. It could
    even lazily read records as needed off disk using whatever portable
    file format you are using. It could use C arrays, C++ STL containers,
    or a database library, instead of ObjC containers for implementing the
    structure of the records and record access.

    However, I do think that using ObjC container classes like
    NSMutableArray would be the best way to implement the data source for
    most developers initially unless one find performance to be
    unacceptable with all those objects getting alloc-ed and dealloc-ed
    when files are opened and closed. So it seems you have enough records
    to hit that bottleneck.

    Also maybe consider using -noteNumberOfRowsChanged on NSTableView as it
    allows you to display data to the user while more records are being
    loaded. Might be useful if you are constructing objects to stuff into a

    Alex Rice <alex...>
    Mindlube Software
    http://mindlube.com/
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, November 18, 2002, at 12:54  AM, Alex Rice wrote:
    > /* suppose loadAnotherRecord deallocs 100K records and loads another
    > 500K */
    > [dataSourceObj loadAnotherRecord];

    Oops, that doesn't make sense. Rather it would [dataSourceObj
    loadAnotherTable]; or [dataSourceObj loadAnotherDatabase], not
    loadAnotherRecord.

    > [tableViewOutlet reloadData];

    Alex Rice <alex...>
    Mindlube Software
    http://mindlube.com/
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Am Montag, 18.11.02 um 06:28 Uhr schrieb Rixstep:

    > With the NSTableView, the delegate idea requires my program - my
    > controlling class - to maintain a mutable array with all the
    > records.

    As Alex already pointed out, the table view does not care how you
    maintain your data.

    You simply get a request for the contents of any cell that's about to
    be displayed and tell the table view what it should put there.

    > I am going to get separate messages sent for every record in my table
    > view

    You will only get messages for those cells that are actually being
    displayed, AFAIK.

    > Even if I could associate data - without creating a class, something
    > I would prefer, as this is just cold data to me and it's going to
    > have to be formatted as CSV or TSV - with each record in a table
    > view, I would still be stuck - or so I think - with individual calls
    > to free() whenever my user wanted to start a new file.

    I don't understand. If you would like to allocate one big chunck of
    memory and manage it on your own - go ahead. Nothing is going to stop
    you. Objective-C is a superset of C after all.

    bye.  Andreas.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • --- j o a r <joar...> wrote: > How often would you replace the contents of the table view? If you
    >
    > switch the contents of the table view so often that memory
    > allocation / deallocation is a serious bottleneck, don't you
    > think that this would cause the table view in itself to be
    > almost useless as an UI element?

    Absolutely not. I have several examples where it not only is necessary, but works fine - given the memory stuff I can use where I have recently been.

    > What would happen when the user is scrolling through the table
    > view, looking for something or keeping a selection, et.c., and you
    > switch the data?

    I don't switch data - the user does. The user cannot switch data and scroll at the same time. I agree that this seems unfeasible with the NSTableView, but it shouldn't be - and it isn't, on other platforms.

    > I'm not sure that I agree with using just one table view for
    > displaying 20.000 records

    20,000 is an example. Most real life situations will require a lot more.

    > it would be rather difficult to navigate

    Not as things stand at the present - on the other platform. There is nothing difficult about it at all.

    > Have you benchmarked this? Where's the bottleneck?

    Don't need to. There is too much happening. Correction: there is _something_ happening, whereas where I have been there is nothing. Two calls and that's it: vacate the view, and good-bye to all data. Two (2) calls.

    The bottleneck is naturally in the recursive deallocs, for each string for each column for each row in the view.

    > Here's a short snippet to read a comma separated file to be used
    > for a table view:
    >
    > - (void) loadTableDataFromFile:(NSString *) path
    > {
    > NSString *str = [NSString stringWithContentsOfFile: path];
    > NSArray *arr = [str componentsSeparatedByString: @","];
    >
    > [myTableViewArray setArray: arr];
    > [myTableView reloadData];
    > }
    >
    > No  error checking, no sorting, et.c., but you get the idea...

    Yes, this is very cool, but it's not on the upside that the problem occurs. We all know we have to get the data in there. What we cannot afford is a haphazard memory arrangement so we're spending as much time getting rid of it later.

    > I would suggest reading and parsing files in a separate thread if
    > the responsiveness of the GUI is important.

    For what today is at most a one second delay, I hardly think this is justified.

    > That said, NSTableView is provided as a general purpose control -
    > not suited for very large tables with a high frequency of updates.

    OK, fine, sure. Then what control does NS have for large tables?

    > the main limitation is that you can only choose to update the
    > whole table view, and not just a given x,y cooordinate in the
    > table through the public API of NSTableView

    I'm prepared to accept this. In both models, the drawing of the view is left to the view itself, and the application responds to needs for data to be displayed. That's the view's problem, but I've never seen a view hiccup for that...

    > In our main application we've created our own table view optimized
    > for our particular needs and this might be something that you need
    > to do if NSTableView cannot  keep up properly.

    Yeah, I'm getting that picture. My complaint isn't so much with the view itself, but with the lack of tidy memory management underneath. That's where the clocks are saved.

    The picture I am getting is that Apple/NS are unsurpassed at graphics, but that types of business things are a bit unfamiliar for them. I would hate to give MS the win on this one, but it looks like their crummy listview, coupled with Cutler's memory management, wins this round.

    Unfortunately. ://

    Cheers, R.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • >> Even if I could associate data - without creating a class, something
    >> I would prefer, as this is just cold data to me and it's going to
    >> have to be formatted as CSV or TSV - with each record in a table
    >> view, I would still be stuck - or so I think - with individual calls
    >> to free() whenever my user wanted to start a new file.

    > I don't understand. If you would like to allocate one big chunck of
    > memory and manage it on your own - go ahead. Nothing is going to stop
    > you. Objective-C is a superset of C after all.

    No, I don't think you do. Sorry if I was unclear.

    It's got nothing to do with languages. It has a bit to do with the API. But mostly it has to do with the underlying memory management in the operating system - or any layer thereof the API wants to put on top.

    In Unix, AFAIK, calloc and malloc are true primitives, whereas in Cutler's Win32 they are not - they resolve to his own memory management schemes - which in this case are essential to survival.

    You can never get away from the task of loading data into a program. What you must get away from here is the bottleneck of having to deal with potentially 100's of 1000's of recursive dealloc calls when a view is to be vacated and repopulated.

    Cheers, R.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • > Do your own control, if you think that is the problem...

    That's downright ridiculous.

    > Well, the point is that a table view isn't necessarily the most
    > suitable user interface element for that kind of need...

    And "that kind of need" is a _very_ common business kind of need - so what does Apple have instead?

    > Ok, lets assume you have 50000 records in your table view.

    This is about scrolling. The issues I mentioned have nothing to do with scrolling. Read it again.

    > DIY. The framework can't do everything for you.

    This is downright ridiculous. What's worse, it's lame.

    > For a consultancy fee, I assure you there are many people
    > (incidently
    > including myself ;) who would help you optimize your code if you
    > are not
    > able to do it yourself.

    Oh drop it. From the tone of your letter, it's obvious you know even less about Cocoa than the rest of us. Go play and be rude somewhere else.

    R.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, November 18, 2002, at 05:43  AM, <rixstep000...>
    wrote:
    > Yes, this is very cool, but it's not on the upside that the problem
    > occurs. We all know we have to get the data in there. What we cannot
    > afford is a haphazard memory arrangement so we're spending as much
    > time getting rid of it later.

    Someone suggested to me off-list that NSTableView might not retain
    objects it gets from the NSTableDataSource. If that's true then the
    bottleneck is completely in the data source implementation and has
    nothing to do really with the table view itself.

    If your data has 1M rows, don't create 1M NSStrings when the data
    source object is created, as the previous loadTableDataFromFile:
    example would do. Instead create the NSStrings lazily.

    The tableview will only request objects from the data source _when it
    needs to display them_. The user can view at most 100 or so rows at
    once, and there is no problem creating 100 NSStrings it won't even be a
    noticable hit creating them every time the user scrolls. Actually only
    1 NSString would be created each time your
    tableView:objectValueForTableColumn:row: is called. Something like this:

    - (id)tableView:(NSTableView *)aTableView
        objectValueForTableColumn:(NSTableColumn *)aTableColumn
    row:(int)rowIndex
    {
    NSString *answer = [NSString stringWithCString:
      someReallyFastFnToReadCSVData( rowIndex, [aTableColumn identifier]
    )];
    return answer;
    }

    If you implement it this way I suspect your performance concerns will
    disappear. I might try this later on because I am curious :-)

    Alex Rice <alex...>
    Mindlube Software
    http://mindlube.com/
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • Am Montag, 18.11.02 um 14:10 Uhr schrieb <rixstep000...>:

    > What you must get away from here is the bottleneck of having to deal
    > with potentially 100's of 1000's of recursive dealloc calls when a
    > view is to be vacated and repopulated.

    Hm. Then why don't you use your own memory management?

    A problem could occur if the table view buffered all cells it had
    displayed at some time. I'm not sure if it does; but even then you
    could probably write a subclass that doesn't.

    > coupled with Cutler's memory management,

    Well, can't you get that converted to the Mac? If it's written in C
    this should be possible.

    bye.  Andreas.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, Nov 18, 2002, at 13:43 Europe/Stockholm,
    <rixstep000...> wrote:

    >> I'm not sure that I agree with using just one table view for
    >> displaying 20.000 records
    > 20,000 is an example. Most real life situations will require a lot
    > more.

    As long as you don't turn into that guy over at Mac OS X Dev that
    wanted to display 37 million rows in a table view...  ;)

    (Thread: "Maximum size for NSTableView?")

    >> That said, NSTableView is provided as a general purpose control -
    >> not suited for very large tables with a high frequency of updates.
    >
    > OK, fine, sure. Then what control does NS have for large tables?

    NSTableView is the only one - but I wouldn't nessecarily rule it out
    already.

    >> In our main application we've created our own table view optimized
    >> for our particular needs and this might be something that you need
    >> to do if NSTableView cannot  keep up properly.
    >
    > Yeah, I'm getting that picture. My complaint isn't so much with the
    > view itself, but with the lack of tidy memory management underneath.
    > That's where the clocks are saved.
    >
    > The picture I am getting is that Apple/NS are unsurpassed at graphics,
    > but that types of business things are a bit unfamiliar for them. I
    > would hate to give MS the win on this one, but it looks like their
    > crummy listview, coupled with Cutler's memory management, wins this
    > round.

    Weren't the Cocoa frameworks created for use in the enterprise? I know
    that we've successfully used them for heavy lifting for years and years
    on a wide variety of platforms - still going strong actually - and the
    streams of data we have to deal with in real time is quite something.

    I think that Alex and Andreas suggestions on memory management might be
    a good thing to look into. Is the memory management "a la Cutler" you
    mentioned a Windows only thing, or something that you could use also on
    Mac OS X?

    j o a r
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • NSTableView reuses one cell per column for the drawing of all rows, so
    I don't think that's a problem.

    j o a r

    On Monday, Nov 18, 2002, at 22:07 Europe/Stockholm, Andreas Mayer wrote:

    > A problem could occur if the table view buffered all cells it had
    > displayed at some time. I'm not sure if it does; but even then you
    > could probably write a subclass that doesn't.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • >>> switch the contents of the table view so often that memory
    >>> allocation / deallocation is a serious bottleneck, don't you
    >>> think that this would cause the table view in itself to be
    >>> almost useless as an UI element?
    >>
    >> Absolutely not. I have several examples where it not only is necessary, but
    >> works fine - given the memory stuff I can use where I have recently been.
    >
    > My point (usability issues ignored, for the time being), is that you can use
    > what ever storage and allocation method you want. For example, you could use a
    > linked list in C code, for which you are responsible of all memory management.
    > The actual allocation is not a siginifiant bottle neck in most cases, but
    > retain/release may be. Many else have pointed this out.
    >
    > In the data source, you then provide the information required by the control.
    > That is seldom more than 200 cells at a time, and that happens in a quite
    > short time, and is not dependant of the size of the underlying data set.
    >
    > / Sincerely, David Remahl
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, November 18, 2002, at 03:49  PM, j o a r wrote:
    >>> I'm not sure that I agree with using just one table view for
    >>> displaying 20.000 records
    >> 20,000 is an example. Most real life situations will require a lot
    >> more.
    >
    > As long as you don't turn into that guy over at Mac OS X Dev that
    > wanted to display 37 million rows in a table view...  ;)
    >
    > (Thread: "Maximum size for NSTableView?")

    Not so fast; I'm lurking over here too, but I wasn't going to bring up
    that thread. At least now I've got company in the "pathological
    NSTableView users' set". ;)

    - - - - - - - - - - - - - - -
    Terrence Asselin
    RiskWise LLC
    - - - - - - - - - - - - - - -
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • At 23:34 +0100  on  11/18/02, j o a r wrote:
    > NSTableView reuses one cell per column for the drawing of all rows,
    > so I don't > think that's a problem.

    And to veer off on to a new topic... I'm doing some work with an
    NSTableView and I"m trying to figure out if there is a way to get
    what amounts to cell by cell access.  Basically I'd like to make a
    table that looks like this:

    Stuff 1    Stuff 2
    blah      NSPopupButton for blah
    blah2      NSPopupButton for blah2
    blah3      NSString for blah3
    blah4      NSString for blah4

    or alternatively have a different popup button menu for blah3 & blah4
    than for blah & blah1.  Any thoughts?
    --
    _____________________________________________
    Kevin Elliott <mailto:<kelliott...> ICQ#23758827
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Monday, November 18, 2002, at 04:23  PM, David Remahl wrote:
    >> My point (usability issues ignored, for the time being), is that you
    >> can use
    >> what ever storage and allocation method you want. For example, you
    >> could use a
    >> linked list in C code, for which you are responsible of all memory
    >> management.
    >> The actual allocation is not a siginifiant bottle neck in most cases,
    >> but
    >> retain/release may be. Many else have pointed this out.
    >>
    >> In the data source, you then provide the information required by the
    >> control.
    >> That is seldom more than 200 cells at a time, and that happens in a
    >> quite
    >> short time, and is not dependant of the size of the underlying data
    >> set.
    >>

    This has been an interesting through and I just want to recap what has
    been said, and point out that one of Rixstep's main questions hasn't
    been answered.

    1) Does Unix/BSD/OS X have the equivalent functionality of Win32's
    HeapCreate, HeapAlloc, HeapDestroy? If no, what is the C programming
    method used instead?

    1a) Rixstep thinks that the absence of these functions is going to
    prevent him from writing a NSTableDataSource that will be as quick as
    the Windows implementation of a tabular browser for many K's of rows.
    Is this as much of a bummer as he thinks?

    1b) Maybe this is a question for asking on Usenet in comp.lang.c or
    something? This just occurred to me: it's likely the answer can be
    found in the source to the WINE project which is basically an
    open-source Win32 runtime for Linux.

    --

    2) The MVC pattern and NSTableDataSource protocol are a help not a
    hinderance and don't prevent Rixstep from writing the backend in as
    gnarly C code as he wants to. :-)

    3) The NSTableView, and most everything in Cocoa, buffers the display
    so one generally doesn't need to worry about locking for redraws like
    one would on Win32.

    4) NSTableView itself is doing nothing to hurt performance. Because of
    the MVC pattern, the NSTableView ONLY sees objects for which is will
    actually display. It doesn't do anything to those objects which is
    going to slow you down. Any bottleneck is in the NSTableDataSource
    implementation.

    HTH

    Alex Rice <alex...>
    Mindlube Software
    http://mindlube.com/
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Tuesday, Nov 19, 2002, at 12:27 US/Eastern, Kevin Elliott wrote:

    > At 23:34 +0100  on  11/18/02, j o a r wrote:
    >> NSTableView reuses one cell per column for the drawing of all rows,
    >> so I don't >think that's a problem.
    >
    > And to veer off on to a new topic... I'm doing some work with an
    > NSTableView and I"m trying to figure out if there is a way to get what
    > amounts to cell by cell access.  Basically I'd like to make a table
    > that looks like this:
    >
    > Stuff 1    Stuff 2
    > blah      NSPopupButton for blah
    > blah2      NSPopupButton for blah2
    > blah3      NSString for blah3
    > blah4      NSString for blah4
    >
    > or alternatively have a different popup button menu for blah3 & blah4
    > than for blah & blah1.  Any thoughts?

    Subclass NSTableColumn, so that you can set different cells for
    different rows.

    - --
    http://homepage.mac.com/clarkcox3/
    <clarkcox3...>
    Clark S. Cox, III
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.7 (Darwin)

    iEYEARECAAYFAj3aqxIACgkQd6STocYT1xXIFwCdG8MsGHf21EQvzsa+vGfLza8h
    nNgAnjCTFwlPzacssURJipULNNUrbqHq
    =CfsF
    -----END PGP SIGNATURE-----
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • I'm trying to display some fonts in an NSTableView and NSOutlineView
    but having some problems with the baseline (I think that's what it's
    called) and fonts getting chopped off. You can see in the screenshot
    at http://www.unsanity.org/rosyna/fontissue.png

    Is there anyway to fix this? I'm setting the attributed string in the
    objectValue delegate method for each table. I've also noticed
    scrolling is extremely slow when showing the fonts. But the cutting
    off and the odd font alignment is what really worries me.
    --

    Sincerely,
    Rosyna Keller
    Technical Support/Holy Knight/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People
    ---

    Please include any previous correspondence in replies, it helps me
    remember what we were talking about. Thanks.
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month november 2002 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