FROM : Daryn
DATE : Tue Dec 31 21:39:11 2002
Actually, how evil is it to subclass a color well to forward
invocations to the well's color, and then use this new color well as
the attribute value of fore/background color in the text storage? Part
of the color well's action message invokes display on the text view.
This _seems_ to work, but it makes me nervous. What might go awry for
me later?
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector {
NSMethodSignature *signature = [super
methodSignatureForSelector:selector];
if (!signature) signature = [[self color]
methodSignatureForSelector:selector];
return signature;
}
- (void)forwardInvocation:(NSInvocation *)invocation {
[invocation invokeWithTarget:[self color]];
}
On Tuesday, December 31, 2002, at 01:17 PM, Daryn wrote:
> In a nutshell, I'm displaying ansi color output from another app in a
> text view. Since the scrollback is arbitrarily large (user pref) and
> thus the ranges may be excessive, I planned to dynamically update the
> visible rect, and defer changing all text until the color ui is
> dismissed.
>
> Greg Titus had a interesting suggestion for subversively faking a
> mutable color, although I'm worried something else wouldn't work as
> expected since the color thinks it's one thing, but is really another.
> I occasionally derive colors, although I can adapt that the use the
> real colors. I'll have to see if it interferes with selection colors
> or text copying.
>
> Thanks for the feedback!
>
> On Tuesday, December 31, 2002, at 12:44 PM, Mike Ferris wrote:
>
>> Is there more than one color?
>>
>> If there's only a single color, just set a new
>> NSForegroundColorAttribute over the whole range of text.
>>
>> But if you're doing something like syntax coloring and there's
>> multiple ranges with different colors and you need to change one of
>> those colors, then what you're describing is probably the wqay to go.
>> PB does something very similar. It uses a custom syntax coloring
>> attribute to mark sections that are comments or numbers or strings or
>> whatever, and when the user changes the preference for one of the
>> elements it scans through, finding ranges that are that element using
>> the custom attribute and resetting the NSForegroundColorAttribute for
>> the ranges that it needs to change.
>>
>> Because this can be arbitrarily expensive depending on how much text
>> you've got and how many discreet ranges, you may want to consider not
>> doing it immediately. If you can't do the real change immediately
>> you could still put some sample text near the color change UI and
>> reflect changes immediately there (where you have control over how
>> expensive it would be) and do the change throughout the user's real
>> text only after the user has decided on a color.
>>
>> You cannot just change the color object that all the ranges use since
>> NSColors are immutable...
>>
>> Mike
>>
>> Begin forwarded message:
>>
>>> From: Daryn <<email_removed>>
>>> Date: Tue Dec 31, 2002 10:11:51 AM US/Pacific
>>> To: <email_removed>
>>> Subject: Dynamic color changes in a text view
>>>
>>> I have a text view that contains text with various configurable
>>> colors. Using a continous color well, I'd like the existing text to
>>> change color.
>>>
>>> My thoughts about how to implement this would involve adding my own
>>> attributes (ie. "MyRedColor", "MyGreenColor", etc) to the text
>>> storage in order to use attribute:atIndex:effectiveRange: to iterate
>>> over the storage and update the color.
>>>
>>> Is there a simpler method to achieve this result? For example, is
>>> it possible to conceptually change a single color object that all
>>> the colored ranges use?
>>>
>>> Daryn
>>> _______________________________________________
>>> cocoa-dev mailing list | <email_removed>
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>> Do not post admin requests to the list. They will be ignored.
>>
>>
>>
> Daryn
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Daryn
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Tue Dec 31 21:39:11 2002
Actually, how evil is it to subclass a color well to forward
invocations to the well's color, and then use this new color well as
the attribute value of fore/background color in the text storage? Part
of the color well's action message invokes display on the text view.
This _seems_ to work, but it makes me nervous. What might go awry for
me later?
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector {
NSMethodSignature *signature = [super
methodSignatureForSelector:selector];
if (!signature) signature = [[self color]
methodSignatureForSelector:selector];
return signature;
}
- (void)forwardInvocation:(NSInvocation *)invocation {
[invocation invokeWithTarget:[self color]];
}
On Tuesday, December 31, 2002, at 01:17 PM, Daryn wrote:
> In a nutshell, I'm displaying ansi color output from another app in a
> text view. Since the scrollback is arbitrarily large (user pref) and
> thus the ranges may be excessive, I planned to dynamically update the
> visible rect, and defer changing all text until the color ui is
> dismissed.
>
> Greg Titus had a interesting suggestion for subversively faking a
> mutable color, although I'm worried something else wouldn't work as
> expected since the color thinks it's one thing, but is really another.
> I occasionally derive colors, although I can adapt that the use the
> real colors. I'll have to see if it interferes with selection colors
> or text copying.
>
> Thanks for the feedback!
>
> On Tuesday, December 31, 2002, at 12:44 PM, Mike Ferris wrote:
>
>> Is there more than one color?
>>
>> If there's only a single color, just set a new
>> NSForegroundColorAttribute over the whole range of text.
>>
>> But if you're doing something like syntax coloring and there's
>> multiple ranges with different colors and you need to change one of
>> those colors, then what you're describing is probably the wqay to go.
>> PB does something very similar. It uses a custom syntax coloring
>> attribute to mark sections that are comments or numbers or strings or
>> whatever, and when the user changes the preference for one of the
>> elements it scans through, finding ranges that are that element using
>> the custom attribute and resetting the NSForegroundColorAttribute for
>> the ranges that it needs to change.
>>
>> Because this can be arbitrarily expensive depending on how much text
>> you've got and how many discreet ranges, you may want to consider not
>> doing it immediately. If you can't do the real change immediately
>> you could still put some sample text near the color change UI and
>> reflect changes immediately there (where you have control over how
>> expensive it would be) and do the change throughout the user's real
>> text only after the user has decided on a color.
>>
>> You cannot just change the color object that all the ranges use since
>> NSColors are immutable...
>>
>> Mike
>>
>> Begin forwarded message:
>>
>>> From: Daryn <<email_removed>>
>>> Date: Tue Dec 31, 2002 10:11:51 AM US/Pacific
>>> To: <email_removed>
>>> Subject: Dynamic color changes in a text view
>>>
>>> I have a text view that contains text with various configurable
>>> colors. Using a continous color well, I'd like the existing text to
>>> change color.
>>>
>>> My thoughts about how to implement this would involve adding my own
>>> attributes (ie. "MyRedColor", "MyGreenColor", etc) to the text
>>> storage in order to use attribute:atIndex:effectiveRange: to iterate
>>> over the storage and update the color.
>>>
>>> Is there a simpler method to achieve this result? For example, is
>>> it possible to conceptually change a single color object that all
>>> the colored ranges use?
>>>
>>> Daryn
>>> _______________________________________________
>>> cocoa-dev mailing list | <email_removed>
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>> Do not post admin requests to the list. They will be ignored.
>>
>>
>>
> Daryn
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Daryn
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Daryn | Dec 31, 19:11 | |
| Greg Titus | Dec 31, 19:29 | |
| Mike Ferris | Dec 31, 19:44 | |
| Mike Ferris | Dec 31, 19:46 | |
| Daryn | Dec 31, 20:17 | |
| Daryn | Dec 31, 21:39 | |
| Greg Titus | Dec 31, 21:52 | |
| Mike Ferris | Jan 2, 17:14 |






Cocoa mail archive

