Re: Getting notification when Facetime call comes in

[Jean-Daniel via Cocoa-dev]

Not sure if that work, but at least, you should try to use the right 
Notification Center. 

NSWorkspace Notification Center is only used to broadcast NSWorkspace 
notifications.

https://developer.apple.com/documentation/avfaudio/avaudiosession/responding_to_audio_session_interruptions
 





> Le 23 août 2021 à 22:30, Gabriel Zachmann via Cocoa-dev 
>  a écrit :
> 
> In my macOS app, I'd like to get notified if and when a FaceTime call comes 
> in.
> 
> I thought I could get these notifications with code like this:
> 
> - (void) applicationDidFinishLaunching: (NSNotification *) aNotification
> {
>NSNotificationCenter *nc = [[NSWorkspace sharedWorkspace] 
> notificationCenter];
>[nc addObserver: self
>   selector: @selector(interrupt:)
>   name: AVAudioSessionInterruptionNotification object: NULL];
> ...
> }
> 
> - (void) interrupt: (NSNotification*) notification
> {
> ...
> }
> 
> 
> I can get a NSWorkspaceWillSleepNotification (which I am also interested in), 
> but I don't get the AVAudioSessionInterruptionNotification.
> My app doesn't do any sounds rendering, though. (just the occasional NSBeep).
> 
> Is there any way I can get that notification in case of incoming Facetime 
> call?
> 
> 
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: NSStream vs NSFileHandle

[Jean-Daniel via Cocoa-dev]

> Le 9 mars 2021 à 09:07, Allan Odgaard via Cocoa-dev 
>  a écrit :
> 
> We currently have two different systems that can’t easily be bridged, 
> effectively doing the same thing, but supporting different sources:
> 
> NSStream can work with files, data, and network streams (created by 
> NSURLSession and other high-level API).
> 
> NSFileHandle can work with files, pipes, stdin/out/error, file descriptors, 
> and due to the latter, sockets created with lower level API.
> 
> When designing new API, I am torn between which of these two interfaces I 
> should support. Semantically I like NSInputStream if I have an API that 
> consume data, but this choice means my API cannot be used with pipes, 
> something which is quite useful for interprocess communication / NSTask, nor 
> with stdin, something I frequently consume in CLI tools.
> 
> OTOH streams do support “bounding” so it’s easy to create self-contained 
> filters and insert them into a stream.
> 
> Any thoughts on this? Have you selected one of them in your API only to 
> regret it later?
> 
> I think introducing a class method to NSStream that creates a read/write 
> stream from an NSFileHandle would go along way. Why has Apple never had this 
> need themselves (to make it part of the public API)?
> 
> It’s probably worth also mentioning blocks, today many things that are 
> “streams” are instead handled via callbacks, which makes the API easier to 
> use for majority of cases, but it is less formalized, so harder to make 
> reusable components to process such (stream) data.

IIRC, NSFileHandle sometimes throws exception, which make it unusable in modern 
software (Swift can’t catch obj-c exception, and they never where really 
considered safe anyway).

If I had to write a new software that need read/write functions today, I would 
go for a modern async API, like dispatch_io.  

Especially as Swift async API are in a good way to be released this year and 
will make writing callback based API far easier.




___

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 reposition subviews without Auto Layout

[Jean-Daniel via Cocoa-dev]

If you want to be pedantic, I would rather say "without using Auto Layout 
constraints ».
Even the -layout method is part of the AutoLayout API.


> Le 17 oct. 2020 à 18:52, Rob Petrovec via Cocoa-dev 
>  a écrit :
> 
> As was pointed out by an earlier reply, even if you use -layout or 
> setAutoresizingMask you are still using auto layout. The frame changes get 
> converted to auto layout constraints under the hood.  If you said “without 
> using Autolayout API” that would be more correct.
> 
> —Rob
> 
> 
>> On Oct 17, 2020, at 9:46 AM, Andreas Falkenhahn via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> Thanks, out of curiosity I've tried to override the "layout" method and see 
>> if it works and it indeed does. So it looks like simply overriding the 
>> "layout" method and doing the positioning and sizing there is also possible 
>> without using any Auto Layout features whatsoever...
>> 
>> On 17.10.2020 at 16:30 Richard Charles wrote:
>> 
>>> You could call this method on your three views.
>> 
>>> -[NSViewView setAutoresizingMask:]
>> 
>>> --Richard Charles
>> 
>> 
 On Oct 17, 2020, at 6:57 AM, Andreas Falkenhahn via Cocoa-dev 
  wrote:
>> 
 Hi,
>> 
 I have an NSView that I set as the content view of my NSWindow. The NSView 
 has three subviews. Where should I reposition and resize those three 
 subviews when the NSWindow size changes? 
>> 
 I see that NSView has a "layout" method that can be overridden but AFAIU 
 this is only to be used for Auto Layout. I don't want to use Auto Layout 
 because my whole layout is very simplistic and just involves those three 
 subviews which I can easily position and size manually. I just need to 
 know where to put the code that sets their new position and size... anyone?
>> 
 -- 
 Best regards,
 Andreas Falkenhahn
>> 
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Andreas Falkenhahnmailto: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/petrock%40mac.com 
>> 
>> 
>> This email sent to petr...@mac.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/mailing%40xenonium.com 
> 
> 
> This email sent to mail...@xenonium.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: UndoManager setActionNames

[Jean-Daniel via Cocoa-dev]

> Le 5 juil. 2020 à 09:07, Arved von Brasch via Cocoa-dev 
>  a écrit :
> 
> Hi list,
> 
> Where’s the best place to intercept undo/redo actions to edit the action name 
> (’setActionName()’) for the UndoManager in a CoreData application? In 
> particular, when a particular entity’s attribute's change. Obviously, I want 
> to do this so that when the user edits something, the menu name is more 
> descriptive than just “Undo”/“Redo”.
> 
> Easiest, in terms of implementation, seems to be in the NSManagedObject 
> subclass by means of an observer on the attribute. However, conceptually, it 
> would make more sense to handle it in the NSArrayController or, maybe the 
> NSTableView or other NSView object where the attribute is edited directly.
> 
> Just wondering where others have settled for best practice.

Sometime, a user action may update many model fields in a single event loop (ie 
in a single undo action).
If you try to set the action in the model, you won’t be able to reflect what 
the user was doing.

___

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: Adding helper target to macOS app?

[Jean-Daniel via Cocoa-dev]

> Le 3 avr. 2020 à 15:44, João Varela via Cocoa-dev  
> a écrit :
> 
> Hello, Laurent
> 
> As far as I know, the documentation is still valid. 
> 
> I would start reading this:
> 
> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
>  
> 
> 
> and this:
> 
> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
>  
> 
> 
> and this:
> 
> https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html#//apple_ref/doc/uid/1123i-CH1-SW1
>  
> 
> 
> 
> macOS has a plethora of options, and that depends a lot on what you want to 
> achieve and the degree of security you need / you want to impose on the main 
> app and its helpers.
> 
> Personally, I have an app bundle that look like this:
> 
> MainApp.app/
>   Contents/
>  info.plist
>  MacOS/
>MainExecutable
>  Helpers/
>Helper1.app
>Helper2.app
>  Library/
>LoginItems/
>   LoginItem.app
>  Resources/
> … all resources here, including help and icon files
> 
> I create different targets for the main app and for each helper and login 
> item and then use scripts to build the whole bundle

Out of curiosity, why are you using custom scripts and not simply some « Copy 
File » Build step to assemble the bundle ?

___

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 which NSMenuItem is under the mouse (cocoa objective C)

[Jean-Daniel via Cocoa-dev]

> Le 7 janv. 2020 à 18:53, JP HARMAND via Cocoa-dev  
> a écrit :
> 
> While a NSMenu item is opened,  some items are disabled and some are enabled, 
> exactly as wanted .
> Moving the mouse over this menu , I now want to know which item is under the 
> mouse what ever it’s sate is.
> I am notified with -(void)menu (NSMenu*)menu 
> willHighlightItem(NSMenuItem*)menuItem each time the mouse moves over an item
> But if this item is disabled, the returned menuItem in nil… hense I cannot 
> know which item it is.
> 
> So 2 questions arise :
> 1)Why  willHighlightItem is notified with a disabled item , as the item will 
> obviously not being highlighted ?

Because: “Only one item per menu can be highlighted at a time. If item is nil, 
it means that all items in the menu are about to be unhighlighted.”

> 2) How to know which item is under the mouse, whatever the item state ?
> 
> Thanks for any idea !!
> 
> Regards
> JP
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: NSWorkspace notifications related to time change

[Jean-Daniel via Cocoa-dev]

