Re: +underPageBackgroundColor

[Gary L. Wade]

On Aug 8, 2012, at 3:23 PM, Graham Cox  wrote:

> The SVG standard defines 147 named colours:  
> http://www.december.com/html/spec/colorsvg.html
> 
> I thought it would be a nice programmer convenience to have NSColor return 
> these colours using the same naming convention that it already uses for its 
> built-in colours


As a somewhat example, you might want to look at the WebKit classes related to 
the DOM.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Graham Cox]

On 08/08/2012, at 7:46 PM, Uli Kusterer  wrote:

> Prefix/suffix them with gc_ / _gc ? Alternately, just define them in a .plist 
> and build your table from that, then you don't need to implement named 
> NSColor methods for them at all.
> 


I have a table, that's not a problem.

The SVG standard defines 147 named colours:  
http://www.december.com/html/spec/colorsvg.html

I thought it would be a nice programmer convenience to have NSColor return 
these colours using the same naming convention that it already uses for its 
built-in colours, e.g. +[NSColor lightskyblueColor]; and in the sRGB colour 
space (and note, there's an SVG colour called "linen"). As soon as you go 
adding prefixes of any kind that convenience somewhat evaporates. However, 
since in reality my use for these comes from parsing SVG, it invariably ends up 
using the table lookup anyway and these methods are unused. So for now, simply 
dropping them out of my category altogether is a simple solution.

But yeah, namespaces would be a very nice addition to Objective-C.

--Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Jayson Adams]

On Aug 7, 2012, at 9:48 AM, Kyle Sluder wrote:

>> Yes, and devs are also supposed to prefix their own methods to avoid exactly 
>> this problem.
> 
> And if your prefix clashes with the hidden one that Apple or another 
> framework vendor chose, you're *still* SOL.
> 
> Nope, we totally don't need namespaces at all. /sarcasm


In the previous namespaces discussion I don't think anyone argued against them. 
 The main concern was the suggested implementation adding too much complexity 
to the language. When I searched for your namespaces proposal in Google (using 
"objective c namespaces") I found it telling that this link was the #5 result:

http://inessential.com/2012/04/04/kyles_objective-c_namespaces_proposal

Best,


__jayson

Circus Ponies NoteBook - Introducing An App That Boosts Your Productivity
at Work or School, So You Get The Grades, Raises and Promotions You Want.

www.circusponies.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Uli Kusterer]

On 07.08.2012, at 00:38, Graham Cox  wrote:

> 
> On 07/08/2012, at 2:38 AM, Kevin Perry  wrote:
> 
>> A stab in the dark: Have you tried running with OBJC_PRINT_REPLACED_METHODS 
>> set? There's a small chance that you have code in your app or a library that 
>> you're linking that replaces via category a method implementation internal 
>> to AppKit that +underPageBackgroundColor relies on.
> 
> 
> Bingo! You nailed it
> 
> I have a category on NSColor that defines all the "named" SVG colours, and 
> there's one called 'linenColor'. In 10.8, there appears to be a private 
> method called +linenColor which is invoked by +underPageBackgroundColor, so 
> it calls my SVG method and I get my sRGB "chino" colour. Removing that method 
> it now works as expected.
> 
> Thanks!
> 
> I just need to figure a safer way to add my SVG named methods They aren't 
> really used for supporting SVG because mostly SVG colours are looked up by 
> parsing the name and using that to do a key-value lookup in a table.


Prefix/suffix them with gc_ / _gc ? Alternately, just define them in a .plist 
and build your table from that, then you don't need to implement named NSColor 
methods for them at all.

Cheers,
-- Uli Kusterer
http://stacksmith.org





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Kyle Sluder]

On Aug 7, 2012, at 9:09 AM, Mike Abdullah  wrote:

> 
> On 7 Aug 2012, at 15:31, Sean McBride  wrote:
> 
>> 
>> Aren't Apple-private methods supposed to start with underscore, to avoid 
>> exactly this problem?
> 
> Yes, and devs are also supposed to prefix their own methods to avoid exactly 
> this problem.

