On 15. Apr 2021, at 21:29, Flavio Donadio via Cocoa-dev
wrote:
> Documents that an application generates and that are meant to be directly
> manipulated by multiple users of the same machine should be stored in
> "/Users/Shared”. It’s the only folder in the whole system that is available
> to
On 2. Sep 2020, at 02:40, Carl Hoefs via Cocoa-dev
wrote:
> I've tried setting UIImageView.image=nil, UIImageView.animationImages=nil,
> toggling UIImageView.hidden, wiping the sandbox, etc., but no joy. Of course,
> restarting the app does force-flush the cache, but that's a no-go.
>
> The
Yeah, the isTemplate definitely shouldn't be set, that would cause that issue,
I'd have expected setting that to false to fix your issue.
I also think there was a feature where NSImage would automatically set the
template flag when an image's name ended in "Template" or something like that.
My first instinct when someone says "not reproducible for me with a scroll
view" on Mac is: Maybe it only occurs with overlay scrollers, or only with
separate scrollers? Have you tried toggling that setting?
Also, are you calling setNeedsDisplay: or setNeedsDisplayInRect: anywhere?
That's
Wildly guessing here, but could be that NSLog uses different implementations
depending on how it was launched. It could be using os_log() under the hood,
which doesn't necessarily format all parameters right away, but rather just
sends them to the logging system, which then formats it?
Cheers,
> On 12. Aug 2019, at 05:26, Kurt Bigler via Cocoa-dev
> wrote:
>
> On 8/10/19 2:38:00 PM, Uli Kusterer wrote:
>>> On 10. Aug 2019, at 23:02, Kurt Bigler wrote:
>>> Currently if I call NSApplicationMain instead of my regular Carbon event
>>> loop (which is based on ReceiveNextEvent),
On 8/26/2019 2:49 AM, Turtle Creek Software via Cocoa-dev wrote:
> In the hybrid C++/Obj-C++ files, we use __bridge on all the casts of void
> pointers to Cocoa object > No use of NSBridgingRetain or Release at
all. Is that necessary
under ARC?
NSBridgingRetain() etc. are basically wrappers
On 8/26/2019 8:28 PM, Turtle Creek Software via Cocoa-dev wrote:
@property (weak) GSOutlineWindowController *mainWindowController;
self.mainWindowController = [[GSOutlineWindowController alloc]
initWithWindowNibName : @"GSOutlineWindowController"];
[self.mainWindowController showWindow :
On 8/24/2019 1:44 PM, Turtle Creek Software via Cocoa-dev wrote:
Our app delegate class is not deallocated. The window controller is
deallocated
despite the member reference there. If we keep the second strong reference
to the controller,
then the outline view is deallocated instead. Nothing
> On 10. Aug 2019, at 23:21, Rob Petrovec via Cocoa-dev
> wrote:
>
>> On Aug 10, 2019, at 3:12 PM, Kurt Bigler wrote:
>>
>> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
wrote:
The NSView subclasses involved are
> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev
> wrote:
>
>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev
>> wrote:
>>
>> The NSView subclasses involved are receiving drawRect: messages but are not
>> receiving mouseDown:.
> You need to implement NSView -hitTest:
> On 10. Aug 2019, at 23:02, Kurt Bigler wrote:
> Currently if I call NSApplicationMain instead of my regular Carbon event loop
> (which is based on ReceiveNextEvent), NSApplicationMain returns immediately.
> I don't call NSApplicationMain immedately because there is scads of
> initialization
On 10. Aug 2019, at 11:16, Uli Kusterer via Cocoa-dev
wrote:
> So this mixing is an ideal approach for slowly porting, but will not get you
> anything shippable until your UI is fully Carbon.
fully Cocoa. Sorry.
___
Cocoa-dev mailing list (Coc
> On 10. Aug 2019, at 08:24, Kurt Bigler via Cocoa-dev
> wrote:
> As part of a process of porting an app from Carbon to Cocoa I'm needing to
> have Carbon and Cocoa windows present at the same time. The Carbon event
> loop is therefore still in place.
The Cocoa event handling code uses
14 matches
Mail list logo
