Re: /Library/Application Support off limits?

[Uli Kusterer via Cocoa-dev]

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 all users.

That is actually wrong. It is dangerous to create world-writable files and 
share them between users. If you need to share data between users that is not 
fixed (e.g. it would make sense if Apple installed GarageBand loops in 
/Application Support, as they will be used by all users that launch Garage 
Band, but since Garage Band comes preinstalled you don't want all that disk 
space for the loops to be used, you want to download them later).

If you have databases shared by multiple users, you should use a Launch Agent 
plist that launches a server process, then have any instances of your app 
currently running (remember, there may be multiple instances running under Fast 
User Switching) talk to that process. That way, the process can also enforce 
valid file formats, making sure one user can not ruin things for another user 
by feeding invalid data or deleting their data.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Invalidating UIImageView's image cache

[Uli Kusterer via Cocoa-dev]

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 only way I've found to invalidate UIImageView's caching (without killing 
> the app) is to play games like generating unique filenames for each run of 
> the processing loop of the app. Apparently UIImageView tracks _filenames_ to 
> determine when to flush/update its cache!
> 
> So, if there actually exists a kosher way to do this, I welcome any/all hints!

I don't have a good answer, but I think this may be more that UIImage caches 
the images, not UIImageView. Maybe you can find something in UIImage's 
docs/headers?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Status bar item icon is always black

[Uli Kusterer via Cocoa-dev]

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. 
You might want to search for that unless you're really using an image named 
"AppIcon".

I'd also check if the asset catalog has any settings that sound like they make 
it a template and turn those off. Maybe something related to light/dark mode 
variants?

I just checked, and Flexibits' Fantastical still can use a colored icon, so 
there must be a way to make it work.

Is your status bar item a menu, or does it behave like a button? Fantastical 
does the latter, so maybe if you ask for a menu, you get some default "menu 
title" themeing?

> On 17. Jun 2020, at 20:17, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I am trying to define an icon for a very simple status bar menu item.
> My problem is that it appears always as black, or not at all, or grey-ish,
> depending on what I have tried, but not as intended.
> 
> I have populated the asset catalog with icon images of all the required sizes 
> that work fine in another , regular app. No luck.
> I have populated the asset catalog with just one icon that I downloaded from 
> here
>   
> https://koenig-media.raywenderlich.com/uploads/2015/03/statusbarbuttonim...@2x.png
> which is supposed to work.
> I still just get a black rectangle in the status bar.
> 
> (The status bar app works, btw.)
> 
> Ideally, I'd like my icon for my status bar app be in color.
> 
> Here is the code:
> 
>let statusBar = NSStatusBar.system
>statusBarItem_ = statusBar.statusItem( withLength: 
> NSStatusItem.squareLength )
> //statusBarItem_.button?.title = "AAL"
>let itemImage = NSImage(named: "AppIcon")
>itemImage?.isTemplate = true
>statusBarItem_.button?.image = itemImage
> 
> I have tried it with and without isTemplate = true.
> 
> 
> Could anyone please give me a hint what I can try?
> Thanks a lot in advance.
> 
> Best, G.
> 
> ___
> 
> 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Catalina scroll view issues

[Uli Kusterer via Cocoa-dev]

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 usually how you cause redraws.

If this is only while scrolling, are you perhaps doing things in drawRect: that 
you shouldn't? drawRect: should only draw when the OS calls it. Calling 
drawRect: directly is not supported. Changing state inside drawRect: or calling 
setNeedsDisplay: or moving or resizing views or windows is not supported in 
drawRect:. These things often work by accident though, so I've seem lots of 
code naïvely doing it.

Similarly, NSView etc. only work when used from the main thread, if you are 
calling methods on views from a secondary thread (like a Dispatch Queue, or a 
callback that isn't guaranteed to be on the main thread), it might work by 
accident, but it is unsupported and unsafe.

Finally, are you maybe forgetting to apply layout constraints to any of your 
views, or forgot to set its translatesAutoresizingMaskIntoConstraints properly 
somewhere? That could cause a view to have the wrong size and clip.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

> On 14. Dec 2019, at 15:16, Redler Eyal via Cocoa-dev 
>  wrote:
> 
> Hi All,
> 
> I'm getting reports from users complaining about a strange display issue on 
> Catalina with my app.
> My app is a word-processor (not based on the cocoa text system) whose main 
> display shows the pages of the document. Every page is a separate view and 
> all the pages are subviews of one big view which resides inside a scroll view.
> 
> The problem is that when with some documents, sometimes, when the user 
> scrolls down the document, some pages are not drawn or even partially drawn. 
> When the user clicks the place where the page is supposed to appear, it shows 
> up.
> Another interesting bit is seems that while the scroll view background is 
> drawn, the document views (the view containing the page views) drawRect is 
> not called or at least not taking effect, I can tell because the pages on 
> this view cast a shadow which is drawn by drawing blank squares on the 
> document view with a transparency layer.
> Last bit of info, copiesOnScroll set to NO for this view and I see that this 
> property is deprecated on Catalina.
> 
> So far I'm struggling with this for a couple of weeks, I wasn't able to 
> reproduce this at all on my machine.
> I'm really desperate for an answer and while I'm not expecting anyone here to 
> provide me with one (wouldn't object, of course :-)) I would love if people 
> reading this might try to speculate to the causes of this or perhaps if you 
> have any direction as to what to test on my users machines in order to be 
> able to reproduce this.
> 
> Thanks
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

___

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: NSLog displays inconsistent format for NSDate

[Uli Kusterer via Cocoa-dev]

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,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

> On 20. Aug 2019, at 21:50, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> When printing out an NSDate using NSLog from within Xcode I get:
> 
> "Tue Aug 20 12:32:40 2019"
> 
> When the same program is run from within a shell (bash) window:
> 
> "2019-08-20 19:32:48 +"
> 
> Is the NSDate output format somehow determined by the environment? My system 
> is set to Local Time Zone (America/Los_Angeles (PDT) offset -25200 
> (Daylight)).
> 
> A code snippet that reproduces the issue follows. 
> 
> -Carl

___

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: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> 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), NSApplicationMain returns 
>>> immediately.  I don't call NSApplicationMain immedately because there is 
>>> scads of initialization that I do without relation to incoming events.
>>  NSApplicationMain looks at your Info.plist to decide which Cocoa NIB to 
>> load at startup and what your NSPrincipalClass is (usually NSApplication). 
>> If you haven't set up your app as a proper Cocoa app, NSApplicationMain will 
>> be unhappy and won't work. Every time I've ported a Carbon app to Cocoa so 
>> far, I basically moved the main() function's contents (except the call to 
>> RunApplicationEventLoop()) into applicationDidFinishLaunching: etc. in an 
>> app delegate. Then it usually worked as before.
> 
> I've reconfigured the info.plist and the relevant code is now inside 
> applicationDidFinishLaunching as you suggested.  However the other area you 
> point out is probably a source of issues.
> 
> My Carbon code is now not getting many events.  It was not getting any events 
> until I arrange to call the Carbon event loop body (single event) from a 
> timer I put in the app delegate.  See the next bit.

 That sounds like it will cause problems. I may have mis-remembered, but one of 
the event loops is compatible with the others. So maybe what we did during our 
bring-up phase back then was just call RunApplicationEventLoop(). Not sure if 
we called it from main() or if calling it from applicationDidFinishLaunching 
worked. It's been too long since I ported a Carbon app to Cocoa.

 But single-dispatching events from a Timer means that half your events get 
processed by AppKit's -sendEvent:, and half by ReceiveNextEvent(). That can't 
go well.

>> In general, you want RunApplicationEventLoop() and timers, 
>> performSelector:afterDelay:0.0 or threads to get processing time reliably 
>> for other things during the event loop.
> 
> Yes, indeed.  I don't know how far I am from RunApplicationEventLoop(), nor 
> does it make sense offhand how I could both do that and use 
> NSApplicationMain, except for modal situations, or maybe dragging.
> 
> Thanks again for any reflections on all this!

Also one tip: You may have to call NSApplicationLoad() at some point, or create 
an NSImage to initialize certain subsystems of Cocoa in an otherwise Carbon app 
(i.e. when you're not letting NSApplicationMain run the event loop). I think 
the NSImage thing may have been for some window activation issue too (I know 
that sounds weird because NSImage and NSWindow don't seem related, I just 
remember being told that at WWDC once, and it helped us for ... something)

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Cocoa-dev Digest, Vol 16, Issue 72

[Uli Kusterer via Cocoa-dev]

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 around the requisite
bridge casts. And yes, in fact they are *only* necessary under ARC (in
MRC you just use retain/release).

When taking a pointer managed by ARC, you *have* to explicitly retain it
if you want to be able to safely pass it elsewhere beyond the lifetime
of whatever ObjC variable it is in. if you don't do that, ARC will think
the pointer is no longer used and will free it, leaving your C++ classes
with dangling pointers. I strongly recommend reading up on those, and in
particular when to use which of the several casts. In general, you can't
just use the Fix It's suggestion as it doesn't know whether an object
needs to be retained or not.

> The void pointers are mostly to text fields and controls, plus the app
> delegate
> and one view.  None of those have had lifetime problems.  We mostly just
> access them and have them do one thing.
>
> No void pointers to the window controller that is dying, nor its window.

By the way, I usually use forward declarations like

#if __OBJC__
@class NSButton;
#else
struct NSButton;
#endif

or the like. Structs name-mangle the same in C++ as the equivalent ObjC
classes, but are recognized by a C++ compiler. Then I create an ObjC++
class whose member variables use that ObjC type, and only have ObjC in
the implementation file.

Gives you the type-safety you're used to, and readable code, but
prevents ObjC++ from leaking into pure C++ code.

I've mostly been doing Swift the past year, but I vaguely remember that
ARC (but maybe only on iOS) does not retain certain objects that MRC
used to. In particular IBOutlets. So unless you declare them as strong,
they don't actually retain. Have you checked that you're not coding
against pre-ARC retain/release rules?

It could be that your object is not strongly referenced and therefore
immediately released.

Cheers,
-- Uli Kusterer
http://www.zathras.de
"The Witnesses of TeachText are everywhere..."
___

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: ARC

[Uli Kusterer via Cocoa-dev]

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 : self];

Sadly, nothing changes after the syntax changes.  @property (strong) also
fails.


A better way to investigate such issue is using the memory debugging

tools in Instrument IMHO.

That would let you see all stack traces of retain/release calls.


We tried that last week.  The problem with ARC debugging is that
breakpoints in dealloc()
happen long after the release.  You know it died, but not when or how.
Sometimes we turn off ARC for one class with compiler directives, then
breakpoint on release.

Have you tried turning on NSZombie etc.? There are a bunch of neat debug
helpers in your Build Scheme's settings.

I think there's also a function objc_retain() or something like that,
which is a *function* in the ObjC runtime that serves as the central
bottleneck. You may have more luck breaking on that.

Cheers,
-- Uli Kusterer
http://www.zathras.de
"The Witnesses of TeachText are everywhere..."
___

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: ARC

[Uli Kusterer via Cocoa-dev]

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 references the view
except being in the .xib file for the window controller.


 That doesn't seem possible. You must be doing something else that
breaks things. A strong reference is a strong reference, an object
doesn't get deallocated if it's still held. Either you have files where
ARC is still turned of (via the -fno-arc option or whatever it is
called) and are assuming it isn't, or it is an unowned
(unsafe-unretained? Whatever it was called in ObjC) or weak reference.

 You also mention you're using C++. If you are passing pointers through
C or C++ code (as void* for instance), then you might be doing something
wrong there. Make sure you're properly using NSBridgingRetain() etc. (or
the equivalent typecasts) and not mixing them up. That could cause ARC
to think it owns another reference to an object and release it again.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
___

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: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> 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 receiving drawRect: messages but are 
>>>> not receiving mouseDown:.
>> 
>>> You need to implement NSView -hitTest: to get mouseDown events.
>> 
>> I have 5 working Cocoa apps, and none implement hitTest.  It is apparently 
>> needed for special circumstances, per the docs "to have a view object hide 
>> mouse-down events from its subviews”.
>   The OP said NSView subclasses.  Not NSControl.  So he needs to 
> implement hitTest to get mouseDown events.  If you read the sentence before 
> the line you quoted:  "This method is used primarily by an NSWindow object to 
> determine which view should receive a mouse-down event.”.  NSView returns nil 
> from hitTest by default, so raw NSViews don’t get mouseDown events.
> 
> —Rob

Have you actually tried creating a custom NSView, because this is simply not 
the behavior I've observed in the last 10+ years as a Cocoa UI programmer.

The only reason to override hitTest is if you want a view through which clicks 
pass through under certain circumstances (i.e., it has a non-rectangular shape 
or a built-in shadow through which clicks should pass to underlying views) or 
if you want to handle clicks that are actually destined for one of your sub 
views.

A plain NSView will do all the correct hit-testing for subviews and itself by 
default. 

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> 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: to get mouseDown events.
> 
> —Rob


No, the default implementation does all you need and is perfectly fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> 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 that I do without relation to incoming events.

 NSApplicationMain looks at your Info.plist to decide which Cocoa NIB to load 
at startup and what your NSPrincipalClass is (usually NSApplication). If you 
haven't set up your app as a proper Cocoa app, NSApplicationMain will be 
unhappy and won't work. Every time I've ported a Carbon app to Cocoa so far, I 
basically moved the main() function's contents (except the call to 
RunApplicationEventLoop()) into applicationDidFinishLaunching: etc. in an app 
delegate. Then it usually worked as before.

 ReceiveNextEvent() seems a bit of an odd choice. In general, you want 
RunApplicationEventLoop() and timers, performSelector:afterDelay:0.0 or threads 
to get processing time reliably for other things during the event loop.

> This makes me wonder about NSApplicationLoad, which I do call.

 NSApplicationLoad() is basically the "turn a Carbon app into enough of a Cocoa 
app to run Cocoa code"-call, so shouldn't be needed in a fully Cocoa app. And 
your guess why NSApplicationMain didn't work was pretty close, I think.

Cheers,
-- Uli Kusterer
http://www.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