And if your prefix clashes with the hidden one that Apple or another framework 
vendor chose, you're *still* SOL.

Nope, we totally don't need namespaces at all. /sarcasm

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Mike Abdullah]

On 7 Aug 2012, at 15:31, Sean McBride  wrote:

> On Tue, 7 Aug 2012 08:38:12 +1000, Graham Cox said:
> 
>> I have a category on NSColor that defines all the "named" SVG colours,
>> and there's one called 'linenColor'. In 10.8, there appears to be a
>> private method called +linenColor which is invoked by
>> +underPageBackgroundColor, so it calls my SVG method and I get my sRGB
>> "chino" colour. Removing that method it now works as expected.
> 
> Aren't Apple-private methods supposed to start with underscore, to avoid 
> exactly this problem?

Yes, and devs are also supposed to prefix their own methods to avoid exactly 
this problem.
> 
> Also, it sure would be nice for us 3rd party devs to be able to have 
> OBJC_PRINT_REPLACED_METHODS 'on' all the time, but it's noisy, complaining 
> about various Apple methods that replace each other. 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Sean McBride]

On Tue, 7 Aug 2012 08:38:12 +1000, Graham Cox said:

>I have a category on NSColor that defines all the "named" SVG colours,
>and there's one called 'linenColor'. In 10.8, there appears to be a
>private method called +linenColor which is invoked by
>+underPageBackgroundColor, so it calls my SVG method and I get my sRGB
>"chino" colour. Removing that method it now works as expected.

Aren't Apple-private methods supposed to start with underscore, to avoid 
exactly this problem?

Also, it sure would be nice for us 3rd party devs to be able to have 
OBJC_PRINT_REPLACED_METHODS 'on' all the time, but it's noisy, complaining 
about various Apple methods that replace each other. 


-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Graham Cox]

On 07/08/2012, at 9:12 AM, Lee Ann Rucker  wrote:

> You could use an NSColorList, or take a cue from NSImage and have an [NSColor 
> colorNamed:]


I have both of these; the 'named' methods are really just an additional 
convenience. I'm not actually making use of them at present, so I've just added 
a conditional compilation flag around them for now.

--Graham


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Lee Ann Rucker]

On Aug 6, 2012, at 3:38 PM, Graham Cox wrote:

> 
> On 07/08/2012, at 2:38 AM, Kevin Perry  wrote:
> 
>> A stab in the dark: Have you tried running with OBJC_PRINT_REPLACED_METHODS 
>> set? There's a small chance that you have code in your app or a library that 
>> you're linking that replaces via category a method implementation internal 
>> to AppKit that +underPageBackgroundColor relies on.
> 
> 
> Bingo! You nailed it
> 
> I have a category on NSColor that defines all the "named" SVG colours, and 
> there's one called 'linenColor'. In 10.8, there appears to be a private 
> method called +linenColor which is invoked by +underPageBackgroundColor, so 
> it calls my SVG method and I get my sRGB "chino" colour. Removing that method 
> it now works as expected.
> 
> Thanks!
> 
> I just need to figure a safer way to add my SVG named methods They aren't 
> really used for supporting SVG because mostly SVG colours are looked up by 
> parsing the name and using that to do a key-value lookup in a table.

You could use an NSColorList, or take a cue from NSImage and have an [NSColor 
colorNamed:]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Graham Cox]

On 07/08/2012, at 2:38 AM, Kevin Perry  wrote:

> A stab in the dark: Have you tried running with OBJC_PRINT_REPLACED_METHODS 
> set? There's a small chance that you have code in your app or a library that 
> you're linking that replaces via category a method implementation internal to 
> AppKit that +underPageBackgroundColor relies on.


Bingo! You nailed it

I have a category on NSColor that defines all the "named" SVG colours, and 
there's one called 'linenColor'. In 10.8, there appears to be a private method 
called +linenColor which is invoked by +underPageBackgroundColor, so it calls 
my SVG method and I get my sRGB "chino" colour. Removing that method it now 
works as expected.

