Re: tables cells and views
Re: tables cells and views
- Subject: Re: tables cells and views
- From: nicolas berloquin <email@hidden>
- Date: Sun, 28 Apr 2002 19:14:51 +0200
There is a reason cells aren't views. As the NSCell doc says, "The
NSCell class provides a mechanism for displaying text or images in an
NSView without the overhead of a full NSView subclass." For example,
if you had a list containing hundreds of items, it would be expensive
to implement it with hundreds of subviews. Prohibitively expensive? I
don't know. In the NEXTSTEP days, the cost of one graphics context per
view was apparently important enough to warrant the introduction of the
cell concept.
alright, I understand the problem of graphics context overhead, but I
guess that once you decide to work with a "heavy" framework, you give up
the idea of having anything light (either in memory, during execution or
on disk...)
I don't know if there are other, non-performance-related reasons for
NSCells. For example, at runtime you can change the cell a view uses.
That doesn't seem like a compelling benefit offhand, but maybe I'm
overlooking something. Another thought: in a list, you typically want
the list view to control the layout of its items. It would not make
sense for a cell to have a -setFrame: method, such as it would inherit
if if were an NSView.
the interesting part about nsview is not its setframe, but all the other
amenities... like subviews, IB visual setup, buttons etc etc
If you just want a list view that uses subviews instead of cells, you
can create it yourself. (Hint: -addSubview and -removeFromSuperview.)
You'll have to write your own logic to manage the layout of the
subviews, but that should be a straightforward exercise. You might see
a cost in performance, but maybe not.
you're right on the point, why not have a class that handles everything
like a tableview/columnview does, BUT has nsviews inside it ?
You mentioned wanting buttons within each cell, so it's not just a
matter of rendering. You also want the buttons to behave properly in
response to clicks and drags.
exaclty, and I'd have to write this myself.... ;-(
You might want to submit your wish to Apple in a bug report
<http://bugreport.apple.com>. Questions on specializing NSCell
behavior appear again and again on these mailing lists. Maybe Apple
could add something to Cocoa (if only more documentation and/or
examples) to make this simpler or more obvious.
(are all lists only text or simple images ?)
No, but very many are. NSCell provides a lightweight mechanism for
these extremely common cases. Meanwhile, it is completely possible in
Cocoa to achieve what you want, though not as trivially as you might
have liked.
here's an example you might have already seen: a list of downloading
files in a web application. You may want more than just text in your
table, you'd have the filename,
a progress indicator, and maybe a button to stop/pause the download....
and this is not a far-fetched example...
I know that 90% of lists will use the text/picture functions and be
happy with them, but like you said, why not have the best of both
worlds ?
I will file a suggestion to apple.
thanks anyway for your answers !!! ^_^
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.