Re: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

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 (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: Cocoa window messages in app being ported from Carbon

[Uli Kusterer via Cocoa-dev]

> 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 CarbonEvents under the hood. AFAIR, you can 
switch to the Cocoa event loop right away, and Carbon windows will just keep 
working.

> I've just started implementing the Cocoa windows.  The NSView subclasses 
> involved are receiving drawRect: messages but are not receiving mouseDown:.
> 
> Incidentally Cocoa menus and modal dialogs are already working, so that is a 
> sign that Cocoa events are to some degree alive and well.

 Modal Cocoa dialogs run their own Cocoa event loop, that's why they work  
It's also the most tested part of Carbon/Cocoa mixing, as that's what Apple 
used for NSOpenPanel & Co. Cocoa menus are Carbon menus under the hood as well, 
NeXT had no Mac-style menu bar (they had windows containing the deprecated 
NSMenuView), so that was based on the Carbon code from the start. There's even 
a private _NSGetCarbonMenu() call that Apple uses internally to get at the 
MenuRef backing an NSMenu.

 Just be aware that there are various small bugs and issues that make it 
impractical to ship an application that mixes modeless Carbon and Cocoa 
windows, mainly to do with window activation/ordering and application 
activation/ordering. What works (since that is what AppKit used itself) is 
modal Cocoa windows in an otherwise Carbon app. HICocoaView worked for some 
views, but not for all of them. Modeless windows will randomly re-order, 
sometimes causing the current modal window to end up behind another window and 
blocking the user from interacting with it.

 So this mixing is an ideal approach for slowly porting, but will not get you 
anything shippable until your UI is fully Carbon.

Cheers,
-- Uli Kusterer
___

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: Sharing Files Between My Apps via iCloud

[Uli Kusterer]

That iCloud doesn't work the way you expected it to is good.

Many apps make that assumption about Dropbox as well, and it is dangerous. 
Dropbox does not know about file packages or relationships between multiple 
files in a folder, so if you have anything but a single-file format, you can 
get document corruption where a table of contents file refers to files that 
don't exist or doesn't reference existing files because an addition and a 
deletion happened simultaneously. Storage mechanisms like this are *already* 
unreliable.

The iCloud API should be fairly simple. You basically just use different API to 
enumerate and access files that lets you ensure your entire change is applied 
*before* anything gets synched, which ensures related files are updated 
atomically and no other device can get "in sideways". You can still lose edits, 
but at least the files themselves stay consistent.

> On 25. Oct 2018, at 19:32, Michal L. Wright  wrote:
> 
> Thanks, Uli.
> 
> I used a dev support issue several weeks back, and received the following 
> info from Dev Tech Support:
> 
> ---
> The file with a leading dot and a .icloud extension is a stub representing a 
> file that is not downloadeded; it is replaced after the file is downloaded. 
> When synchronizing a file to an iOS device, which is not a greedy client, 
> iCloud automatically transfers the file metadata; the real file, however, is 
> only downloaded when requested. When the metadata comes in, iOS creates a 
> stub to represent the file. You can get more details from our document, 
> Designing for Documents in iCloud. 
> 
> You see the stub because you use file system APIs to search the content in 
> your iCloud container, which is not the right way to go. In any case, you 
> shouldn’t work directly with a stub with file system APIs.
> 
> The right way is to use NSMetadataQuery which can give you the items you have 
> in your container and then notify you of the incremental changes. With that, 
> you will get the right file metadata, including the file name, and can access 
> a file via NSFileCoordinator.
> ---
> 
> It seems that iCloud is not designed to work as a simple file storage 
> mechanism, the way MobileMe was (and the way Dropbox can work now). It can be 
> done, but it seems much more complex than those systems, and I’m not 
> confident that I can make it work reliably, so I’ve decided not to pursue it 
> at this time.
> 
> — Mike
> 
> 
>> On Oct 23, 2018, at 00:03 , Uli Kusterer  
>> wrote:
>> 
>> AFAIK the .icloud files are placeholders iCloud creates for Finder to show 
>> while a file is still downloading (there will be a little indicator next to 
>> it in Finder list view showing it's still downloading.
>> 
>> You should probably just ignore those files and wait until iCloud has 
>> finished downloading.
>> 
>> Their content is probably just information needed to show the progress in 
>> Finder, if anything at all. Or it is partial file data, maybe with space 
>> already reserved for the final size.
>> 
>> Cheers,
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> http://www.zathras.de
>> 
>> On 16. Sep 2018, at 20:27, Michal L. Wright  wrote:
>>> I have apps for Mac OS (myMacApp) and iOS (myIOSApp) that use the same file 
>>> format. The apps can synchronize files using WiFi or Dropbox.
>>> 
>>> Now I’m working on using iCloud for synchronization. I’m using the same 
>>> approach that works with Dropbox, which is:
>>> 
>>> 1. myIOSApp can read from and write to the app folder on Dropbox.
>>> 
>>> 2. If the file has not been previously synced, a copy can be written to 
>>> Dropbox for uploading to myIOSApp.
>>> 
>>> 3. Once copies of the file exist on both platforms, they can be synced 
>>> after one or both has been edited.
>>> 
>>> 4. If the copy in myIOSApp has been edited, that copy is written to Dropbox.
>>> 
>>> 5. In myMacApp, when the sync menu item is selected, myMacApp looks for the 
>>> file (by name) on Dropbox, downloads it and saves it with a temporary file 
>>> name.
>>> 
>>> 6. The temporary file is compared with the original, and any differences 
>>> are resolved.
>>> 
>>> 7. The temporary file is deleted from the Mac, and myMacApp writes the 
>>> resolved file to Dropbox.
>>> 
>>> 8. myIOSApp reads the resolved file from Dropbox.
>>> 
>>> I’ve gotten to the point that both myMacApp and myIOSApp can read from and 
>>> write to the same ubiquity container, using NSFileManager routi

Re: Sharing Files Between My Apps via iCloud

[Uli Kusterer]

AFAIK the .icloud files are placeholders iCloud creates for Finder to show 
while a file is still downloading (there will be a little indicator next to it 
in Finder list view showing it's still downloading.

You should probably just ignore those files and wait until iCloud has finished 
downloading.

Their content is probably just information needed to show the progress in 
Finder, if anything at all. Or it is partial file data, maybe with space 
already reserved for the final size.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

On 16. Sep 2018, at 20:27, Michal L. Wright  wrote:
> I have apps for Mac OS (myMacApp) and iOS (myIOSApp) that use the same file 
> format. The apps can synchronize files using WiFi or Dropbox.
> 
> Now I’m working on using iCloud for synchronization. I’m using the same 
> approach that works with Dropbox, which is:
> 
> 1. myIOSApp can read from and write to the app folder on Dropbox.
> 
> 2. If the file has not been previously synced, a copy can be written to 
> Dropbox for uploading to myIOSApp.
> 
> 3. Once copies of the file exist on both platforms, they can be synced after 
> one or both has been edited.
> 
> 4. If the copy in myIOSApp has been edited, that copy is written to Dropbox.
> 
> 5. In myMacApp, when the sync menu item is selected, myMacApp looks for the 
> file (by name) on Dropbox, downloads it and saves it with a temporary file 
> name.
> 
> 6. The temporary file is compared with the original, and any differences are 
> resolved.
> 
> 7. The temporary file is deleted from the Mac, and myMacApp writes the 
> resolved file to Dropbox.
> 
> 8. myIOSApp reads the resolved file from Dropbox.
> 
> I’ve gotten to the point that both myMacApp and myIOSApp can read from and 
> write to the same ubiquity container, using NSFileManager routines.
> 
> When myMacApp reads files from iCloud, the files have the correct file 
> extension, something like this: MyFile.xten
> 
> When myIOSApp running on the iPhone reads files that it wrote, the file names 
> are fine, but when reading files written by myMacApp, they look like this: 
> .MyFile.xten.icloud
> 
> I was thinking that I must be missing something regarding how entitlements or 
> info.plist were set up for each app, but it turns out that files written by 
> myIOSApp running on the iPad are treated the same way. And, myIOSApp running 
> on the iPad treats files that were written from the same app running on the 
> iPhone the same way.
> 
> The ubiquity container can be viewed in Terminal on the Mac by typing ls -r 
> "Library/Mobile Documents/iCloud~com~mycompany~myiosapp”
> 
> When the files are listed in Terminal, all I see are the file names, with 
> nothing to differentiate them based on which app wrote them, nor based on 
> which device they came from. None of them have the leading period or the 
> trailing .icloud.
> 
> I also use the following to create a listing of the files in the ubiquity 
> container:
> 
>   NSURL *iCloudURL = [[NSFileManager defaultManager] 
> URLForUbiquityContainerIdentifier:nil];
>   if (iCloudURL)
>   NSArray* fileList = [[NSFileManager defaultManager] 
> contentsOfDirectoryAtPath:iCloudURL.path error:NULL];
> 
> I step through the fileList array and use fprintf to show the paths. They 
> show the same problem with the leading period and trailing icloud.
> 
> Trying to work around the modified file names hasn’t produced any useful 
> results so far. If I read the files with the incorrect name, the content is 
> incorrect. If I strip off the the leading period and trailing icloud before 
> trying to read, the read fails.
> 
> I would appreciate any insights as to the cause of the problem and, of 
> course, it’s solution.
> 
> Thanks,
> Mike Wright
> 
> ___
> 
> 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/witness.of.teachtext%40gmx.net

___

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: XPC Question

[Uli Kusterer]

On 18. Sep 2018, at 19:25, Alastair Houghton  
wrote:
> Well, Cocoa has Distributed Objects, which you could use for this purpose.  
> DO has some interesting behaviour (in particular, watch out - it can throw 
> exceptions, even when calling methods that don’t normally do so), but it does 
> let you send messages to objects fairly easily over a network.

From what I remember, DO also has some very ... interesting behaviour when it 
comes to time-outs, and predictable timing, as well as dropped connections. 
Basically, it mostly assumes a stable, near-instant network, and there's no 
good way to recover from a dropped network, and no control over how long it 
will take to recover from stalls etc. either.

In short, DO is intended for small LANs, so if you're planning to use it over 
the internet ... don't.

If you need a fairly painless way for network communication, I'd suggest 
creating your own mechanism on top of queues of message objects and keyed, or 
better secure, archiving. You can always model things after XPC, with the same 
method names etc.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Bothersome "NSView-Encapsulated-Layout-Height" constraint?

[Uli Kusterer]

On 31. Aug 2018, at 02:23, Demitri Muna  wrote:
> I expect the highlighting to extend to the full height of the row. I tried to 
> force this by adding two constraints, 2 pixels above and below the image, 
> then got this:
> 
> 2018-08-30 14:55:36.807612-0400 Nightlight[78272:15775715] [Layout] Unable to 
> simultaneously satisfy constraints:
> (
>" 16   (active)>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" DE_DataCell.height == 12   (active, names: DE_DataCell:0x60c000188470 )>"
> )
> 
> This shows where the problem is: a height constraint on the row of 12 with 
> the name "NSView-Encapsulated-Layout-Height”. This is the exact height I see 
> being drawn. I have no idea where this is coming from or how to fix it 
> though. Any help welcome - it’s annoying because this seems like such simple 
> thing!

 Did you perhaps forget to set translatesAutoresizingMaskIntoConstraints = NO 
on one of the views you return it defaults to YES on newly-created views)? This 
constraint is used by the layout system to apply heights you specify elsewhere. 
I *think* it is one for non-AutoLayout views. If I'm misremembering, check for 
any other views that arrange their subviews, like NSStackViews.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Typing with multiple selections in NSTextView

[Uli Kusterer]

On 20. Sep 2018, at 08:54, Georg Seifert  wrote:
> I wonder why it supports multiple selection in the first place, when you can 
> do almost nothing with it?

The way I remember it being introduced at WWDC was not as "multiple selection" 
but rather as "column selection". That might make some of the oddities in the 
feature set a little more obvious: Extracting columnar data.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Carbon -> Cocoa

[Uli Kusterer]

On 22. Aug 2018, at 19:40, Alastair Houghton  
wrote:
> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
> there’s really no reason that CFRunLoop would have to spawn a background 
> thread just to monitor some file descriptors. As far as I can tell, the 
> current CFRunLoop implementation is built on top of GCD, which sadly we don’t 
> have the source code for; I don’t have time to reverse engineer it right now 
> to see whether or not GCD does in fact spawn background thread(s) for this or 
> not, but I see no particular reason it should have to.

 I recall hearing from someone at Apple that they basically ported GCD to Linux 
for the Swift Linux release ... have you looked whether that code might give 
any clues about what may be happening on macOS?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Carbon -> Cocoa

[Uli Kusterer]

On 18. Aug 2018, at 20:19, Stephane Sudre  wrote:
> Regarding the complexity of porting from C++ Carbon to Cocoa, there's
> also the important question of what your minimum OS target is.
> 
> Maybe one of the reasons why you kept a Carbon version alive so long
> is that the application needs to keep working on older OS versions.
> 
> Porting to OS X 10.10 or later is not the same thing as porting to
> 10.6 or later for instance.

+1. I think we pretty much only supported whatever the current OS version was 
in our Cocoa ports. We had the Carbon versions in parallel that supported the 
older OSes, so it wasn't as if users would notice. There were significant 
improvements over macOS releases. Particularly 10.2 and 10.8, IIRC. I haven't 
had to Carbon-port much later than that.

... well, that's not true, I did a rough Carbon-to-Cocoa port for a friend 
about a year ago, but that was just getting the basics to work and solving the 
hard issues (like adding certain modifications he needed to standard views to 
Cocoa, in a Cocoa way), and hasn't shipped yet.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Carbon -> Cocoa

[Uli Kusterer]

On 16. Aug 2018, at 13:54, Casey McDermott  wrote:
> I am curious, are there other developers on this list working on conversions
> from C++ Carbon to Cocoa?
> 
> If so, how is it going?

I've worked on a few in previous jobs, it was definitely a lot of work, but 
most of that was due to the lack of MVC separation in most existing C++ 
codebases, and due to (at the time) only limited support for co-habitation of 
Cocoa and Carbon code in the same app, so we had to branch and develop two apps 
(the shipping Carbon and the work-in-progress Cocoa app), because certain 
things (like mixing non-modal Cocoa and Carbon windows) were just too buggy.

Luckily most of these ports pre-dated 64 bit (well, pre-dated Apple being 
annoying about 32-bit apps), so we could port to Cocoa first, then to 64 bit 
from there.

Some of the apps shipped, some got sold to other companies and those companies 
haven't shipped their Cocoa versions yet ... so I can't claim a 100% success 
rate.

In retrospect, for most of them I'd say the best approach is to just tear off 
the view layer, wrap all the remaining code in some sort of API, then swap out 
the UI layers. We basically did that for Game Capture and that was our fastest 
port.

In the ones where we attempted to port parts over, there was usually a huge gap 
between the easy beginnings and later parts. Replacing file panels, standard 
alerts, cursors etc. with Cocoa calls, replacing all modal windows with Cocoa 
windows etc. was fairly straightforward. Actually moving over the menu bar 
required taking the main event loop along, and only *then* would non-modal 
Cocoa windows work properly.

You can mix modeless Cocoa and Carbon windows in a RAEL-based app or even 
WNE-based app, and they will sort of work, but it's only suitable for testing 
both versions of a window, nothing you would want to ship. Too many subtle 
focus and window-ordering bugs in daily use.

That said, NSSelectorFromString() let us make a pretty neat translation scheme 
between ObjC menu item selectors and HICommands, and many older C++ frameworks 
actually behave more like ObjC's -validateMenuItem: than modern Carbon did, so 
in one case I was very happy an app's codebase hadn't been brought up to speed 
with Carbon best practices, because I could just hollow out TCL classes and 
back them with ObjC objects and all was fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: is there a way to determine if an NSButton is toggleable ?

[Uli Kusterer]

> On 20. Aug 2018, at 12:04, Guillaume Laurent  
> wrote:
> 
> Hi all,
> 
> 
> For a custom UI I’ve had to write a custom control deriving from NSButton, 
> which highlights itself in a special way on mouse-over. In the method which 
> does the highlighting, I check if the button’s state is either .on or .off, 
> so I know which title or alternateTitle to display. But I realized that, no 
> matter the button's type, the state is always toggled on click. That is, even 
> if the button’s type is set to MomentaryPushIn, the button’s state is toggled 
> after a click. I’d have thought that this was the case only for 
> OnOff/Toggle/Switch… types.
> 
> Since there is no NSButton.type getter, is there a way to determine if the 
> button’s type is toggleable or not ? And what is the reason for switching 
> state for types like MomentaryPushIn ?

 You want to look at the showsStateBy bit field. See:

http://orangejuiceliberationfront.com/building-a-custom-nsbutton/

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: NSComboBox

[Uli Kusterer]

On 26. Jul 2018, at 02:50, Casey McDermott  wrote:
> Sometimes one has no idea what's in the list, so it really helps to be able 
> to scroll.
> A popup is probably better for that, but not when in hands-on-keyboard mode.

 You're aware that popups support type-selection, arrow keys etc.? In fact, all 
menus on OS X have supported that for quite a while now.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: NSDrawer

[Uli Kusterer]

Just for completeness' sake: You're aware of NSPopover?

> On 3. Jul 2018, at 04:08, Casey McDermott  wrote:
> 
> NSDrawer is deprecated, but it's also perfect for our application.
> We still haven't found a good substitute.
> 
> Our app has an outline view that loads various types of business records
> into a tab view.  Some of them have optional extra info.  When it's small a 
> panel is fine,
> but some records have large tables: about the same size as the main record.  
> A drawer is perfect for viewing them side-by-side with the main info.  
> In a panel it obscure the main record, and users need to see both.
> 
> Is there a work-around for an attached window that pops out on the side,
> and acts like a drawer?  
> 
> Any idea when deprecation turns into total non-support?
> 
> Thanks,
> 
> Casey McDermott
> www.TurtleSoft.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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Can anyone suggest an open source license for Nursery framework?

[Uli Kusterer]

On 28. Oct 2017, at 20:36, Marco S Hyman <m...@snafu.org> wrote:
>> Can anyone suggest an open source license for Nursery framework?
> 
> https://creativecommons.org/share-your-work/

  Not a good idea. CC is intended for creative works, (art, writing) and not 
for software:

https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Can anyone suggest an open source license for Nursery framework?

[Uli Kusterer]

MIT/BSD require credit to be given somewhere visibly. If you don't want that (I 
kept getting support e-mails for apps that used my code because my name was 
more prominent than their support page in the apps), zlib is basically the same 
without the credit requirement.

On 28. Oct 2017, at 16:05, Torsten Curdt <tcu...@vafer.org> wrote:
> I'd suggest to have a look at the Apache or MIT open source license.
> 
> cheers,
> Torsten
> 
> On Sat, Oct 28, 2017 at 1:17 PM, Akifumi Takata <akif...@icloud.com> wrote:
> 
>> Dear all,
>> 
>> Can anyone suggest an open source license for Nursery framework?
>> 
>> I am not familiar with open source license.
>> 
>> I prefer a license that can be used for both commercial and non-commercial
>> use, without having to return the changes made by the user to the source
>> code to the repository.
>> 
>> Regards,
>> Akifumi Takata
>> ___
>> 
>> 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/tcurdt%40vafer.org
>> 
>> This email sent to tcu...@vafer.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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Problem using NSTimer in privileged helper tool

[Uli Kusterer]

On 19. Oct 2017, at 18:04, Mark Allan <markjal...@gmail.com> wrote:
> So I tried refactoring the block into a separate method and using an older 
> NSTimer method:
>   [NSTimer timerWithTimeInterval:0.2 target:self 
> selector:@selector(updateTheDelegateForRunID:) userInfo:runID repeats:YES];
> 
> 
> This causes my privileged helper tool to crash with the following message 
> printed to Console:
> 
> Terminating app due to uncaught exception 'NSInvalidArgumentException', 
> reason: '*** -[NSXPCEncoder _checkObject:]: This coder only encodes objects 
> that adopt NSSecureCoding (object is of class '__NSCFTimer').'

 What kind of class is 'self' in this case, and is the 
-updateTheDelegateForRunID: method part of your XPC protocol?

 Methods called by an NSTimer must have the form

-(void) foo: (NSTimer*)sender

So in this case, the first argument passed to -updateTheDelegateForRunID: will 
be the timer itself. If the method call is bridged over XPC, this would mean it 
would try (and fail) to secure code an NSTimer. I don't think clang knows 
enough about NSTimer to be able to tell that the SEL passed to it should take 
an NSTimer* argument, so you're not getting a type error, even though you are 
passing a method that takes the wrong type.

Also, your parameter is probably not what you think it should be. You are 
passing something named runID to your timer's userInfo. This will initialize 
the timer's userInfo property with that value. It is not the value that gets 
passed to -updateTheDelegateForRunID:.

So my guess is what you really need is an intermediate "timer fired" adapter 
method:

-(void) updateTheDelegateForRunIDTimerFired: (NSTimer*)sender
{
[self updateTheDelegateForRunID: [sender userInfo]];
}

and pass that as the timer's selector instead.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Using Storyboard References as objects

[Uli Kusterer]

On 4. Oct 2017, at 21:09, Rick Aurbach <r...@aurbach.com> wrote:
> Ideally, the view would contain an outlet collection which would store its 
> associated sub-controllers. And it would be really nice if I could connect 
> EITHER a scene from the current storyboard OR a storyboard reference. (Again, 
> similarly to what a UITabController can do.)

 One thing I once played with was (ab)using segues for this. IIRC it required:

- a custom segue subclass (to prevent the OS from trying to do a segue itself)
- saving a pointer to the destination view controller in prepareForSegue
- all segues being named after a pattern (I had an IBInspectable in the main 
scene's view controller with a "base name" and just appended a number to that)

That at least gave you connecting lines in the Storyboard from the main view 
controller to the individual pages.

Then you just take the view controller's view and stick it in your container 
view, or remove it and put another one in, as appropriate.

I would be curious if there is a better way for this though.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Is "-init" really needed?

[Uli Kusterer]

On 8. Aug 2017, at 18:38, Doug Hill <cocoa...@breaqz.com> wrote:
> As others have mentioned, I too have never seen any evidence or statements 
> from Apple that discourages +new or -init. Or designated initializers.

 I never said anything about init or designated initializers. In fact, ObjC 
gained support for marking designated initializers fairly recently.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Is "-init" really needed?

[Uli Kusterer]

On 8. Aug 2017, at 02:23, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote:
> Is the use of +new discouraged also?

 Apple have gone back and forth on this AFAIR. +new was actually the 
pre-retain/release way to create an object. So it has been discouraged since 
... OpenStep, I think? But it was never formally deprecated, and I'm seeing it 
used more and more in ARC code these days.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Detecting if current user owns the screen (screen lock/FUS)

[Uli Kusterer]

Lock screen still gives the name of the user behind the screen lock.

Mühevoll auf meinem Telefon getippt.

> On 21. Apr 2017, at 11:43, Stephane Sudre <dev.iceb...@gmail.com> wrote:
> 
> SystemConfiguration.framework?
> 
> You can:
> 
> - retrieve the current uid,gid, user name with SCDynamicStoreCopyConsoleUser
> - be notified via a C callback when the console user changes
> (SCDynamicStoreCreate, SCDynamicStoreKeyCreateConsoleUser(),
> SCDynamicStoreSetNotificationKeys, SCDynamicStoreSetDispatchQueue or a
> more classic runloop source) and then then call
> SCDynamicStoreCopyConsoleUser.
> 
> Note that when the login window is displayed, the current user name is
> "loginwindow".
> 
> I've never checked which uid or user name was returned when the screen
> is locked.
> 
> 
> On Fri, Apr 21, 2017 at 9:57 AM, Uli Kusterer
> <witness.of.teacht...@gmx.net> wrote:
>> Hi,
>> 
>> I have an application (think hardware driver) that runs as a particular 
>> (GUI) user. Now, if that user is switched out using Fast User Switching or 
>> the screen lock has engaged, I want to prevent the driver from working (as 
>> the user sitting in front of the computer with access to the hardware is 
>> obviously not them).
>> 
>> The only documented API I've found is 
>> NSWorkspaceSessionDidResignActiveNotification etc., but this doesn't help me 
>> because it only notifies me when the state changes, it doesn't let me obtain 
>> an initial state (I suppose I could assume if I'm running as a user, my 
>> session is active, but would prefer actually knowing).
>> 
>> I've also found that CGSessionCopyCurrentDictionary() contains an 
>> undocumented key that lets me know whether the screen lock is engaged, but 
>> that reports the screen as not locked when the user is still logged on, but 
>> switched out using fast user switching.
>> 
>> Is there any official, supported way to determine whether the user my app is 
>> running as actually owns the screen and screen lock is not engaged that I 
>> could use for this purpose? Since I only need to know the current state when 
>> the user actually triggers my device, a polling API would be fine.
>> 
>> Cheers,
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> 
>> 
>> 
>> ___
>> 
>> 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/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 
> 
> 
> -- 
> Packaging Resources - http://s.sudre.free.fr/Packaging.html
> ___
> 
> 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

___

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: [OT] Question about writing documentation

[Uli Kusterer]

On 21. Apr 2017, at 19:28, davel...@mac.com wrote:
> You did't say what you tried, but IMO the best app for professional looking 
> figures on the Mac is OmniGraffle from omnigroup.com. There are extensive 
> stencil libraries for many things and I expect one could work (at least as a 
> starting point) for you or you could create a stencil group you could reuse. 
> They have a free trial.
> 
> I'm not affiliated with OmniGroup - just a satisfied customer.

Also, I'm not sure if OmniGraffle still has this feature, but in ye olde days 
you could drag an Xcode project on OmniGraffle and it would actually generate a 
diagram from the source files. That might have been back in the Project Builder 
days though, so might have been discontinued with one of the two dozen ObjC 
syntax and Xcode file format changes.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."



___

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

Detecting if current user owns the screen (screen lock/FUS)

[Uli Kusterer]

Hi,

I have an application (think hardware driver) that runs as a particular (GUI) 
user. Now, if that user is switched out using Fast User Switching or the screen 
lock has engaged, I want to prevent the driver from working (as the user 
sitting in front of the computer with access to the hardware is obviously not 
them).

The only documented API I've found is 
NSWorkspaceSessionDidResignActiveNotification etc., but this doesn't help me 
because it only notifies me when the state changes, it doesn't let me obtain an 
initial state (I suppose I could assume if I'm running as a user, my session is 
active, but would prefer actually knowing).

I've also found that CGSessionCopyCurrentDictionary() contains an undocumented 
key that lets me know whether the screen lock is engaged, but that reports the 
screen as not locked when the user is still logged on, but switched out using 
fast user switching.

Is there any official, supported way to determine whether the user my app is 
running as actually owns the screen and screen lock is not engaged that I could 
use for this purpose? Since I only need to know the current state when the user 
actually triggers my device, a polling API would be fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."



___

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: Unicode filenames with Apple File System and UIManagedDocument

[Uli Kusterer]

I can't find the start of this thread, but this sounds a lot like you were 
using -UTF8String instead of -fileSystemRepresentation to save out your file 
names. That's the main difference between those two calls: 
-fileSystemRepresentation decomposes UTF8 the way HFS+ does, so should never 
adopt newer decompositions, and will instead guarantee the same string will 
decompose the same way — as long as you don't forget to use it somewhere.

Of course, if you are using command line tools, they might not be properly 
normalizing the file names.

Apologies if this was already covered in the lost beginning of this thread.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

> On 8 Mar 2017, at 22:35, Peter Edberg <pedb...@apple.com> wrote:
> 
> 
>> On Mar 8, 2017, at 12:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
>> 
>> Message: 1
>> Date: Tue, 07 Mar 2017 15:03:41 -0500
>> From: davel...@mac.com
>> To: Alastair Houghton <alast...@alastairs-place.net>,David Duncan
>>  <david.dun...@apple.com>
>> Cc: cocoa-dev list <cocoa-dev@lists.apple.com>
>> Subject: Re: Unicode filenames with Apple File System and
>>  UIManagedDocument
>> 
>> 
>> 
>> My app has the option to zip up the directories UIManagedDocument creates 
>> and email it (so users can back up their data or share it with others). The 
>> person sent it to me. Below is what I did in the Terminal so you can see 
>> what happens when I try to unzip it. If this doesn’t come through on the 
>> email list with the characters looking correct, I can screenshot it.
>> 
>> This is one of the data files that was created on iOS 10.2 and then won’t 
>> open now on an iOS 10.3 device. It appears the directory name and zip file 
>> name do not match and it won’t unzip correctly. It does create a directory 
>> but the directory is empty instead of containing the StoreContent and 
>> persistentStore files. The zip file is 34KB so it may or may not actually 
>> have the data in it.
>> 
>> $ ls
>> إعلام.zip
> 
> 
> It is probably worth noting that the first Arabic character in the above 
> filename (i.e. the one that appears on the right, adjacent to the period) has 
> a canonical decomposition, as per this line from UnicodeData.txt 
> (http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt 
> <http://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt>):
> 0625;ARABIC LETTER ALEF WITH HAMZA BELOW;Lo;0;AL;0627 0655;...
> 
> That is, in some cases this character 0625 (UTF8: D8 A5)  will be converted 
> to the sequence 0627 0655 (UTF8: D8 A7 D9 95).
> 
> This decomposition was introduced in Unicode 3.0. If there are processes that 
> use decomposition according to Unicode 9 versus Unicode 2.x, or processes 
> that don't decompose versus ones that do, then the filename bytes will be 
> different.
> 
> - Peter E
> 
> 
> 
> ___
> 
> 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net


___

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: why use extern "C"

[Uli Kusterer]

On 7 Mar 2017, at 17:45, bigpig <bigpig1...@gmail.com> wrote:
> I see some code like this in iOS project:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif

Others have mentioned what this code does, but I think it'd be useful to 
provide some background why this is needed:

In C, functions are distinguished by name. A function named "min" must take the 
same parameter types wherever it occurs in your program. There may be no two 
functions with the same name.

In C++, both the name and the parameter types are used to distinguish between 
two functions. You may have several functions that have the same name, as long 
as they take a different number of parameters, or take parameters of different 
types.

However, under the hood, both C++ and C are compiled to machine code. And that 
only supports a single function with the same name, and doesn't know about 
parameter types. So what the C++ developers did to make this behaviour possible 
is that they changed the names for functions. Every function contains a few 
characters at the end of its name that indicate what types its parameters have.

That way, the two functions actually have a different name to the assembler, 
but there is a rule the programming language can use to generate the actual 
function name based on the name and types it knows. This is what is called 
"name mangling."

However, this is something only C++ does, and only C++ knows about. Name 
mangling is fine when you are only using C++, but when you want to make C++ 
functions available to C code, you need to tell your C++ compiler not to mangle 
the function names so C will be able to call them. This is what 'extern "C"' 
does. It turns off name mangling for the functions between the "{" and "}".

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Change NSCursor globally

[Uli Kusterer]

On 15 Feb 2017, at 11:24, Colas B  wrote:
> thanks for your answer.
> I want to do the former: when the user enables a mode in the application, the 
> cursor changes, exactly in the way you described (the shape changes). The 
> user should be able to use this custom cursor over a PDFView, a UIScrollView, 
> etc. However, I need the cursor only in one window. Later the user can leave 
> this mode and go back to the normal behaviour.
> I'm looking for a solution that does not require subclassing all the views.

 This is still very vague, so I don't think I have enough information to help 
you.

 The problem might be that you have overlapping tracking regions, where one is 
fully contained inside the other. I think NSTrackingArea doesn't like that 
(it's been a while, so I might be mis-remembering).

 I'm not sure if there's a way to remove or move the other tracking areas, but 
that seems like a skanky hack. You can't handle this in a generic way without 
risking unexpected behaviour from the views involved.

 That said, depending on what views you're dealing with, you might have luck 
with overriding its parent view's hitTest method.

-- Uli


PS -  I'm a bit confused about your code, as it contains mentions of iPhone and 
you mention UIScrollView ... but iOS doesn't have a mouse ... ? Typos?


___

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: Sometimes all my menus are disabled

[Uli Kusterer]

Have you tried printing the responder chain when this happens? But as others 
have said, funnelling all menu choices through a menuClick: method sounds 
backwards.

On 12 Feb 2017, at 18:01, Andreas Falkenhahn  wrote:
> I'm experiencing a strange issue with my app. Sometimes, maybe in 1 out of 10
> programs starts, all menus of my app are grayed out, including standard menus
> like "Services", "Hide XXX", "Hide Others", "Show All", "Minimize", "Zoom",
> "Bring All To Front", really everything is grayed out right after my app has
> launched!
> 
> I don't really know what to do about this because I don't have any actual code
> in my app that relates to menus. The menu is created in Interface Builder and
> the individual items are connected to "AppDelegate menuClick:" in the 
> "Sent Actions" part of Xcode. That's pretty much all I have.
> 
> What could be the problem here? How can I find out what's going awry here?
> 
> As I said, in 9 of 10 attempts everything works fine, but in maybe 1 of 10
> attempts all menus are grayed out right after my app has launched, making it
> impossible to use my app :-(
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.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: AVSimplePlayer in Swift?

[Uli Kusterer]

On 13 Jan 2017, at 00:42, Charles Jenkins <cejw...@gmail.com> wrote:
> Here is the code I promised to post. This version is using didSet instead
> of KVO. In both cases, if I imitate the way AVSimplePlayer seeks in the
> setter for currentTime, the video won’t play.

Just a thought: Does AVSimplePlayer[ObjC] actually call the getters and 
setters, or does it assign directly to the ivars? I don't have access to the 
code right now.

In the latter case, there would be no KVO notification, whereas in your case 
didSet always runs. Also, AFAIR KVO or at least bindings have loop prevention. 
So if you're triggering a notification on a particular object/property and 
while that is being handled in -observeValueForKeyPath:..., it will not send a 
second notification.

Did you move code from the -observeValueForKeyPath:... into didSet?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Change NSCursor globally

[Uli Kusterer]

On 6 Feb 2017, at 18:57, Colas <colasj...@yahoo.fr> wrote:
> I am developing an application with several windows and views (NSTextView, 
> etc.).
> I would like to change the cursor globally in my application, so that even if 
> the cursor enters the trackingRect of (for instance) an NSTextView it does 
> not change.
> Is this possible?
> I need also to revert back to the usual behaviour.

Can you give a bit more info on what is this for? Is this for a longer time 
where the user will be interacting normally with your application (e.g. your 
app has an "I'm on a projector make the cursor huge and red" mode, or is a 
presentation in a kiosk system that needs to look different), or is this just 
temporarily (e.g. while drawing out a selection rectangle for a screenshot of a 
subsection of the screen)? 

For the former, you'll have to override methods on each individual kind of 
view. For the latter, you can just create a transparent, borderless window and 
give it a tracking area that sets your cursor.

I can give more detailed suggestions for these approaches, but there are many 
ways to do the same thing that work better or worse depending on what your 
needs are.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Intercept Save when closing NSDocument

[Uli Kusterer]

On 10 Feb 2017, at 18:23, Jens Alfke <j...@mooseyard.com> wrote:
> 
>> On Feb 10, 2017, at 9:19 AM, Keary Suska <cocoa-...@esoteritech.com> wrote:
>> 
>> I would start by overriding -saveDocument: and -saveDocumentAs: in your 
>> NSDocument subclass with a breakpoint so I can see what is being done.
> 
> Even easier: wait for the save dialog to appear, then hit the Pause button in 
> the debugger and look at the backtrace to see the entire call chain. Look for 
> any NSDocument method that you can override.

 That was very handy for modal dialog panels. Sadly for modeless windows and 
modeless sheets, I don't think this still works. If anyone has a similar trick… 
I suppose you could try setting breakpoints in the various beginSheet calls in 
NSApplication/NSWindow, or maybe one on -setSheetParent: might be enough.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: NSTouchBar in Carbon

[Uli Kusterer]

On 12 Dec 2016, at 07:22, David M. Cotter <m...@davecotter.com> wrote:
> My app is mostly C++ (because it’s cross platform) with Carbon on the UI 
> edges, and the absolute minimum required ObjectiveC++ to make it work.  
> (please no discussion about why this is stupid / i should write a modern app 
> etc)
> 
> So I need to programmatically instantiate an NSTouchBar, somehow
> 
> i do have a “MainController” which is just an NSObject, and a literally empty 
> nib i COULD put something into.
> 
> but i do NOT have an NSView or NSViewController to connect the touch bar to, 
> and i’d prefer not to have to use any storyboard if i can avoid it (of course 
> i will if it can’t be avoided)
> 
> how do i go about just creating an NSTouchBar in objC and having it show up 
> and respond to taps?

 From a casual look at the comments in the NSTouchBar.h header, it seems as if 
you only need an application delegate (which I assume you mean by your 
MainController NSObject?) that implements NSTouchBarProvider to return an 
NSTouchBar object. Of course, if you implement it all there, you'll have to 
come up with your own way to determine from the frontmost window etc. which 
items to show.

 As to implementing the actual items, it seems like, lacking an NSCarbonView, 
you need to use an NSView to provide those (and if you're using some standard 
view, that will in turn need to either be subclassed or need another object to 
talk to that knows how to dispatch messages to your Carbon code.

 FWIW, in our Cocoa port, we tried just funneling everything through the app 
delegate as fake Carbon events (and all our existing code needed minimal 
changes to handle fake instead of real events because the structure stayed the 
same). We eventually gave up on that as it just invites impedance mismatches 
about who gets what message. So in the end, we changed all our C++ classes to 
create Cocoa NSWindowController objects and load the actual windows from Cocoa 
(but still use our fake Carbon Events to dispatch stuff under the hood).

 That meant all windows converted worked as part of the responder chain. It's 
been too long for me to remember what we actually did in what order. I think we 
first converted the menu bar to Cocoa alone, then slowly migrated windows bit 
by bit, starting with modal windows first. Maybe that info helps you some in 
deciding what to do.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: App with QuickLook Generator

[Uli Kusterer]

On 30 Dec 2016, at 00:28, Raglan T. Tiger <r...@crusaderrabbit.net> wrote:
> I have a QL Generator in y App Bundle ... been there since, we'll, a long 
> time.  The ql generator needs to read a file to get some instructions. The 
> sea always worked fine.
> 
> Now building with 10.11 SDK on XC 7.3.1the ql generator is denied reading the 
> instruction file on OS X version 10.9.5 with this message:
> 
> Sandbox: QuickLookSatelli(985) deny file-read-data / Users / x / 
> Documents / y / dict.plist 
> 
> This does not occur on 10.11.x or 10.12.1 and never occurred before building  
> as described above.
> 
> So, what am I missing re:Sandbox (even though the app is not sandboxed)

 QuickLook importers are plugins loaded into a QuickLook system process running 
in the background, not in your app. I guess Apple got around to sandboxing that 
process. I don't know if there is any documentation (haven't worked on a 
QuickLook importer in years), but I'd try properly adding sandboxing 
entitlements to your importer and seeing if that fixes things, as if it was a 
standalone app.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: How to update UI from a background thread

[Uli Kusterer]

On 21 Sep 2016, at 18:20, Dave <d...@looktowindward.com> wrote:
> This doesn’t work probably because the Class is that is calling back the 
> delegate method that updates the Scroll View is also being run on the main 
> thread. Sorry I should have said this earlier. I tried updating the UI on a 
> background thread and it seemed to work BUT I got warning message from 
> CALayer or maybe CATransaction and I think it caused the App to hang.

 You can do limited drawing into an existing view hierarchy on a secondary 
thread (that's how e.g. the throbbing default button in previous OS versions 
was drawn), but you have to do it in a very particular way.

Whatever you do, you mustn't manipulate the view hierarchy from a thread. All 
that'll do is screw up AppKit's or UIKit's internal data structures and lead to 
random crashes due to memory corruption.

> The time consuming method I am calling is in a third party library and it 
> must be called in the main thread. 

 Does it need to be running in your application? Usually you do most of the 
work on a secondary thread, then use dispatch_async() or so to send the parts 
that need to happen on the main thread back there. If you can't do that, 
another option would be to run the code on the main thread of another process, 
e.g. using XPC, and have that call you back when it needs to make your app do 
something on *its* main thread.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Modern API to read textClipping files

[Uli Kusterer]

On 23 Sep 2016, at 08:49, Allan Odgaard <lists+cocoa-...@simplit.com> wrote:
> Is there any non-deprecated API to read textClipping files?
> 
> FSOpenResFile() was deprecated in 10.8 but I haven’t found a way to replace 
> it. There is the com.apple.ResourceFork extended file attribute, but it seems 
> to be stored in some legacy format that I would rather not try to interpret.

AFAIK that's just the raw resource fork contents exposed in that extended 
attribute. I'm not aware of any API to read these files beyond the Resource 
Manager API.

If you change your opinion on reading it yourself, I wrote some code a while 
ago that reads resource forks:

https://github.com/uliwitness/ReClassicfication/blob/master/InterfaceLib/FakeResources.c

(There are more files in that folder, check out the entire project at 
https://github.com/uliwitness/ReClassicfication/)

Note that the code for writing out resource forks is still buggy, but the 
reading code works fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

On 23 Sep 2016, at 01:19, Sandor Szatmari <admin.szatmari@gmail.com> wrote:
> // my .m file
> static NSString * const kMyContext = @"my fantastic context";

 This avoids the issue of having a different string in a different module and 
relying on details of your compiler and its optimizer. However, it can still 
run afoul of them, in the other direction, depending on which string you use: 
I've seen people do this and use the name of the property being observed as the 
string's value. Which is not an unlikely choice for an observation in the base 
class. And in that case, the optimizer might give the base class and you the 
same string to point to in your static variable.

 OTOH, if you use your subclass's name, you're less likely to collide. But why 
use the memory for the additional string and risk making the value less unique 
when

void *kMyContext = 

is *guaranteed* to give you a unique address that nobody else's object may 
occupy?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

> On 23 Sep 2016, at 01:07, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 22, 2016, at 15:45 , Gabriel Zachmann <z...@tu-clausthal.de> wrote:
>> 
>> Sure, but an observation method is what would be called a "callback" in 
>> plain C.
>> In C, I can have many different callbacks.
>> I don't see why that should not be possible in Obj-C - I just would need a 
>> mechanism to add tell the system the names / function pointers to be 
>> registered as observers.
> 
> It is of course possible in Obj-C. There are APIs that have a “didEnd” 
> selector, such as (deprecated) ‘[NSApplication 
> beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:]’. That’s 
> similar to the KVO notification method concept, except that you get to 
> specify a selector and a target object. Note, however, that such APIs tend to 
> have a context parameter, too**.
> 
> But that’s because the KVO notification mechanism is a more ancient design 
> concept, where it likely seemed simple, adequate and flexible. I assume it 
> comes from NeXTStep days (late 80s or early 90s), not OS X 10.0 days (early 
> 2000s), although I don’t know for sure.

 Are you sure? I only learned Cocoa when it came to OS X, but my impression was 
that, while KVC came from NeXT, KVO arrived with bindings … that would have 
been 10.3 or 10.4-ish?

> ** In the “didEnd” selector mechanism, the context parameter is likely used 
> for actual context information, rather than for identifying the source of the 
> invocation. It can be used that way with KVO notifications, too, but the fact 
> that they’re funneled through a single method in the observer object means 
> that the context is implicitly known anyway, and the context parameter has 
> been appropriated as a marker for the source of the observation.

 Yeah, I wouldn't conflate the context on beginSheet: and the majority of Cocoa 
calls with the one on KVO. And I would actually argue that you *should not* use 
the KVO context as actual storage, as as soon as it contains useful 
information, you can't tell it from someone else's context anymore (such as 
your superclass's). At the least using it for data would be bad style.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

On 23 Sep 2016, at 00:45, Gabriel Zachmann <z...@tu-clausthal.de> wrote:
>> Because the observer is an object. Your observation and a superclass 
>> observation come from the same object. Whether these are to be treated as 
>> different observations** cannot be determined automatically, hence the need 
>> for a “context”.
> 
> Sure, but an observation method is what would be called a "callback" in plain 
> C.
> In C, I can have many different callbacks.
> I don't see why that should not be possible in Obj-C - I just would need a 
> mechanism to add tell the system the names / function pointers to be 
> registered as observers.
> 
> Anyways, the concept of a block gets closer to what I mean, except it is 
> still not a named function/method.

 The problem is that KVO was designed (probably because it avoids the overhead 
of an NSInvocation, as the observeValueForKeyPath method can't be called using 
performSelector) to funnel all its callbacks through a single method on your 
object.

 If it allowed specifying a SEL to call, on the observer, you wouldn't need a 
context parameter.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

> On 22 Sep 2016, at 19:53, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 22, 2016, at 03:16 , Gabriel Zachmann <z...@tu-clausthal.de> wrote:
>> 
>> That makes me wonder: why isn't it possible to register several, different 
>> observers for the same thing?
>> That way, I wouldn't need to care about observations I didn't create, would 
>> I?
> 
> Because the observer is an object. Your observation and a superclass 
> observation come from the same object. Whether these are to be treated as 
> different observations** cannot be determined automatically, hence the need 
> for a “context”.
> 
> The reason it’s messy is that the observer/notification API is old and 
> doesn’t follow modern API design practices. If this were being designed 
> today, the “observeValueForKeyPath…” method would likely be replaced by a 
> block/closure (similar to a completion handler) that’s passed as a parameter 
> to the “addObserver…” call, and there wouldn’t be any contexts.

Or it could be done like other places in Cocoa (was it NSTrackingArea? Or the 
event monitors?), where you get an "id" return value back (some unknown object) 
that represents your registration and that you keep around and pass to the 
remove call to specify which registration to unregister.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

On 22 Sep 2016, at 04:00, Doug Hill <cocoa...@breaqz.com> wrote:
> As to the context type, I would be interested to know of cases where the 
> observer doesn't have control over the context.

 As your quote says:

> "Contexts chosen in a similar manner in the super- or subclass will be 
> unlikely to overlap."

 It is to insulate code inherited from a superclass that observes the same 
property as code in the superclass. By using a unique context as an additional 
identifier for the subscription, the subclass can't accidentally unsubscribe 
the base class that still wants to stay subscribed.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

> On 22 Sep 2016, at 03:36, Graham Cox <graham@bigpond.com> wrote:
> 
> 
>> On 22 Sep 2016, at 10:40 AM, Quincey Morris 
>> <quinceymor...@rivergatesoftware.com> wrote:
>> 
>> On Sep 21, 2016, at 17:01 , Graham Cox <graham@bigpond.com> wrote:
>>> 
>>> This should be: if([(NSString*)context 
>>> isEqualToString:@“mediaLibraryLoaded”])…
>> 
>> Actually, this is not a good idea either, because *other* observations — 
>> ones you don’t control — might use a value that’s not an object, or not even 
>> a valid pointer.
> 
> 
> Fair point.
> 
> Which is yet another reason why void* is such a shitty concept. Apple could 
> easily have insisted that parameter was id without any real 
> problems, so void*… sheesh.
> 
> So Gabriel’s alternative is basically to use a global address, as you 
> otherwise suggested.
> 
> void* tsk… *goes away muttering*

No. It is not supposed to be a refCon or userInfo. It's a unique identifier for 
this observation (which can't be "self", because then observations registered 
by a subclass would get the same identifier as observations registered by the 
base class, and if one unsubscribes or re-subscribes earlier than the other, 
one could remove the other's observation and would break things.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

> On 22 Sep 2016, at 03:21, Slipp Douglas Thompson 
> <apple+cocoa-...@slippyd.com> wrote:
> 
> 
>> On Sep 21, 2016, at 8:00 PM, Slipp Douglas Thompson 
>> <apple+cocoa-...@slippyd.com> wrote:
>> 
>>> On Sep 21, 2016, at 17:01 , Graham Cox <graham@bigpond.com> wrote:
>>>> 
>>>> This should be: if([(NSString*)context 
>>>> isEqualToString:@“mediaLibraryLoaded”])…
>>> 
>>> Actually, this is not a good idea either, because *other* observations — 
>>> ones you don’t control — might use a value that’s not an object, or not 
>>> even a valid pointer.
>> 
> 
> I see your point about context plausibly not being neither an NSObject nor 
> nil.  While you could check if context is an NSObject beforehand (is there 
> even a reliable way to do this?  CocoaWithLove 
> <http://www.cocoawithlove.com/2010/10/testing-if-arbitrary-pointer-is-valid.html>
>  couldn't find a great approach ;-/)— I think coding consistently against all 
> other addObserver: calls in your app is a good-enough solution.  I.E. If you 
> implement observeValueForKeyPath: with [context isEqual: …] checks, make sure 
> all the other addObserver: calls (for those same keys, at least) are using 
> nil or NSObjects.

That's not enough. You would also have to ensure that none of Apple's code uses 
a non-object context in any KVOs it installs on any of your objects.

Which you can't.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.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

Re: Stupid objective-c question

[Uli Kusterer]

> On 22 Sep 2016, at 02:05, Gabriel Zachmann  wrote:
>> 
>>> how can the compiler know that '==' in this case is a NSString comparison?
>> 
>> It can’t because it isn't. What’s being compared are raw pointers. The 
>> string value is irrelevant.
> 
> Let me try to paraphrase, in order to check whether I am understanding 
> correctly.
> 
> Whenever I have two string literals @"XYZ" at different places in the same 
> compilation unit,
> and the XYZ are identical, then the compiler (or the Objective-C standard) 
> make sure that
> the pointers to those literals are identical?
> In other words, the compiler unifies the two occurrences of the two literals, 
> thus effectively storing only one literal?

 This is an optimization that Apple's compiler (and most compilers) currently 
apply for string constants, yes. However, they can only do that in the same 
executable. I.e. a framework or loadable plug-in bundle will get its own copy, 
as we can't know whether the executable loading it already has its own copy of 
that string or not. Also, of course, if you have an NSMutableString that ends 
up having the same content as an NSString, you get different addresses.

 If you want a more detailed answer, I blogged about this a while ago:

http://orangejuiceliberationfront.com/cocoa-string-comparisons-and-the-optimizer/

>> So, this technique is generally Not A Good Idea™.
> 
> If my understanding is correct, then I wholeheartedly agree.
> 
> That brings me to another question.  I've got this piece of code from an 
> example on MLMediaLibrary.
> 
> This is how I start the whole thing:
> 
>  [mediaLibrary_ addObserver: self
>  forKeyPath: @"mediaSources"
> options: 0
> context: (__bridge void *) @"mediaLibraryLoaded"];
> 
> And this is the beginning of the corresponding KVO:
> 
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>   change: (NSDictionary *) change context: (void *) 
> context
> {
>  MLMediaSource * mediaSource = [mediaLibrary_.mediaSources objectForKey: 
> MLMediaSourcePhotosIdentifier];
>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>  {
> 
> So what would be the proper way to do it?  Should I just define my own string 
> constant?

Do

void *kMediaLibraryLoadedKVOContext = 

for more details, see my other message in this thread.

-- Uli


___

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: Stupid objective-c question

[Uli Kusterer]

On 22 Sep 2016, at 02:02, Doug Hill  wrote:
>>> My question is: how can the compiler know that '==' in this case is a 
>>> NSString comparison?
>>> Or is some other magic going on here? if so, which?
>>> Does the compiler know it should perform some kind of dynamic method 
>>> dispatch?
>> 
>> My guess, without seeing the code that set up the observer, is that it was 
>> also set up with @"mediaLibraryLoaded", and the compiler collects and reuses 
>> string constants, so the address is the same. I'd guess that if you ensure 
>> that the string is a unique variable, it won't work.
>> 
>> NSString* s = [NSString stringWithFormat:@"%@%@%@", @"media", @"Library", 
>> @"Loaded"];
>> if(context == (__bridge void*)s)
>> 
>> Steve via iPad
> 
> For the above test, you could also try turning off the LLVM code-gen setting 
> "gcc_reuse_strings".
> (Which parenthetically, you probably wouldn't want to do in shipping code, 
> particularly if you have a lot of strings.)
> 
> But yeah, as everyone says, it's generally not a good thing to rely upon this 
> behavior, and just use -[NSString isEqual:]

 Do *not* call methods on the context to a KVO observation! It is not 
guaranteed to actually be an object! It is not storage for user data, it is 
simply a unique identifier for your subscription to these KVO callbacks.

-- Uli
___

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: Stupid objective-c question

[Uli Kusterer]

> On 22 Sep 2016, at 02:01, Graham Cox  wrote:
> 
> 
>> On 22 Sep 2016, at 9:44 AM, Gabriel Zachmann  wrote:
>> 
>> I have found on the net 
> 
> That isn’t always a recommendation ;)
> 
> 
>>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )

Gabriel,

this is a pointer comparison, not a string comparison. If the addObserver call 
happens in another module (usually unlikely) or Apple changes how its compiler 
coalesces string constants, this will break.

> Don’t do this, even if it appears to work. You got lucky, or are taking 
> advantage of undocumented implementation details.
> 
> This should be: if([(NSString*)context 
> isEqualToString:@“mediaLibraryLoaded”])…
> 
> I expect the first thing -isEqualToString: does is a pointer comparison, so 
> it’s unlikely to be significantly less performant for the case of when the 
> pointers are literally identical.

No, Graham, don't do that!

There is no guarantee that the context is a valid object. It is just supposed 
to be a unique pointer value so your class can tell a KVO notification from 
notifications for other observers on the same object (e.g. if a subclass 
observes the same value as a base class).

The best (but a bit clever) way to declare your context is

void* kMediaLibraryLoadedContext = 

this may look invalid, but actually just reserves a bit of memory in your app's 
globals section that now has a unique address. As a convenience, it writes this 
address into itself. So instead of  you can just 
write kMediaLibraryLoadedContext.

Cheers,
-- Uli



___

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: How to make Xcode launch a different app when "Running" my code?

[Uli Kusterer]

On 18 Sep 2016, at 12:02, Gabriel Zachmann <z...@tu-clausthal.de> wrote:
> When I "Run" my code in Xcode (i.e., hit CMD-R), I would like Xcode to build 
> the code, copy the product to its destination,
> and then run a *different* application, not the product it has built.
> (all on macOS, not iOS)

 Sure! Pick "Edit Scheme..." from the target selection popup in your Xcode 
window's toolbar. There, select the "Run" entry on the left. In the "Info" tab, 
you can set the executable to run to any executable in your project, or another 
arbitrary one. 

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Class is implemented in both

[Uli Kusterer]

On 15 Aug 2016, at 03:29, Trygve Inda <cocoa...@xericdesign.com> wrote:
> I have a Pref Pane and a Screen Saver module. They both share a common
> helper class (MyDisplayManager).
> 
> When the pref pane has been loaded and I go into the screen saver (or vis
> versa), because the host app is System preferences, I get:
> 
> Class MyDisplayManager is implemented in both One of the two will be
> used. Which one is undefined.
> 
> The class comes from the same source file. What is the best way to handle
> this? I could ignore it because the classes are the same (same source file)
> so it should not matter which one is used.
> 
> Is there a better way without duplicating and renaming the class?

Source file doesn't matter, it's the executable they're in. The "correct" 
solution would be to have a Framework that both link against. That way, the OS 
knows it's the same thing and loads it only once and links both to it. Of 
course, that only works if it is actually the same framework on disk. 
Otherwise, you may still get the loader seeing them as different (which is the 
only sane thing Apple can do, apart from checksumming both and thereby 
verifying they are actually identical, they really have no way they're the same 
version). So you'd probably need an installer that installs all three into 
predictable locations where they can find each other.

If you can't do that, the only thing you can do is have several different 
copies with different names. a #define in a precompiled header would work. You 
can have a separate header file containing all the shared stuff from any 
precompiled header you might have had before. That way, your PCH could look 
like this:

   #define MYScreenSaverAndPrefPaneHelperClass  
MYPrefPanesScreenSaverAndPrefPaneHelperClass
   #include "MyAppPrefix_Common.pch"

Just keep in mind that this define won't be picked up by any XIBs you're using. 
So if your class gets instantiated by a XIB, you need two versions, or at least 
a shell script build phase that does the same name replacement on the XIB and 
then manually feeds the result through ibtool. If your class only is the file's 
owner of a XIB, then you needn't bother. The file's owner's class is only 
advisory (you get whatever kind of object was passed in as owner when loading 
the XIB).

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Drag and Drop on iOS

[Uli Kusterer]

On 11 Aug 2016, at 13:49, Graham Cox <graham@bigpond.com> wrote:
> I have a small app that works on Mac, and I’m further developing an iOS 
> version of it.
> 
> I’m wondering what the general approach is for dragging an object from one 
> view to another in iOS is. On the Mac version, I simply use the usual drag 
> image+pasteboard approach, but on iOS this appears not to be supported. Both 
> of the views in question are subviews of the same window (obviously, since 
> iOS doesn’t have multiple windows) so that probably simplifies things. Is it 
> just a case of moving a CALayer belonging to a common ancestor view and then 
> doing whatever is needed to communicate between the views when the drag 
> completes? Or is there something in UIKit that handles some of that 
> generically? It wasn’t obvious where to look; I didn’t see anything in UIView.

Nothing specific, no. Useful tools are gesture recognizers (there is one that 
handles both a press-and-hold and the dragging afterwards, I think), turning 
off clipsToBounds on the container view sometimes also can be useful (e.g. for 
drag-out-to-delete). And people seem to generally add a layer shadow to the 
item being dragged, but beyond that you're pretty much back where you were in 
System 6 before the Drag Manager came around.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Ending NSTask doesn't release file handle opened by the task it wraps.

[Uli Kusterer]

On 21 Jul 2016, at 17:20, Graham Cox <graham@bigpond.com> wrote:
> One of my apps uses NSTask to wrap a command line utility that is embedded in 
> the same app’s resources. This utility writes files to disk - I have no 
> knowledge of which APIs it uses to do this. If the task has ended (and I can 
> see that the actual instance of the running command line tool has disappeared 
> from my process tasks in Activity Monitor), and I send the file to the trash, 
> I can’t delete it (empty trash) until the app as a whole is quit - I get the 
> message that the file is still in use.
> 
> I’ve checked that I’m closing down the NSTask properly, as far as I can see.
> 
> Is this the expected behaviour?

Are you reading all the data from the task (i.e. its standardOutput, not the 
file) before you close it? AFAIR that's a prerequisite for it to properly close.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: How to implement a control/view that maps to a "String?" (in Swift)

[Uli Kusterer]

On 04 Jun 2016, at 21:43, Daryle Walker <dary...@mac.com> wrote:
> I guess I could implement a “String” property with a NSTextView.  What about 
> a “String?” though.  NIL and empty strings are distinct in the model, and 
> I’ll like to reflect that in the document window too.  (Although no one but 
> me would pick a NIL option over an empty text-view and string.)  I was 
> thinking of a tab-view, one pane with the text view, and the other with a 
> placard saying there is no text section yet and a button to add one.  (I 
> would have a menu item to remove the section, to edit the other way.)
> 
> Is this a good way to present in the window?  Any gotchas?  (Oh, this is on 
> OS X and I’m using storyboards.)

I'd just put a checkbox in front of the field. Check it off to mean NIL, check 
it on to enable and edit the text field.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Application Activation Problem

[Uli Kusterer]

On 18 May 2016, at 14:25, Dave <d...@looktowindward.com> wrote:
> My curiosity got the better of me and I looked at NSWorkspace again and found 
> the activeApplication but it was deprecated in 10.11, however when I looked 
> for closely I found frontmostApplication which is (I think) exactly what I 
> want! Thanks for the tip.

 That's even better than iterating runningApplications, I suppose. Though if 
the app you're launching is a GUI app, you may want -menuBarOwningApplication 
instead.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Application Activation Problem

[Uli Kusterer]

On 18 May 2016, at 12:44, Dave <d...@looktowindward.com> wrote:
> I got side-tracked with some other issues and will be taking another look at 
> this on Friday and I will certainly have a good look at the available 
> methods/properties of NSWorkspace, but from memory I don’t think there is a 
> method that returns the currently active application, although I could be 
> wrong. If there were it would be relatively easy to do this.

 Not NSWorkspace, NSRunningApplication. You can get a list of running 
applications from NSWorkspace. NSRunningApplication.active can then be 
KVO-observed to find out when it becomes frontmost, according to the comments 
in that header.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Application Activation Problem

[Uli Kusterer]

On 17 May 2016, at 10:34, Dave <d...@looktowindward.com> wrote:
>> On 16 May 2016, at 22:17, Jerry Krinock <je...@ieee.org> wrote:
>> 
>> Dave, I’ve tried to do stuff similar to this with NSWorkspace, and found it 
>> to be often frustrating.  According to your initial post, you’ve already 
>> tried pretty hard.  If lengthening the time delay still does not work good 
>> enough for you, then, 
>> 
>> • If the apps that you want to cycle through are *your* apps, make them talk 
>> to one another using some proper interapplication communication.
>> 
>> • If the apps that you want to cycle through are *others’* apps, then I 
>> agree with Ken that you should reconsider if you really “need” to do this.
> 
> They are not my Apps, and I have and I do! I’d have never opened this can of 
> worms if I didn’t have to!
> 
> I’m really surprised that there doesn’t seem to be a “Application Ready” type 
> notification. It struck me that this is a similar problem to AppleScript:
> 
> tell application “X”
>   activate
> end tell
> 
> I remember quite a while back that I had problems if I tried to send events 
> to the Application too soon after the activate statement, this was usually 
> fixed by adding a delay. These days it the above statements seem to work and 
> I’m wondering if some code has been added to stop this from happening, and, 
> if so if I could do something similar.

 Have you looked into NSWorkspace's NSRunningApplications yet? I think it lets 
you check which one is active.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: NSTableView is messaging zombie delegate

[Uli Kusterer]

On 08 May 2016, at 21:19, Matthew LeRoy <mle...@minitab.com> wrote:
> Unfortunately, setting the table view’s delegate to nil during tear-down 
> (either in -windowWillClose: or in NSViewController’s -dealloc) doesn’t seem 
> to fix the issue. I still get random but regularly reproducible crashes, with 
> the same stack trace.

Random ideas that may look similar:

1. -copy being called by the OS on a subclass of an AppKit class that you made 
(NSCells are popular for this), where you forgot to override -copyWithZone:
2. Random memory smasher (easily caused by manipulating UI from another thread)
3. Some MRC code in your ARC code over-releasing an object before it's even 
handed to NSViewController as a delegate.

… uh, can't think of anything else right now.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Pinning a Window to a Window

[Uli Kusterer]

On 23 Apr 2016, at 14:27, Dave <d...@looktowindward.com> wrote:
>> On 22 Apr 2016, at 18:17, Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
>> - Whether you want in the app store. If not, 
> Not, don’t want the App in the App store and the I’m not the developer of the 
> other app.
> 
> I just want to put a window in front of another a window in a given 
> application and have it track that Window. A bit like if you have a sheet 
> displayed on a Window, if you move the main window the sheet moves with it, 
> if you click in the window of another App, and that App’s Window overlaps the 
> the Window with the Sheet up, then it will appear on top of both the Main 
> window and the Sheet.
> 
> Because my window is a “Floating Window” it floats above the Windows of ALL 
> applications, I want it to just float above the window in the App it is 
> pinned to.

 Is it really like a sheet, or is it more like xScope, where you annotate parts 
of that other window? The approach Bill Cheeseman suggests could work for the 
latter case, though I would say that, for performance reasons, you probably 
want to make your window smaller and move it around instead of redrawing every 
time.

>> you could theoretically inject your own code into another app and then add 
>> your own views or windows (but this has a lot of potential to break the 
>> other app, so isn't very popular and very hard to get right)
> 
> I’m all ears and would love to know more about this?

 I haven't done this in ages, but the basic approach is that you find some kind 
of plugin that gets loaded into the other application and are thus able to run 
in that process (Input Managers, AppleScript Scripting Additions, or the like 
... search terms are SIMBL, Haxies or Osax, usually. Xcode and Mail also have 
plugin mechanisms, as do Photoshop and a few other big names), and then you can 
just make your window a subwindow of the existing one. Or you find some code 
that lets you inject code into another application, like Wolf Rentzsch's 
mach_inject.

 But really, if you can at all avoid doing this, I'd recommend you find another 
way. We've had support nightmares caused by other developers who injected 
themselves into our applications and made assumptions that didn't hold, and it 
took us ages to realize where the code was coming from that was causing 
unexpected behaviour in *our* application. You'll have to program very 
defensively.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Pinning a Window to a Window

[Uli Kusterer]

On 22 Apr 2016, at 15:23, Dave <d...@looktowindward.com> wrote:
> Is there any way of “pinning” one of my App’s windows so it is always in 
> front of a window owned by another application? I’m using a Floating Window 
> style at the moment, which works ok, but the window floats in fronts of 
> everything. I’d like my window to always be just in front of the target 
> window. Is this possible?

 Not really. That said, there are numerous answers depending on your concrete 
circumstances, like:

- Who owns the other application (are you developer of both, or are they 
willing to help, or do they offer plugin mechanisms), or is it maybe a 
particular application (e.g. Finder keeps the desktop background in a separate 
window from the one holding the icons, so you can sneak a window in between, 
and also offers Finder Sync extension API).
- What your window does. (Sometimes it looks like you need your own UI, when 
really just using a Service that adds a contextual menu item can get your 
functionality in the other app and make it look built-in to the user)
- Whether you want in the app store. If not, you could theoretically inject 
your own code into another app and then add your own views or windows (but this 
has a lot of potential to break the other app, so isn't very popular and very 
hard to get right)

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Proper way to set up constants when building an iOS framework

[Uli Kusterer]

On 12 Apr 2016, at 19:30, Alex Zavatone <z...@mac.com> wrote:
> On Apr 12, 2016, at 12:43 PM, Charles Jenkins wrote:
> 
>> I imagine you’re already doing this, but your message wasn’t clear, so 
>> forgive me if I sound patronizing.
>> 
>> The constants should be declared extern in the header file, but not assigned 
>> any values. The value assignments should appear inside a single .m file in 
>> your framework.
> 
> I am not doing that.  But it's what I'm going to be doing now.
> 
> So, define them like this:
> 
> SecurityDefaults.h
> 
> extern NSString * const ABC_MY_IMPORTANT_CONSTANT;

NB - Just to save you some pain in the future, this is called a "declaration", 
not a definition. It is like a function or method prototype. It just tells the 
compiler "trust me, when it comes time to linking, there will be a variable 
with this name and type". The "definition" is what you then write in the .m 
file, and is the one, canonical definition of your constant.

Also, if this is a Cocoa project, I recommend you stick to the AppKit 
convention and use neither all-upercase nor the 'k' prefix, and instead just 
use inter-caps and your prefix. Like 
NSApplicationDidFinishLaunchingNotificationName. Less surprise for new people 
coming on the project that way.

Alex wrote:
> One thing though.  I did do a #import of "Constants.h" into my framework's 
> header file and that's not filling the role of what a .pch would fill in a 
> standalone app, even though I thought that someone said it would.

 A precompiled prefix header is a compile-time construct that only applies to 
the interior of your framework. You can't really tell people linking to your 
framework to add a certain prefix header. So you can use a pch for actually 
writing the framework implementation, but have to be careful to not require 
that someone has a certain PCH in the headers that you expose via your 
framework's headers folder (copied by the build phase). However, since clients 
usually #import your framework's umbrella header anyway, you could just put all 
important includes into the umbrella header (or headers included by your 
umbrella header) and then put your umbrella header into your framework's PCH. 
That way, you can write code without having to manually include stuff and any 
client gets the same combination of headers. If they want, they can then put 
the framework include into *their* PCH (i.e. usually the host app's).

 That said, having everything in your prefix header invites people to add 
dependencies to their code across all module boundaries, so I would recommend 
manually including only the very headers the code in a particular location 
needs. It's a bit more typing, but it makes for more honest code, as modules 
who acquire too many includes are immediately visible and invite you to split 
them up or re-arrange them, that way restoring loose coupling and making your 
code more maintainable, and more reusable.

Alex wrote:
> If I put the #import there, the app immediately gets build errors.
> 
> Am I missing something on where I should import the constants' header?

Do you have a "Copy Headers" build phase to copy your headers into the built 
product's package?

You may also want to read up on the C concept of "compilation units". Basically 
it means that (Objective)C(++) can only compile source files, not headers. So 
what it does is it goes through the list of sources in your project, compile 
each separately by taking a copy of it, replacing all #include and #import 
statements with the contents of the corresponding header file, and then taking 
that one huge source file and compiling it, making a note of all symbols it 
defines.

This means for one that including an ObjC header from a C file loses the 
information that this header was ObjC, as it all gets "pasted" into the .c file 
currently being compiled. So if your header gets included by a different 
language source file, you'll get all sorts of funny errors because the C 
compiler does not understand what '@interface' means etc. This could be one 
reason for the errors you're getting.

Charles wrote:
> Also, because of my C++ background, I’d see if the compiler would accept 
> NSString const * const, because you want a constant pointer to an NSString 
> that is constant; but I recognize that may not be the way things are done in 
> Obj-C.

Yeah, while in general that would be true, there currently is no such thing as 
a NSString const as far as the ObjC compiler is concerned. ObjC's constants are 
still sort of a runtime construct ... in some ways, AFAIR. 

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

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

Please do not post admin request

Re: Window updates stall on headless Mac mini

[Uli Kusterer]

> On 21 Mar 2016, at 20:19, Steve Mills <sjmi...@mac.com> wrote:
> 
> On Mar 21, 2016, at 14:09:48, Ken Thomases <k...@codeweavers.com> wrote:
>> 
>> Thread 9 is apparently what's blocking your main thread.  It is animating a 
>> progress indicator.  I have encountered my own problems with this heartbeat 
>> thread deadlocking Cocoa.  (You are not encountering a deadlock, per se.)  
>> You can try removing the progress indicator from your UI, turn off its 
>> animation, or configure it to not use threaded animation (set the 
>> usesThreadedAnimation property to false; you can do this in IB via user 
>> attributes).
> 
> Interesting. I'd looked at that thread and assumed that Apple knew what they 
> were doing, so I ignored it. Thanks again for you expertise.

 It could be a combination of Ken's and Carl's issues: drawing taking 
unexpectedly long due to GPU not being activated, and that in turn causing the 
heartbeat thread to take out the lock too often, starving the other thread.

 It could also be a side effect of anything else you're doing on a thread. 
Particularly if, somewhere, you're accidentally doing UI on a non-main thread.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:25, Alex Zavatone <z...@mac.com> wrote:
> Would it be recommended to package my ARC code with ARC turned off and 
> package that in a framework and then link to that from the non ARC app that 
> will need to load it?

 Nope, that would leak all over the place, or dangle pointers depending on 
whether you're prone to using alloc/init and new to create your objects, or 
factory methods.

 Think of ARC this way: ARC manages memory for you (except for circles of 
strong references, aka retain cycles, those you have to resolve by marking 
back-references as weak) inside ARC-using source files. Basically, it inserts 
the requisite retain/release calls for you. So, once generated, ARC code is 
(for all we care for this discussion) undistinguishable from non-ARC code.

 However, you need to help ARC at the bridging point between ARC and non-ARC by 
following ObjC's naming conventions, and also by properly marking references as 
strong or weak. For your non-ARC classes that are referenced by ARC, this means 
if you have a -copyMachine factory method, ARC will see the "copy" and assume 
it's a method with copy semantics instead (+1 reference returned), and end up 
over-releasing the +0 reference of the factory method. The other way round is 
similar. If you create a -copyMachine method, ARC will just return a +1 
reference from it and any other code using it must release it once done to 
avoid leaking.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: ARC code in a non ARC app. iOS

[Uli Kusterer]

On 24 Feb 2016, at 00:47, Quincey Morris <quinceymor...@rivergatesoftware.com> 
wrote:
> For example, an object obtained via [[…alloc]init…] is generally assumed to 
> be returned with a +1 ownership, but an object obtained via a class method 
> named ‘newXXX…’ is generally assumed to be returned with +0 ownership.

 Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? 
Because +new is documented to just be a shorthand for +alloc followed by -init 
on the result, so +newBlah behaving differently than +new sounds kinda 
inconsistent to me. Did I miss a serious gotcha there?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: ScalableUserInterface.framework

[Uli Kusterer]

On 15 Feb 2016, at 23:53, Raglan T. Tiger <r...@crusaderrabbit.net> wrote:
> A target that has been building suddenly throws a link error:
> 
> ld: file not found: 
> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
>  for architecture i386
> 
> Other targets in the project build jus fine linking the same frameworks.
> 
> Any help would be most appreciated.
> 
> (Yes, I know this is a Cocoa list, but this is where the smart people are to 
> be found!)

Wildly guessing here:

Are you actually explicitly linking against ScalableUserInterface? You should 
really only be linking against QuartzCore, not any of the embedded frameworks.

Alternately, are you really linking against the framework in 
/System/Library/Frameworks? You should really be linking against the framework 
from the SDK.

Finally, did you just update Xcode or change the SDK? Maybe the current SDK is 
now 64-bit only, but your app is still 32/64, and so it won't link because it 
can't find the 32-bit linking info anymore.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Obj-C - your thoughts on hiding data members?

[Uli Kusterer]

On 27 Jan 2016, at 12:30, Dave <d...@looktowindward.com> wrote:
> I find the “_” very difficult to see and also I tend to think of it as “Apple 
> Reserved”, which I think it used to be?

Still is, for *methods* so for selectors/properties. However, a single 
underscore is fine for instance variables backing a method, and in fact is the 
default when auto-synthesizing. And it's also not in violation of the C 
standard's rules about underscored and double-underscored identifiers (see e.g. 
here for a good summary of those 
http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier).

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Any way to intercept the URL-opening mechanism on OS X?

[Uli Kusterer]

On 03 Jan 2016, at 00:04, Conrad Shultz <conrad_shu...@apple.com> wrote:
>> On Dec 22, 2015, at 3:51 PM, Rick Mann <rm...@latencyzero.com> wrote:
>> 
>> You know how you can click links in email, and heck, to open them in Safari 
>> (or whatever browser)? Is there any way to write an extension of some sort 
>> that can intercept this and re-write the URL? I tried to write a filter in 
>> Safari proper for the URL that the user pastes into the address bar, but 
>> Safari plug-ins don't have access to that.
>> 
>> I want to write a thing to strip all the utm_* parameters off the URLs.
> 
> Rather than a plug-in, would a Safari extension do what you need? You might 
> take look at 
> https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/WorkingwithWindowsandTabs/WorkingwithWindowsandTabs.html

You could probably modify Weberal Express to do that: 
https://github.com/gnyrd/WebEx ?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Getting the final value from an NSSlider drag

[Uli Kusterer]

> On 29 Dec 2015, at 23:45, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Dec 29, 2015, at 5:44 AM, Graham Cox <graham@bigpond.com> wrote:
>> 
>> On 29 Dec 2015, at 7:44 PM, Roland King <r...@rols.org> wrote:
>>> 
>>> I can subclass NSSlider or possibly NSSliderCell but that sounds like a 
>>> whole world of pain, if I have to do that I’ll probably just put a 
>>> coalescing delay into the whole thing which waits 1/2 second after an 
>>> update before it actually does the update. 
>>> 
>>> Any good ways to do this? 
>> 
>> In your action method, call another method that handles the final value 
>> using -performSelector:withObject:afterDelay: but just before you do that, 
>> call +[NSObject cancelPreviousPerformRequestsWithTarget:...] for the same 
>> message. This schedules a deferred message but immediately cancels it as 
>> long as the values come pouring in. On the last time, when you stop moving 
>> the slider, the final -performSelector will get to its target and do its 
>> work. The afterDelay parameter can be set to whatever value you think you’ll 
>> need to allow for a slowly moved slider NOT to fire the final message. I 
>> typically use 0.1sec.
> 
> This gives false positives if the user simply stops moving the mouse but 
> doesn't release the mouse button.  There's no delay you can specify that 
> avoids this, since there's no upper bound to how long the user can hold the 
> mouse button.  (With assistive technologies, the user doesn't even have to be 
> actually holding anything for the duration.)

 It shouldn't. performSelector:afterDelay: schedules using 
NSRunLoopDefaultMode, while the slider uses NSEventTrackingRunLoopMode. So it 
will never fire while the slider is still tracking. In fact, you could use 0.0 
as the delay.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: applicationSupportDirectory access for admin and standard users

[Uli Kusterer]

On 21 Dec 2015, at 23:16, Jonathan Mitchell <jonat...@mugginsoft.com> wrote:
> NSURL *appSupportDir = [[NSURL alloc] initFileURLWithPath:[[NSFileManager 
> defaultManager] applicationSupportDirectory] isDirectory:YES];

 Have you tried running this code in the debugger? Have you checked whether 
there are any console logs when you run this code? Why haven't you posted any 
results of those?

 I just plonked this code into CodeRunner and immediately get the following 
exception log:

2015-12-28 09:46:51.689 Untitled[44980:2704545] -[NSFileManager 
applicationSupportDirectory]: unrecognized selector sent to instance 
0x7fe969402450
2015-12-28 09:46:51.694 Untitled[44980:2704545] *** Terminating app due to 
uncaught exception 'NSInvalidArgumentException', reason: '-[NSFileManager 
applicationSupportDirectory]: unrecognized selector sent to instance 
0x7fe969402450'

And, in fact, when I check the NSFileManager.h header in the 10.11 SDK that 
seems to be true: NSFileManager doesn't declare an applicationSupportDirectory 
method, it seems.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Finder-like user interface?

[Uli Kusterer]

On 28 Dec 2015, at 01:15, Graham Cox <graham@bigpond.com> wrote:
>> On 28 Dec 2015, at 9:45 AM, SevenBits <sevenbitst...@gmail.com> wrote:
>> 
>> For a new application I’m building I need to have a view showing a 
>> grid-based layout of files, similar to the default view of the Finder. I’m 
>> not sure how to implement this. NSCollectionView appears to suffice, and 
>> I’ve used it before, but it simply isn’t performant as it doesn’t reuse 
>> cells, and it doesn’t seem like it’s designed for this kind of thing. On the 
>> other kind, NSBrowser seems to be built for representing the file system, 
>> but based on example code I’ve found on ADC it only seems suitable for 
>> building an interface out of Miller columns, which isn’t suitable for me.
>> 
>> Is anyone aware of how to do something like this? I’m open to using 
>> 3rd-party components and/or code if necessary.
> 
> I’ve used Uli Kusterer’s UKDistributedView for this, using a cell class of my 
> own, and a few other mods. I’m not sure if Uli is still maintaining this, but 
> it did the job.  
> http://www.cocoabuilder.com/archive/cocoa/93982-ann-ukdistributedview-finder-icon-view.html
> 
> Uli reads this list, he may be able to tell you the latest news.

 I'm using the version on my Github at 
https://github.com/uliwitness/UKDistributedView in Stacksmith, so it still 
compiles and runs. That said, the look of the included cell is not quite 
in-line with today's Finder (I think it's more like 10.5's or so), and if I was 
doing this class again today, I'd probably try to switch to using CALayers 
instead of cells. Also, of course the IB plugin stuff in there is no longer 
useful. But the main view and cell classes proper should be a decent (and 
reasonably performant) starting point for your needs. Pull requests are 
appreciated.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Best way to get a file path for presentation to the user

[Uli Kusterer]

On 19 Dec 2015, at 09:51, Graham Cox <graham@bigpond.com> wrote:
> My use case is an interface that sets up a batch of files for saving in a 
> particular folder. The user chooses the folder using a standard NSOpenPanel, 
> but I want to display the chosen location in the UI so that they don’t need 
> to remember it. I don’t think a NSPathControl is really appropriate for this.

 What gives you that impression? That seems to be exactly what it was made for.

> But I do want the string to be the most understandable for the user. I don’t 
> know really how many average users understand what ~/ means, but it’s 
> probably the best I can do.

 "~" is a nerd thing. If you're in any way in touch with whoever does your 
support, you don't want to add something this confusing to your GUI. What I did 
in UKFilePathView is just shorten the path at the start to a point of interest 
when displaying it, e.g. having the path display just start at the home folder 
and using the file icon to have the user recognize it is a user folder.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Best way to get a file path for presentation to the user

[Uli Kusterer]

On 18 Dec 2015, at 21:33, Ken Thomases <k...@codeweavers.com> wrote:
> On Dec 18, 2015, at 12:23 PM, Jens Alfke <j...@mooseyard.com> wrote:
>> 
>>> On Dec 18, 2015, at 1:24 AM, Graham Cox <graham@bigpond.com> wrote:
>>> 
>>> I want to display a path to the user. I have a URL, I need to show the 
>>> local file path that represents (it’s always a local file path), where the 
>>> /Users// is replaced by ~/
>> 
>> The best methods for this are in NSFileManager:
> 
>> - (NSString *)displayNameAtPath:(NSString *)path;
> 
>> - (nullable NSArray *)componentsToDisplayForPath:(NSString 
>> *)path;
>> 
>> There are other transformations to the path for display besides “~”. For 
>> example, the user should never see “/Volumes”, or hidden suffixes like 
>> “.app”. And some names get completely localized for display — the 
>> “Downloads” directory looks like “Dvökhn¶r” in Elbonian, for example.
> 
> And in a UI, it may be better to use an NSPathControl than to display a path 
> as text.

Definitely recommend using an NSPathControl and to avoid displaying a path at 
all. Most users don't understand file paths. Also keep in mind that display 
names are HFS-style names that may contain slashes, so using a slash as a path 
separator with those can lead to wrong display.

Check out what the "Open recent" submenu does with file names for a good idea 
to follow if you can't use a path control. Particularly how it distinguishes 
between two files with the same name in different locations.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: CGContextClipToRects: invalid context 0x0.

[Uli Kusterer]

On 18 Dec 2015, at 17:59, Richard Charles <rcharles...@gmail.com> wrote:
> Debugging a linked library without symbols is difficult (bordering on 
> impossible).

 It's not easy, but far from impossible. If you can read assembly, you can 
usually figure out quite a lot. The debugger will disassemble stack frames for 
you when you step into them. It would be a little easier for Objective-C code, 
where all method names are registered publicly, as are class names and a good 
part of each object's layout.

It helps to familiarize oneself with LLDB's commands. Particularly what 
registers 64-bit apps use to store parameters and how to print them from inside 
a method call, and how the 'po' command works for printing objects.

But for complaints about an invalid context, it sometimes helps to verify that 
any API you use from the library this error comes from is documented to accept 
NULL where you pass it NULL. And in this case I'd also print the current 
CGContext before any calls you make, and ensure that you save and restore your 
context before and after any calls where you change it, especially if you 
create your own contexts. And ensure that you retain any contexts that you're 
keeping around across calls, and verifying that your window is visible and not 
deferred if you try to draw in it. (This is all assuming you're not making a 
basic mistake like calling drawRect: directly or (even indirectly) requesting 
redraws from inside drawRect:

If none of this helps, a common occurrence of weird behaviour like this is also 
sometimes screwing up internal state by using thread-safe API that is not 
documented to support being used from more than one thread at once, or API 
that's not safe to use from non-main threads at all, from several threads. Any 
if that ring a bell?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: changing the name of my webview

[Uli Kusterer]

On 17 Nov 2015, at 00:30, Scott Berry <sb356...@gmail.com> wrote:
> In my main storyboard I’d like to call my web view “BrowseAirports.”  How do 
> I tell Xcode to do this so that when I call the code to open the web view it 
> knows that my web view in storyboard is “BrowseAirports”?

Do you mean some name the user actually sees, or the one in Xcode's outline 
view for a XIB file? If the latter, just click the little box at the bottom and 
to the right of the bar containing all the toplevel objects of your XIB to show 
their names and the full outline, and then just double-click a name to edit it.

Or do you mean the HTML title tag?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Identifying a specific Mac model

[Uli Kusterer]

I just tried it on the golden MacBook (in IB) and I got a golden icon.

> On 15 Sep 2015, at 15:59, John Daniel <etresoft.apple.li...@icloud.com> wrote:
> 
> Thanks! That did the trick. It took a couple of tries to get it working. I 
> forgot that the namedImage method returns a scaled down image. it is a little 
> counter-intuitive, but you have to scale the image up and then it will pick 
> the bigger image in the icns file.
> 
> I still don’t know if it will display in gold on a new MacBook, but it seems 
> to work on two MacBookPros and an iMac.
> 
> John Daniel
> i...@etresoft.com
> 
> 
> 
>> On Sep 14, 2015, at 12:43 PM, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>> 
>> If you just want to current machine icon, just use + [NSImage 
>> imageNamed:NSImageNameComputer]
>> 
>> 
> 
> 
> ___
> 
> 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/witness.of.teachtext%40gmx.net
> 
> This email sent to witness.of.teacht...@gmx.net

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: best way to implement a clickable grid?

[Uli Kusterer]

On 15 Sep 2015, at 02:35, Jens Alfke <j...@mooseyard.com> wrote:
> I would probably just implement it as a custom NSView. Then it doesn’t even 
> have to be represented in memory as a grid; you just remember the level for 
> each x coord and fill in the appropriate squares when drawing.
> 
>> Or is there a better way to handle click events on a simple NSView?
> 
> Just override mouseDown:, mouseDragged:, mouseUp:. You’ll have to convert the 
> event coords from window to view coords.

 Oh, if you go the route of a custom view like Jens and I suggest, don't forget 
to implement Accessibility for it. You can probably just give a number 
indicating the level, but otherwise you might have to do whatever NSSlider does 
to expose itself to Accessibility. Or maybe you could just subclass NSSlider, 
replace all the tracking and drawing code, and that way get Accessibility for 
free.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: best way to implement a clickable grid?

[Uli Kusterer]

On 15 Sep 2015, at 02:17, Patrick J. Collins <patr...@collinatorstudios.com> 
wrote:
> Hi everyone,
> 
> I am looking to implement something that would look somewhat like a
> graphic equalizer.  Meaning, a grid of blocks...  Clicking on a single
> grid block would change the appearance of all cells directly under it..
> So in other words, clicking on 1,1 would turn on 1,1. but clicking 1,5
> woudl turn on 1,5, 1,4, 1,3, 1,2, 1,1...
> 
> I am curious if anyone here has a suggestion of what the best design
> approach would be for something like this?  Should I just
> programatically generate a bunch of NSViews?  Should I overal an
> invisible button over each view?  Or is there a better way to handle
> click events on a simple NSView?
> 
> Any push in the right direction would be greatly appreciated.  Thanks!

I'd generally use a single view and use the click Y coordinate to determine 
which segment was clicked, then I'd have two images, one containing unselected, 
the other selected versions of the grid elements, and would just clip to those.

It's what I did for our equalizer display. Although I in fact used two CALayers 
to show the image. That way the clipping happens on the GPU and the CPU doesn't 
constantly need to update the entire image and upload it onto the GPU. IIRC the 
contentsRect property is what I used to tell the GPU how to clip the drawing in 
the "selected" layer.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Mantaining legacy APIs in a framework

[Uli Kusterer]

On 01 Sep 2015, at 01:09, Graham Cox <graham@bigpond.com> wrote:
> Apple’s frameworks do this quite often, but I’m not sure how to achieve this 
> in my own. Something simple like -respondsToSelector: isn’t any good, because 
> of course it always does respond to the selector in the base class, and the 
> framework has no knowledge of subclasses beyond its own borders. Seems like 
> I’d need to drop down into the runtime functions but it’s still not really 
> obvious what would work. How do Apple do this?

 Do subclasses call the superclass method, or not? If they don't (neither in 
their override, nor from outside), you could just remove the method in the base 
class, then implement -foo:withBar: to call -foo: if present?

 Alternately, you could offer a new base class. Anyone who wants to write 
against the new API, has to use the new base class. Existing code keeps linking 
against the old class, which still implements -foo:. You could then override 
-init to create an instance of the new class if the user just creates an 
instance of the old class without overriding anything.

 Or maybe you could walk the method list of a subclass instance and check if 
anyone below your base class implements -foo:, and if yes, swizzle in a 
compatibility implementation of -foo: or one of -foo:withBar: that calls -foo:?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
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: Xcode warning from linking to a third-party framework in both app and in framework included in app?

[Uli Kusterer]

On 18 Aug 2015, at 17:48, Steve Mykytyn smyky...@gmail.com wrote:
 Both the app and the included framework use
 
 objc[1735]: Class PFObject is implemented in both included framework and
 app. One of the two will be used. Which one is undefined.
 
 I guess I could simply make sure to only use Parse my private framework,
 but it seems like this should be fixable somehow...

Yeah, sharing the same framework among both is really the only safe solution. 
Otherwise if one of those ends up being a different version, one of the clients 
will get the wrong version of *that one class* while other classes might be 
newer/older. You'll get fun random crashes.

Also, if you have internal, non-exported globals that contain unique values 
(like KVO keys that are used with pointer equality), you might suddenly have 
two copies of them, one for each framework, which would also cause issues 
because they won't be seen as identical when they should.

You definitely don't want to have two copies of the same framework linked in. 
Too much opportunity for things to go wrong, run twice etc.

If you must, use #defines and edit the XIBs so the class names are different 
(e.g. by prefixing all classes etc.), but that's hairy to do consistently 
without missing one, especially if it's not your code.

Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
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: Private Methods

[Uli Kusterer]

On 18 Aug 2015, at 16:58, Richard Charles rcharles...@gmail.com wrote:
 Also why does Apple say If you are subclassing a large Cocoa framework 
 class”. What if I am subclassing a small Cocoa framework class. What 
 difference would it make?


 Statistics. Small classes probably only consist of the public API, or maybe 
even just of getters and setters. OTOH large classes are very likely to have 
more methods under the hood to implement all the functionality they provide.

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...



___

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: ARC and Manual Memory Management

[Uli Kusterer]

On 10 Aug 2015, at 13:59, Dave d...@looktowindward.com wrote:
 Has anyone come up with a way of having the source code support both ARC and 
 Manual Memory Management without using #IFDEF or #IF ?
 
 I’ve never understood why the compiler doesn’t just ignore code like:
 
 [super dealloc];
 
 [MyObj release];
 
 If it’s being compiled for ARC, that way both could be compiled with the same 
 source code or is there more to it?

 Because then there'd be no point in using ARC. ARC is supposed to take the 
hassle of manual memory management off your hands, and automate it to avoid 
mistakes. It is also less misleading if the retain/release lines aren't in your 
code, compared to having them in there but being no-ops. It also inter-operates 
seamlessly with non-ARC code (as it generates the retains and releases for you, 
it is equivalent to manually managed code to any non-ARC caller).

 Is there a reason why you can't add -fobjc-arc to the compiler flags for the 
files that use ARC in your non-ARC projects? That way, you can bit by bit move 
your project to ARC, yet don't have to manually manage the new code.

 The only reason I'm aware of is if you need to port to a platform that doesn't 
support libArclite (like really old Mac/iOS versions).

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: ARC and Manual Memory Management

[Uli Kusterer]

 On 10 Aug 2015, at 21:12, Dave d...@looktowindward.com wrote:
 
 
 On 10 Aug 2015, at 19:11, Uli Kusterer witness.of.teacht...@gmx.net wrote:
 
 On 10 Aug 2015, at 13:59, Dave d...@looktowindward.com wrote:
 Has anyone come up with a way of having the source code support both ARC 
 and Manual Memory Management without using #IFDEF or #IF ?
 
 I’ve never understood why the compiler doesn’t just ignore code like:
 
 [super dealloc];
 
 [MyObj release];
 
 If it’s being compiled for ARC, that way both could be compiled with the 
 same source code or is there more to it?
 
 Because then there'd be no point in using ARC. ARC is supposed to take the 
 hassle of manual memory management off your hands, and automate it to avoid 
 mistakes. It is also less misleading if the retain/release lines aren't in 
 your code, compared to having them in there but being no-ops. It also 
 inter-operates seamlessly with non-ARC code (as it generates the retains and 
 releases for you, it is equivalent to manually managed code to any non-ARC 
 caller).
 
 If it just ignored those constructs, it was be much less confusing, simply 
 because there would only one set of source code. release or dealloc are not 
 guaranteed to do what is says on the tin anyway, I mean you can override them 
 and do whatever you want. I can’t see that ignoring or just having empty 
 methods under ARC would make it more confusing, especially if the compiler 
 emitted a warning. But there is no point in worrying about it now since I 
 can’t see them changing it!!! lol
 
 Is there a reason why you can't add -fobjc-arc to the compiler flags for the 
 files that use ARC in your non-ARC projects? That way, you can bit by bit 
 move your project to ARC, yet don't have to manually manage the new code.
 
 That’s even more confusing then having them as no-ops, because it not obvious 
 when you open a file whether it’s ARC or not and it’s quite hard to quickly 
 find out.
 
 The only reason I'm aware of is if you need to port to a platform that 
 doesn't support libArclite (like really old Mac/iOS versions).
 
 Well, that wouldn’t work for categories on Cocoa objects, or would it?

 Why wouldn't it work for categories? The generated code contains 
retains/releases They're just implemented via objc_retain() instead of 
[retain]. Only the source is different.

 I’m beginning to think that using the flag is the best option, or just 
 forgetting about having a common source base and dupe them.


 You can use the flag others mentioned to turn off ARC, or (if you're not on 
old OSes where ARC is unavailable, but just running code that you haven't 
converted to ARC yet) the one I mentioned to turn it back on, IIRC. Also keep 
in mind that you can start your ARC-using files with

#if __has_feature(objc_arc)
#error This file needs ARC
#endif

to make it obvious they use ARC *and* to prevent yourself from shooting 
yourself in the foot in mixed code (I guess the errors you get from calling 
release should make it easy to detect non-ARC files under ARC).

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: Improve performance of data structure saved to disk

[Uli Kusterer]

On 06 Aug 2015, at 15:36, Juanjo Conti jjco...@carouselapps.com wrote:
 I've checked the number of entries and is only 350. They are regular
 cookies for well known sites like google, new relic, twitter...

 That should not be a performance bottleneck. How often are you calling this 
(let's call it saveAllCookies for lack of a better term) on your entire cookie 
storage per whatever unit of time makes sense? Like, when a new cookie comes 
in, is there more than one call to saveAllCookies? 

 This is part of a CookieStorage class replacement, so I read/write the hole
 storage each time a cookie is set or deleted.

 So, how large is the biggest cookie? What's the average size? If your cookies 
are large, it might be better to just individually serialize each cookie to its 
own file and then only write out ones that have actually changed.

Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
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: Improve performance of data structure saved to disk

[Uli Kusterer]

On 06 Aug 2015, at 05:17, Juanjo Conti jjco...@carouselapps.com wrote:
 At the moment I'm using Keyed-Archiving, but after detecting performance
 issues and read I'm changing to Core-Data.

 How did you detect these performance issues, and where exactly did it show you 
that keyed archiving is at fault?

 The data structure is a NSMutableDictionary in which keys are instantness
 of a custom class CookieKey and values and instances of NSHTTPCookie.
 CookieKey has 3 string properties (domain, path and name) and implements
 NSCoding protocol.

 You are storing browser cookies and are seeing performance issues with keyed 
archivers? How many cookies do you have? Or are they somehow insanely large? 
How often do you read/write the whole storage?

 Given keyed archiving is a generic, and forward-compatible way of storing 
objects, there are of course ways to create a more efficient implementation for 
a particular narrower case, but they're reasonably efficient for at least a 
couple hundred, maybe even thousands of objects, so I'm a bit skeptical that 
this really is your performance bottleneck.

 In the new implementation CookieKey will extend NSManagedObject and have
 the 3 string properties + a NSData one called cookie. And I'll work with a
 NSMutableArray.
 
 Is it a good idea? Another approach to use Core Data and improve
 performance?

 It depends on your cookies and what makes them slow. If you have many cookies 
and you generally look them up by URL, CoreData might be the right approach. If 
your cookies are simply ridiculously large for a cookie, CoreData will probably 
make things worse. Storing NSData in a managed object is usually not the best 
idea, as you can't index the data, and the sqlite database underlying a 
CoreData store isn't really intended to store large blobs of data.

 Without knowing how you diagnosed your performance issue and what part is 
actually slow (writing changed objects? Reading the list at startup? Looking up 
an entry?) we can't really make good suggestions.

 My wild guess from what you've said so far is that you might have picked an 
unsuitable algorithm to look up your objects and that is what's slow. Does 
CookieKey (I hope that class has a prefix on its name in your actual code!) 
implement -compare:, -isEqual: and -hash? Does it implement NSCopying like a 
key should? How did you implement those? How are you looking up your objects 
(if that is what's slow)?

Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
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: Swift enums and NSNotificationCenter

[Uli Kusterer]

On 06 Aug 2015, at 02:19, Rick Mann rm...@latencyzero.com wrote:
 On Aug 5, 2015, at 17:14 , Jens Alfke j...@mooseyard.com wrote:
 It’s part of the language design that only classes support inheritance, not 
 structs or enums. 
 
 Basically, subclassing pass-by-value types is problematic. For example, what 
 happens when you assign a SubclassStruct value to a variable of type 
 BaseStruct, or pass it to a function parameter of type BaseStruct? Do the 
 extra instance variables get chopped off when it’s copied? What happens if 
 you call a BaseStruct method that was overridden in SubclassStruct?
 
 C++ lets you do this, but it can lead to really nasty problems, so style 
 guides like Effective C++ recommend avoiding it.
 
 But for extending the cases in an enum, it seems pretty nice.

It seems pretty nice until you need to optimize it. If e.g. the original enum 
had = 256 different values, it might have been implemented as a uint8_t behind 
the scenes. Now someone subclasses it and adds the 257th Where do you store 
that value now? Or even if it is a fixed size and still large enough to hold 
the value, what if the base enum is in the system and an application adds its 
own types to it? If the system ever adds another value, you might have two 
indistinguishable values for two different meanings.

There are ways around this: You could have sub-enums declare their cases as 
globals which get initialized at load-time by adding to the last value of the 
base-enum, but then you lose any guarantees about the rawValue of an enum ... 
it just becomes really messy really quick, and still has a tendency to break 
when the base-enum fills up its storage. For cases like that you might as well 
use a string property, which will be less likely to collide.

Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
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: Programmatically switching text fields

[Uli Kusterer]

On 03 Aug 2015, at 06:01, Graham Cox graham@bigpond.com wrote:
 Thinking further, I do have a NSTabView between the window and these fields, 
 and the tab on which the fields are placed are not on the default tab. I seem 
 to recall there were issues with tab views a long time ago, and perhaps it’s 
 naive to assume they’re fixed. It’s also probable that setting 
 initialFirstResponder to an item that’s not on the displayed tab might fail, 
 though it’s weird that it leaves it in a half-selected state. I’ll look at 
 responding to the tab delegate methods to select the field when the tab is 
 switched.


 Is your window key and visible at the time when you select the other view? 
Have you tried calling makeKeyAndOrderFront: on it to see if that fixes things? 
This is really one of those cases that should Just Work™, so I'm kinda confused 
why you have to do so much delegate stuff.

 Have you tried making a version without the tab view? If that is broken as 
well, then it's not related to tab views.

 FWIW, tab views probably still remove views on tabs that aren't current from 
the view hierarchy (Cocoa didn't have view hiding until ~10.2), so it could of 
course be related to that.

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...



___

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: Regarding these Olivia messages. Can we do something about the list security?

[Uli Kusterer]

On 30 Jul 2015, at 13:57, Dave d...@looktowindward.com wrote:
 The easy answer is for the Apple lists NOT to send email addresses of the 
 poster(s) and to direct all replies to the list itself. When I hit reply, it 
 set TO: to the original sender, then CC:The List and others in the thread, 
 this is what the spammer is picking up.
 
 Then any spam would go to the list and it could dealt with there once, not by 
 all that are affected.


 Since you have to be subscribed to the list to post, the likelihood would even 
be that either the message would either be rejected right away, or there would 
be a sender address subscribed to the list that could be unsubscribed to cause 
future bounces. That sounds like an actionable approach.

 List admins, is this a possible setup for whatever list management software 
you're using?

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: WKWebView Allow file selection button to select directories

[Uli Kusterer]

On 30 Jul 2015, at 15:27, Tim Fletcher timothy.m.fletc...@gmail.com wrote:
 In a WKWebView I am rendering the following button 
 
 input type=file webkitdirectory directory multiple
 
 However this is not working. I have downloaded the latest version of Webkit.


 Define this is not working. No Choose button shows up? You can't select a 
folder in the open panel that comes up? You can't drag a folder onto the button?

 When I try this in Safari, I get a button, and I can drag a folder on it, but 
the Choose button is disabled when I'm inside a folder. So to me it looks 
like a bug with a workaround (just drag-and-drop onto the button instead). 
Maybe you can theme it so it is just a drop here graphic instead of a button?

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: Unique ID for a Window?

[Uli Kusterer]

On 29 Jul 2015, at 13:25, Dave d...@looktowindward.com wrote:
 Yes I saw this, I wasn’t sure what “Current User Session” meant in this case. 
 Also if there could be a window owned by one App with the same CGWindowNumber 
 as another App, IOW, if there could be more than one Window in the Window 
 Array that has the same number? e.g. I need more than once piece of info to 
 ensure it is unique.


 AFAIK it's the number the window server uses to identify a window. So unless 
you have multiple user sessions (i.e. you have a second user logged in using 
Fast User Switching), there is only one window with that ID at a time. It is 
unique across all the applications running under the same user's account. Which 
usually is all windows your application can see (unless your app is running as 
root, but really, nobody except maybe login screen plugin developers would do 
that).

 Note that I'm saying at a time. There is no guarantee that an application 
might not close the window whose number you have, then open a new one, and get 
a new window with the same number. It's unlikely to happen, but I don't think 
it's stated anywhere that that is impossible. OTOH, also keep in mind that an 
application might close a window and re-open it instead of just hiding and 
showing it, which might change its window number.

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...



___

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: Dubrovnik Sucesss!

[Uli Kusterer]

On 22 Jul 2015, at 11:58, Dave d...@looktowindward.com wrote:
 Success! Thanks so much for your help Jonathan, I definitely owe you a pint 
 or two! 
 
 If anyone is trying use Dubrovnik/Mono on Mac OS X and needs to know how to 
 make it work - give me a shout and I’d be happy to lend a hand. It’s probably 
 better to mail me directly as it’s a little bit OT for this list.
 
 Thanks to everyone that contributed.


 Could you maybe post the question and answer somewhere and do a quick 
follow-up here with a link? It's always infuriating to find sth. via search 
that says I've solved it and nothing more.

 Maybe a Stack Overflow question where you post the answer with it immediately 
or so?

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: Has anyone used Dubrovnik?

[Uli Kusterer]

On 21 Jul 2015, at 12:21, Dave d...@looktowindward.com wrote:
 The scheme 'Dubrovnik Unit Tests' is not configured for Running.
 
 The scheme 'Dubrovnik Unit Tests' has nothing configured to build for Running 
 and has no executable specified to Run. Edit the scheme to configure the Run 
 action.


Have you tried selecting a different scheme from the popup at the top left of 
the window? You're trying to run the unit tests as an application right now, 
which unsurprisingly won't work. Or maybe they just have a broken scheme, but 
if you pick the one to build the library it works?

BTW, this really sounds more like a Dubrovnik issue (or an Xcode issue) than a 
Cocoa thing, have you tried their mailing lists or the Xcode list?

Cheers,
-- Uli Kusterer
The Witnesses of TeachtText are everywhere...




___

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: Drag highlight problems

[Uli Kusterer]

On 20 Jul 2015, at 04:36, John Brownie john_brow...@sil.org wrote:
 Everything works correctly except for the drag highlight. Sometimes, and I 
 haven't been able to work out what the sequence is, the drag highlight will 
 be left on after the drop happens. The problem seems to be some sort of race 
 condition, but I'm finding it hard to track down. Putting logging in each of 
 the three methods makes the problem go away, so that isn't useful.
 
 Am I doing something wrong? I'm on OS X 10.10.4, Xcode 6.4.

Looking at my code here: 
https://github.com/uliwitness/UliKit/blob/master/UKFilePathView.m, I also clear 
my drag highlight in concludeDragOperation:.
___

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: OsX - HTTP resource load blocked

[Uli Kusterer]

On 19 Jul 2015, at 10:47, Marc Danguy mdan...@free.fr wrote:
 a strange one : Code Signature Invalid

 Do you maybe have a shell script build phase that modifies the bundle after it 
has been signed ?
___

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: C Sharp?

[Uli Kusterer]

On 14 Jul 2015, at 19:48, Dave d...@looktowindward.com wrote:
 Does anyone know of a tool/framework that allows C# code to be compiled and 
 called from Cocoa?

Dave,

 are you aware of Elements (http://www.elementscompiler.com/elements/) ? It's 
not quite your solution, but it allows creating a C# app that calls ObjC 
methods and instantiates ObjC classes. So you could write your Cocoa code in C# 
as well, saving you a lot of work manually translating between languages at the 
interface points.

Cheers,
-- Uli
___

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