Re: iPad keyboards
On Thu, Dec 12, 2013 at 3:08 PM, Rick Mann wrote: > > That's good to know; I thought they were requiring iOS 7. > > https://developer.apple.com/news/index.php?id=12172013a#top > Even so, does an iOS 6 SDK-based app not get all iOS 7 styling? I'd try > the experiment myself, but it's a bit of work to install Xc 4.6.3. > http://stackoverflow.com/questions/18423896/is-it-possible-to-install-ios-6-sdk-on-xcode-5 http://stackoverflow.com/questions/11424920/how-to-point-xcode-to-my-10-6-sdk-so-it-can-be-used-as-a-base-sdk/11424966 Good times ;) -Luther ___ 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
UILabel HTML to attributed string conversion: odd font choice for text
I have formatted text delivered to the app as HTML that I am converting to a
NSAttributedString and then assigning to a UILabel like this:
NSDictionary* options =
@{
NSCharacterEncodingDocumentAttribute: @(NSUTF8StringEncoding),
NSDefaultAttributesDocumentAttribute:
@{
NSFontAttributeName:label.font,
NSForegroundColorAttributeName: label.textColor,
NSStrikethroughStyleAttributeName: @1,
NSUnderlineStyleAttributeName:
@(NSUnderlineStyleSingle)
},
NSDocumentTypeDocumentAttribute: NSHTMLTextDocumentType
};
attributedString = [[NSAttributedString alloc] initWithData:data
options:options documentAttributes:NULL error:&error];
label.attributedText = attributedString;
The UILabel has its font set to Avenir Next Medium, which the code above uses
as the base font for the attributed string. The HTML is of the form:
Blah blah blah blah blah blah blah blah blah
What I'm seeing visually is that the normal paragraph text is fine but that the
text inside the tag is nearly unreadable. I added code to dump out the
attribute runs and found that the starting paragraph text is what's expected:
NSFont = " font-family: \"AvenirNext-Medium\";
font-weight: normal; font-style: normal; font-size: 16.00pt";
but that the text inside the tag uses Avenir Next UltraLight Italic:
NSFont = " font-family: \"AvenirNext-UltraLightItalic\";
font-weight: normal; font-style: italic; font-size: 16.00pt";
This seems odd to me since there's a perfectly fine Avenir Next Medium Italic
available. Is this an expected font choice for italic text given the setup
above and, more importantly, is there a way for me to end up with an attributed
string that's using the italic version of the base font short of manually
walking each of the attribute runs and "correcting" the font?
Thanks,
Steve
___
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: UILabel HTML to attributed string conversion: odd font choice for text
On Dec 17, 2013, at 1:04 PM, Jens Alfke wrote: > On Dec 17, 2013, at 10:44 AM, Steve Christensen wrote: > >> This seems odd to me since there's a perfectly fine Avenir Next Medium >> Italic available. Is this an expected font choice for italic text given the >> setup above > > That seems wrong to me too. > > I just experimented in TextEdit on OS X 10.9 — created some text in Avenir > Next Medium, then italicized one word. It came out Avenir Next Italic (not > Medium Italic), which is slightly wrong (too light) but not as wrong as what > you got on iOS. > > My best guess is that the metadata in the fonts themselves is wrong: maybe > Medium Italic doesn’t have the same weight value as Medium. I just specifically set up an run to use Avenir Next Medium Italic and I can't see any difference in font weight, so if it's something like that then the algorithm that makes that determination is pickier about it than I. >> and, more importantly, is there a way for me to end up with an attributed >> string that's using the italic version of the base font short of manually >> walking each of the attribute runs and "correcting" the font? > > You could try creating some CSS to define a custom font/style mapping, then > insert that into the HTML… I'm doing this same sort of thing in several locations within the app which would mean providing CSS for each as a workaround. Not the most elegant solution but for now I have ended up post-processing the attributed string, replacing the font in italicized runs with an italicized version of the base font. If someone else can provide further enlightenment into something I've done wrong and how to fix it then I can rip out this bit but for now this will do. Thanks, Jens. - Steve ___ 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: UILabel HTML to attributed string conversion: odd font choice for text
On Dec 17, 2013, at 10:44 AM, Steve Christensen wrote: > This seems odd to me since there's a perfectly fine Avenir Next Medium Italic > available. Is this an expected font choice for italic text given the setup > above That seems wrong to me too. I just experimented in TextEdit on OS X 10.9 — created some text in Avenir Next Medium, then italicized one word. It came out Avenir Next Italic (not Medium Italic), which is slightly wrong (too light) but not as wrong as what you got on iOS. My best guess is that the metadata in the fonts themselves is wrong: maybe Medium Italic doesn’t have the same weight value as Medium. > and, more importantly, is there a way for me to end up with an attributed > string that's using the italic version of the base font short of manually > walking each of the attribute runs and "correcting" the font? You could try creating some CSS to define a custom font/style mapping, then insert that into the HTML… —Jens ___ 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: Best solution for game loop on OSX?
On 12/17/13, Uli Kusterer wrote: > On 17 Dec 2013, at 00:15, Dan Treiman wrote: >> The two best solutions (and by best I mean least time-wasting) are >> CVDisplayLink and NSTimer. >> >> CVDisplayLink synchronizes with the display refresh rate and gives you >> callbacks in a background thread. This somewhat like CADisplayLink on >> iOS. Its pretty easy to do but your code must be thread-aware. >> >> NSTimer has more than enough resolution for games, and if you are using >> OpenGL for graphics you should do: (…) > > He’s talking about OpenAL, not OpenGL. Audio, not graphics. So I don’t > think the display links are a good choice here. They’re intended to avoid > tearing when doing screen display, and depending on your screen and power > saver settings may not get called as often as you’d want for sound. So I'll put in my 2 cents since OpenAL is something I have a lot of expertise in. NSTimer generally works pretty well (and I was under the impression that 10.9 timers are even more accurate now). Even though the firing rate can be inconsistent, I don't think you need a lot of precision for spatial audio. I've never been exposed to an audio system and been in a situation where I could discern the difference between audio points only a tiny distance away from each other. The problem I've had with CVDisplayLink in the past is when the window/view disappears for certain reasons (I can't remember...was it user minimizing, or what), the display link callbacks automatically turn off. This is fine for graphics, but sucks if you are trying to keep track of time elapsed or want to continue playing background music. (I haven't experienced this problem with CADisplayLink on iOS.) Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ 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
AutoLayout constraint priorities
I have a fairly deep NSView hierarchy which fails to satisfy its vertical constraints. The embedded views are generally just embedded within their containers. To me it seems that the constraints should be viable. However this is not the case and I have to reduce a bottom constraint from a priority of 1000 to 999. The layout looks identical both before and after the priority is lowered. Are there situations in complex hierarchies where errors accumulate while solving the constraints and a lower priority constraint simply becomes a practical necessity? 2013-12-17 15:14:39.040 BrightPay[20716:303] Unable to simultaneously satisfy constraints: ( "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "" ) Will attempt to recover by breaking constraint Regards Jonathan Mitchell Mugginsoft LLP jonat...@mugginsoft.com - KosmicTask - the Integrated Scripting Environment for OS X. http://www.mugginsoft.com/KosmicTask - Follow on Twitter @KosmicTask - Objective-C and OS X contract work undertaken http://www.linkedin.com/in/mugginsoft - Github http://github.com/mugginsoft ___ 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: Best solution for game loop on OSX?
On 17 Dec 2013, at 00:15, Dan Treiman wrote: > The two best solutions (and by best I mean least time-wasting) are > CVDisplayLink and NSTimer. > > CVDisplayLink synchronizes with the display refresh rate and gives you > callbacks in a background thread. This somewhat like CADisplayLink on iOS. > Its pretty easy to do but your code must be thread-aware. > > NSTimer has more than enough resolution for games, and if you are using > OpenGL for graphics you should do: (…) He’s talking about OpenAL, not OpenGL. Audio, not graphics. So I don’t think the display links are a good choice here. They’re intended to avoid tearing when doing screen display, and depending on your screen and power saver settings may not get called as often as you’d want for sound. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
NSDistributedNotificationCenter Strangeness
My apologies if this question has appeared once already - I'm resending it
because I fear it may have been lost during the Cocoa Dev List outage.
Here's a little oddity that might either be me being foolish (again) or relate
to an open Radar. I'm inclined to the former because (according to my search
of this list, to see if anyone else was having the same problem) the Radar was
opened in 2011 - which should be enough time to squish the bug!
I'm trying to use NSDistributedNotificationCenter to communicate between two
apps. The app posting the notification does it as follows:
NSDistributedNotificationCenter *centre = [NSDistributedNotificationCenter
defaultCenter];
NSDictionary *dict = [NSDictionary dictionaryWithObject:[NSNumber
numberWithBool:openDialogue] forKey:@"ShowMenuBar"];
[centre postNotificationName:@"SetMenubar" object:nil userInfo:dict];
NSLog(@"Posted Toggle Menu bar item");
And the app observing the notification has the observer set up in
applicationDidFinishLaunching, thus:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSDistributedNotificationCenter *centre = [NSDistributedNotificationCenter
defaultCenter];
[centre addObserver:self selector:@selector(setMenubar:)
name:@"SetMenubar"
object:nil];
setMenubar is as follows (just for completeness)
-(void)setMenubar:(NSNotification *) aNote
{
NSLog(@"Received Notification, setting menubar");
[self displayMenu:[[aNote.userInfo objectForKey:@"ShowMenuBar"]boolValue]];
}
When I flip the toggle, I see 'Posted Toggle Menu bar item' in Console, but
'Received Notification, setting menubar' doesn't reliably show. In fact, there
is a way of getting it to notice the notification. I can click somewhere in
the UI of the receiving app - but that rather defeats the purpose of using
NSDistributedNotificationCenter.
So, my questions are these:
Is this an existing problem and, if it is, does anyone know of a good
workaround?
Am I doing this right? Should I be building some kind of event loop and
polling to see if a Notification has been posted? I guess not - it'd be rather
wasteful!
Is applicationDidFinishLaunching the right place for this?
Any help that you can offer will be very gratefully received.
___
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: _NSWarnForDrawingImageWithNoCurrentContext
I have found that if I use
[mImage setCacheMode:NSImageCacheNever];
The trouble never occurs. It occurs when I use
[mImage setCacheMode:NSImageCacheAlways];
I don¹t know whether that¹s a Cocoa¹s bug.
Do you think I have to file a bug to Apple?
Regards
-- Leonardo
Da: "Stephen J. Butler"
Data: Mon, 16 Dec 2013 17:57:30 -0600
A: Leonardo
Cc: Cocoa Development
Oggetto: Re: _NSWarnForDrawingImageWithNoCurrentContext
Did you try the suggestion the warning listed? Breaking on "void
_NSWarnForDrawingImageWithNoCurrentContext()"? Because a stack trace for
when the error occurs would be helpful.
On Sat, Dec 14, 2013 at 6:32 AM, Leonardo wrote:
> Hi, when I rotate my NSView, my image disappears for a second from the
> screen and I get this error message
>
> It does not make sense to draw an image when [NSGraphicsContext
> currentContext] is nil. This is a programming error. Break on void
> _NSWarnForDrawingImageWithNoCurrentContext() to debug. This will be logged
> only once. This may break in the future.
>
> So I have put a symbolic breakpoint there and I have found the line causing
> the error, which is in NSView's drawRect method:
>
> [mImage drawInRect:inRect fromRect:fillRect operation:NSCompositeSourceOver
> fraction:mOpacity];
>
> When the image disappears, I can quite see a white rectangle coming from my
> line
>
> NSRectFillUsingOperation(myBounds, NSCompositeSourceOver);
>
> So I'm sure myBounds rect is ok. To tune up my test I made sure that mImage
> is never nil and has positive size, iRect and fillRect have always positive
> size too and they never change, mOpacity is always 1.0 and the current
> context is always not nil. As my log says:
>
> imageSize 1251 x 705, inRect {{0, 0}, {300, 200}}, fillRect {{97, 0}, {1057,
> 705}}, mOpacity 1.0, frameCenterRotation 2.647995, current context is not
> nil
>
> The error occurs when I rotate the view with frameCenterRotation, but not at
> any degree.
>
> - (void)setMAngle:(CGFloat)value
> {
> mAngle = value;
> [self setFrameCenterRotation:mAngle];
> [self setNeedsDisplay:YES];
> }
>
> For example, if I still rotate the NSView to frameCenterRotation 4.689613 I
> can quite see the image and I don't get the error.
> Furthermore, if I replace mOpacity with a fixed value 1.0 in the code
>
> [mImage drawInRect:inRect fromRect:fillRect operation:NSCompositeSourceOver
> fraction:1.0];
>
> the error NEVER occurs. However even using the CGFload variable mOpacity
> always = 1.0, the problem sometimes occurs when I rotate the view.
> Just to be sure I have even overrided the isOpaque method returning NO. Same
> trouble.
> I'm really puzzled. Any idea?
>
>
> Regards
> -- Leonardo
>
>
> ___
>
> 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/stephen.butler%40gmail.com
>
> This email sent to stephen.but...@gmail.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: Best solution for game loop on OSX?
On 13 Dec 2013, at 10:57 pm, Alex Hall wrote: > To do so smoothly, though, will require a loop, so I can update the position > in small increments many times per second. You probably know this, but it’s a point worth repeating. Whatever method you use to make the game loop, don’t fall into the trap of assuming that each callback is equivalent to seconds. Instead, measure the elapsed time and derive your position(s) accordingly. In other words, suppose you want to move an object from position p1 to position p2 over a period of, say, 1 second. You might assume a framerate of 30fps and therefore divide p2-p1 into thirty equal increments and add that increment at each frame. DO NOT DO THAT! If your timer is held up for any reason, your animation slows down. Instead, calculate the elapsed time at each frame and derive the true position from it. That way, if the timer is held up, your framerate drops but the positions of everything remains correct. Seems obvious but I’ve seen many developers fall into this trap, especially if it’s their first game. —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