Thanks!

I just need to figure a safer way to add my SVG named methods They aren't 
really used for supporting SVG because mostly SVG colours are looked up by 
parsing the name and using that to do a key-value lookup in a table.

--Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Kevin Perry]

A stab in the dark: Have you tried running with OBJC_PRINT_REPLACED_METHODS 
set? There's a small chance that you have code in your app or a library that 
you're linking that replaces via category a method implementation internal to 
AppKit that +underPageBackgroundColor relies on.

Also, it might be interesting to turn on MallocStackLoggingNoCompact and 
finding out the backtrace of the creation of that NSColor object.

-KP

On Aug 5, 2012, at 11:06 PM, Graham Cox  wrote:

> I've tried just drawing this colour to a plain view, and I get no texture, 
> just a pale "chino" sort of colour. Looking at what I get from this method in 
> the debugger:
> 
> (NSColor *) $1 = 0x00010983f850 NSCustomColorSpace sRGB IEC61966-2.1 
> colorspace 0.980392 0.941176 0.901961 1
> 
> 
> This seems to be the colour I'm seeing. I would not really expect it to be in 
> the sRGB colorspace, but the real giveaway is this - if I ask this colour for 
> its -patternImage, it throws an exception, just as the documentation says it 
> will IF IT HAS NO PATTERN IMAGE. Something's gone wrong delivering this 
> colour to my app from the internals of Cocoa. But what?
> 
> 
> 2012-08-06 16:02:17.068 Artboard[22765:303] *** -patternImage not valid for 
> the NSColor NSCustomColorSpace sRGB IEC61966-2.1 colorspace 0.980392 0.941176 
> 0.901961 1; need to first convert colorspace.
> 2012-08-06 16:02:17.071 Artboard[22765:303] (
>   0   CoreFoundation  0x7fff882e9716 
> __exceptionPreprocess + 198
>   1   libobjc.A.dylib 0x7fff8bfb5470 
> objc_exception_throw + 43
>   2   CoreFoundation  0x7fff882e94ec 
> +[NSException raise:format:] + 204
>   3   AppKit  0x7fff81b09948 -[NSColor 
> patternImage] + 66
> 
> 
> My code:
> 
>   NSColor* bkg = [NSColor underPageBackgroundColor];
>   NSImage* patImg = [bkg patternImage];
> 
> 
> 
> --Graham
> 
> 
> 
> 
> 
> 
> 
> On 04/08/2012, at 6:51 PM, Marcus Karlsson  wrote:
> 
> 
>> I'm getting the pattern when I use it with -setBackgroundColor: on a
>> scrollview. What do you get if you try it on an empty scrollview,
>> perhaps in a new project just in case there's something else that
>> prevents it from drawing?
>> 
>> Marcus
>> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
> 
> This email sent to kpe...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Graham Cox]

I've tried just drawing this colour to a plain view, and I get no texture, just 
a pale "chino" sort of colour. Looking at what I get from this method in the 
debugger:

(NSColor *) $1 = 0x00010983f850 NSCustomColorSpace sRGB IEC61966-2.1 
colorspace 0.980392 0.941176 0.901961 1


This seems to be the colour I'm seeing. I would not really expect it to be in 
the sRGB colorspace, but the real giveaway is this - if I ask this colour for 
its -patternImage, it throws an exception, just as the documentation says it 
will IF IT HAS NO PATTERN IMAGE. Something's gone wrong delivering this colour 
to my app from the internals of Cocoa. But what?


