Re: Color entire table view row
Re: Color entire table view row
- Subject: Re: Color entire table view row
- From: David Remahl <email@hidden>
- Date: Fri, 05 Apr 2002 16:21:20 +0200
>
Hi,
>
>
> Well, what is not elegant in using the data source and setting the
>
> properties of the cell each time? That is the way things are normally done.
>
> If you want to use proper MVC, have a model data storage and a controller
>
> that combines the data with your interpretation of it (the colour).
>
>
I think that having a single attributed string and using the elegance of:
>
[[somearray objectAtIndex:rowIndex] valueForKey: [tableColumn identifier]];
>
For tableView:objectValueForTableColumn:row:
>
is a nice way to go.
>
>
Yes, some color information is stored, but this is neither editable by the
>
user (the color of any particular string, "Error" being red, etc.) nor is it
>
unecessarily embedded into the 'model.'
It would still be embedded into the controller. The model shouldn't have
table view data source methods.
>
>> Something like this as a table view delegate would be awfully nice:
>
>> - (NSDictionary *)displayAttributesForRow:(int)row
>
>>
>
>> But oh well. :P
>
>
>
> That is virtually what you have in the current implementation. This is what
>
> would cause excess maintainance, if Apple would implement it, duplicating
>
> already good code. But do feel free to file a feature request :-)
>
>
It's nothing like what I have. There's a big difference between setting this
>
thing per-cell and per-row. I imagine tracing your app would show you this,
>
as I imagine invoking this method once per _cell_ would call it cols * rows
>
times and invoking it once per row would only call it rows times (where rows
>
and cols are the numbers of rows and columns, obviously).
Yes, you are right. I didn't consider that you might have several columns.
My mistake.
>
>> Still too much work and still not elegant. This is one of those features
>
>> where "I'd implement it in my app if it exists, but it's not worth the time
>
>> or effort to write my own (and then be forced to maintain it)." I'm just
>
>> surprised that there's no method like the one I listed above.
>
>>
>
> Hmm, I tell you, you would never, ever, never have the patience to write
>
> even the smallest carbon application...
>
>
Don't be a jerk, don't assume, don't presume, etc. etc. I said that it's
>
such a tiny feature that anything more than ten minutes of writing code
>
isn't worth it. _ANY_ developer in _ANY_ development environment can think
>
of situations in which they can't justify spending an hour to do something
>
to implement a feature so small almost nobody will ever see it.
Nope, neither can Apple...
Anyway, I'm sorry if I came across in a bad way. I really should have had a
winking smiley there :).
>
> What kind of method are you expecting? A [yourCell setTextColor:col]? That
>
> _is_ exactly what the attributed strings are there for. Do you expect the
>
> class to ignore color information in the attributed string if the color was
>
> explicitly set, or should attributedness never use the explicit color?
>
>
Most tables display standard old strings, so surely the attributes could be
>
applied either on an override or non-overriding basis. If the attributes
>
returned controlled set NSForegroundAttributeName then an "override:YES"
>
would override any attributed strings who had also set that. And an
>
override:NO would not.
>
>
Why would this be elegant? Because it'd be part of the cocoa frameworks
>
instead of _me_ having to write it, and instead of _every_ other developer
>
who wants to color rows separately having to write it. It seems like a
>
fairly simple thing to do on a collection of data in a table, coloring whole
>
rows or columns... Something lots of people might want to do. In short,
>
seems like a little hole in NSTableView.
Hmm, I don't know, but I think the by far most common case is that you will
want colour just a single cell...And secondly, this would be just another
thing NSCell subclassers would have to consider, _adding_ coding work to
developers wanting to support the cocoa classes well..
>
My original question having now been answered, I thank you all for your
>
input and get back to work.
/ :-) Thank you :-)
// David
_______________________________________________
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.