> Le 18 déc. 2019 à 20:10, Carl Hoefs via Cocoa-dev  
> a écrit :
> 
> 
> 
>> On Dec 18, 2019, at 11:35 AM, James Walker via Cocoa-dev 
>>  wrote:
>> 
>> On 12/18/19 9:55 AM, Carl Hoefs via Cocoa-dev wrote:
>> 
>>> However, I cannot get this notification to fire on system time changes. My 
>>> other notifications (such as sleep wake, etc) do fire.
>>> -Carl
>>>[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver: self
>>>selector: @selector(systemTimeChanged:)
>>>name: NSSystemClockDidChangeNotification object: NULL];
>>> -(void) systemTimeChanged: (NSNotification *) notification
>>> {
>>>NSLog(@"-systemTimeChanged: %@", [notification name]);
>>> }
>> 
>> I'm not sure what that workspace notification center is for.  Maybe try 
>> [NSNotificationCenter defaultCenter].
> 
> 
> Thanks for the suggestion. Apple docs have [[[NSWorkspace sharedWorkspace] 
> notificationCenter] in their code snippets. But [NSNotificationCenter 
> defaultCenter] doesn't work either. Very odd. Might there be some way in 
> Xcode or Console to see what notifications are being fired?
> 

Workspace Notification Center is only for workspace specific notifications. All 
other notifications are send on the default Notification Center only.

I just did test, and I properly receive notifications on each time change in 
the System preferences.


> -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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: NSWorkspace notifications related to time change

[Jean-Daniel via Cocoa-dev]

> Le 18 déc. 2019 à 18:25, Steve Mills via Cocoa-dev 
>  a écrit :
> 
>> On Dec 18, 2019, at 11:19, Carl Hoefs via Cocoa-dev 
>>  wrote:
>> 
>> I have a macOS daemon that uses NSTimers for scheduling user event 
>> reminders. 
>> 
>> This works well except for abrupt time changes:
>> (1) the user explicitly changes the date/time
>> (2) the user crosses into a different time zone
>> (3) daylight saving time comes/goes. 
>> Then I need to recalculate the timers based on the new current time.
>> 
>> The Apple docs don't list any NSWorkspace notifications related to the 
>> above. 
>> How can I handle these cases?
> 
> Look in a different header, one related to time; NSDate.h, where you’ll find 
> NSSystemClockDidChangeNotification.
> 
> Steve via iPhone


Note that 2 and 3 are not time change from the system point of view. The system 
clock don’t change in such cases.

You may have some luck with NSSystemTimeZoneDidChangeNotification though (as 
daylight saving time is usually considered a change of timezone).


___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

My bad, I just see that when rereading the description. Of course, it will 
requires an updated runtime.

> Le 16 déc. 2019 à 09:21, Saagar Jha  a écrit :
> 
> There’s also a check for method swizzling and other invalidation, assuming 
> that there is cooperation from the runtime. Unless I’m misunderstanding what 
> you mean by the selector changing?
> 
> Saagar Jha
> 
>> On Dec 16, 2019, at 00:16, Jean-Daniel > <mailto:mail...@xenonium.com>> wrote:
>> 
>> 
>>> Le 16 déc. 2019 à 06:05, Saagar Jha >> <mailto:saa...@saagarjha.com>> a écrit :
>>> 
>>> It’s been a while, but I just thought you both might be interested in some 
>>> follow-up I did for this idea. I implemented it for fun in clang 
>>> <https://github.com/saagarjha/expresscall> and it turns out that it’s a 
>>> pretty decent performance win 
>>> <https://saagarjha.com/blog/2019/12/15/bypassing-objc-msgsend/> over 
>>> objc_msgSend, both because it dispatches faster and because the compiler 
>>> can do a full inline through it.
>> 
>> Yes, but you don't preserve the objc_msgSend semantic.
>> 
>> If I understand you code correctly, all you do is checking if it is the same 
>> ISA, which does not guarantee in anyway that the selector did not change 
>> since the previous call.   
>> 
>> As classes are fully dynamic and methods can be swizzle, you must perform a 
>> full IMP lookup for every calls, which complexly defeat the purpose of 
>> inline caching.
>> 
> 

___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 16 déc. 2019 à 06:05, Saagar Jha  a écrit :
> 
> It’s been a while, but I just thought you both might be interested in some 
> follow-up I did for this idea. I implemented it for fun in clang 
>  and it turns out that it’s a 
> pretty decent performance win 
>  over 
> objc_msgSend, both because it dispatches faster and because the compiler can 
> do a full inline through it.

Yes, but you don't preserve the objc_msgSend semantic.

If I understand you code correctly, all you do is checking if it is the same 
ISA, which does not guarantee in anyway that the selector did not change since 
the previous call.  

As classes are fully dynamic and methods can be swizzle, you must perform a 
full IMP lookup for every calls, which complexly defeat the purpose of inline 
caching.

___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 21 nov. 2019 à 21:20, Pier Bover via Cocoa-dev  
> a écrit :
> 
> I won't respond each of you one by one but here are a couple of
> observations.
> 
> Metal is not a cross platform technology hence why so many projects still
> rely on OpenGL in macOS (eg: Firefox).


No, that because they don’t have enough time to migrate it to modern framework.
OpenGL is deprecated everywhere and superseded by Vulkan (which is cross 
platform and available on macOS/iOS thanks to moltenVK). 


___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

Probably because the benefit is minor compare to this optimisation (which let 
the compiler completely inline the called ‘method’ if it want).

The actual method dispatch implementation is fast enough (in case of cache hit) 
to not gain much from inline caching, which introduce another layer of caching 
with its cost.
It may even slow done the software as it add some additional checks to any 
method calls.



> Le 20 nov. 2019 à 23:46, Saagar Jha via Cocoa-dev  
> a écrit :
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. Maybe that was too complicated 
> to implement or didn’t have the right performance characteristics. But I 
> guess this isn’t really the right list for discussing that…
> 
> Saagar Jha
> 
>> On Nov 20, 2019, at 14:27, Jens Alfke via Cocoa-dev 
>>  wrote:
>> 
>> 
>> 
>>> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>>>  wrote:
>>> 
>>> If Obj-C is dead, why is Apple still adding new language extensions (and 
>>> not minor one) ?
>>> 
>>> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>>>  
>>> <https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1>
>> 
>> Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
>> optimization of internal methods — not just because the call is faster, but 
>> because the method body is now inlineable.
>> 
>> I remember talk of this inside Apple way back when (early 2000s) but at the 
>> time IIRC it was considered too dangerous to be worth the performance gain. 
>> These days it's probably even more of a win because of LTO.
>> 
>> —Jens
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
>> 
>> This email sent to saa...@saagarjha.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 20 nov. 2019 à 01:26, Gerald Henriksen via Cocoa-dev 
>  a écrit :
> 
> On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:
> 
>> When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES 
>> to Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>> (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>> layer written in Objective-C), Swift and lots of other stuff. From my point 
>> of view I do not see Apple sweeping away Objective-C and the Cocoa 
>> frameworks any time soon. 
> 
> Just because Apple may need to keep Objective-C around for the
> frameworks doesn't mean they will continue to allow applications to be
> written in it.
> 
> All they need to do is either eliminate the option (stop shipping the
> Objective-C compiler), or do so by requiring all applications to have
> something that is only available via Swift.

If Obj-C is dead, why is Apple still adding new language extensions (and not 
minor one) ?

https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
 




___

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: Thoughts on Objective-C++

[Jean-Daniel via Cocoa-dev]

> Le 12 nov. 2019 à 21:30, Richard Charles via Cocoa-dev 
>  a écrit :
> 
> 
>> On Nov 12, 2019, at 1:16 PM, GNDGN  wrote:
>> 
>> ‘It’s like giving a glass of ice water to somebody in hell’ - Jobs
>> 
> 
> Apple released iTunes for Windows in October 2003. Apparently Cocoa and any 
> supporting frameworks were ported to Windows 16 years ago. So what is the 
> problem providing this to outside developers?
> 
> --Richard Charles

Supporting a public API is far more complex and costlier than supporting some 
private frameworks.
What would be the benefit for Apple to support public API for Windows ?


___

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: Need for Swift

[Jean-Daniel via Cocoa-dev]

> Le 16 oct. 2019 à 11:49, Stephane Sudre via Cocoa-dev 
>  a écrit :
> 
> On Tue, Oct 15, 2019 at 2:26 PM Sandor Szatmari via Cocoa-dev
>  wrote:
> 
>> But honestly, I don’t have enough Swift experience to know if you can write 
>> bad Swift code.
> 
> I'm just reading Swift code here and there and it's my personal
> opinion that 75% of the Swift code I read is bad code.

That matches my observation whatever the language is. 
This is not something related to Swift. This is just how most developers works.

> Why do Swift developers think it's mandatory to write code that is illegible?
> Is Swift mainly used by freelances or consultants that will not have
> to maintain the software?

Not more than other projects with language designed to be easy to use and 
usable by as many people as possible.

You won’t find as much bad C++ and Rust code because the complexity of the 
languages filter out casual developers.





___

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: Need for Swift

[Jean-Daniel via Cocoa-dev]

> Le 15 oct. 2019 à 04:43, Alex Zavatone via Cocoa-dev 
>  a écrit :
> 
> 
> 
>> On Oct 14, 2019, at 1:25 PM, Carl Hoefs via Cocoa-dev 
>>  wrote:
>> 
>> The group that likes Obj-C sees Swift as being "arbitrarily syntactical" 
>> with the syntax of the language getting in the way of programming. (There is 
>> a third group that likes both languages, but it is very small.)
> 
> I am in this group.  The syntax of Swift just feels so arbitrary and to look 
> deeper to solve more problems… if it weren’t for those compiler messages, it 
> would be a mess.  I, for one shuddered when I saw “if let x = y” being 
> something that people are expected to use and that damn, “you must unwrap 
> this optional”, simply ends up making things that were simple in Objective-C, 
> completely cumbersome in Swift.  

Nobody force you to use "if let ».

If you want to write error prone code like in Obj-C, just use optional 
chaining. This is exactly the same than dispatching message without checking 
for nil before and will works as you like to do in Obj-C.


___

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: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 12 oct. 2019 à 03:07, 조성빈 via Cocoa-dev  a 
> écrit :
> 
>> 
>> 2019. 10. 12. 오전 9:55, Richard Charles via Cocoa-dev 
>>  작성:
>> 
>> 
>>> On Oct 11, 2019, at 1:14 PM, Turtle Creek Software via Cocoa-dev 
>>>  wrote:
>>> 
> I know this is the Cocoa devs list... but why not make a website?
> It would be easier to develop, completely crossplatform, no app store
> complications, you would be in total control of your stack, etc.
>>> 
>>> QuickBooks has gone that route.  They still grudgingly sell desktop apps,
>>> but really push people towards their cloud version.  Besides all the
>>> benefits you mention, it's a steady monthly income.  Hence why Microsoft
>>> and Adobe are also going that route.  Apple too.
>> 
>> If I understand this correctly.
>> 
>> Microsoft Office Web apps (Word, Excel, PowerPoint) are simplified versions 
>> of desktops apps that run in a web browser along with a subscription service.
>> 
>> Apple iWork web apps (Pages, Numbers, Keynote) are feature complete versions 
>> of desktop and mobile apps that run in a web browser. Apple has never 
>> released the details of how they do this.
> 
> Microsoft Office & Apple iWork web apps could be complex due to compatibility 
> with the offline ones, and that they have a feature set that only has 
> steadily expanded for a ten to twenty years.
> They also need to have their app integrated with their other services.
> 
>> Adobe Creative Cloud apps (Lightroom and Photoshop) are native apps for 
>> desktop and mobile with cloud based storage and a subscription service. They 
>> are not cross-platform browser based web apps.
>> 
>> None but the biggest of companies can do this.
> 
> That’s not true, web apps aren’t really complex if you get to use the npm 
> ecosystem. There are high quality libraries that do much of the heavy 
> lifting, so writing ones usually are wiring glue code between the libraries.

I’m not quite sure what your definition of complex is, but on my side, I 
consider that an app that use hundred (if not thousand) of dependencies that 
have to be review and properly managed to avoid conflict and can disappear 
without notice and break your app, is a complex system.

___

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: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 11 oct. 2019 à 16:59, Turtle Creek Software via Cocoa-dev 
>  a écrit :
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.


At least for ARC, it is fully open source.
The runtime part can be found in the objc4 project, and the compiler part come 
from clang, and is open source as well.

And knowing that, you will see that for such complex features, having them open 
source does not bring you many benefit to use them, as it is barely impossible 
to infer what the compiler optimiser pass will output by simply reading the 
source.

___

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: Thoughts on Cocoa source code

[Jean-Daniel via Cocoa-dev]

> Le 10 oct. 2019 à 00:14, Jens Alfke via Cocoa-dev  
> a écrit :
> 
> 
> 
>> On Oct 9, 2019, at 11:39 AM, Aandi Inston  wrote:
>> 
>> * But for whatever reason, I'm using the Mac OS 10.14 SDK. So that will get 
>> a compile-time warning.
> 
> Only if you don't turn on -Werror, which I really, really recommend everyone 
> do. Calling a method that a class isn't declared as implementing is a fairly 
> common mistake, and warnings are way too easy to overlook.
> 
> In this situation, you get around the warning/error by declaring the method 
> yourself in a category on the framework class.
> 
>> * I add a check for actual OS version, so I am very sure not try to call  
>> [NSApplication doUsefulThing] 
>> unless the OS is 10.15 or later.
>> * But what happens if it runs in 10.15? Does it actually do the useful thing?
> 
> The method will be called, yes. I can't think of any particular reason it 
> wouldn't work. 

It may not work if -doUsefulThing rely on some code that performs a « Link SDK 
version » runtime check and assume the new code path wlll be executed because 
this method is not supposed to be called from a app linked on an older SDK..

This is rather unlikely, but this is usually safer to update your SDK if you 
want the last features.


___

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: Thoughts on Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 5 oct. 2019 à 07:14, Pier Bover via Cocoa-dev  
> a écrit :
> 
>> But once you get experienced with Cocoa and Objective-C, you can build
> applications or rewrite them fairly quickly, IMHO.
> Yeah but Objective-C is slowly being phased out. Someone from Apple already
> said in a previous e-mail newer APIs are only available for Swift.
> 
> As for Cocoa it seems like it will be slowly replaced by the iOS SDK or by
> newer APIs that are universal. Who knows, Apple doesn't usually do a great
> about communicating its medium term plans. Maybe in 5 years Cocoa or
> Objective-C will be phased out much like Carbon.

AppKit is not Cocoa. iOS SDK shared most fo its code with the macOS SDK, so 
even if it had to replace it (which is absolute non-sense seeing where Apple is 
going with Swift UI), it would be a far less big deal than the Carbon/Cocoa 
transition.

And Obj-C is not going to be more deprecated than C++ was deprecated with 
Carbon. A language is not a framework.



___

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

[Jean-Daniel via Cocoa-dev]

> Le 30 sept. 2019 à 17:16, Robert Walsh via Cocoa-dev 
>  a écrit :
> 
> 
> Swift may be the solution, but it's built on a weak foundation. It makes
> cross-platform development almost impossible. The TIOBE index shows Swift
> declining (and Objective-C increasing). So, maybe it isn't.
> 
> I don't yet have a lot of experience with Swift, but I would already argue 
> that Swift is not the solution.  Swift is cool and has some really neat 
> features that make for good presentations and blog posts (where the 
> real-world issues and constraints associated with interfacing to other 
> systems, particularly older ones that do not use HTTP, can be minimized or 
> eliminated entirely); however, to use it to do anything other than building a 
> desktop or IOS GUI application seems to result in code with messy syntax and 
> what seem to me to be hacks in order to bridge between NS* and CG* code.  
> (Lots of casts and strange machinations for massaging pointers.)  I'm in the 
> process of converting an application written in C++ using an older version of 
> Qt because the Qt code relies on Carbon (which has been removed from 
> Catalina).  The new code is in Swift.  I've written and maintained code that 
> uses UNIX-style C sockets for many years, but finding a native approach for 
> plain sockets in Swift was very
>  difficult.  There appears to be good support for async HTTP communication, 
> but not much for socket-based TCP.  

SwiftNIO is protocol agnostic, and let you manipulate any data stream as you 
like. Moreover, it is cross platform (unlike the lower level Network Framework, 
which is far superior to using unix socket IMHO, but can’t be use for cross 
platform dev). 



___

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 problems

[Jean-Daniel via Cocoa-dev]

> Le 4 sept. 2019 à 00:18, Turtle Creek Software  a 
> écrit :
> 
> The app delegate is NOT being deallocated prematurely- we have a breakpoint 
> there to check.
> 
> We don't allocate the app delegate explicitly, so I had to set a breakpoint 
> in init() to see when it happens.
> It's created in main() via NSApplicationMain.  Presumably its end of scope 
> would be when main ends.
> The MainMenu.xib includes a Delegate object for our GSAppDelegate class, so 
> it must be allocated
> via the nib-loading process (the stack trace says InitWithCoder).  
> 
> GSAppDelegate has strong references to 4 window controller members: main 
> window, prefs window, and a couple of log windows.
> But that alone has not kept the main window controller alive.  We haven't 
> tested the others.
> 
> The main window controller that was mysteriously dying used to have a strong 
> reference back to the app delegate.
> Whether strong, weak or non-existent, it didn't make any difference.  I 
> suppose we could add a strong ref somewhere else
> just to be double safe, but I'm not sure where else would make sense.

You can get the same effect by retaining the controller explicitly (creating a 
leak, so should be for testing purpose only).

CFBridgingRetain(windowController);

> The startup code was created 3 years ago when we were new to Cocoa, probably 
> from one of the HIllegass books.  
> It may have flaws, but the app has been running OK otherwise.  The problems 
> only started when we read about circular references
> and started making up-references __weak.  
> 
> BTW the Clang specs for ARC mention that it's not exception-safe.  If I 
> understand correctly,
> strong references will leak, and weak references are released.  We don't 
> throw any Cocoa exceptions but
> maybe the system does.

Manual Ref counting was not safe either, just like almost everything in Obj-C 
frameworks. Exception are used only for fatal errors (expect in a couple of 
legacy API). Don’t bother with exception safety. If your code raises an 
exception, fix the bug to avoid seeing it again.


___

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 problems

[Jean-Daniel via Cocoa-dev]

> Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev 
>  a écrit :
> 
> Thanks for all the suggestions for the problems we had with a controller
> being
> deallocated unexpectedly under ARC.  Unfortunately, none of them fixed it.
> 
> We do need to get back to regular app programming, so it will just stay a
> mystery.
> I was hoping we were doing something obviously dumb, but I guess the bug is
> more subtle.
> 
> The app runs OK with the old code with multiple strong references to it
> They are circular references, but that controller sticks around for the
> full app lifetime.  Presumably any leakage
> won't happen until late in the game, anyhow.
> 
> Thanks,

Just a last suggestion. How is you App delegate created ? Do you keep a strong 
ref on it. Else it will be deallocated and so will the controller.

___

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

[Jean-Daniel via Cocoa-dev]

> Le 1 sept. 2019 à 01:10, Carl Hoefs via Cocoa-dev  
> a écrit :
> 
> 
>> On Aug 31, 2019, at 2:51 AM, Allan Odgaard via Cocoa-dev 
>>  wrote:
>> 
>> On 31 Aug 2019, at 2:49, Carl Hoefs via Cocoa-dev wrote:
>> 
>>> Same result if I run it as a system daemon. So as you suggest it seems 
>>> there could be some sort of environment sensitivity going on. If only I 
>>> knew what env var to set in the shell... UTC really isn't what I'm looking 
>>> for.
>> 
>> The issue appears to be that `NSLog` sends your format string and arguments 
>> to the unified logging system, this is what Xcode and Console displays, and 
>> here you get dates formatted using the local time zone.
>> 
>> But it *also* does a simple `stringWithFormat:` and sends the result to 
>> standard error, at least when running in a terminal. This is where you are 
>> seeing a more crude formatting of the date which is not adjusted to the 
>> local time zone.
>> 
>> Open a new tab in your terminal, in that tab run this command:
>> 
>>  log stream|grep 'Configured date'
>> 
>> Now run your executable, and in the tab where it is running, you should see 
>> the UTC date, but in the tab where you are watching the log stream, you get 
>> the local date.
>> ___
>> 
> 
> Thanks for the input! 
> 
> I realized this is occurring because I'm allowing macOS to generate the date 
> string according to its whims. If I do the string generation, then I can get 
> consistent results. So I added the following line to my code:
> 
>NSString *dateString = [NSDateFormatter 
> localizedStringFromDate:configuredDate dateStyle:NSDateFormatterFullStyle 
> timeStyle:NSDateFormatterLongStyle];
> 
> and now I get a standardized string I can at least can live with, valid for 
> all situations:
> 
> Configured date: Saturday, August 31, 2019 at 3:55:02 PM PDT
> 

Note that your output is still Local dependent and can change from on system to 
an other.


___

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

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

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

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

Re: ARC

[Jean-Daniel via Cocoa-dev]

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.

> Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev 
>  a écrit :
> 
> In GSAppDelegate.h
>  GSOutlineWindowController *mainWindowController;
> 
> In GSAppDelegate.mm
> - (void) showOutlineWindow
> {
> if (mainWindowController == NULL)
>  mainWindowController = [[GSOutlineWindowController alloc]
> initWithWindowNibName : @"GSOutlineWindowController"];
> [mainWindowController showWindow : self];
> }
> 
> We don't do any ref-counting at all.  A search for CFRetain and CFRelease
> showed zero items.
> 
> I would say that ARC is certainly way better than the previous manual
> ref-counting.  That must have been hellish.
> Fortunately we only started the Carbon->Cocoa port 3 years ago, so we
> didn't need to retain/release.
> But we have wasted at least a month, tracking down mysterious object
> deletions that theoretically should not happen.
> 
> At this point we pretty much have breakpoints on dealloc() for every
> class.  That lets us know when something is
> dying, but gives no clue as to why.  Breakpoints on release() go deep into
> Apple Assembly code.
> 
> On Sun, Aug 25, 2019 at 12:42 PM Jens Alfke  wrote:
> 
>> 
>>> On Aug 24, 2019, at 4:46 AM, Turtle Creek Software <
>> supp...@turtlesoft.com> wrote:
>>> 
>>> Our app delegate class is not deallocated.  The window controller is
>> deallocated
>>> despite the member reference there.
>> 
>> That should not be possible. Could you paste the exact line of code that
>> declares the window-controller reference in the app delegate?
>> 
>> Have you verified that, at the point when the controller is dealloced, the
>> reference in the app delegate is still non-nil? (I sometimes find it useful
>> to set a breakpoint in the dealloc method, in weird cases like this.)
>> 
>> Do you have any remaining code that messes with ref-counting, I.e. by
>> using CFRetain/Release on Obj-C objects?
>> 
>> —Jens
>> 
>> (And let me chime in that ARC is an excellent feature. Cocoa used to have
>> ‘true’ garbage collection as an option, but it was rarely used on Mac due
>> to memory and performance impact, and never implemented on iOS for that
>> reason. ARC works much better. Swift memory management is based on ARC, so
>> it’s definitely the way of the future.)
>> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: C++ pointer to Cocoa object

[Jean-Daniel]

> Le 7 sept. 2018 à 19:46, Casey McDermott  a écrit :
> 
> We need to link some of our C++ classes to a matching Cocoa class.
> It's easy for Cocoa to reference C++ objects.  Going the other way is harder.
> 
> We have been using a linker class that has a void pointer to the Obj-C object
> in the C++ header.  We then cast it to a Cocoa object in the Obj-C++ source.
> For example, in the C++ header we have:
> 

How are you setting the pointer ? If you are using ARC and want to get a strong 
reference on the object, you have to use __bridge_retained, which tell ARC to 
keep the reference valid.
Once you are done with the objc object, you have to release it.

> void *mCocoaPopupPtr = nil;
> 
> Then in the source:
> 
> void GSCocoaPopupLinker::setCocoaFieldVisible(const BOOL inValue)
> {
>   if (mCocoaPopupPtr != nil)
>   {
>   GSPopupButton *cocoaPopup = (__bridge GSPopupButton 
> *)mCocoaPopupPtr;
>   [cocoaPopup setHidden : !inValue];
>   }
> }
> 
> Problem is, with ARC turned on, the pointer is never nil, so it crashes.  
> The void pointer somehow becomes an NSAtom instead of 0.
> 
> There's very little documentation on NSAtom, but it appears to be Apple's way 
> to 
> use the excess bits in a 64-bit address to store class info. 
> 
> Is there some other way to test for an invalid void pointer?
> 
> Thanks,
> 
> Casey McDermott
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: How to clear macOS app bundle cache

[Jean-Daniel]

> Le 4 sept. 2018 à 17:01, Andreas Falkenhahn  a écrit :
> 
> On 04.09.2018 at 15:54 Alastair Houghton wrote:
> 
>> OK. Have you tried logging the path of a file in the bundle, so you
>> can see where it’s being read from?
> 
> CFBundleCopyBundleURL(CFBundleGetMainBundle()) always returns the path
> of the bundle on the network volume.

Maybe looking at the list of open files (in the Activity Monitor) may give you 
an hint about what is the real path of the mapped binary.
It is one of the few working method to get the real path of mapped libraries 
(/private/var/db/dyld/dyld_shared_cache_x86_64h instead of the system 
frameworks path for instance).

> 
>> If the path still says the network, what kind of network is it and
>> are there any caching settings or other settings you might be able
>> to adjust? (I remember, for instance, that, years ago, similar
>> problems used to occur if you were using a Windows-based network
>> because of low resolution timestamps on files.) If the path doesn’t
>> say the network, it might tell us where to look to clear out cached data.
> 
> Unfortunately, I'm no macOS expert so I don't know where to look. I'm
> using a standard macOS installation. The network drive is an SMB share.
> 
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto: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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Detecting if /Network/Library is available

[Jean-Daniel]

> Le 3 sept. 2018 à 19:07, Sandor Szatmari  a 
> écrit :
> 
> I have a problem to solve where it appears I need to detect if 
> /Network/Library is available or not.  
> 
> Basically, I’d like to handle situation where I need to copy items from 
> /Network/Library at times when it’s it’s not yet available but may be 
> available soon…  i.e. at boot, or after the Network cycles, etc.
> 
> There’s a couple of strategies I can think of:
> 
> Keep failing the copy until it works or a default time out expires
> Notification of availability (Preferred, but I can’t find a way to do this)
> Quit and retry later.
> 
> Any suggestion/guidance anyone can provide on this?

I’m not familiar with /Network/Library, but if this is a standard directory, 
you can wait for it to be created using file system event (I think there is a 
node dispatch source for that), and if this is a mount point, you can use disk 
arbitration framework to get notification.

___

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

[Jean-Daniel]

> Le 20 août 2018 à 18:51, Jens Alfke  a écrit :
> 
> 
> 
>> On Aug 18, 2018, at 11:19 AM, Stephane Sudre  wrote:
>> 
>> It might be the new Carbon once:
>> 
>> - there is ABI stability in Swift. This could be not before late 2019.
>> 
>> - the new APIs are only available in Swift. Is Swift NIO a hint this
>> is coming sooner than expected? 
> 
> By “NIO” do you mean the new Network.framework? They did only demo the Swift 
> API at WWDC, but it has a full C API too. (Which makes sense, since part of 
> its goal is to drag C developers away from the POSIX sockets API.)
> 

No, NIO is basically Netty in swift (and can use Network.framework under the 
hood): https://github.com/apple/swift-nio 


___

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 with NSWorkspace.shared and uid 0

[Jean-Daniel]

AFAIK, this is not an issue with uid 0 specifically, but more an issue with how 
LaunchService works (the framework underlying this part of NSWorkspace).

The system maintains a per user databases of the installed bundles. This 
databases is updated each time an user interact with a new application, mount a 
drive, etc.

As the user 0 is not a legit interactive user, it’s LaunchService database 
lacks a lots of informations. This design make sens as it is perfectly fine for 
an user to install a bundle into its home directory and it should be the only 
one to see it.

As Jens said, AppKit (and LaunchService) are not design to be used by a uid 0 
daemon and should instead only be used by user agents running on each active 
session (which can then report the result to a uid 0 daemon).


> Le 13 déc. 2017 à 04:14, sqwarqDev  a écrit :
> 
> When using the absolutePathForApplication(withBundleIdentifier:) api, I find 
> that if the path is on an external mount, the api will return nil / none if 
> the uid is 0, when it will return an actual path when the uid is a valid user 
> login id (eg, 501, 502 etc). 
> 
> To reproduce, mount a .dmg containing some app that isn’t on the boot drive, 
> and insert its bundeID for the value of inputPath in the code below:
> 
> 
> import Foundation
> import AppKit
> 
> let inputPath = “com.some.bundleID"
> let pathToApp: String? = 
> NSWorkspace.shared.absolutePathForApplication(withBundleIdentifier: inputPath)
> let result = pathToApp ?? "nil"
> print(result)
> 
> 
> In Xcode, if I edit the scheme to debug/run as myself, I’ll get a valid 
> result, but if I edit it to run as root, I’ll get back this error msg:
> 
> schedule invalidation  connection (31)>
> 
> I have also tried querying LaunchServices directly with 
> 
> let altPath = LSCopyApplicationURLsForBundleIdentifier(inputPath as CFString, 
> )
> 
> which again returns successfully as me, but as root gives the error:
> 
> Error Domain=NSOSStatusErrorDomain Code=-10814 "kLSApplicationNotFoundErr: 
> E.g. no application claims the file”))
> 
> It’s been suggested to me that the problem may be that the LS database isn’t 
> updated for transient mounts for the root user. That makes sense of the error 
> messages, but two questions:
> 
> 1. Should this be considered a bug, or expected behaviour?
> 2. Any suggestions for a workaround?
> 
> 
> TIA
> 
> 
> 
> Best
> 
> 
> Phil
> @sqwarq
> 
> 
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Loading very large image files (>10GB)