2012-08-06 16:02:17.068 Artboard[22765:303] *** -patternImage not valid for the 
NSColor NSCustomColorSpace sRGB IEC61966-2.1 colorspace 0.980392 0.941176 
0.901961 1; need to first convert colorspace.
2012-08-06 16:02:17.071 Artboard[22765:303] (
0   CoreFoundation  0x7fff882e9716 
__exceptionPreprocess + 198
1   libobjc.A.dylib 0x7fff8bfb5470 
objc_exception_throw + 43
2   CoreFoundation  0x7fff882e94ec 
+[NSException raise:format:] + 204
3   AppKit  0x7fff81b09948 -[NSColor 
patternImage] + 66


My code:

NSColor* bkg = [NSColor underPageBackgroundColor];
NSImage* patImg = [bkg patternImage];



--Graham







On 04/08/2012, at 6:51 PM, Marcus Karlsson  wrote:


> I'm getting the pattern when I use it with -setBackgroundColor: on a
> scrollview. What do you get if you try it on an empty scrollview,
> perhaps in a new project just in case there's something else that
> prevents it from drawing?
> 
> Marcus
> 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Marcus Karlsson]

On Sat, Aug 04, 2012 at 08:48:20AM +1000, Graham Cox wrote:
> 
> On 04/08/2012, at 6:55 AM, "Gary L. Wade"  
> wrote:
> 
> > That "color" is actually a pattern. What are you doing that gives you the 
> > unexpected result?
> 
> I'm expecting it to be a pattern, with a fairly obvious linen texture.
> 
> I get the colour and i use it to -setBackgroundColor: on my scrollview (which 
> has a custom clip view so that the "page" is centered when it becomes smaller 
> than the visible rect, so revealing the background).
> 
> If I create a colour directly from a texture image, it works fine, but using 
> this, I get a pale cream colour with no apparent texture.

I'm getting the pattern when I use it with -setBackgroundColor: on a
scrollview. What do you get if you try it on an empty scrollview,
perhaps in a new project just in case there's something else that
prevents it from drawing?

Marcus



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Graham Cox]

On 04/08/2012, at 6:55 AM, "Gary L. Wade"  wrote:

> That "color" is actually a pattern. What are you doing that gives you the 
> unexpected result?

I'm expecting it to be a pattern, with a fairly obvious linen texture.

I get the colour and i use it to -setBackgroundColor: on my scrollview (which 
has a custom clip view so that the "page" is centered when it becomes smaller 
than the visible rect, so revealing the background).


If I create a colour directly from a texture image, it works fine, but using 
this, I get a pale cream colour with no apparent texture.


--Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Sean McBride]

On Fri, 3 Aug 2012 23:00:26 +1000, Graham Cox said:

>ML introduces +[NSColor underPageBackgroundColor];
>
>I had thought this was to be the grey linen texture as used in Mail, etc
>but instead I'm getting a sort of flat pale cream colour. Is that right?

I think it's supposed to be the colour related to NSPageController:



-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Gary L. Wade]

That "color" is actually a pattern. What are you doing that gives you the 
unexpected result?
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

On Aug 3, 2012, at 1:14 PM, Marcus Karlsson  wrote:

> 
> On Aug 3, 2012, at 3:00 PM, Graham Cox  wrote:
> 
>> Hi all,
>> 
>> ML introduces +[NSColor underPageBackgroundColor];
>> 
>> I had thought this was to be the grey linen texture as used in Mail, etc but 
>> instead I'm getting a sort of flat pale cream colour. Is that right?
>> 
>> 
>> --Graham
> 
> Hello.
> 
> I don't know if that's correct but I had to take a screenshot and look 
> closely at them side by side just to compare them. I can't see any noticeable 
> difference between the background in Mail and a custom view filled with that 
> color.
> 
> Marcus

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: +underPageBackgroundColor

[Marcus Karlsson]

On Aug 3, 2012, at 3:00 PM, Graham Cox  wrote:

> Hi all,
> 
> ML introduces +[NSColor underPageBackgroundColor];
> 
> I had thought this was to be the grey linen texture as used in Mail, etc but 
> instead I'm getting a sort of flat pale cream colour. Is that right?
> 
> 
> --Graham

Hello.

I don't know if that's correct but I had to take a screenshot and look closely 
at them side by side just to compare them. I can't see any noticeable 
difference between the background in Mail and a custom view filled with that 
color.

Marcus



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com