On Dec 10, 2014, at 3:48 PM, Ken Thomases k...@codeweavers.com wrote:
By the way, why is it important to understand why the behavior has changed?
It has always been the case that that notification could come at any time, so
your code has to cope in any case.
When my application
2014-12-10 21:00 GMT+01:00 cocoa-dev-requ...@lists.apple.com:
In the meantime, I compared all the code of my previous version against the
code of the new version, looking for changes that might cause this difference
in behavior. The only really big change is that my new version makes use of
Thanks for the reply!
You are right that `splitView:additionalEffectiveRectOfDividerAtIndex:`
looks better. I tried id but it still exhibits the said behavior.
But I noticed that the grab area is indeed wider than 1px (perhaps it is
even 5px!) but the mouse cursor does not turn into
On Dec 11, 2014, at 4:40 AM, Stephane Madrau steph...@madrau.com wrote:
Just my two cents : if NSVisualEffectView is one of the APIs that
triggers a GPU change, then you're likely to get a monitor changed
notification when the application starts, since GPU changes will be
handled on the OS
On Dec 11, 2014, at 3:31 AM, Bill Cheeseman wjcheese...@gmail.com wrote:
On Dec 10, 2014, at 3:48 PM, Ken Thomases k...@codeweavers.com wrote:
By the way, why is it important to understand why the behavior has changed?
It has always been the case that that notification could come at any
On Dec 11, 2014, at 6:53 AM, Ken Thomases k...@codeweavers.com wrote:
This was never a good strategy. That notification does not necessarily only
occur when the user changes screen resolution or rearranges the displays. As
I mentioned, it happens when the Dock changes size or if the
2014-12-11 14:32 GMT+01:00 cocoa-dev-requ...@lists.apple.com:
That's an interesting suggestion.
(...) I don't see anything specifically about GPU switches, but there are
plenty of functions that can reconfigure a display using the window server. I
can imagine some of them might be used
On Dec 11, 2014, at 8:51 AM, Stephane Madrau steph...@madrau.com wrote:
To exclude the fact it could be linked to a GPU switch or not, you can
try following
- use the gfxCardStatus tool to verify if your app effectively changes
the GPU when it starts
- force a GPU switch before launching
Rick C. rickcort...@gmail.com wrote:
I write an NSString and NSData object to my app’s .plist and of course read it
back when needed and this works fine 99% of the time. On occasion a user
reports some trouble to me and I ask for the .plist and find out that this
NSString/NSData object is
On Dec 11, 2014, at 8:51 AM, Stephane Madrau steph...@madrau.com wrote:
To exclude the fact it could be linked to a GPU switch or not, you can
try following
- use the gfxCardStatus tool to verify if your app effectively changes
the GPU when it starts
- force a GPU switch before launching
On Dec 10, 2014, at 11:05 PM, Rick C. rickcort...@gmail.com wrote:
Hi,
Digging deeper I find that most often the user has their home folder on a
different drive (external?) than the actual app. What would be the solution
to make sure these objects are written properly in this case?
On Dec 10, 2014, at 11:05 PM, Rick C. rickcort...@gmail.com wrote:
I write an NSString and NSData object to my app’s .plist and of course read
it back when needed and this works fine 99% of the time. On occasion a user
reports some trouble to me and I ask for the .plist and find out that
On Dec 11, 2014, at 02:56 , ecir hana ecir.h...@gmail.com wrote:
Btw., when I don't do `setDocumentView` for the textviews, the cursor shows
up as expected.
Why is this happening? Is it possible to have the resizing cursor over the
whole divider frame?
My guess is that there’s something
Thanks for the reply again! The problem is I now tried to only copy-paste
from the Apple docs and Cocoa with Love and I still get the said behavior.
That is, when I move the mouse cursor slowly across the divider it changes
back to text selection cursor right after leaving the splitting line. In
So I found some old code where I was using NSAppleScript with defaults write
ouch! :-) Sorry about that but curious why would this fail at times? Pretty
sure that switching it to the proper NSUserDefaults will work fine…
On Dec 11, 2014, at 10:24 PM, gweston gwes...@mac.com wrote:
Rick
I was trying to make a simple 2D array of this struct:
struct Color {
var r : Float = 0
var g : Float = 0
var b : Float = 0
}
As I was reading up on arrays in Swift, I came across this example
initialization:
var threeDoubles = [Double](count: 3, repeatedValue: 0.0)
And there was
On Dec 11, 2014, at 3:24 PM, Daniel Blakemore dblakem...@pixio.com wrote:
If I do this, however, it breaks:
var arr2 = [Array](count:6, repeatedValue:[Color](count:8, repeatedValue:
Color()))
[Array] is syntactic sugar for ArrayArray. It is not a complete type.
It is an array of arrays of
Sweet! That does totally work.
Why did it compile if it's an incomplete type? Shouldn't that be something
that you catch at compile time in a type-safe language?
I'm always hesitant about type inference in Swift because you have a 50-50
chance of the compiler not understanding at all and
Why did it compile if it's an incomplete type? Shouldn't that be something
that you catch at compile time in a type-safe language?
Don't know. It failed on my machine. I copied/pasted your code to a
playground and got a red exclamation point due to a fault. Then I looked
closer at the
It's not that I don't trust that it works, I don't trust that what I try
will work. It's like in those long hours of debugging some
non-deterministic, impossible-to-find error where you start to doubt things
like the order of operations so you add more parens just to be sure.
And I indicated it
Hi all,
I get the following message in Xcode 6.1.1, iOS 8 when I tap a text field with
keyboard specified as NumberPad in a xib:
Can't find keyplane that supports type 4 for keyboard
iPhone-Portrait-NumberPad; using 3876877096_Portrait_iPhone-Simple-Pad_Default”
No such message if I specify a
21 matches
Mail list logo