[Jean-Daniel]

UIImage is optimized to read pixel from disk at draw time and can be used to 
downsample a large image progressively ( 
https://developer.apple.com/library/content/samplecode/LargeImageDownsizing/Introduction/Intro.html
 )

I guess NSImage can do something similar. If not, this can probably be done 
using CGImageSource API.

> Le 4 déc. 2017 à 03:06, Rick Mann  a écrit :
> 
> Is there support in NSImage[View]/Core Image for loading and displaying very 
> large images (TIFF files larger than 10 GB)? I'm having trouble googling for 
> an answer.
> 
> -- 
> Rick Mann
> rm...@latencyzero.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Register media source to system

[Jean-Daniel]

> Le 23 oct. 2017 à 22:47, Jens Alfke  a écrit :
> 
> 
> 
>> On Oct 22, 2017, at 11:39 AM, Totte Alm  wrote:
>> 
>> Om Mac OS X (not iOS), I need to take video and/or audio from input 
>> devices(like built in iSight ot FaceTime cameras), found using the standard 
>> AVCaptureDevice.devices(); and then make it available for other applications 
>> using the same interface, after they have been processed.
> 
> What do you mean by "make it available for other applications using the same 
> interface”?

I’m not sure what you’re looking for, but I would have a look to the 
CoreMediaIO sample code: 
https://developer.apple.com/library/content/samplecode/CoreMediaIO/Introduction/Intro.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/archive%40mail-archive.com

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

Re: Problem using NSTimer in privileged helper tool

[Jean-Daniel]

> Le 20 oct. 2017 à 18:56, Quincey Morris  
> a écrit :
> 
> On Oct 20, 2017, at 03:23 , Mark Allan  wrote:
>> 
>> That worked with the block-based NSTimer API but not the selector-based API. 
>>  I tried changing it to 'currentRunLoop' which got rid of the crash, but the 
>> timer never fired.
> 
> This is pure guesswork, but I suspect this is what was going on:
> 
> — When you scheduled the timer on the main run loop, it was actually being 
> scheduled on the main app’s run loop. When it was block based, only the block 
> had to be passed across the XPC interface (which somehow works), but when it 
> was selector-based, the timer itself had to be passed (which doesn’t work). 
> Admittedly this is a pretty silly explanation, but it may have some relation 
> to the truth.
> 
> — When you scheduled the timer on the current run loop, everything was fine 
> either way, except the run loop *wasn’t running* in the XPC thread, so the 
> timer never fired.
> 
> This is similar to a problem that came up on the developer forums a few weeks 
> ago. A developer was using Disk Arbitration callbacks to monitor volumes 
> being mounted, and tried to move that code to an XPC process. The callback 
> was scheduled on the run loop, yet it was never called. There was more recent 
> API that was block-based instead, and that turned out to work fine in an XPC 
> process. The fact that scheduling on the run loop didn’t crash indicated that 
> there *was* a run loop, but the fact that the callbacks didn’t fire suggested 
> that it wasn’t running.

There is always a runloop as it is created lazily when accessing it. So the 
scheduling will always work. But if the current thread does not call 
-[NSRunLoop run] (or a variant), it will never be dispatched.


___

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: Question about NSObject based Class & delegates

[Jean-Daniel]

Why are you using Implicitly Unwrapped Optional (IUO) for your instance 
variables ? This is the best way to get crashes like you do.

IUO should only be used for very specific cases (IBOutlet)

> Le 14 août 2017 à 20:59, Eric E. Dolecki  a écrit :
> 
> I have a custom class. I want to use some delegation in it. How do I go
> about this - currently this crashes when I assign delegates to self.
> 
> class AudioRecordingManager: NSObject, AVAudioPlayerDelegate,
> AVSpeechSynthesizerDelegate {
> 
>let fileName = "demoRecording.m4a"
>var messageToSpeakAfter: String = ""
>var synthesizer:AVSpeechSynthesizer!
>var audioPlayer:AVAudioPlayer!
> 
>override init() {
>super.init()
>audioPlayer = AVAudioPlayer()
>synthesizer = AVSpeechSynthesizer()
>   * audioPlayer.delegate = self // CRASH here*
>synthesizer.delegate = self
>}
> ...
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Is "-init" really needed?

[Jean-Daniel]

> Le 10 août 2017 à 16:09, Charles Srstka  a écrit :
> 
>> On Aug 10, 2017, at 8:59 AM, Alastair Houghton 
>>  wrote:
>> 
>> On 10 Aug 2017, at 14:57, gerti-cocoa...@bitart.com 
>>  wrote:
>>> 
>>> On Aug 10, 2017, at 02:18, Alastair Houghton  
>>> wrote:
 
 Personally I *would* still discourage +new in favour of class-specific 
 convenience constructors because I think it’s less expressive and also 
 less consistent (e.g. +array is better, in my opinion, than +new, not 
 least because +arrayWithObjects: and others exist).
>>> 
>>> [NSArray new] := [[NSArray alloc]init]
>>> 
>>> [NSArray array] := [[[NSArray alloc]init]autorelease]
>>> 
>>> +array and friends came along with the introduction of autorelease pools, 
>>> to replace +new with something that didn't imply ownership (the oft 
>>> mentioned special meaning of "new" as prefix). So while with ARC they are 
>>> essentially equivalent, previously they were not.
>> 
>> Yes, I know that, thanks.
>> 
>> The point is, with ARC, they’re equivalent, and most new code uses ARC, so, 
>> again, I’d discourage +new in favour of class-specific convenience 
>> constructors.
>> 
>> Kind regards,
>> 
>> Alastair.
> 
> They’re equivalent syntactically, but performance-wise, +array and friends 
> will cause the object to be put into an autorelease pool. Therefore, +new is 
> better for performance.

Putting an object into an autorelease pool is very cheap. It is just a write of 
the pointer value in a thread local array. When using ARC, the object is still 
pushed in the autoreleased stack, but it may be immediately pop by the caller. 
So yes, +array still have a couple of additional operations to perform,  but it 
should be mesure to tell if this is significant performance wise.

___

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: adding arc to a fundamentally non-arc project

[Jean-Daniel]

Did you switch from 32bit to 64bit ? Or enable the ‘symbol hidden by default’ 
build setting. The symbol visibility model is completely different on 64 bit 
and classes must be exported to be visible by other modules.

> Le 15 juil. 2017 à 23:00, Matthew Weinstein  a écrit :
> 
> Trying to move from QTKit to AVKit. Compiling on El Capitan (at the moment). 
> So I have a handler that is arc and handles all the AVKit stuff and compiled 
> with the -fobjc-arc flag in the build phases... I create and assign the 
> handler to a document object using the myhandler = [[MWArcHandler alloc] 
> init]; but the linker constantly complains that it can't find MWArcHandler: 
> it's there in the build phases; and it is in the target, but I can't convince 
> the linker that it is there.
> 
> Any suggestions?
> 
> PS very new to ARC programming.
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: file encription/decriptoin iOS

[Jean-Daniel]

> Le 27 juin 2017 à 04:25, Sandor Szatmari  a 
> écrit :
> 
> This is an interesting thread.  The OP's original question made me think of 
> the functionality Apple recently (how recently I'm not sure) added to the iOS 
> Notes app.  It allows you to selectively 'encrypt' (password protect) a note. 
>  This functionality allows you to pass your phone to someone to let them read 
> a note and not worry about them skipping to your note with all your 'secret 
> info'.  Also, if someone got your phone in an unlocked state, (it could 
> happen I guess) they couldn't trust a Mac and browse to plain text files.  

Notes are sync with iCloud and can be read on a Mac where this is far more 
common to share a session.

> I must say at this point I whole heartedly agree with all the warnings for 
> implementing encryption schemes.  But is there not also a valid use case 
> here?  Unless I'm misunderstanding things, Apple seemed to think so.
> 
> Sandor
> 
>> On Jun 26, 2017, at 13:59, Jens Alfke > > wrote:
>> 
>> 
>>> On Jun 26, 2017, at 9:50 AM, Alex Zavatone  wrote:
>>> 
>>> You can use the iExplore app to look in the Documents folder of any device 
>>> you attach to your Mac. 
>> 
>> But you can only attach a device to your Mac if the device is unlocked, 
>> since you have to OK the “Do you trust this computer?” alert.
>> As recent court cases have shown, unlocking an iOS device against the 
>> owner’s will is nearly impossible.
>> 
>>> Also, data protection SUCKS because it locks the files if the app goes in 
>>> to the background, basically suspending any file based background 
>>> operations like sql db updates. 
>> 
>> It does this by default, but you can alter those settings if you need 
>> background access to certain files, basically trading some security for 
>> greater access.
>> 
>>> Thanks to the help of Chris Thorman, I was able to update an AES256 hmac 
>>> method to work with UTF-8 char sets.  We use this for data security over 
>>> http.
>> 
>> It’s much easier to just enable SSL/TLS on the HTTP server. (Though I 
>> realize there are cases where you don’t have control over the server, or 
>> circumstances prevent deploying HTTPS.)
>> 
>>> Now, it might be overkill or just bad design, but we use a CoreData db with 
>>> transformable property and encrypt the data stored. 
>> 
>> How do you store the encryption key? That’s often the downfall; even if you 
>> put it in the Keychain, it can be accessed by an attacker if your app’s 
>> files are accessible (unless you add TouchID authentication to it.)
>> 
>> (Also, I hope you’re using a different IV for each record you encrypt. Sorry 
>> to be a broken record about this, but it’s important.)
>> 
>> —Jens
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
>>  
>> 
>> 
>> This email sent to admin.szatmari@gmail.com 
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> )
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> 
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com 
> 
> 
> This email sent to mail...@xenonium.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: Translating KVO-ed property to Swift

[Jean-Daniel]

Just a tough that go in the ‘always use dynamic’ side. I think setter 
interposition is not the only issue with KVO. KVO also need to be able to fetch 
the old property value when -willChange: is called. I’m not sure about how it 
does that, but I’m pretty confident it will break if the getter is not properly 
exposed in Obj-C, which may be the case if the property is neither declare 
@objc, nor dynamic.

> Le 20 avr. 2017 à 22:06, Quincey Morris  
> a écrit :
> 
> On Apr 20, 2017, at 10:24 , Charles Srstka  wrote:
>> 
>> I mean, yes, we could go all the way down to explaining how everything works 
>> in terms of the physics and chemistry of electrons and semiconductors, but 
>> that wouldn’t be very practical, would it?
> 
> I subscribe to the principle already quoted from the documentation: If you 
> KVO-observe a property, mark it “dynamic”. I like this because it is simple 
> and unambiguous. If anyone asked me for advice, I’d say to follow this 
> principle and don’t agonize any further.
> 
> As a different discussion, at a different level, I agree that there are 
> scenarios where you can omit “dynamic” and still get all the KVO 
> notifications you wanted. What scenarios? Well, I think the essence of your 
> argument is that it can be omitted for a KVO-observed *dependent* property. 
> That at least sounds pretty plausible to me, and it may even be true by 
> definition. If anyone asked you for advice, then I guess you’d say to accept 
> this as an extension of the documented principle. Me, I’m not 100% certain 
> about this, if for no other reason than the documented principle is 
> future-proof against a change in the way things work where Apple says, “Well, 
> we told to you mark all KVO-observed properties dynamic.” But, people can go 
> for advice where they want.
> 
> Where I disagree is in your much stronger claim that a computed property is 
> *necessarily* a dependent property. I think this is just false. The Swift 
> distinction between computed and stored properties is syntactic and has 
> nothing to do with KVO**. A KVO-observed computed property should therefore, 
> according to the documented principle, be marked “dynamic”. For anyone 
> following your extended principle, if it’s also a dependent property, they 
> can omit the “dynamic”. If not, not.
> 
> 
> ** Indeed, it’s trivially easy to convert a public stored property into a 
> public computed property that uses a private, stored, non-KVO-observed 
> property as its instance storage.
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Translating KVO-ed property to Swift

[Jean-Daniel]

> Le 17 avr. 2017 à 10:52, Quincey Morris <quinceymor...@rivergatesoftware.com> 
> a écrit :
> 
> On Apr 17, 2017, at 01:43 , Jean-Daniel <mail...@xenonium.com 
> <mailto:mail...@xenonium.com>> wrote:
>> 
>> var version: String? {
> 
> A slight correction: this declaration actually must be:
> 
>> dynamic var version: String? {
> 
> 
> otherwise KVO isn’t guaranteed to work in Swift.

This is a good practice, but I don’t think this is required for computed 
property, especially if you take care of willChange/didChange manually, as the 
OP does.


___

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: Translating KVO-ed property to Swift

[Jean-Daniel]

One way to solve that is to declare an explicit private stored property for the 
ivar, and a public computed property for the logic.

private var _version: String? = nil

var version: String? {
get { return _version }
set { your set version code }
}


> Le 17 avr. 2017 à 10:24, Rick Mann  a écrit :
> 
> I have a number of properties in Objective-C written like this, 
> short-circuiting notifications when the value doesn't change:
> 
> -
> @synthesize version = mVersion
> 
> - (void)
> setVersion: (NSString *) inVersion
> {
>if (inVersion == nil && mVersion == nil)
>{
>return;
>}
>if ([inVersion isEqualToString: mVersion])
>{
>return;
>}
> 
>[self willChangeValueForKey: @"version"];
>mVersion = inVersion;
>[self didChangeValueForKey: @"version"];
> }
> -
> 
> Now I want to translate this method into Swift. Thing is, AFAIK you can't 
> name the ivar created for a property. Is there a way to translate this to 
> swift?
> 
> TIA,
> 
> -- 
> Rick Mann
> rm...@latencyzero.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Reference to embedded view controller in IB?

[Jean-Daniel]

> Le 6 avr. 2017 à 22:35, Kyle Sluder  a écrit :
> 
> On Wed, Apr 5, 2017, at 03:42 PM, Doug Hill wrote:
>> I have a view controller that I instantiate in my Storyboard. This view
>> controller has an embedding view inside it's view, and this embedding
>> view has another view controller in it.
>> 
>> I need to configure this embedded view controller but I don't know a way
>> to make it available to my container VC in Interface Builder. For
>> example, it would be great to create an outlet in my container view
>> controller to the embedded view controller. But I don't see any way to do
>> this.
>> 
>> Can this be done? Are there other ways to get a reference to the embedded
>> view controller at runtime?
> 
> Give an identifier to the embed segue and implement -prepareForSegue: in
> your root VC to check for this segue and grab its destination VC.
> 
> --Kyle Sluder

Is prepareForSegue called for all kinds of segue, including embedding VC ? This 
is definitely not the case on macOS, but the behavior may be different on iOS.
___

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: Normalisation of filenames

[Jean-Daniel]

> Le 5 avr. 2017 à 07:49, Gerriet M. Denkmann  a écrit :
> 
> 
>> On 3 Apr 2017, at 05:58, Aki Inoue  wrote:
>> 
 This is the standard Unicode Normalization behavior. Each Unicode 
 character is assigned the Unicode Combining Property, an integer value 
 defining the canonical ordering of combining marks.
 
 The Unicode Combining Property for THAI CHARACTER SARA UU is 103, and THAI 
 CHARACTER MAI EK 107. So, MAI EK always comes after SARA UU in the 
 canonical order.
 
 On the other hand, THAI CHARACTER SARA II has the property value 0 which 
 indicates the start of the reordering segment. That’s why the character is 
 not reordered in respect to other Thai combining characters.
> 
> I just read UNICODE NORMALIZATION FORMS .
> 
> Under “11.1 Stability of Normalized Forms" it says: “A normalized string is 
> guaranteed to be stable; that is, once normalized, a string is normalized 
> according to all future versions of Unicode.”

> 
> That means: As consonant + tone-mark + top-vowel is normalised in the current 
> Unicode, there is no way to create a better normalisation which would 
> normalise this to: consonant + top-vowel + tone-mark.
> 
> Apple uses (as far as I remember) a variant of Unicode’s canonical 
> decomposition form.

Yes they do. I think is due to lack of backward compatibility for 
normalisation. I don’t think a string normalized in new Unicode version is 
guarantee to have the same normalization in past version.

If new version of HFS start using new Unicode version, it would break the 
filename if you try to mount the drive with an older driver. So HFS keep using 
an old Unicode normalisation.

> So Apple could use a better normalisation.
> 
> But: An existing filename, which is not normalised under the new and better 
> normalisation rules, would become inaccessible. Not good.
> Renormalising all filenames according to the new and better normalisation 
> rules would be probably rather expensive. 
> Also one would need to rename some files, which become identical under the 
> new rules. Kind of messy, but not too much.
> 
> So I do not really see a way out of this problem (created by some 
> questionable decisions of the Unicode people).
> 
> 
> Kind regards,
> 
> Gerriet.
> 
> P.S. A similar problem exists with NIKHAHIT + Sara Aa versus Sara Am. Looks 
> identical, but is not normalised.

___

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: Official sidebar?

[Jean-Daniel]

The OP ask about « Side Bar » not  «  Tab Bar ».

> Le 26 mars 2017 à 00:40, Saagar Jha  a écrit :
> 
> Nothing, if I remember correctly. Cocoa should handle window tabs for you.
> 
> Saagar Jha
> 
>> On Mar 25, 2017, at 07:49, Daryle Walker  wrote:
>> 
>> Testing out my app. Finally noticed the new "Show Tab Bar" View menu item. 
>> The menu also handles the tool bar, full screen, and a sidebar. Never 
>> noticed that last one before. What do I have to do in my storyboard and/or 
>> window controller to support that?
>> 
>> (Of course, I don't need one right now. But I'm still curious.)
>> 
>> Sent from my iPhone
>> ___
>> 
>> 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/saagar%40saagarjha.com
>> 
>> This email sent to saa...@saagarjha.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Unicode filenames with Apple File System and UIManagedDocument

[Jean-Daniel]

> Le 21 mars 2017 à 12:03, davel...@mac.com a écrit :
> 
>> 
>> On Mar 21, 2017, at 1:06 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Mar 20, 2017, at 2:23 PM, davel...@mac.com wrote:
>>> 
>>> NSURL *url = [[self courseDirectory] URLByAppendingPathComponent:name];
>> 
>> There’s nothing wrong with that call; it’s the canonical way to add a path 
>> component to a URL, filesystem or not.
>> 
>>> NSURL *url = [NSURL fileURLWithFileSystemRepresentation:[name 
>>> fileSystemRepresentation] isDirectory:YES relativeToURL:[self 
>>> courseDirectory]];
>> 
>> This call doesn’t make sense. You’re converting to filesystem representation 
>> and then back again, for no reason.
>> 
>> What Apple suggested is to Unicode-normalize the filename before adding it 
>> to the URL. Did you try doing that?
>> 
>> —Jens
> 
> Jens,
> 
> I’m trying to find out what that means. Someone suggested off-list to me that 
> I should be calling this:
> 
> https://developer.apple.com/reference/foundation/nsstring/1409474-decomposedstringwithcanonicalmap?language=objc
>  
> 
> 
> Is that correct?
> 
> So based on that, I think it means I should do:
> 
> NSURL *url = [[self courseDirectory] 
> URLByAppendingPathComponent:name.decomposedStringWithCanonicalMapping];
> 
> Thanks,
> Dave Reed
> 


This is what the reply suggest but that make no sens for me. If you are 
accessing the file using URL, that the work of the framework to convert the URL 
into the right file system representation.

That said, if using name.decomposedStringWithCanonicalMapping fix your problem, 
so go with it.


___

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

[Jean-Daniel]

> Le 7 mars 2017 à 21:03, davel...@mac.com a écrit :
> 
>> 
>> On Mar 7, 2017, at 1:19 PM, Alastair Houghton <alast...@alastairs-place.net> 
>> wrote:
>> 
>> On 7 Mar 2017, at 12:47, Jean-Daniel <mail...@xenonium.com> wrote:
>>> 
>>> Did you try to use NSString -fileSystemRepresentation instead of UTF-8, or 
>>> even better, use URL. While using UTF-8 for path worked well on HFS+, It 
>>> was never guaranteed to work on all FS.
>> 
>> FWIW, the macOS kernel does use UTF-8 at the VFS interface (and therefore 
>> the BSD syscalls that take path arguments expect UTF-8).  This is different 
>> to most other UNIXen (which tend to treat paths as a bunch of bytes, at 
>> least at syscall level and often at filesystem level too).  It’s definitely 
>> the case that for the built-in FAT, NTFS and HFS+ implementations, UTF-8 
>> will work.  Other filesystem implementations really *should* be treating 
>> what they get as UTF-8 too, but obviously that’s not guaranteed.
>> 
>> AFAIK all -fileSystemRepresentation does is it processes the Unicode string 
>> according to the rules in TN1150 and then convert to UTF-8; but you don’t 
>> actually *need* to do the HFS+ mapping (TN1150) before calling the BSD API 
>> (and it doesn’t even make any sense to do so unless the filesystem is HFS+, 
>> which -fileSystemRepresentation has no way of knowing).  The main benefit is 
>> that the result will compare bytewise equal with a filename read from the 
>> filesystem (assuming HFS+).  On other filesystems, well, things are 
>> different.  VFAT and later variants store UTF-16, as does NTFS, but the 
>> rules in both cases differ.  ExtFS, UFS et al. tend to regard filenames as a 
>> bunch of bytes and don’t even try to record what encoding was used.  I don’t 
>> know what ZFS, XFS or JFS do; using Unicode at filesystem level on a 
>> UNIX-like system is not unproblematic (because it may very well *not* be the 
>> same encoding being used at the user’s terminal), but equally the bunch of 
>> bytes approach creates all kinds of fun (you may *see* a file with a 
>> particular name, but you can’t necessarily name it yourself from the 
>> keyboard...)
>> 
>> Not that I’d recommend *not* using -fileSystemRepresentation; Apple says we 
>> should, so we should.  I’m just observing that it isn’t a particularly good 
>> API and in future it’ll either be deprecated or do the exact same thing as 
>> -UTF8String because there’s really no other good option I can see.
>> 
>> Kind regards,
>> 
>> Alastair.
> 
> I saw the other posts about fileSystemRepresentation and tried the code I 
> posted earlier in the thread didn’t have any effect.
> 
> 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
> 
> $ unzip *.zip
> Archive:  إعلام.zip
> checkdir error:  cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent
> No such file or directory
> unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore.
> checkdir error:  cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent
> No such file or directory
> unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore-shm.
> checkdir error:  cannot create Ϻ+?Ϧ+?Ϻ+?/StoreContent
> No such file or directory
> unable to process Ϻ+?Ϧ+?Ϻ+?/StoreContent/persistentStore-wal.
> 
> $ ls
> ?+%F2Ϧ+%E4?+%E0/  إعلام.zip
> 
> When you unzip it, it should create a directory with the exact same name as 
> the .zip file (just without the .zip extension). 
> 
> This may be enough information that it’s worth filing a bug report now. Does 
> anyone have any other suggestions? Again, creating an Arabic file on iOS 10.3 
> works fine, but these ones that were created on 10.2 do not open on 10.3.

If new files work but old ones are broken, so it is probably a FS migration 
issue. Look like something went wrong while converting H

Re: Unicode filenames with Apple File System and UIManagedDocument

[Jean-Daniel]

> Le 6 mars 2017 à 14:28, davel...@mac.com a écrit :
> 
> I have an iOS app (Attendance2) written in Objective-C. One of my users 
> upgraded to the public 10.3 iOS beta and reported he could no longer open his 
> documents (I have a subclass of UIManagedDocument so they are Core Data files 
> stored in the package/directory format that UIManagedDocument uses). I didn’t 
> notice any issues with my test device using the developer beta of 10.3. He 
> changed the file names from Arabic to Roman and then he said he could open 
> them.
> 
> Everything I do with NSString is via UTF8 (and it worked fine with Arabic 
> letters for this person before updating to the 10.3 beta) so I don’t think 
> I’m doing anything wrong.
> 

Did you try to use NSString -fileSystemRepresentation instead of UTF-8, or even 
better, use URL. While using UTF-8 for path worked well on HFS+, It was never 
guaranteed to work on all FS.



___

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: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 19 janv. 2017 à 22:18, Daryle Walker  a écrit :
> 
> 
>> On Jan 16, 2017, at 12:08 PM, Charles Srstka  
>> wrote:
>> 
>>> On Jan 14, 2017, at 4:41 AM, Daryle Walker >> > wrote:
>>> 
>>> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
>>> file moves. There are file references in macOS, which would be more stable, 
>>> but I read that there’s a bug in the URL class where it would degrade 
>>> file-reference URLs to standard-file URLs, so that’ll be problematic. 
>>> Another solution would to create bookmark data from a file URL and take a 
>>> hash of that. But are multiple bookmark data blocks of the same file URL 
>>> consistent enough for this idea to work?
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type. However, if 
>> you’re using Objective-C, file reference URLs will still work fine, and you 
>> can always make an Objective-C wrapper that stores a file reference URL and 
>> use that from Swift.
> 
> I looked at some code that gives a workaround for the file-reference URL 
> problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
> values, then sprinkles those onto a URL string template. Since UUIDs are 
> 128-bit values, I could just copy a reference ID directly into a UUID.

The file reference URL content is an implementation details and relying on the 
fact that a reference ID is 128 bit is very fragile IMHO, especially as Apple 
is planning to introduce a new FS soon. On APFS they may decide to use 
something completely different for file reference.



___

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: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 14 janv. 2017 à 11:41, Daryle Walker <dary...@mac.com> a écrit :
> 
> 
>> On Jan 11, 2017, at 3:58 PM, Keary Suska <cocoa-...@esoteritech.com> wrote:
>> 
>> 
>>> On Jan 11, 2017, at 11:16 AM, Jens Alfke <j...@mooseyard.com> wrote:
>>> 
>>> 
>>>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel <mail...@xenonium.com> wrote:
>>>> 
>>>> UUID means Universally unique identifier and it must be unique: 
>>>> https://en.wikipedia.org/wiki/UUID 
>>>> <https://en.wikipedia.org/wiki/UUID><https://en.wikipedia.org/wiki/UUID 
>>>> <https://en.wikipedia.org/wiki/UUID>>
>>>> To generate an UUID, use a standard system function (CFUUID, NSUUID, 
>>>> libuuid, …)
>>> 
>>> This is not what I believe Daryle was asking, and it’s sent everyone off on 
>>> a tangent about what UUIDs are.
>>> 
>>> My interpretation of the original question: Is an NSIncrementalStore’s UUID 
>>> scoped to the specific database, or is it scoped to that _implementation_ 
>>> of the store? That is, is the UUID generated at runtime or at compile time?
>>> 
>>> I don’t know the answer; just hoping to get the discussion back on track :)
>> 
>> The docs say:
>>  "A unique identifier for the store at the given URL. It must be 
>> uniquely and reproducibly derivable, such that multiple instances of your 
>> store return the same UUID”
>> 
>> My reading is that the store UUID would be unique to a specific database 
>> since it is only unique to the URL location of the store. I thin the docs 
>> use “instance” in a strictly OOP sense.
> 
> Yes, this is what my question is about. Could I grab a UUID from a 
> get-a-random-UUID site,

You don’t need a get a random UUID site to get an uuid. Open your terminal and 
type uuidgen.

> hard code it as a type-level property in Swift, and use it for every 
> instantiation (even for different files)? If this isn’t acceptable, I’m 
> seemingly stuck since the data format doesn’t have a UUID field within it and 
> I can’t base a UUID off of a hash of the file since it would change after 
> each edit.
> 
> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive 
> file moves. There are file references in macOS, which would be more stable, 
> but I read that there’s a bug in the URL class where it would degrade 
> file-reference URLs to standard-file URLs, so that’ll be problematic. Another 
> solution would to create bookmark data from a file URL and take a hash of 
> that. But are multiple bookmark data blocks of the same file URL consistent 
> enough for this idea to work?

Your storage should have metadata and contains the UUID. Each time you create a 
new database, you should generate a new UUID and store it in your storage 
metadata. 
If your storage don’t support that (that's unfortunate for a storage format 
that is supposed to support storing any type of data, as in practice you can 
always create a internal table to store them), maybe the best you can do is 
attach the metadata to the file directly using extended attributes for 
instance. Extended attribute may be lost by some operation, but it should be 
relatively stable as long as the file does not leave the machine.


___

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: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

UUID means Universally unique identifier and it must be unique: 
https://en.wikipedia.org/wiki/UUID 

To generate an UUID, use a standard system function (CFUUID, NSUUID, libuuid, …)


> Le 10 janv. 2017 à 11:36, Daryle Walker  a écrit :
> 
> Been reading up on NSIncrementalStore, including its guide. I think I grok it 
> more now. When initializing an instance, you're supposed to submit an UUID. 
> Can a single value be used for all instances, or is it supposed to unique per 
> instance?  If the latter, and the source data doesn't already have a UUID 
> field, do you to take heroic measures to ensure uniqueness? Or is a casual 
> effort enough?
> 
> Sent from my iPhone
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Retaining non-document windows

[Jean-Daniel]

> Le 4 janv. 2017 à 20:37, Quincey Morris  
> a écrit :
> 
> On Jan 4, 2017, at 02:30 , Daryle Walker  wrote:
>> 
>> I always had to guess how to retain a non-document window. I usually get it 
>> after a bunch of hacking, but I want more official advice. Like I can get 
>> from here.
>> 
>> I think there are three scenarios:
>> - a window with 0 or 1 instances like an app-global photo album 
>> - arbitrary number of independent windows with the same type, like a web 
>> browser 
>> - an auxiliary window supporting a normal one, changing its displayed data 
>> when the top normal window changes. It should be hidden when no normal 
>> windows are open.
>> 
>> Whatever retaining system is used needs to handle when a window closes. It 
>> either sets a single handle to NIL, removes the pointer from an array, or 
>> hides the window (still holding a retain).
> 
> It’s a little bit complicated because there is history to window management. 
> For example, windows have a “release when closed” option (for historical 
> reasons) that interacts with the nib-loading machinery.
> 
> However, I think the real answer to your question is pretty easy: always, 
> always use a window controller for each window. The window controller manages 
> the lifetime of the NSWindow object, and you manage the lifetime of the 
> window controller objects by keeping a reference (to the one window 
> controller, or an array of references to multiple window controllers) in a 
> known location. It’s often done as a property on the application delegate 
> object, but it could also be a NSWindowController-subclass static property, 
> depending on your architecture.
> 
> If you’re using storyboards, you should already have one window controller 
> per window. There may be nothing else to do in this case. However, I don’t 
> know that there’s a direct way to get a programmatic reference to the window 
> controller easily. If you need it, you may have to resort to an indirect 
> technique.

When using storyboard, the only way to instantiate window is by getting a 
reference to the window controller (by using 
-instantiateControllerWithIdentifier:), so it should not be an issue.



___

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: Linking one framework to two places in a project and static libs

[Jean-Daniel]

> Le 13 déc. 2016 à 21:59, Alex Zavatone  a écrit :
> 
> I've got a lovely (cough) non ARC iOS project that consists of 1 project file 
> that the target app is made from that links to 5 other projects that are 
> compiled to static libs through the odd method of specifying their path in 
> Other Linker Flags.
> 
> This is built (cough) through the legacy build path setting of having the 
> build folder within each of the project folders.  The absolute path of each 
> is what is entered in Other Linker Flags of the main project file to allow 
> the iOS target app to link to these static libs.  
> 
> Yes, it hurts my brain too.
> 
> Both the project file and one of the static libs need to be aware of my 
> framework.  
> 
> Considering how much of a mess this whole thing is to figure out, I simply 
> paste one copy of my framework into Framework folder of the app and the 
> Resources folder of the static lib that needs it, so which ever one Xcode 
> picks doesn't matter.
> 
> This is sloppy as hell.
> 
> Is there a method that uses a shortcut, alias or symbolic link to have the 
> framework that should be in the Resources folder then the static lib ids 
> built refer to the actual file that is in the Frameworks folder that the app 
> uses??
> 
> How do people handle this > 1 lib in a project needs to refer to another 
> compiled lib?
> 

Why do the static lib need the framework ? A static lib is just a bundle of .o 
file packed into a single file. There is no linking step involved. So you need 
just the header of the framework, not the framework itself. Only the final 
binary need the framework.


___

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: Migrating shared library plugins to Cocoa Touch Frameworks

[Jean-Daniel]

> Le 4 déc. 2016 à 21:41, Andreas Falkenhahn  a écrit :
> 
> I've now implemented plugin support using dlopen() in my app and
> it works fine so far.
> 
> However, it seems like *all* symbols are exported to the dylib
> inside the Cocoa Touch Framework. How can I configure Xcode to
> export only certain symbols? I want to name the symbols that
> should be exported explicitly.
> 
> When compiling normal macOS dylibs I don't use Xcode at all but
> makefiles. In that case, I simply use gcc's -exported_symbol_list
> argument to tell the linker which symbols should be made public.
> I could probably use this approach for Cocoa Touch Frameworks as
> well but I was wondering whether Xcode has a more convenient
> solution of marking symbols for export than using the -exported_symbol_list
> linker option. Is there any?
> 

The best way if you don’t want to use a symbole file is to make all symboles 
hidden by default (using the GCC_SYMBOLS_PRIVATE_EXTERN Xcode build settings), 
and then annotate the exported symbols using the visibility attribute.

In practice, it means you should declared the exported symbols as follow:

__attribute__((__visibility__("default"))) extern void visible_function();

You can declare a macro to simplify such construct

#define MY_PLUGIN_EXPORT __attribute__((__visibility__("default"))) extern 

MY_PLUGIN_EXPORT 
void visible_function();

This attribute should also be set on obj-c class you want to export.


___

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: Get file argument

[Jean-Daniel Dupas]

> Le 4 sept. 2016 à 20:48, Jens Alfke  a écrit :
> 
> 
>> On Sep 4, 2016, at 4:56 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> Is there also a way to get the file argument without having an NSApp,
>> i.e. can my program somehow obtain the file argument *before* creating
>> the NSApp object or is that impossible?
> 
> Perhaps through LaunchServices, or by implementing its own AppleEvent handler 
> for the ‘odoc’ event.
> 
> I do still feel that your attempt to build this 3rd-party code wrapper by 
> avoiding the normal Cocoa application/event loop is a mistake. You’re going 
> to run into one problem after another by going completely against the grain 
> of the framework like this.
> 

Whatever you do, you still have to pull the incoming events, else you Apple 
Event won’t be dispatched. As the canonical way to do that is though NSApp, I 
don’t now if this is possible.



___

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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 19:33, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
>> 
>> Le 24 août 2016 à 18:50, David Duncan <david.dun...@apple.com> a écrit :
>> 
>> 
>>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay <j...@szuhay.org> wrote:
>>> 
>>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>>> into a viewRect
>>> with 
>>> 
>>> CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>>> 
>>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>>> currently use 1024x1024
>>> but could easily make them 512x512 or 768x768.
>>> 
>>> So my question is, “Is is more efficient to draw the layer into a smaller 
>>> viewRect (down-sample) 
>>> or into a larger ViewRect (up-sample)?” 
>>> 
>>> Or does it even matter?
>> 
>> It depends on if quality or performance matters more.
>> 
>> Downsampling is generally more expensive because you have to deal with more 
>> data and so you become more easily bandwidth limited, but at the same time 
>> if you must resample an image, down sampling generally produces better 
>> quality. Upsampling is the opposite of all that.
>> 
>> So if performance matters more than quality, then you probably want to 
>> upsample.
>> 
> 
> Moreover, the performance will greatly depends the sampling algorithm you 
> choose. CGImage provide a couple of algorithms with different tradeoff (see 
> CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).

Just for the record, here is a link with different technics available on OS X 
to do that: 

http://nshipster.com/image-resizing/


> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Core Graphics: Is it better to up-sample or down-sample images when drawing into a rect?

[Jean-Daniel Dupas]

> Le 24 août 2016 à 18:50, David Duncan  a écrit :
> 
> 
>> On Aug 24, 2016, at 1:23 AM, Jeff Szuhay  wrote:
>> 
>> I’m using a bunch of layers to draw images to, compose them, and then draw 
>> into a viewRect
>> with 
>> 
>>  CGContextDrawLayerInRect( viewContext, viewRect, myLayer);
>> 
>> Of course, I’m trying to pick the most reasonable size for my layers. I 
>> currently use 1024x1024
>> but could easily make them 512x512 or 768x768.
>> 
>> So my question is, “Is is more efficient to draw the layer into a smaller 
>> viewRect (down-sample) 
>> or into a larger ViewRect (up-sample)?” 
>> 
>> Or does it even matter?
> 
> It depends on if quality or performance matters more.
> 
> Downsampling is generally more expensive because you have to deal with more 
> data and so you become more easily bandwidth limited, but at the same time if 
> you must resample an image, down sampling generally produces better quality. 
> Upsampling is the opposite of all that.
> 
> So if performance matters more than quality, then you probably want to 
> upsample.
> 

Moreover, the performance will greatly depends the sampling algorithm you 
choose. CGImage provide a couple of algorithms with different tradeoff (see 
CGContextSetInterpolationQuality() and NSImage and UIImage equivalents).


___

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

[Jean-Daniel Dupas]

> Le 15 août 2016 à 18:02, Jens Alfke <j...@mooseyard.com> a écrit :
> 
> 
>> On Aug 15, 2016, at 11:34 AM, Jean-Daniel Dupas <mail...@xenonium.com 
>> <mailto:mail...@xenonium.com>> wrote:
>> 
>> No, You can have only one PCH per project. That said, you can define a 
>> second one that include the first one for your second project.
> 
> I think you meant to say you can have only one PCH per _target_.

Of course. Thanks for the correction. 

___

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

[Jean-Daniel Dupas]

> Le 15 août 2016 à 15:27, Trygve Inda  a écrit :
> 
>> 
>>> On Aug 15, 2016, at 3:41 AM, Stephane Sudre  wrote:
>>> 
>>> . you could redefine the class name in the .pch of one project.
>> 
>> +1 — I’ve had to do this before, and it works fine. Just add
>> #define MyDisplayManager MyDisplayManager_PP
>> or whatever.
>> 
>> The caveat is that of course IB doesn’t read the PCH, so you’ll have to
>> manually change the class name in any nibs it may appear in.
>> 
>> —Jens
> 
> Both projects share a common pch. Is there a way to add a second pch to just
> one of them?

No, You can have only one PCH per project. That said, you can define a second 
one that include the first one for your second project.



___

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: undomanger performance

[Jean-Daniel Dupas]

> Le 1 mai 2016 à 01:42, Quincey Morris <quinceymor...@rivergatesoftware.com> a 
> écrit :
> 
> On Apr 30, 2016, at 12:49 , Jean-Daniel Dupas <mail...@xenonium.com 
> <mailto:mail...@xenonium.com>> wrote:
>> 
>> Maybe registering the changes is not executed immediately but deferred until 
>> the end of the current event loop cycle
> 
> There’s no “maybe” about it. By default, the undo manager groups all undo 
> actions registered between iterations of the run loop into a single top-level 
> group.

There is other way to group action that deferring the registration until the 
end of the event loop. That’s why I said maybe.


___

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: undomanger performance

[Jean-Daniel Dupas]

Just my 2 cents. 

Maybe registering the changes is not executed immediately but deferred until 
the end of the current event loop cycle, so the undo manager can group them 
into a single operation.

In such case, it would mean that what you think is the undo registration is 
just a call to schedule the real operation and is relatively fast, but the real 
works take much more time and is deferred until the end of the current event 
handling.

> Le 30 avr. 2016 à 21:39, Georg Seifert  a écrit :
> 
> Hi
> 
> My app deals with an object tree that can have millions of leaves. It is 
> possible to run an operation on all of them. Each will register its own 
> change with the undo manager. The hole operation might tale a few second (the 
> last line in the trace below). But after my operation is finished, there is 
> another operation triggered by the system that takes much longer than the 
> original task and it blocks the UI. It is directly linked to the undo 
> registration, if I disable it, this does not happen. 
> 
> Running Time  Self (ms)   Symbol Name
> 26258.0ms   81.3% 0,0 _dispatch_mgr_thread  0x4ef18d
> 26258.0ms   81.3% 0,0  _dispatch_mgr_thread
> 26258.0ms   81.3% 0,0   _dispatch_mgr_invoke
> 26250.0ms   81.2% 0,0_dispatch_mgr_queue_drain
> 26248.0ms   81.2% 48,0_dispatch_queue_drain
> 26168.0ms   81.0% 1,0  _dispatch_client_callout
> 26141.0ms   80.9% 97,0  _dispatch_source_set_timer3
> 25561.0ms   79.1% 25561,0_dispatch_timers_update
> 481.0ms1.4%   8,0_dispatch_resume_slow
> 2.0ms0.0% 2,0_dispatch_queue_wakeup
> 8.0ms0.0% 0,0   free
> 6.0ms0.0% 6,0   dispatch_release
> 6.0ms0.0% 6,0   _os_object_release
> 4.0ms0.0% 4,0   dispatch_resume
> 1.0ms0.0% 1,0   nano_free_definite_size
> 1.0ms0.0% 0,0   
> 12.0ms0.0%12,0 OSAtomicEnqueue
> 9.0ms0.0% 4,0  gcd_queue_item_complete_hook
> 6.0ms0.0% 1,0  _dispatch_continuation_free_to_cache_limit
> 3.0ms0.0% 2,0  
> _dispatch_introspection_queue_item_dequeue_hook
> 1.0ms0.0% 1,0  DYLD-STUB$$free
> 1.0ms0.0% 0,0  
> 2.0ms0.0% 2,0 _dispatch_introspection_callout_return
> 7.0ms0.0% 6,0_dispatch_cache_cleanup
> 1.0ms0.0% 0,0_dispatch_timers_run
> 4162.0ms   12.8%  0,0 Main Thread  0x4ef176
> 
> Does anyone has an idea what’s going on?
> 
> Thanks
> Georg Seifert
> Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Value of the MAC_OS_X_VERSION_MIN_REQUIRED macro

[Jean-Daniel Dupas]

It is unsafe to use availability conditional in headers.
You can’t guarantee that the framework client will has the same settings that 
what was used to compile the framework.

That said, if you want to use weak when compiling for ARC and assign otherwise, 
you can just use #if __has_feature(objc_arc)


> Le 20 févr. 2016 à 19:00, Ilya Kulakov  a écrit :
> 
> Hi,
> 
> I would like to add support for ARC's weaks to my framework that supports Mac 
> OS X down to 10.6
> 
> My current solution is:
> 
> #if defined(MAC_OS_X_VERSION_MIN_REQUIRED) && MAC_OS_X_VERSION_MIN_REQUIRED 
> >= 1070
>@property (weak) NSObject *delegate;
> #else
>@property (assign) NSObject *delegate;
> #endif
> 
> However, the value of MAC_OS_X_VERSION_MIN_REQUIRED is always 1070 despite of 
> set Deployment Target (I compile on 10.11).
> Why is it so and what solution could I use in my situation?
> 
> Best Regards,
> Ilya Kulakov
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Can an NSArray ever have a count of -1?

[Jean-Daniel Dupas]

> Le 20 févr. 2016 à 07:28, Quincey Morris 
>  a écrit :
> 
> On Feb 19, 2016, at 22:14 , Gerriet M. Denkmann  wrote:
>> 
>> Is there (yet) a Swift version of ‘[NSString stringWithFormat: “%08lx”, 
>> (someCast) someValue]’ ?
> 
> No, and yes, and no, and yes.
> 
> There is currently AFAIK no such native formatting syntax in Swift print 
> statements, so “no”.
> 
> But you can of course use ‘String (format: “%08lx”, someCast (someValue))’. 
> This isn’t actually cheating, because Swift has its own implementation of the 
> entire NSString API. There’s no bridging to NSString objects involved in 
> these functions, so “yes”.
> 
> But you can’t *use* this API in Swift unless you import Foundation. Without 
> the import, Swift will pretend it doesn’t have those String APIs, though it 
> really does, so “no”.
> 
> But starting with Swift 3, later this year, Foundation will migrate natively 
> into Swift — for all supported Swift platforms, such as Linux — so I assume 
> there will be some kind of native String formatting syntax, so “yes”, though 
> whether it will use the same format strings as Cocoa, I don’t know.


Even if swift is planning to provide a Foundation framework, one of the strong 
requirement is that it must be source compatible with the Apple Foundation, as 
that is the one that will be used on Apple platforms. So if it does not behave 
like NSString, it should be considered a bug.


___

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 an NSArray ever have a count of -1?

[Jean-Daniel Dupas]

> Le 19 févr. 2016 à 22:29, Jens Alfke  a écrit :
> 
> 
>> On Feb 19, 2016, at 1:17 PM, Jim Adams  wrote:
>> 
>>   SLogInfo(@"Starting csi %ld count %d", csi, sortedEvents.count);
>> 
>> In the console I see:
>> INFO: Starting csi -1 count -1
>> The very next line crashes when the sortedEvents are accessed. What could 
>> cause the array to have a -1 count?
> 
> You’re using the wrong format strings for both of those parameters.
> 
> csi is 64-bit so you need %lld. The formatter sees %ld and thinks it’s 32-bit 
> not 64-bit, so it skips the wrong amount of space on the stack when going to 
> the next parameter, which is why you then get a bogus value for the count.
> 
> Also, NSArray.count is of type NSUInteger, which is unsigned, and has 
> different sizes on different platforms. The right format specifier is either 
> %lu (in a 32-bit app) or %llu (in 64-bit).

Not exactly. %d is for 32 bit signed integer, but %ld is for signed long, and 
so is the right formatter for NSInteger value (which is a typedef alias of 
long) and 64 bit integer on 64 bit platform.

%lld is for signed long long and is the same as long for most platform.




___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

> Le 11 févr. 2016 à 02:16, Ben Kennedy <b...@zygoat.ca> a écrit :
> 
>> On 10 Feb 2016, at 5:00 pm, Gary L. Wade <garyw...@desisoftsystems.com> 
>> wrote:
>> 
>> You've made my point. None of my friends would even bother with looking at 
>> the certificate for his site (assuming that's his site from his email 
>> address) and move on. At worst, they'd call me and I'd say don't go there 
>> since I don't want them to screenshot that and text it to me to figure it 
>> out.
> 
> No, you are misunderstanding me.  My point is that it may not be valid to 
> assume the web server at 213.186.33.24 (to which xenonium.com resolves) will 
> answer to HTTPS with a cert for "xenonium.com".
> 
> For example, https://213.186.33.24 presents the same "hostname mismatch" 
> alert, because the cert is not named for "213.186.33.24".
> 
> Conduct the same exercise for any A record returned for www.apple.com, and 
> you'll also get this result.  Completely expected.
> 
> Now, if Jean-Daniel has stated definitively that https://xenonium.com is 
> expected to serve up a matching certificate, you have an argument I would 
> agree with.  But for all we know (unless I've missed it), he's serving his 
> material at https://ssl13.ovh.net.
> 
> b

Sorry for the confusion. I’m not taking about that web site. It is on a 
mutualized hosting platform that forces me to pay to install a certificate that 
match my hostname.

If I need to distribute secure content from that site, I can use the 
alternative access URL https://ssl13.ovh.net/~xenonium/ 
<https://ssl13.ovh.net/~xenonium/>.





___

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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

> Le 10 févr. 2016 à 05:48, Trygve Inda  a écrit :
> 
>> If your hosting provider still charges an arm and a leg for SSL, switch.
> 
> I need SSL for multiple subdomains. My host (Pair Networks) charges $449/yr
> for such a certificate. That seems really expensive. What are others paying
> for this? I have been very happy with Pair as we run a complex server setup
> with multiple cron jobs, custom C programs etc.
> 

I pay 0$ and can have as many domains as I want on my certificactes. I’m using 
let'sencrypt  for all my servers. It requires some setup but it’s free and 
works very well.

https://letsencrypt.org 

> I also see no way to add an SSL certificate to a CNAME'd site at Amazon S3:
> 
> download.xericdesign.com CNAME
> s3.amazonaws.com/download.xericdesign.com/
> 
> Trygve
> 
> 
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

OK. I did watch the POC and it appears this is not in the update process, but 
in the check for update that the attack occurs.

> Le 9 févr. 2016 à 23:27, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
> I agree. I can’t see how that can work with a properly configured Sparkle, 
> that is an App that accepts only properly signed update.
> 
> 
>> Le 9 févr. 2016 à 23:22, Graham Cox <graham@bigpond.com> a écrit :
>> 
>> Thanks for the heads-up Jens.
>> 
>> Is it enough to change the SUFeedURL to https (if your server supports it, 
>> which ours does), or does it also require the library to be updated? The 
>> comment you link doesn’t clarify it for me - it mentions WebView, but I’m 
>> not clear about how Sparkle is using Webview - wouldn’t it just request the 
>> appcast directly, parse it and then download the update notes if it finds an 
>> update BEFORE opening a webview? Other than displaying the update notes I 
>> don’t see why Sparkle would open a Webview, but my understanding of how it 
>> works could well be wrong.
>> 
>> There’s another thing too. Even if the appcast feed were compromised and an 
>> “update” containing malware were injected, it would still have to be signed 
>> correctly using the developers private key which Sparkle checks before 
>> installing the update. So even if it got that far it would surely fail at 
>> that step?
>> 
>> —Graham
>> 
>> 
>> 
>>> On 10 Feb 2016, at 8:10 AM, Jens Alfke <j...@mooseyard.com> wrote:
>>> 
>>> Ars Technica has an article today about a vulnerability in the Sparkle 
>>> auto-update framework, which can allow an attacker to hijack an app update 
>>> check to install malware on the user’s Mac:
>>> 
>>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
>>> 
>>> The clearest description of the bug is in this comment:
>>> 
>>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/?comments=1=30615427#comment-30615427
>>> 
>>> Basically: If your app uses a version of Sparkle older than 1.13 — like 
>>> every single Sparkle-using app on my computer :( — and the updates are 
>>> delivered over a non-HTTPS connection, you’re vulnerable (or rather, your 
>>> users are.)
>>> 
>>> The attack’s not trivial: it requires someone to tamper with the appcast 
>>> RSS feed being received by Sparkle, at the time that it checks for an 
>>> update. Most likely this would be by poisoning the DNS on a shared router 
>>> and pointing your domain to their server; or else they could compromise the 
>>> router to sniff the HTTP traffic and inject the payload into the stream.
>>> 
>>> The best fix is to upgrade your server to use HTTPS. If your hosting 
>>> provider still charges an arm and a leg for SSL, switch.
>>> In addition (or as the second-best fix if you can’t go SSL), download the 
>>> latest Sparkle and update your app project to use it.
>>> 
>>> —Jens
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

I agree. I can’t see how that can work with a properly configured Sparkle, that 
is an App that accepts only properly signed update.


> Le 9 févr. 2016 à 23:22, Graham Cox  a écrit :
> 
> Thanks for the heads-up Jens.
> 
> Is it enough to change the SUFeedURL to https (if your server supports it, 
> which ours does), or does it also require the library to be updated? The 
> comment you link doesn’t clarify it for me - it mentions WebView, but I’m not 
> clear about how Sparkle is using Webview - wouldn’t it just request the 
> appcast directly, parse it and then download the update notes if it finds an 
> update BEFORE opening a webview? Other than displaying the update notes I 
> don’t see why Sparkle would open a Webview, but my understanding of how it 
> works could well be wrong.
> 
> There’s another thing too. Even if the appcast feed were compromised and an 
> “update” containing malware were injected, it would still have to be signed 
> correctly using the developers private key which Sparkle checks before 
> installing the update. So even if it got that far it would surely fail at 
> that step?
> 
> —Graham
> 
> 
> 
>> On 10 Feb 2016, at 8:10 AM, Jens Alfke  wrote:
>> 
>> Ars Technica has an article today about a vulnerability in the Sparkle 
>> auto-update framework, which can allow an attacker to hijack an app update 
>> check to install malware on the user’s Mac:
>>  
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
>> 
>> The clearest description of the bug is in this comment:
>>  
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/?comments=1=30615427#comment-30615427
>> 
>> Basically: If your app uses a version of Sparkle older than 1.13 — like 
>> every single Sparkle-using app on my computer :( — and the updates are 
>> delivered over a non-HTTPS connection, you’re vulnerable (or rather, your 
>> users are.)
>> 
>> The attack’s not trivial: it requires someone to tamper with the appcast RSS 
>> feed being received by Sparkle, at the time that it checks for an update. 
>> Most likely this would be by poisoning the DNS on a shared router and 
>> pointing your domain to their server; or else they could compromise the 
>> router to sniff the HTTP traffic and inject the payload into the stream.
>> 
>> The best fix is to upgrade your server to use HTTPS. If your hosting 
>> provider still charges an arm and a leg for SSL, switch.
>> In addition (or as the second-best fix if you can’t go SSL), download the 
>> latest Sparkle and update your app project to use it.
>> 
>> —Jens
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

Maybe an issue cause you use __weak reference which zeroed for some reason.
Can you try to use __unsafe_unretained instead and see what happen ?

> Le 5 févr. 2016 à 14:46, Dave <d...@looktowindward.com> a écrit :
> 
> 
>> On 5 Feb 2016, at 13:34, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>> 
>> And obviously, you also add - encodeWithCoder: and -initWithCoder: methods 
>> in your custom classes.
> 
> Yes, see my other thread, it decodes all the other fields but not the (weak) 
> back links get set to nil most of the time…….
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

That is your need, not your problem. 

To archive an object graph (cyclic or not), you just do [NSKeyedArchiver 
archiveRootObject:graph toFile:@"myfile"];



> Le 5 févr. 2016 à 14:28, Dave <d...@looktowindward.com> a écrit :
> 
> Hi,
> 
> See my other thread on this list which explains it fully  - 
> "Archive/Unarchive Problem/Question?”.
> 
> Basically I need to save/restore a Network of Custom Objects…..
> 
> All the Best
> Dave
> 
>> On 5 Feb 2016, at 13:18, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>> 
>> You don’t tell use what is your problem. You can perfectly encode any 
>> structure using Keyed archivers (whether there is cycles and backlinks).
>> 
>>> Le 5 févr. 2016 à 14:13, Dave <d...@looktowindward.com> a écrit :
>>> 
>>> Hi,
>>> 
>>> I’m having problems with Back Links when Archiving/Unarchiving an Object. I 
>>> found the text below at:
>>> 
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
>>> 
>>> 
>>> Root Object
>>> 
>>> An object graph is not necessarily a simple tree structure. Two objects can 
>>> contain references to each other, for example, creating a cycle. If a coder 
>>> follows every link and blindly encodes each object it encounters, this 
>>> circular reference will generate an infinite loop in the coder. Also, a 
>>> single object can be referenced by several other objects. The coder must be 
>>> able to recognize and handle multiple and circular references so that it 
>>> does not encode more than one copy of each object, but still regenerate all 
>>> the references when decoding.
>>> To solve this problem, NSCoder introduces the concept of a root object. The 
>>> root object is the starting point of an object graph. To encode an object 
>>> graph, you invoke the NSCoder method encodeRootObject:, passing in the 
>>> first object to encode. Every object encoded within the context of this 
>>> invocation is tracked. If the coder is asked to encode an object more than 
>>> once, the coder encodes a reference to the first encoding instead of 
>>> encoding the object again.
>>> 
>>> NSCoder does not implement support for root objects; NSCoder’s 
>>> implementation of encodeRootObject: simply encodes the object by invoking 
>>> encodeObject:. It is the responsibility of its concrete subclasses to keep 
>>> track of multiple references to objects, thus preserving the structure of 
>>> any object graphs.
>>> 
>>> The last paragraph seems pertinent to my problem, so do I need to do 
>>> something special for “weak”, back links in order to “keep track of 
>>> multiple references to objects”? If so could some please tell me how to do 
>>> this? I’m really struggling to get something out the door and was advised 
>>> to use the Keyed Archiver/Unarchiver as it would be the simplest 
>>> implementation……
>>> 
>>> Is this any other documentation or sample code available? There are plenty 
>>> of trivial examples out there, no nothing I can find that works for weak 
>>> back links, although according to all the Apple Blurb I can find, it is 
>>> possible, they just don’t tell you how to do it that I can find!
>>> 
>>> Thanks in Advance for Any Help
>>> All the Best
>>> Dave
>>> 
>>> ___
>>> 
>>> 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/mailing%40xenonium.com
>>> 
>>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

And obviously, you also add - encodeWithCoder: and -initWithCoder: methods in 
your custom classes.

> Le 5 févr. 2016 à 14:33, Jean-Daniel Dupas <mail...@xenonium.com> a écrit :
> 
> That is your need, not your problem. 
> 
> To archive an object graph (cyclic or not), you just do [NSKeyedArchiver 
> archiveRootObject:graph toFile:@"myfile"];
> 
> 
> 
>> Le 5 févr. 2016 à 14:28, Dave <d...@looktowindward.com> a écrit :
>> 
>> Hi,
>> 
>> See my other thread on this list which explains it fully  - 
>> "Archive/Unarchive Problem/Question?”.
>> 
>> Basically I need to save/restore a Network of Custom Objects…..
>> 
>> All the Best
>> Dave
>> 
>>> On 5 Feb 2016, at 13:18, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>>> 
>>> You don’t tell use what is your problem. You can perfectly encode any 
>>> structure using Keyed archivers (whether there is cycles and backlinks).
>>> 
>>>> Le 5 févr. 2016 à 14:13, Dave <d...@looktowindward.com> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> I’m having problems with Back Links when Archiving/Unarchiving an Object. 
>>>> I found the text below at:
>>>> 
>>>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
>>>> 
>>>> 
>>>> Root Object
>>>> 
>>>> An object graph is not necessarily a simple tree structure. Two objects 
>>>> can contain references to each other, for example, creating a cycle. If a 
>>>> coder follows every link and blindly encodes each object it encounters, 
>>>> this circular reference will generate an infinite loop in the coder. Also, 
>>>> a single object can be referenced by several other objects. The coder must 
>>>> be able to recognize and handle multiple and circular references so that 
>>>> it does not encode more than one copy of each object, but still regenerate 
>>>> all the references when decoding.
>>>> To solve this problem, NSCoder introduces the concept of a root object. 
>>>> The root object is the starting point of an object graph. To encode an 
>>>> object graph, you invoke the NSCoder method encodeRootObject:, passing in 
>>>> the first object to encode. Every object encoded within the context of 
>>>> this invocation is tracked. If the coder is asked to encode an object more 
>>>> than once, the coder encodes a reference to the first encoding instead of 
>>>> encoding the object again.
>>>> 
>>>> NSCoder does not implement support for root objects; NSCoder’s 
>>>> implementation of encodeRootObject: simply encodes the object by invoking 
>>>> encodeObject:. It is the responsibility of its concrete subclasses to keep 
>>>> track of multiple references to objects, thus preserving the structure of 
>>>> any object graphs.
>>>> 
>>>> The last paragraph seems pertinent to my problem, so do I need to do 
>>>> something special for “weak”, back links in order to “keep track of 
>>>> multiple references to objects”? If so could some please tell me how to do 
>>>> this? I’m really struggling to get something out the door and was advised 
>>>> to use the Keyed Archiver/Unarchiver as it would be the simplest 
>>>> implementation……
>>>> 
>>>> Is this any other documentation or sample code available? There are plenty 
>>>> of trivial examples out there, no nothing I can find that works for weak 
>>>> back links, although according to all the Apple Blurb I can find, it is 
>>>> possible, they just don’t tell you how to do it that I can find!
>>>> 
>>>> Thanks in Advance for Any Help
>>>> All the Best
>>>> Dave
>>>> 
>>>> ___
>>>> 
>>>> 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/mailing%40xenonium.com
>>>> 
>>>> This email sent to mail...@xenonium.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/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.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: Question about Archives and Serialisations Programming Guide

[Jean-Daniel Dupas]

You don’t tell use what is your problem. You can perfectly encode any structure 
using Keyed archivers (whether there is cycles and backlinks).

> Le 5 févr. 2016 à 14:13, Dave  a écrit :
> 
> Hi,
> 
> I’m having problems with Back Links when Archiving/Unarchiving an Object. I 
> found the text below at:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Archiving/Articles/archives.html
> 
> 
> Root Object
> 
> An object graph is not necessarily a simple tree structure. Two objects can 
> contain references to each other, for example, creating a cycle. If a coder 
> follows every link and blindly encodes each object it encounters, this 
> circular reference will generate an infinite loop in the coder. Also, a 
> single object can be referenced by several other objects. The coder must be 
> able to recognize and handle multiple and circular references so that it does 
> not encode more than one copy of each object, but still regenerate all the 
> references when decoding.
> To solve this problem, NSCoder introduces the concept of a root object. The 
> root object is the starting point of an object graph. To encode an object 
> graph, you invoke the NSCoder method encodeRootObject:, passing in the first 
> object to encode. Every object encoded within the context of this invocation 
> is tracked. If the coder is asked to encode an object more than once, the 
> coder encodes a reference to the first encoding instead of encoding the 
> object again.
> 
> NSCoder does not implement support for root objects; NSCoder’s implementation 
> of encodeRootObject: simply encodes the object by invoking encodeObject:. It 
> is the responsibility of its concrete subclasses to keep track of multiple 
> references to objects, thus preserving the structure of any object graphs.
> 
> The last paragraph seems pertinent to my problem, so do I need to do 
> something special for “weak”, back links in order to “keep track of multiple 
> references to objects”? If so could some please tell me how to do this? I’m 
> really struggling to get something out the door and was advised to use the 
> Keyed Archiver/Unarchiver as it would be the simplest implementation……
> 
> Is this any other documentation or sample code available? There are plenty of 
> trivial examples out there, no nothing I can find that works for weak back 
> links, although according to all the Apple Blurb I can find, it is possible, 
> they just don’t tell you how to do it that I can find!
> 
> Thanks in Advance for Any Help
> All the Best
> Dave
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: View-based NSTableView and ending editing with "return"

[Jean-Daniel Dupas]

> Le 24 janv. 2016 à 09:51, Arved von Brasch  a écrit :
> 
> Hello list,
> 
> After putting it off for too long, I’m migrating to view-based NSTableViews.  
> I’ve worked through most of the conversion problems I’ve had, and am 
> generally pretty happy.  There is, however, one problem I haven’t been able 
> to solve.
> 
> I have a NSButton in the same window as my table.  The button has “return” as 
> a key-equavlent.  This worked fine with a cell-based NSTableView, but with a 
> view-based table, ending editing in the table with a “return” key press 
> always triggers the NSButton as well.  This is obviously undesirable 
> behaviour, but I can’t work out an obvious place to intercept the “return” 
> key press and discard it.
> 
> My attempts thus far have been messing around with a subclass of the 
> NSTableView. I’m thinking this is probably wrong, and I should be subclassing 
> the NSTextField instead, but my experience with such things is minimal, and 
> my Google-Fu has failed me in finding someone else with a similar problem.  
> So, my question is if anyone can give me a pointer to how to go about this.
> 
> Thanks in advance,
> Arved

You may try too use the TextField delegate methods, especially:

- (BOOL)control:(NSControl 

 *)control textView:(NSTextView 

 *)textView doCommandBySelector:(SEL)command

You can detect that this is a return if the selector match 
@selector(insertNewline:), and in such case, return true to inhibit the event.

Return false in all other cases.


___

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: The joys of people using valueForKey to get objects out of a dictionary.

[Jean-Daniel Dupas]

> Le 10 nov. 2015 à 19:52, Alex Zavatone  a écrit :
> 
> 
> On Nov 10, 2015, at 12:35 PM, Greg Weston wrote:
> 
>> 
>> 
>>> It's been about 4 or 5 years since I made this mistake but I've just seen a 
>>> massive swath of code where every access of a dictionary object is using 
>>> valueForKey instead of objectForKey.
>>> 
>>> I've got a few examples of why this is a "really bad idea"™, 
>> 
>> I would like to see these examples, because I can't think of any reason why 
>> it should be a bad idea. Per the documentation, it's a wrapper around 
>> objectForKey: with one special case.
> 
> I'm looking at a large chunk of code that uses all dictionary object access 
> using valueForKey.  All of it is wrapped within @try/@catch blocks, implying 
> that the original authors ran into lots of exceptions being raised and they 
> didn't know why.
> 
> My main inclination for using objectForKey over valueForKey to access the 
> object for a key within a dictionary is that objectForKey is actually a 
> dictionary method while valueForKey is a method declared in the 
> NSKeyValueCoding.h file.
> 
> I did find this example on SO yesterday, and this important issue with 
> regards to missing keys.
> 
> http://stackoverflow.com/questions/1062183/difference-between-objectforkey-and-valueforkey
> 
> 
> Here's a great reason to use objectForKey: wherever possible instead of 
> valueForKey: - valueForKey: with an unknown key will throw 
> NSUnknownKeyException saying "this class is not key value coding-compliant 
> for the key ".
> 
> But according to Charles and Mike comment and my testing, it doesn't - in 
> some cases.
> 
> Take this code on iOS 9:
> NSDictionary *myStuff = [NSDictionary dictionaryWithObjectsAndKeys:@"a", 
> @"A", nil];
> 
> po myStuff 
> {
>A = a;
> }
> 
> po [myStuff valueForKey:@"a"];
> nil
> 
> // Just as Charles and Mike mentioned
> 
> po [myStuff objectForKey:@"a"];
> 
> nil
> // Just as we expect
> 
> But if we remove the @ (obviously unintended), valueForKey causes an 
> EXC_BAD_ACCES while objectForKey reports "error: string literal must be 
> prefixed by '@'".
> 
> And David does state that whether an exception is thrown or not is 
> implementation dependent.  
> 
> From what Greg showed and in my testing, valueForKey will crater if you use 
> an @ in your key name, something I haven't seen until I tested it.
> 
> If we're not using @ within our key names, I haven't seen much here that 
> indicates why it's dangerous, nor why the code I'm looking at that uses 
> valueForKey on dictionaries needs to be wrapped in @try/@catch statements.
> 
> 
> For what we're doing on a daily basis, if we're not using @ within our keys, 
> I still can't see anything concrete besides "objectForKey is an NSDictionary 
> method" while "valueForKey is a KVO method".
> 
> Hmm.  
> 
> Thanks to all for their input on this.  
> 
> - Alex Zavatone
> 

If you don’t want to have to ask yourself if it should be valueForKey or 
objectForKey, just use the new bracket syntax to access dictionary. 

NSDictionary *myStuff = @{ @"A" : @"a" };

myStuff[@"a"]



___

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: API to determine status of System Integrity Protection?

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 01:33, Ed Wynne  a écrit :
> 
> 
> On Sep 13, 2015, at 5:47 PM, Stephane Sudre  wrote:
> That document doesn't mention an API…
 Hence, since that is the current documentation, my conclusion : “Don’t 
 think so”.
>>> There is an API. Much like with sandboxing it just may not be public, which 
>>> means it is inappropriate for discussion here. I’m not sure why Apple 
>>> considers this kind of thing off limits, but that is inappropriate for 
>>> discussion here as well.
>> 
>> I must be missing something but why should there be an API?
> 
> There are many reasons. For example, writing to the areas SIP protects 
> typically requires authorization. Not offering the user an impossible action 
> is a much better UX than letting them go through the trouble of 
> authenticating only to have it fail anyway.

No trying to write in a protected area in the first place is even better. You 
don’t need to check, just don’t do it.

> 
>> - determining whether SIP is on requires to check whether the running
>> OS on 10.11 or later.
> 
> This check is not sufficient since SIP can be disabled.
> 
>> Also it could done by parsing the output of $
>> csrutil status but this would assume the output format will not change
>> in the future.
> 
> Exactly, which makes this a bad option.
> 
>> - determining whether you can write to a file or folder can be done
>> with the usual BSD, Cocoa APIs, can't it?
> 
> Yes and no. Not having the beta (er, GM seed) handy to check, I honestly 
> don’t know if the R/W file system permissions are reported differently when 
> SIP is present and enabled. Based on how sandboxing operates, I would assume 
> they are not.
> 
> But that isn’t to say some things won’t be detectably different, which was 
> the point of my suggestion about secondary checks. They might be possible, 
> but they are still a bad option since they usually fall into the category of 
> undocumented side effects. 
> 
>> - knowing which parts of the file hierarchy are protected is covered
>> by the documentation (Interestingly I've just discovered that
>> /Applications/Utilities is a no trespassing area).
> 
> 
> Except they aren’t protected when SIP is disabled, which was the point of the 
> OP’s question.
> 
> -Ed
> 
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Identifying a specific Mac model

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 12:16, sqwarqDev  a écrit :
> 
> 
> On 14 Sep 2015, at 01:09, John Daniel  wrote:
> 
>> 
>> MacBook8,1 covers all colours of the new MacBook.
>> I am trying to differentiate the silver, from the space grey, from the gold.
> 
> Since the machines are physically identical save the paint job, I don’t think 
> anything like sysctl or any other hardware identifier is going to help you. 
> The only difference I’d imagine between a silver and gold MB would be the 
> catalogue/product number. For example, Mactracker has the following order 
> numbers for the 2015 MB:
> 
>> MF855LL/A (1.1 GHz with 256 GB storage, Silver) MK4M2LL/A (1.1 GHz with 256 
>> GB storage, Gold) MJY32LL/A (1.1 GHz with 256 GB storage, Space Gray) 
>> MF865LL/A (1.2 GHz with 512 GB storage, Silver) MK4N2LL/A (1.2 GHz with 512 
>> GB storage, Gold) MJY42LL/A (1.2 GHz with 512 GB storage, Space Gray)
> 
> The chances of this being coded into the machine itself I’d imagine are zero. 
> If that’s right, then the best you can do is ask your user to enter that 
> information in order to display the correct icon. In lieu of that, your only 
> option is to display a generic icon for the model identifier that you find in 
> the usual way(s).
> 


Apple used to display the right color for iPod icons, why wouldn’t they do it 
too for new MacBook network icon. Especially as the three variants are present 
in the System icons. I’m pretty sure the color is coded somewhere in the 
machine.
___

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

[Jean-Daniel Dupas]

> Le 14 sept. 2015 à 15:53, John Daniel  a 
> écrit :
> 
> Thanks for the responses. Unfortunately, Apple is way ahead of all of us.
> 
> The “Model Identifier” (MacBook8,1 et al.) is not sufficient to identify a 
> particular model. It only identifies general families of models. All you have 
> to do is go to My OWC (http://eshop.macsales.com/MyOWC/ 
> ), pick MacBook Pro, and look at the 
> options. 
> 
> The system images are where they should be. I don’t understand Apple’s 
> reasoning, but that is where Apple wants them. 
> 
> I don’t know if Apple even tracks the colour of the retina MacBooks. I don’t 
> have one myself. I haven’t been able to find a serial number online. The 
> serial number generator scripts posted online don’t generate valid serial 
> numbers for this model. 
> 
> Scraping the Apple self-service warranty page might work, but I don’t have 
> any MacBook serial numbers for testing. I really don’t want to parse HTML. 
> Even so, people seem to treat serial numbers as personal information and 
> might freak out if I start sending them over the internet. If I had a few 
> serial numbers for testing, I would know more - or at least something.
> 
> I do extract the last 4 characters and send them to Apple’s support web 
> services to get the “marketing name” like "MacBook (Retina, 12-inch, Early 
> 2015)”. But those names don’t seem to include colour. I know of a few 
> different queries for Apple’s services for technical specifications, possible 
> memory upgrades, OS name, and this marketing name. This is a true web service 
> that returns parseable XML. I don’t know if there is any query that will give 
> me the machine icon.
> 

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/archive%40mail-archive.com

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

Re: NSManagedObject, NSString property retain vs copy

[Jean-Daniel Dupas]

 Le 30 juil. 2015 à 18:26, Fritz Anderson fri...@manoverboard.org a écrit :
 
 On 30 Jul 2015, at 11:03 AM, Trygve Inda cocoa...@xericdesign.com wrote:
 
 It seems Apple is using retain rather than copy for NSString properties in
 an NSManagedObject subclass.
 
 I was always under the impression that copy should be used for NSString, so
 why the retain??
 
 For an immutable string, -copy is implemented as a -retain. -copy is a guard 
 against the receiver’s relying on the unchanging contents of a string whose 
 contents can be changed. If the contents cannot in fact be changed, there’s 
 no point in allocating new memory and copying the bytes into it.
 
 It’s an implementation detail; what makes you believe it makes a difference?

If it is in the property declaration, it is not an implementation detail, it is 
part of the public API.

And as the receiver can’t guarantee that a passed NSString is not a 
NSMutableString under the hood, it should always declare property as copy, so 
the fact that some sample code (I guess this is what the op is talking about) 
use retain is dubious.


___

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?

[Jean-Daniel Dupas]

 Le 29 juil. 2015 à 12:25, Dave d...@looktowindward.com a écrit :
 
 Hi,
 
 For reasons that are too complex to go in to, I need to somehow create a 
 Unique ID that is valid for the life of a Window. The Window I am trying to 
 identify is not owned by my App (think Screen Dump, like “Grab”). 
 
 I ran this code:
 
 CFArrayRef windowList = 
 CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID);
 for (NSMutableDictionary* entry in (NSArray*)windowList) 
 {
NSString* ownerName = [entry objectForKey:(id)kCGWindowOwnerName];
NSInteger ownerPID = [[entry objectForKey:(id)kCGWindowOwnerPID] 
 integerValue];
NSLog(@%@:%ld, ownerName, (long)ownerPID);
 }
 CFRelease(windowList);  
 
 This is the dictionary returned for this Email message:
 
 {
kCGWindowAlpha = 1;
kCGWindowBounds = {
Height = 858;
Width = 1003;
X = 874;
Y = 342;
};
kCGWindowIsOnscreen = 1;
kCGWindowLayer = 0;
kCGWindowMemoryUsage = 3462288;
kCGWindowName = New Message;
kCGWindowNumber = 2895;
kCGWindowOwnerName = Mail;
kCGWindowOwnerPID = 507;
kCGWindowSharingState = 1;
kCGWindowStoreType = 2;
 },
 
 Are one or more of these values guaranteed to be Unique (within the Window 
 List) and not to change during the life-time of the Window? 
 
 Thanks a lot.
 
 All the Best
 Dave

From the Window Services Reference:

kCGWindowNumber
The value for this key is a CFNumberRef 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFNumberRef/index.html#//apple_ref/c/tdef/CFNumberRef
 type (encoded as kCGWindowIDCFNumberType 
https://developer.apple.com/library/mac/documentation/Carbon/Reference/CGWindow_Reference/Constants/Constants.html#//apple_ref/c/macro/kCGWindowIDCFNumberType)
 that contains the window ID. The window ID is unique within the current user 
session. 




___

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 to Swift conversion question

[Jean-Daniel Dupas]

 Le 28 juil. 2015 à 16:03, Eric E. Dolecki edole...@gmail.com a écrit :
 
 The more I stretch to Swift goals, the more I learn. However I've come upon
 a little thing where I am translating code into Swift and quickly stumbled.
 
 *Obj-C:*
 NSValue *keyboardEndFrameValue = [[notification userInfo]
 objectForKey:UIKeyboardFrameEndUserInfoKey];
 
 
 *Swift (the closest I've come):*
 var keyboardEndFrameValue =
 NSValue(notification.userInfo[UIKeyboardFrameEndUserInfoKey])
 

NSValue() is not a cast, it is a constructor.

Should be something like

var keyboardEndFrameValue = 
notification.userInfo[UIKeyboardFrameEndUserInfoKey] as NSValue


 Error for Swift: insert nonretainedObject:
 When I Fix-It with the above suggestion, the error becomes Cannot
 subscript a value of type '[NSObject: AnyObject]?' with an index of type
 'String'
 
 So I then end up with this (but it looks really strange):
 
 var keyboardEndFrameValue = NSValue(nonretainedObject:
 notification.userInfo[UIKeyboardFrameEndUserInfoKey as String])
 
 No warnings or errors, but I wanted to check to see if I'm appeasing the
 compiler but have it wrong.
 
 Thanks,
 Eric
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Swift and parameter names

[Jean-Daniel Dupas]

 Le 30 juin 2015 à 23:46, Quincey Morris quinceymor...@rivergatesoftware.com 
 a écrit :
 
 On Jun 29, 2015, at 15:42 , Rick Mann rm...@latencyzero.com wrote:
 
 Here's an example (and this is what I frequently encounter) where requiring 
 parameter names adds nothing but clutter:
 
   let config = WKWebViewConfiguration()
   self.webView = WKWebView(frame: self.webViewContainer.frame, 
 configuration: config);
 
 I’ve been thinking about this since yesterday, and while I don’t particularly 
 agree that the parameter names are extraneous in *this* case, I can think of 
 a couple of special cases:
 
 1. If the function/method being called has extremely well-known parameters, 
 then I think I’d prefer the function to have a form that omits the names. In 
 particular, CGRect, CGPoint and CGSize:
 
  let rect = CGRect (x: 0, y: 0, width: 10, height: 10) // vs:
  let rect = CGRect (0, 0, 10, 10)
 

Only because you are used to CGRect. QuickDraw used to defined a rect using 
left, top, right, bottom values. Here you assume that your code reader is 
already familiar with the API.

 The point here is that the parameter semantics are known from the *name* of 
 the function, not from the actual parameters. We have this convention 
 already, in the default behavior where the first keyword to a regular 
 function/method is omitted:
 
  doSomethingWithRect (someRect)
 
 
 This is similar to the CGRect initializer case, in that we know from the name 
 what the parameter is (because it tells us, in this case, not necessarily 
 because we knew it in advance).
 
 2. There’s common situation where a variable name very often *is* a parameter 
 keyword. For example:
 
  init (frame: CGRect, configuration: WKWebViewConfiguration) {
  super.init (frame: frame, configuration: configuration)
  }
 
 In this case, the name of the variable in the ‘super’ call *is* the same as 
 the keyword, because that’s a syntactic default in Swift. Under these 
 circumstances, I could see this being allowed:
 
  init (frame: CGRect, configuration: WKWebViewConfiguration) {
  super.init (frame, configuration)
  }
 
 It may or may not be desirable to require that the keywords are all omitted 
 or all retained, or that this would only work for parameter variables (which 
 have a natural relationship to their keyword).
 
 What do you think? This wouldn’t eliminate all the cases you’ve set your 
 sights on, but it would probably remove the most egregious ones. If there’s 
 some consensus here, I’ll file radars.
 
 
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Subclassing a Subclass of SBApplication

[Jean-Daniel Dupas]

Using class extension is probably a safe way to extends such classes.

@interface SXPhotoshopApplication (MyExtension)

- (void)myWrapper;

@end


 Le 29 juin 2015 à 13:54, Dave d...@looktowindward.com a écrit :
 
 Hi,
 
 I’m using the Scripting Bridge, and I was wondering if it ok to subclass 
 SBXXX classes. Basically, I have a header file generated by the “sdp” tool 
 with definitions as below:
 
 And I’d like to subclass this to add some extra wrapping to hide some of the 
 nastiness from the rest of the app and provide a tighter integration with the 
 current app handling. I remember reading somewhere that these classes 
 shouldn’t be subclassed, but I can’t seem to find it again now.
 
 Thanks a lot
 Dave
 
 -
 
 @interface SXPhotoshopApplication : SBApplication
 
 - (SBElementArray *) documents;
 - (SBElementArray *) fonts;
 - (SBElementArray *) notifiers;
 
 @property (copy, readonly) NSNumber *bestType;  // the best type for the 
 object's value
 @property (copy, readonly) NSNumber *defaultType;  // the default type for 
 the object's value
 @property (copy) NSDictionary *properties;  // all of this object's 
 properties returned in a single record
 @property (copy) SXPhotoshopColorValue *backgroundColor;
 @property (copy, readonly) NSString *build;  // the build number of Adobe 
 Photoshop application
 @property (copy) id colorSettings;  // name of selected color settings' set
 @property (copy) SXPhotoshopDocument *currentDocument;  // the frontmost 
 document
 @property SXPhotoshopE050 displayDialogs;  // controls whether or not 
 Photoshop displays dialogs
 @property (copy) SXPhotoshopColorValue *foregroundColor;
 @property (readonly) double freeMemory;  // the amount of unused memory 
 available to Adobe Photoshop
 @property (readonly) BOOL frontmost;  // is Photoshop the frontmost 
 application?
 @property (copy, readonly) NSString *locale;  // language locale of 
 application
 @property (copy, readonly) NSArray *macintoshFileTypes;  // list of file 
 image types Photoshop can open
 @property (copy, readonly) NSString *name;  // the application's name
 @property BOOL notifiersEnabled;  // enable or disable all notifiers
 @property (copy, readonly) id preferencesFolder;  // full path to the 
 preferences folder
 @property (copy, readonly) NSArray *recentFiles;  // files in the recent file 
 list
 @property (copy, readonly) NSString *scriptingBuildDate;  // the build date 
 of the scripting interface
 @property (copy, readonly) NSString *scriptingVersion;  // the version of the 
 Scripting interface
 @property (copy, readonly) SXPhotoshopSettingsObject *settings;  // 
 preference settings
 @property (copy, readonly) NSString *systemInformation;  // system 
 information of the host application and machine
 @property (copy, readonly) NSString *version;  // the version of Adobe 
 Photoshop application
 @property (copy, readonly) NSArray *windowsFileTypes;  // list of file image 
 extensions Photoshop can open
 
 - (void) AETEScriptsScriptsJavaScriptNameName:(NSString *)JavaScriptNameName 
 JavaScriptFileFile:(NSString *)JavaScriptFileFile 
 JavaScriptTextText:(NSString *)JavaScriptTextText 
 JavaScriptDebuggingDebugging:(BOOL)JavaScriptDebuggingDebugging 
 JavaScriptMessageMessage:(NSString *)JavaScriptMessageMessage;  // Photoshop 
 scripting support plug-in
 - (void) open:(id)x as:(SXPhotoshopOpAs)as 
 withOptions:(SXPhotoshopOpenOptions *)withOptions 
 showingDialogs:(SXPhotoshopE050)showingDialogs smartObject:(BOOL)smartObject; 
  // open the specified document file(s)
 - (void) print:(id)x sourceSpace:(SXPhotoshopE945)sourceSpace 
 printSpace:(NSString *)printSpace intent:(SXPhotoshopE130)intent 
 blackpointCompensation:(BOOL)blackpointCompensation;  // print the specified 
 object(s)
 - (void) quit;  // quit the application
 - (NSArray *) PhotoshopOpenDialog;  // use the Photoshop open dialog to 
 select files
 - (NSString *) batch:(NSString *)x fromFiles:(NSArray *)fromFiles 
 from:(NSString *)from withOptions:(SXPhotoshopBatchOptions *)withOptions;  // 
 run the batch automation routine
 - (NSString *) createPDFPresentationFromFiles:(NSArray *)fromFiles 
 toFile:(id)toFile withOptions:(SXPhotoshopPresentationOptions *)withOptions;  
 // create a PDF presentation file
 - (NSString *) createContactSheetFromFiles:(NSArray *)fromFiles 
 withOptions:(SXPhotoshopContactSheetOptions *)withOptions;  // create a 
 contact sheet from multiple files
 - (NSString *) createPhotoGalleryFromFolder:(id)fromFolder 
 toFolder:(id)toFolder withOptions:(SXPhotoshopGalleryOptions *)withOptions;  
 // Creates a web photo gallery
 - (NSString *) createPhotoMergeFromFiles:(NSArray *)fromFiles;  // 
 DEPRECATED. Merges multiple files into one, user interaction required.
 - (NSString *) createPicturePackageFromFiles:(NSArray *)fromFiles 
 withOptions:(SXPhotoshopPicturePackageOptions *)withOptions;  // create a 
 picture package from multiple files
 - (BOOL) featureEnabledName:(NSString 

Re: Scripting Bridge Questions

[Jean-Daniel Dupas]

 Le 25 juin 2015 à 15:13, Dave d...@looktowindward.com a écrit :
 
 
 On 25 Jun 2015, at 13:33, Bill Cheeseman wjcheese...@gmail.com wrote:
 
 
 On Jun 25, 2015, at 8:09 AM, Dave d...@looktowindward.com wrote:
 
 That’s the problem, “sdef and/or “sdp barf when I try to generate the 
 header file and without the header file you are pretty much dead in the 
 water.
 
 
 I haven't noticed a specific description of the failure you're experiencing. 
 Do you get a partial header file, or a header file that contains errors or 
 that causes errors in your Scripting Bridge implementation? I have found in 
 the past that I can manually edit header files generated by sdef/sdp, at 
 least by removing irrelevant declarations that aren't needed or that cause 
 problems, and when I do it right the edited header files work with Scripting 
 Bridge.
 
 
 I get this error:
 
 sdp: enumerator of enumeration e183: missing required name attribute.
 
 and an (very) incomplete file, e.g. most of it is missing.
 

That just means you wrote an invalid sdef file in the first place. 


___

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: Scripting Bridge Questions

[Jean-Daniel Dupas]

 Le 25 juin 2015 à 15:57, Dave d...@looktowindward.com a écrit :
 
 
 On 25 Jun 2015, at 14:48, Bill Cheeseman wjcheese...@gmail.com wrote:
 
 
 On Jun 25, 2015, at 9:13 AM, Dave d...@looktowindward.com wrote:
 
 I get this error:
 
 sdp: enumerator of enumeration e183: missing required name attribute.
 
 
 Can you generate the sdef file separately, then manually edit it to supply 
 the missing required 'name' attribute, and then run sdp on the edited sdef 
 file? You will presumably have to give more than a little thought to what 
 the missing name attribute should be, but maybe you'll hit pay dirt.
 
 I’m looking into doing that now, but I can’t seem to find an editor that will 
 open it, at the moment it’s ONE giant line of text, I renamed it to .xml and 
 tried to open in XCode - same.
 

You can pretty format it using xmllint command line tool.

xmllint --pretty 1 yourfile.xml  your_formatted_file.xml

 Cheers
 Dave
 
 
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Using CFSTR() with const char * variable

[Jean-Daniel Dupas]

That’s not going to work.

__builtin___CFStringMakeConstantString is a special compiler function that 
requires a constant string to work in the first place, as it tells the compiler 
to generate CFString literal.

I doubt the compiler will accept anything else as parameter.


 Le 7 juin 2015 à 03:39, Steve Christensen puns...@mac.com a écrit :
 
 In my prefix file that is used to build precompiled headers, I include the 
 following after #import-ing all the framework headers. It replaces the 
 standard definition with a version that doesn't insert quotes around an 
 unquoted string literal.
 
 #undef CFSTR//(cStr)
 #ifdef __CONSTANT_CFSTRINGS__
 #define CFSTR(cStr)  ((CFStringRef) 
 __builtin___CFStringMakeConstantString(cStr))
 #else
 #define CFSTR(cStr)  __CFStringMakeConstantString(cStr)
 #endif
 
 
 
 On Jun 5, 2015, at 8:02 PM, Carl Hoefs newsli...@autonomy.caltech.edu 
 wrote:
 
 If I use CFSTR() in the following way:
   CFStringRef mystr = CFSTR( This is a string );
 there is no problem.
 
 However, if I use a variable instead of “string” Xcode flags this as an 
 error:
   const char *mystring = This is a string;
   CFStringRef mystr = CFSTR( mystring );
  ^   — Expected )
 
 In CFString.h, CFSTR is defined as:
   #define CFSTR(cStr)  __CFStringMakeConstantString( cStr )
 
 Is it possible to use CFSTR() with a const char * variable?
 
 Xcode 6.3.2
 -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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Looking at self = [super init].

[Jean-Daniel Dupas]

 Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
 
 Was just looking at good old object initialization and came across a stupid 
 idea.
 
 For most object initialization, we do this:
 
 - (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self; 
 }
 
 in some cases, the set up within the parens could get pretty long.  In cases 
 like that, I generally set up another method to handle that for organization, 
 but if you're passing objects into into your init method, then you're passing 
 more data again and the code could get less cleaner looking than it could be.
 
 So, I thought, why don't we check if self != [super init] and then 
 immediately return if that is the case?
 
 That would change object initialization to this:
 
 - (id)init {
if (self != [super init]) {
return;
}
 
// Set up stuff here.
// We don't care if this gets long.
// We really don't.  This could go on and on.
   
return self; 
 }

You must at least returns nil in the fast path, else the compiler will not be 
happy.


___

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: Looking at self = [super init].

[Jean-Daniel Dupas]

 Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
 
 Was just looking at good old object initialization and came across a stupid 
 idea.
 
 For most object initialization, we do this:
 
 - (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self; 
 }
 
 in some cases, the set up within the parens could get pretty long.  In cases 
 like that, I generally set up another method to handle that for organization, 
 but if you're passing objects into into your init method, then you're passing 
 more data again and the code could get less cleaner looking than it could be.
 
 So, I thought, why don't we check if self != [super init] and then 
 immediately return if that is the case?
 
 That would change object initialization to this:
 
 - (id)init {
if (self != [super init]) {
return;
}
 
// Set up stuff here.
// We don't care if this gets long.
// We really don't.  This could go on and on.
   
return self; 
 }
 

And now that a reread the code, it is patently wrong.

if (self = [super init]) is a assignment to self not a comparison.

If you want to do a fast path, you have to do

self = [super init];
if (!self)
return nil;




___

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: WTF is happening?

[Jean-Daniel Dupas]

I found only 5 classes that does not responds to isProxy and they are all 
internal classes, so real code will never have to deal with instances of such 
classes.

And all classes prefixed by « OS_ » inherits NSObject and responds to isProxy. 

I run the experiment for myself and do not doubt the result.

 Le 15 déc. 2014 à 12:12, Charles Jenkins cejw...@gmail.com a écrit :
 
 During the course of this thread, Maxthon has given us code that would enable 
 us to run the experiment for ourselves. I do not doubt him.
 
 —
 
 Charles Jenkins
 
 
 On Monday, December 15, 2014 at 2:31 AM, Maxthon Chan wrote:
 
 My class scanning returned several OS* classes that does not conform to 
 NSObject protocol.
 
 On Dec 15, 2014, at 00:29, Clark S. Cox III clarkc...@gmail.com 
 (mailto:clarkc...@gmail.com) wrote:
 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
 
 What makes you think that Object is used in *any* of those places?
 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com 
 (mailto:garyw...@desisoftsystems.com) wrote:
 
 Are you saying that Apple's well-documented approach to see if an object 
 is derived from NSProxy does not work? If that's the case, you need to 
 submit a bug report to Apple. That's a serious issue that only Apple can 
 help you with.
 
 If you are using objects not derived from NSObject nor NSProxy, then 
 change your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info 
 (mailto:m...@maxchan.info) wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class 
 is interested. But due to the nature of this class scanning before I can 
 make sure that the class derives from NSObject I cannot call any method 
 on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 (mailto:garyw...@desisoftsystems.com) wrote:
 
 If all you care about is if an object is a proxy or not, look at 
 isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info 
 (mailto:m...@maxchan.info) wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
 if (c == other)
 return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com 
 (mailto:k...@ksluder.com) wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”? The error
 says you’re accessing past the end of a string.
 
 
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 mailto: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 
 http://lists.apple.com/
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com 
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com
 
 This email sent to clarkc...@gmail.com mailto:clarkc...@gmail.com
 ___
 
 Cocoa-dev mailing list 

Re: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 13:31, Uli Kusterer witness.of.teacht...@gmx.net a écrit :
 
 On 15 Dec 2014, at 12:42, Jean-Daniel Dupas mail...@xenonium.com wrote:
 I found only 5 classes that does not responds to isProxy and they are all 
 internal classes, so real code will never have to deal with instances of 
 such classes.
 
 Maxthon is iterating over the classes in the system. Even internal classes to 
 the OS show up in that list, so I really don't see how he would *not* have to 
 be able to at least deal with their presence.
 

Fair enough, but I didn’t got any issue while dealing with theses classes. I 
managed to query if they responds to a selector, got there superclass and more.

 Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
 simply has each image representation subclass add itself to an NSArray from 
 its +initialize method. I'd think that'd be less fragile than walking the 
 entire class list.

I fully agree on that. Relying on class iteration is generally a design flaw. 
It is too fragile to be used in a reliable and futur proof way.
But I don’t think you can rely on +initialize to register subclasses as 
initialize will not be called until the someone try to use the target class (or 
one of it’s subclass).

You can use +load but should probably be careful when doing so as there is no 
guarantee about the class loading order AFAIK. 


___

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: WTF is happening?

[Jean-Daniel Dupas]

bool isSubclass(Class cls, Class superclass) {
if (class_respondsToSelector(object_getClass(cls), 
@selector(isSubclassOfClass:))) {
return [cls isSubclassOfClass:superclass];
}
}

 Le 15 déc. 2014 à 16:49, Maxthon Chan m...@maxchan.info a écrit :
 
 But I still need some way to tell them from NSObject/NSProxy decedents from 
 my class walking. Any method calling will cause a crash there.
 
 On Dec 15, 2014, at 23:48, Clark S. Cox III clarkc...@gmail.com wrote:
 
 That does not mean that they're using Object only that they're using a 
 base class other than NSObject or NSProxy. Why can't you just ignore 
 such classes?
 
 Sent from my iPhone
 
 On Dec 14, 2014, at 23:31, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 My class scanning returned several OS* classes that does not conform to 
 NSObject protocol.
 
 On Dec 15, 2014, at 00:29, Clark S. Cox III clarkc...@gmail.com 
 mailto:clarkc...@gmail.com wrote:
 
 
 On Dec 13, 2014, at 11:57, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 NSProxy checking actually work, but throwing those classes that derive 
 from Object class (note I used capitalised O here, the old Object class 
 from early NeXT times, also used heavily in OS X kernel, GCD and Mach 
 ports)
 
 What makes you think that Object is used in *any* of those places?
 
 into the mix means that no method can be sent before class is determined. 
 I would suggest Apple add one runtime function class_isSubclassOfClass() 
 that mirrors the functionality of NSObject and NSProxy method 
 isSubclassOfClass so that derivatives of the old Object class can be 
 detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com 
 mailto:garyw...@desisoftsystems.com wrote:
 
 Are you saying that Apple's well-documented approach to see if an object 
 is derived from NSProxy does not work? If that's the case, you need to 
 submit a bug report to Apple. That's a serious issue that only Apple can 
 help you with.
 
 If you are using objects not derived from NSObject nor NSProxy, then 
 change your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/ http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class 
 is interested. But due to the nature of this class scanning before I 
 can make sure that the class derives from NSObject I cannot call any 
 method on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 mailto:garyw...@desisoftsystems.com wrote:
 
 If all you care about is if an object is a proxy or not, look at 
 isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/ http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info 
 mailto:m...@maxchan.info wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of 
 a certain class. Before any NSObject method can be issued I have to 
 check if it is actually NSObject or NSProxy derivative instead of an 
 Object derivative that does not support NSObject methods. This calls 
 for runtime equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have 
 to implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
  if (c == other)
  return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will 
 file a bug report to Apple and ask them to add this, as it is useful 
 in class scanning and i am using this technique heavily in jailbreak 
 detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com 
 mailto:k...@ksluder.com wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The 
 error
 says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
 mailto: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 
 http://lists.apple.com/
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/clarkcox3%40gmail.com 
 

Re: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 19:45, Fritz Anderson fri...@manoverboard.org a écrit :
 
 I can be dense. Do I understand correctly that
 
 - You have an application that ideally should run continually.
 
 - It accepts plugins that provide one or more classes.
 
 - Those classes must at least observe a protocol; otherwise there would be no 
 sensible way to use them.
 
 - They must have unique names.
 
 - As is typical of ObjC plugins, the classes are packaged in a dynamic 
 library; and as is typical, the library is wrapped in a package directory, 
 which your application has registered with Launch Services as a package, of a 
 certain type and edit/view/associate relationship to your application. I'm 
 sure this is so in your case, as plugins typically need to carry resource 
 files.

Just for the record, typical Obj-C plugins are packaged in loadable bundle 
(MH_BUNDLE), which are a different binary object kind than dynamic library 
(MH_DYLIB).

 - If a package, the plugin might carry an Info.plist file — plugins commonly 
 do.
 
 - You mean to load and unload plugins dynamically, as they appear and 
 disappear in a designated directory, without interrupting the application.
 
 Do I follow you so far? If so, I have some comments.
 
 You can't unscramble the egg: Dynamically-loaded classes can be loaded any 
 time you like, but they cannot be reloaded or unloaded. Surely you know this; 
 surely I misunderstand (or am behind the times).
 
 If you are (practically) committed to a package structure with an Info.plist, 
 why can't you add an array key listing the names of the provided classes? 
 Or for that matter, a text file containing the names? That's one of the 
 things NSBundle is for. It is a universal practice. Just works is a great 
 ideal, but one can expect someone who knows how to build a dynamic library to 
 understand such things.
 
 The declared classes might not implement the required methods, but that's 
 easy and safe to detect once they are loaded. If you must reject, your duty 
 ends when you log the problem and put up an alert.
 
 Am I missing something?
 
— F
 
 
 On Dec 15, 2014, at 11:59 AM, Maxthon Chan m...@maxchan.info wrote:
 
 What I am doing here is to determine a format handling class based on file 
 extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect 
 and allow one plugin to include multiple format handling classes. Also since 
 I am creating an open system I don’t want to require other plugin writers to 
 register their classes, instead the main code shall discover plugins on its 
 own.
 
 This means that the main code will not be able to call any plugin classes 
 methods so +initialize never get called. Also your approach means that the 
 main code will hold a strong reference to the plugin code which prevents 
 plugin unloading.
 
 Class walking may be fragile, but it is fragile enough to allow plugins to 
 come and go easily without having to restart the main code.


___

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: WTF is happening?

[Jean-Daniel Dupas]

 Le 15 déc. 2014 à 21:36, Greg Parker gpar...@apple.com a écrit :
 
 
 On Dec 15, 2014, at 11:02 AM, Jean-Daniel Dupas mail...@xenonium.com wrote:
 
 Le 15 déc. 2014 à 19:45, Fritz Anderson fri...@manoverboard.org a écrit :
 
 - As is typical of ObjC plugins, the classes are packaged in a dynamic 
 library; and as is typical, the library is wrapped in a package directory, 
 which your application has registered with Launch Services as a package, of 
 a certain type and edit/view/associate relationship to your application. 
 I'm sure this is so in your case, as plugins typically need to carry 
 resource files.
 
 Just for the record, typical Obj-C plugins are packaged in loadable bundle 
 (MH_BUNDLE), which are a different binary object kind than dynamic library 
 (MH_DYLIB).
 
 MH_BUNDLE is no longer typical. The only advantage of MH_BUNDLE is that you 
 might be able to unload it, but you probably shouldn't try. Feel free to use 
 MH_DYLIB for all of your plugin needs.

It is typical in the sense that Xcode defaults to mach-o type bundle when 
creating a plugin project and most (if not all) Apple provided plugins are 
bundle (as are most third party plugins).

 (libobjc prevents unloading of any MH_DYLIB containing Objective-C metadata. 
 It does not summarily disallow unloading of MH_BUNDLE, but there's a long 
 list of caveats that make bundle unloading unusable except in rare 
 situations.)



___

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: WTF is happening?

[Jean-Daniel Dupas]

The Object class is not used anywhere is OS X. It is deprecated and should have 
been removed from the runtime long time ago. 

The OS X kernel does not even include obj runtime, so it can’t possibly use the 
Object class. Mach port are integer that represent kernel object and not 
classes.

The root class for all OS Object (XPC, GCD, …) is NSObject (which live in the 
runtime too).

If you find subclasses of Object, you are obviously doing something wrong.

 Le 13 déc. 2014 à 20:57, Maxthon Chan m...@maxchan.info a écrit :
 
 NSProxy checking actually work, but throwing those classes that derive from 
 Object class (note I used capitalised O here, the old Object class from early 
 NeXT times, also used heavily in OS X kernel, GCD and Mach ports) into the 
 mix means that no method can be sent before class is determined. I would 
 suggest Apple add one runtime function class_isSubclassOfClass() that mirrors 
 the functionality of NSObject and NSProxy method isSubclassOfClass so that 
 derivatives of the old Object class can be detected more easily.
 
 On Dec 14, 2014, at 03:49, Gary L. Wade garyw...@desisoftsystems.com wrote:
 
 Are you saying that Apple's well-documented approach to see if an object is 
 derived from NSProxy does not work? If that's the case, you need to submit a 
 bug report to Apple. That's a serious issue that only Apple can help you 
 with.
 
 If you are using objects not derived from NSObject nor NSProxy, then change 
 your design.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:40 AM, Maxthon Chan m...@maxchan.info wrote:
 
 Ain’t work! Will crash if an Object derivative showed up.
 
 I am scanning ALL loaded classes and only subclasses of a certain class is 
 interested. But due to the nature of this class scanning before I can make 
 sure that the class derives from NSObject I cannot call any method on it.
 
 On Dec 14, 2014, at 03:34, Gary L. Wade garyw...@desisoftsystems.com 
 wrote:
 
 If all you care about is if an object is a proxy or not, look at isProxy.
 --
 Gary L. Wade (Sent from my iPad)
 http://www.garywade.com/
 
 On Dec 13, 2014, at 11:06 AM, Maxthon Chan m...@maxchan.info wrote:
 
 What I am doing here is scanning all loaded classes for subclasses of a 
 certain class. Before any NSObject method can be issued I have to check 
 if it is actually NSObject or NSProxy derivative instead of an Object 
 derivative that does not support NSObject methods. This calls for runtime 
 equivalent for one of the following NSObject methods:
 
 - [NSObject respondsToSelector:(SEL)aSelector] = 
 class_respondsToSelector(Class, SEL) // this crashed.
 + [NSObject conformsToProtocol:(Protocol *)aProtocol] = 
 class_conformsToProtocol(Class, Protocol *) // check for NSObject 
 protocol, this does not work.
 + [NSObject isSubclassOfClass:(Class)aClass] // no equivalent, have to 
 implement it myself
 
 I ended up creating this:
 
 BOOL class_isSubclassOfClass(Class cls, Class other)
 {
 for (Class c = cls; c; c = class_getSuperclass(c))
if (c == other)
return YES;
 return NO;
 }
 
 If i remembered it right GNUstep runtime have this function. I will file 
 a bug report to Apple and ask them to add this, as it is useful in class 
 scanning and i am using this technique heavily in jailbreak detection.
 
 On Dec 14, 2014, at 01:20, Kyle Sluder k...@ksluder.com wrote:
 
 On Sat, Dec 13, 2014, at 10:19 AM, Phillip Mills wrote:
 Why do you think the problem is with “respondsToSelector:”?  The error
 says you’re accessing past the end of a string.
 
 Because the crash happens in a call stack that originates in
 class_respondsToSelector, and involves none of Maxthon's code.
 
 --Kyle Sluder
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: How does the Swift Darwin module work?

[Jean-Daniel Dupas]

AFAIK, variadic C functions are not (yet) callable from swift code.


 Le 18 oct. 2014 à 20:37, Rick Mann rm...@latencyzero.com a écrit :
 
 I need access to fcntl, so I thought I'd do what Apple does with Darwin. But 
 I don't actually see how to do that. They create Darwin.stdio.fopen(), for 
 example. But then how do they call the underlying C fopen()?
 
 For that matter, Swift can call C functions directly in some cases, and not 
 at all in others.
 
 OH! Is it because fcntl is special? Check out its declaration:
 
   int fcntl(int, int, ...) __DARWIN_ALIAS_C(fcntl);
 
 __DARWIN_ALIAS_C is:
 
   #define __DARWIN_ALIAS_C(sym)   __asm(_ __STRING(sym) 
 __DARWIN_SUF_NON_CANCELABLE __DARWIN_SUF_UNIX03) 
 
 So, is there some magic module I can create in Swift to make that accessible 
 to my Swift code?
 
 -- 
 Rick Mann
 rm...@latencyzero.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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.com

-- Jean-Daniel





___

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 not use path-based API? (was: Loading image resources)

[Jean-Daniel Dupas]

Le 14 sept. 2014 à 10:23, Quincey Morris quinceymor...@rivergatesoftware.com 
a écrit :

 On Sep 14, 2014, at 00:57 , Aandi Inston aa...@quite.com wrote:
 
 Why? Really, why? Certainly there are APIs where we have to use URL's and
 we have to convert the path into a URL, but where a non-deprecated
 path-based URL exists, what current or future obstacles do you foresee? The
 URL doesn't seem to be more predicable or persistent, for example.
 
 It’s not an absolute rule, and it’s certainly possible to defend the use of 
 path APIs, but here are some of my reasons:
 
 1. NSURL-based APIs were introduced *in order to* replace path-based APIs, so 
 using the new APIs maybe helps to future-proof your code. IOW, sometimes 
 Apple gives us hints as to what continents are moving in the API geoscape, 
 and sometimes they do this by replacing APIs with new ones that more or less 
 seem to do the same thing — until later they don’t.
 
 For example, although Cocoa generally requires *file* URLs for non-internet 
 things, it’s possible that in the future we’ll need to locate resources that 
 don’t have a traditional path.
 
 2. I think some path-based APIs had quirks, for example about handling paths 
 that started with a tilde, or other environment-related issues. Generally, 
 NSURL-based APIs are regular in their behavior. However, I don’t have any 
 examples of this difference at hand, and I could easily be wrong about this 
 point.
 
 3. Some NSURL-based APIs improved or corrected the methods that they 
 replaced. For example, the new APIs follow standard conventions for returning 
 errors.
 
 4. Some things can only be done with NSURL-based APIs. For example, sandboxed 
 access to files chosen by users.
 
 Because of #3 and #4, you’re going to be using NSURL at least some of the 
 time, and mixing the two API styles gets messy fast. If you have to pick one, 
 NSURL is the one to pick.
 
 Here are some of the reasons for using path-based APIs:
 
 1. You’re writing a command line utility that’s (e.g.) POSIX-compliant or 
 crosses to other UNIX platforms. In that case, its probably more consistent 
 to stick with paths, unless you have some other reason to deal with URLs.
 
 2. You’ve got existing code that uses path-based APIs, and you can’t justify 
 the time it would take to convert.
 
 Because the above is too long to be useful in response to posts on other 
 issues, I decided to reduce it to “You should use URL-based equivalents 
 generally.”
 

One other point is that NSURL API abstract the way you access a file and let 
you transparently use different concept to reference a file like 'file 
reference'.


___

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: What is the modern Cocoa way to send an Apple Event to yourself?

[Jean-Daniel Dupas]

Le 22 août 2014 à 07:24, Daryle Walker dary...@mac.com a écrit :

 I changed my app from implementing -application:openFile: to 
 -application:openFiles: in my application delegate. Then, I noticed that my 
 Open File menu command directly calls my window creation function, and I 
 decided to change the action handler to call -application:openFiles: instead. 
 Later I realized that changing a global via -replyToOpenOrPrint: to the 
 application object may not be a good idea if said object doesn’t expect it 
 (like outside of application launch). So now I want to re-reimplement the 
 open-file action handler by calling the open-file Apple Event to myself. 
 Looking through the modern Apple docs, I see all sorts of stuff about 
 handling Apple Events, but nothing about sending them. Help.

I think you can use NSWorkspace. It will generate the same events than the one 
send when you try to open a file from the Finder.



___

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: Translating to Swift

[Jean-Daniel Dupas]

In fact, this is actually exactly equivalent to you sample. Global and class 
variable initialization on Swift is performed lazily and is implemented using 
dispatch_once().

And after a second thought, I think that it should be 'let' and not 'var', and 
you don't want the pointer to be changed after initialization.

I don't remember if static class variable are supported yet, but if they are, 
you can also use one instead of a global.

Le 14 août 2014 à 20:44, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 
 
 On 13 Aug 2014, at 17:35, Jean-Daniel Dupas mail...@xenonium.com wrote:
 
 At global scope
 
 var sharedThing : Thing = Thing();
 
 
 Excellent. Just what I needed.
 
 But: is this thread-safe? What if several threads are trying to use the 
 sharedThing? The Swift book doesn't mention the word thread.
 
 Kind regards,
 
 Gerriet.
 
 Le 13 août 2014 à 12:30, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :
 
 
 How could I translate this to Swift?
 
 + (Thing *)sharedThing
 {
 static Thing *commonThing;
 static dispatch_once_t justOnce;
 dispatch_once( justOnce, ^void
 {
 commonThing = [ [ Thing alloc ] init ];
 }
 );
 
 return commonThing;
 }
 
 Gerriet.
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Translating to Swift

[Jean-Daniel Dupas]

At global scope

var sharedThing : Thing = Thing();

Le 13 août 2014 à 12:30, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :

 
 How could I translate this to Swift?
 
 + (Thing *)sharedThing
 {
   static Thing *commonThing;
   static dispatch_once_t justOnce;
   dispatch_once( justOnce, ^void
   {
   commonThing = [ [ Thing alloc ] init ];
   }
   );
   
   return commonThing;
 }
 
 Gerriet.
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Common Date between Swift and ObjC

[Jean-Daniel Dupas]

You can use an enum. The compiler treats them as constant and they are 
available both in Obj-C and Swift.

Le 12 août 2014 à 20:04, Paul Scott psc...@skycoast.us a écrit :

 Except the compiler cannot treat them as constants for optimization.
 
 Paul
 
 On Aug 12, 2014, at 10:57 AM, Gerriet M. Denkmann gerr...@mdenkmann.de 
 wrote:
 
 
 On 13 Aug 2014, at 00:52, Jeff Kelley slauncha...@gmail.com wrote:
 
 Gerriet,
 
 You should be able to make a constant variable, not a preprocessor 
 definition, and import the file that declares it in your project’s bridging 
 header. Something like this:
 
 in Constants.h:
 extern const NSInteger kParameterA;
 
 in Constants.m:
 const NSInteger kParameterA = 17;
 
 Then, in your bridging header, you’d import Constants.h.
 
 Sounds like a good idea. I will try it tomorrow.
 Thanks a lot!
 
 
 Kind regards,
 
 Gerriet.
 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: app icon for Launchpad

[Jean-Daniel Dupas]

That's probably a Launchpad icon caching issue. I don't know where it used to 
cache icons though.

Le 17 juin 2014 à 05:35, Roland King r...@rols.org a écrit :

 My OSX app has an icon. It shows in the dock when active, it shows on 
 Alt-Tab, it shows in the Applications folder, however in Launchpad I get the 
 generic OSX Application Icon. 
 
 I'm using Images.xcassets for my icons (it's a fairly new project). What do I 
 need to have for Launchpad to show the icon? 
 ___
 
 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/mailing%40xenonium.com
 
 This email sent to mail...@xenonium.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: Xcode 5 Obj-C++

[Jean-Daniel Dupas]

Le 30 janv. 2014 à 12:49, jonat...@mugginsoft.com a écrit :

 
 On 30 Jan 2014, at 00:42, Jens Alfke j...@mooseyard.com wrote:
 
 
 Anyone exposing a C++ API in a dynamic library is nuts, IMHO. 
 
 What is it that makes C++ so unsuited to code sharing?

We're not talking about code sharing, we are talking about dynamic library.

It is barely possible to create a stable ABI in C++. This language suffers all 
possible form of fragile base class problem: 
Add a new ivar, all subclasses and stack allocated objects are broken.
Add a new virtual method, you break all virtual subclasses.
And I'm not even mentioning the fact that it is possible to build incompatible 
code from the same sources, depending the C++ features you enable (RTTI, …)

The problem is limited with STL as most of it is just templates and the STL 
dylib itself contains very few code.

While trying to expose a stable API and ABI in a dynamic library is possible, 
it is very complex or require some nasty construct like pimpl (which does not 
solve the virtual method issues).

 
 Objective-C has great clarity of purpose (send a guy a message) and openness.
 Perhaps this is what makes it a great base for building dynamic systems 
 (which is what UI driven applications generally are).
 
 If I need a computational engine within such a dynamic system (say I want to 
 solve the Cutting Stock Problem) then C++ can supply focussed performance.
 
 Jonathan
 ___
 
 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/devlists%40shadowlab.org
 
 This email sent to devli...@shadowlab.org

-- Jean-Daniel





___

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 CFUUIDCreateString() return lowercase characters?

[Jean-Daniel Dupas]

According to the current CF sources, CFUUIDCreateString() returns an uppercase 
string.

But if I really want to know what I get, I would rather use the libuuid 
functions provided by the system: uuid_unparse_lower() and uuid_unparse_upper().

See man uuid for details.


Le 21 janv. 2014 à 11:21, Markus Spoettl ms_li...@shiftoption.com a écrit :

 Hi,
 
  up until now I've been assuming that CFUUIDCreateString() returns strings 
 using uppercase letters. There's lots of empirical evidence that it does do 
 that, but nothing in writing.
 
 NSUUID's -UUIDString documentation also suggests uppercase characters being 
 used, but doesn't commit to it either.
 
 Anyone with authority here to confirm that assumption?
 
 Regards
 Markus
 -- 
 __
 Markus Spoettl
 ___
 
 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/devlists%40shadowlab.org
 
 This email sent to devli...@shadowlab.org

-- Jean-Daniel




___

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