Re: printing black

[Alastair Houghton]

On 22 Jan 2019, at 08:16, Georg Seifert  wrote:
> 
> Hi
> 
> I have a app that can print black shapes (using normal cocoa view based 
> printing). A lot users complain that the printouts are not really black (the 
> printouts are rastered, so the color sync tries to simulate a CMJK black but 
> even thou that it is black already). 
> 
> We played around with the pdf made form the print dialog. Printing that from 
> Adobe Acrobat produces the same results. But Acrobat has an option to convert 
> the PDF to optimise it for Digital printing. It attaches a genericGrayscale 
> profile to the PDF. 
> 
> Does any have a hint what to do? 

There’s often a printer setting on users’ printers to tell them to use (just) 
black ink.  OTOH I think the problem is that Quartz by default prints using 
“rich black” (i.e. C+M+Y+K) rather than black, which is *sometimes* the right 
thing to do and makes sense in some respects, but when you really want *just 
black* it’s annoying.

It’s probably also muddy looking on many inkjet printers.

I don’t know whether it’s possible use color spaces to tell Quartz to use just 
plain black.  It quite probably is (you might find using CMYK colours and just 
picking K will work, I don’t know; ColorSync could still interfere, mind).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: NSImage to JPEG file?

[Alastair Houghton]

On 16 Jan 2019, at 20:17, Jens Alfke  wrote:
> 
>> On Jan 16, 2019, at 9:59 AM, Carl Hoefs  
>> wrote:
>> 
>> But all of that would come "for free" if NSImage inherited from NSData, no?
> 
> Well, that wouldn’t make sense, because an NSImage isn’t a piece of data. It 
> can have multiple data representations (JPEG, PNG, PDF…) and it might not 
> have any at all if it was created directly in-memory with a pixmap. It’s a 
> thing that can create a data representation.

Quite.  This point is worth emphasising, actually.  A very common mistake 
people make when trying to write OO programs is using inheritance where there 
isn’t an is-a relationship.

NSImage definitely *is not* an NSData, and so should not inherit from it.

(Indeed, it could even have a custom NSImageRep backing it that does the 
drawing on the fly; indeed, there is actually a built-in version of this in the 
current version of Cocoa, where you can specify a block that gets used to 
render the image whenever the system feels it’s necessary.)

This confusion isn’t helped by the fact that certain commonly used OO languages 
(I’m looking at you, C++) muddy the waters by trying to use inheritance for 
multiple different purposes (e.g. interfaces, typically via pure virtual 
classes; mixins and the like for *implementation* purposes - which largely only 
works because of multiple inheritance and/or templates, depending on how the 
mixin is built).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Custom NSButton image effects for pressed/disabled

[Alastair Houghton]

On 12 Dec 2018, at 01:03, Lars C. Hassing  wrote:
> 
> If I assign an image to an NSButton it is displayed with nice pressed and 
> disabled effects.
> 
> In my custom NSButton, that should display image1+title+image2, I override 
> drawRect:, but how do I obtain the EXACT SAME system effects for the two 
> images?

Override -drawRect: to call the cell’s -drawWithFrame:inRect: *twice*, once 
with the cell’s image set to image1 and the alignment set to left, and once 
with the cell’s image set to image2 and the alignment set to right, making sure 
to clip appropriately so it only draws the portions you want. Obviously your 
custom button is going to have its own “image1” and “image2” properties, right, 
so you don’t care that the “image” property is all over the place :-)

e.g. on the first call, draw this:


.+---+ .
.| 1 |  Title  .
.+---+ .


Then on the second call, add this part:

   ...
 +---+ .+---+.
 | 1 |  Title  .| 2 |.
 +---+ .+---+.
   ...

Do note that if you take this approach, you’re relying on controls being 
NSCell-based. At some point in the future, I think that’s likely to change, at 
which point you might need to do something else.

It’s also conceivable that this might work better on current versions of the 
macOS if you made a custom NSButtonCell subclass and did the clipping and two 
calls in that. Why? Because various controls currently try to detect whether 
they’re using a custom cell or not and use different rendering code if they are 
not…

> I am looking for system functions to produce the SAME look and feel as Cocoa 
> controls.
> 
> Motif, Windows and Carbon all have system functions to draw control parts in 
> various states
> to help developers achieve a consistent look and feel, why wouldn’t Cocoa be 
> interested in supporting that?


Cocoa does in fact have this kind of functionality internally, but it’s 
currently SPI rather than API. I’m not sure whether Apple intends to expose the 
theme support at some time in the future.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: XPC Question

[Alastair Houghton]

On 18 Sep 2018, at 16:48, Sandor Szatmari  wrote:
> 
> Thanks Alistair!
> 
> Anyone else have additional info?

Well, Cocoa has Distributed Objects, which you could use for this purpose.  DO 
has some interesting behaviour (in particular, watch out - it can throw 
exceptions, even when calling methods that don’t normally do so), but it does 
let you send messages to objects fairly easily over a network.  There’s also 
Sun RPC (which uses the rpcgen tool, which you can find documented here: 
). 
 Both of those are built-in to the macOS.

There are other options too, but they’ll be more work; for instance CORBA, DCE 
RPC (or indeed DCOM, which is based on it), SOAP, XML-RPC, or a Restful HTTP(S) 
interface.  Or, indeed, a custom TCP-based server.

Exactly what you use depends on what’s best for your use case, which you don’t 
describe.  In particular, cross-platform support is a major driver here; if you 
use DO, you probably won’t find it easy to talk to Windows or Linux machines if 
you ever need to in the future, and while Sun RPC is easy on most UNIX systems, 
Windows uses DCE RPC.  CORBA is probably only of interest if you’re trying to 
talk to some enterprise system already built with it.  SOAP, XML-RPC and 
Restful HTTP(S) are fairly general purpose and might be good choices if you 
ever wanted to talk to a server built with (say) Python or Ruby.

Anyway...

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: touchesMoved value setting

[Alastair Houghton]

> On 18 Sep 2018, at 13:44, Eric E. Dolecki  wrote:
> 
> I have a UI control that can be adjusted up and down using touch & drag.
> I've been asked to provide a control value based on how far the drag is via
> distance. So far so good.
> 
> What my designer wants is a value change of every 20 pixels or so (control
> is 150px tall @ the moment) - so every 20 pixels = a change of 1. This will
> require multiple touch and drags but he's fine with it.
> 
> The math is probably simple, but it's eluding me this morning. How can I
> easily convert my distance (I also have an increment Bool so I know whether
> it's addition or subtraction) to an appropriate value?

I’m not sure you’ve described the problem particularly clearly, because when I 
read your e-mail I came the conclusion that you just need to divide your 
distance by 20, but that can’t be right otherwise you’d have worked it out 
yourself…

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: XPC Question

[Alastair Houghton]

On 18 Sep 2018, at 13:37, Sandor Szatmari  wrote:
> 
> Can you do XPC RPC over an IP connection?  Or, in other words… Can you do XPC 
> between two computers?

Not as far as I’m aware. As far as I know, XPC is built on top of Mach 
messaging, which in theory can be used across the network but IIRC the version 
of Mach used in Darwin doesn’t support it.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: keyboard focus handling in custom controls

[Alastair Houghton]

On 10 Sep 2018, at 13:21, iain  wrote:
> 
> I have an application, which has 3 controls
> 
> [button] [custom view] [button]
> 
> I’ve set the NextKeyView of each of them to the control to the right
> [button] -> [custom view] -> [button]
> 
> And the tab and shift tab works between them as expected.
> 
> The situation gets more complicated because the custom view has 3 possible 
> focus areas, which I also want to be part of the tab chain.
> As it’s one big custom drawn widget, I’ve implemented a rudimentary tab 
> handler in the KeyDown: method with a counter to keep track of which area is 
> focused.
> And it sort of works
> 
> But, I’m wondering how to know if the parent NSView gained keyboard focus 
> through a tab or a shift-tab
> 
> If focus is on the first button, and you press Tab, the focus should go to 
> the 1st area of the custom view
> If focus is on the last button and you Shift Tab from it, the focus should go 
> to the 3rd area of the custom view
> Currently, it always has to go to the area that was focused when the view 
> lost focus.
> 
> Is there a way to do what I’m wanting?

In your -becomeFirstResponder, you could examine the current event (noting that 
keypresses aren’t the only way you could gain keyboard focus) to determine 
whether it was a Tab or Shift-Tab keypress. You can get the event using [NSApp 
currentEvent]. Make sure it works with Full Keyboard Access turned on in System 
Preferences as well.

Also note that you will want to implement the relevant accessibility support; 
otherwise, when users turn on VoiceOver, they won’t be able to focus individual 
elements in your view, and the VoiceOver cursor (which is not the same thing as 
the normal keyboard focus system) won’t interact properly with your view.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: C++ pointer to Cocoa object

[Alastair Houghton]

On 8 Sep 2018, at 15:32, Casey McDermott  wrote:
> 
>>> If you are using ARC and want to get a strong
> reference on the object, you have to use __bridge_retained
> 
> That is handy to know!  I see there is also __bridge_transfer to go the other 
> way.

IMO the Core Foundation wrappers CFBridgingRetain( ) and CFBridgingRelease() 
are slightly easier to follow in code; I’ve never been a huge fan of having 
lots of double-underscore things floating about.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: How to clear macOS app bundle cache

[Alastair Houghton]

On 6 Sep 2018, at 13:59, Andreas Falkenhahn  wrote:
> 
> On 06.09.2018 at 11:31 Alastair Houghton wrote:
> 
>> On 6 Sep 2018, at 05:23, Jeff Szuhay  wrote:
>> Did you try clearing the defaults persistent domain in your code?
>> I don’t think that is likely to help. Andreas was complaining that
>> the code in his bundle was being cached somewhere, so when he
>> rebuilt it didn’t always load the new version. User defaults doesn’t seem 
>> relevant here.
>> The only other thing I can think of is that sometimes Xcode doesn’t
>> actually rebuilt properly; 
> 
> Note that I'm not using Xcode. The app is built using plain makefiles.

FWIW, make can also do the same thing on network filesystems if the timestamps 
aren’t granular enough. Xcode seems more fragile for some reason (I’ve had it 
fail to properly rebuild locally on more than a few occasions).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: How to clear macOS app bundle cache

[Alastair Houghton]

On 6 Sep 2018, at 05:23, Jeff Szuhay  wrote:
> 
> Did you try clearing the defaults persistent domain in your code?

I don’t think that is likely to help. Andreas was complaining that the code in 
his bundle was being cached somewhere, so when he rebuilt it didn’t always load 
the new version. User defaults doesn’t seem relevant here.

The only other thing I can think of is that sometimes Xcode doesn’t actually 
rebuilt properly; it hadn’t really occurred to me before that that might be the 
problem, but particularly if the build is being done on a network volume, 
there’s a real risk this could happen. This is especially true if the volume is 
backed by a FAT disk because those have a two second (yes, two second) 
timestamp granularity, which can very easily cause unexpected problems building 
code. You can probably tell if the build system is the culprit here because if 
you tell it to do a full clean (IIRC you have to hold Option and choose the 
clean option from the menu to get it to wipe things completely) and rebuild 
then it’ll start working.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: How to clear macOS app bundle cache

[Alastair Houghton]

On 4 Sep 2018, at 19:57, Andreas Falkenhahn  wrote:
> 
> On 04.09.2018 at 18:27 Marco S Hyman wrote:
> 
>> Have you tried disabling SMB client side caching? 
>> https://support.apple.com/en-us/HT207520
> 
> Doesn't change anything. Maybe because the share is SMB 1, not SMB 2 or 3 as 
> stated in the article.

Does the server you’re using also support NFS? The last time I used networked 
filesystems from a Mac, NFS worked better than either SMB or AFP (indeed, in 
some cases, NFS was noticeably faster too).

I know it’s a bit of a pain switching from SMB, but since some servers 
straightforwardly support both, it might not be the worst option. If you’re 
using OS X Server to do it, I wrote some notes back in 2012 
 that might still be relevant.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: How to clear macOS app bundle cache

[Alastair Houghton]

On 4 Sep 2018, at 14:30, Shane Stanley  wrote:
> 
> On 4 Sep 2018, at 11:28 pm, Alastair Houghton  
> wrote:
>> 
>> On 4 Sep 2018, at 00:19, Shane Stanley  wrote:
>>> 
>>> On 3 Sep 2018, at 11:31 pm, Andreas Falkenhahn  
>>> wrote:
>>>> 
>>>> I'm looking for a solution to flush the app bundle cache
>>> 
>>> If you find one, I'd love to know what it is. I had no luck at all.
>> 
>> Is the application in question sandboxed?
> 
> No.

OK. Have you tried logging the path of a file in the bundle, so you can see 
where it’s being read from?

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.

Kind regards,

Alastair

--
http://alastairs-place.net

___

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

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

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

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

Re: How to clear macOS app bundle cache

[Alastair Houghton]

On 4 Sep 2018, at 00:19, Shane Stanley  wrote:
> 
> On 3 Sep 2018, at 11:31 pm, Andreas Falkenhahn  wrote:
>> 
>> I'm looking for a solution to flush the app bundle cache
> 
> If you find one, I'd love to know what it is. I had no luck at all.

Is the application in question sandboxed? If so, have you checked to see 
whether the application bundle gets copied into the sandbox? (I don’t have time 
to look right now myself, but it might make sense to do that for sandboxed 
bundles launched from a network drive.)

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
> 
> On 23 Aug 2018, at 12:06, Alastair Houghton  
> wrote:
>> 
>> Run loops are based on dispatch queues too, these days.
> 
> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
> I these behave as normal sources without any sign of dispatch queues as far 
> as I can tell?
> 
> I did experiment with using dispatch sources instead, but these can not be 
> recursed, which was a showstopper unfortunately. I would have loved to use 
> the queue debugging feature (backtrace recording) to tie posted Qt events 
> back to their origin.

You can see the code here

https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html 
<https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html>

Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
very tightly integrated… CFRunLoop appears to be using dispatch queues for 
timers, and there’s clearly integration such that dispatched calls will run 
within the run loop.

It does still have its own separate run loop sources, observers and so on, I 
believe; they all talk to the run loop itself via a set of Mach ports.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 21:42, Saagar Jha  wrote:
> 
>> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
>> there’s really no reason that CFRunLoop would have to spawn a background 
>> thread just to monitor some file descriptors. As far as I can tell, the 
>> current CFRunLoop implementation is built on top of GCD, which sadly we 
>> don’t have the source code for
> 
> libdispatch is open source: 
> https://github.com/apple/swift-corelibs-libdispatch 
> 

On 23 Aug 2018, at 04:30, Uli Kusterer  wrote:
> 
> 
> I recall hearing from someone at Apple that they basically ported GCD to 
> Linux for the Swift Linux release ... have you looked whether that code might 
> give any clues about what may be happening on macOS?


Interesting. That isn’t quite the same libdispatch that’s used on the macOS by 
the look of things, but it does appear to have things merged across from the 
macOS version. It looks, from a cursory examination, as if the macOS 
functionality is built on top of a kernel “work queue” implementation that 
lives inside the non-open-source pthread.kext. (I’m sure I’m not the only one 
to have noticed that quite a bit of functionality has been moved from open 
source parts of the macOS to closed-source libraries and KEXTs; personally I 
find this a disappointing development, as it makes debugging and developing 
software harder if it’s impossible to inspect the source code.)

Anyway, from what I can see it seems highly unlikely that there will be any 
background threads to monitor file descriptors, at least on the macOS.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 19:32, Jens Alfke  wrote:
> 
>> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>> mailto:alast...@alastairs-place.net>> wrote:
>> 
>> Well, yes and no. If the network library works that way, it’ll fire its 
>> callbacks on the background thread, which makes life awkward if you’re 
>> interacting with the UI
> 
> Then you write glue around the callbacks that dispatches them on a selectable 
> dispatch queue. (Which you'll want to do anyway, because who wants to work 
> with C callbacks?)

You’ll take a performance hit doing that; not sure how large, but some, for 
sure. Not necessarily a big issue for most apps, but worth bearing in mind.

>> Much better to use a library that’s properly integrated with the native run 
>> loop and that therefore doesn’t end up calling your code on a background 
>> thread.
> 
> To be pedantic, both NSURLSession and Network.framework are based on dispatch 
> queues, not runloops. They call delegate code on the dispatch queue assigned 
> to the task.

Run loops are based on dispatch queues too, these days.

> Anyway, I agree with you that using a library integrated with OS facilities 
> is better than one that isn't. But developers using non-HTTP protocols, or 
> coding in C/C++, don't have that luxury … not until they can move up to iOS 
> 12 / macOS 10.14 as their deployment SDKs.  In my case that's probably about 
> three years away. :(

It’s worth checking whether any of the other libraries have dispatch queue or 
run loop integration. It wouldn’t surprise me if some of them do — it isn’t 
much of a stretch, once you have an async I/O library, to add the necessary 
support. That was sort of the point I was making, namely that it’s worth 
looking carefully at the available options to see which have the platform 
support you need to make them interoperate well with your platform specific 
code (without necessarily being platform specific themselves).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 17:53, Jens Alfke  wrote:
> 
>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton > <mailto:alast...@alastairs-place.net>> wrote:
>> 
>> So, for instance, it’s not so good on macOS or iOS if its event dispatcher 
>> is based on select(), (e)poll() or kqueue() because what you really want on 
>> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, 
>> you’ll end up having to use threading to run the network library’s event 
>> loops on background threads, which for an async networking library kind of 
>> defeats the point IMO.
> 
> It does mean you have to spin up one background thread to sit and wait for 
> events; but that's not a big hardship. You still get the scalability benefits 
> of event-driven I/O, vs. having to use one thread per socket the 
> old-fashioned way.

Well, yes and no. If the network library works that way, it’ll fire its 
callbacks on the background thread, which makes life awkward if you’re 
interacting with the UI as you’ll need to forward to the main thread and it may 
in some cases for you to use synchronisation when you wouldn’t have needed to. 
Much better to use a library that’s properly integrated with the native run 
loop and that therefore doesn’t end up calling your code on a background thread.

> (NSURLSession and Network.framework are doing the same thing under the hood, 
> after all.)

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

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 21 Aug 2018, at 10:09, Mike Crawford  wrote:
> 
>> drag C developers away from the POSIX sockets API
> 
> Don't be dismayed if you're not happy with NIO:
> 
> There are numerous APIs that do such dragging, for example the
> ADAPTIVE Communications Environment (ACE):
> 
>   http://www.dre.vanderbilt.edu/~schmidt/ACE.html 
> 
> 
> Mozilla's NetScape Portable Runtime, The Electric Magic Company's
> ZooLib is C++ and MIT Licensed:
> 
>   http://www.em.net/portfolio/2000/12/zoolib.html 
> 
> 
> I expect there are many others.

One of the problems with many of those libraries is that they tend to insist 
that your software use their own event loop implementation(s). Admittedly it’s 
been a while since I looked at ACE (for example), but NIO is at least going to 
be using the same mechanisms that you’d use anyway in a macOS or iOS 
application.

Anyway, when looking at an async networking library, you want to check that it 
will integrate nicely with the set of platforms you care about, using the kind 
of event dispatch you require in your application. So, for instance, it’s not 
so good on macOS or iOS if its event dispatcher is based on select(), (e)poll() 
or kqueue() because what you really want on macOS/iOS is for the event dispatch 
to go via CFRunLoop; if it doesn’t, you’ll end up having to use threading to 
run the network library’s event loops on background threads, which for an async 
networking library kind of defeats the point IMO. (Of course, you may want to 
have event loops running in threads or thread pools for performance reasons, 
but one of the real benefits of async networking libraries is that you can use 
them from the main thread in your GUI code.)

Likewise, on Windows you’re going to want something that uses 
MsgWaitForMultipleObjectsEx() or similar, and on Linux you definitely want 
epoll() support.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 20 Aug 2018, at 14:27, Casey McDermott  wrote:
> 
> Moving anything from Obj-C to C++ objects is easy, because the .mm file can 
> contain both.
> 
> Moving back is hard, because C++ can't reference Obj-C classes.

It can, but only if it’s either (a) in a .mm file, or (b) prepared to call the 
Objective-C runtime functions. You can include the Objective-C runtime from a 
C++ file, and you’ll get all the base types (so, not the Foundation or AppKit 
types, or any of your own, but you will get “id”, “Protocol”, “Class” and so 
on), and can make method calls using appropriate Objective-C runtime APIs. I’m 
not saying either of those would be better than what you’ve done, mind.

>>> I’d tentatively suggest that it’s likely that Swift will develop some means 
>>> of 
> interfacing more directly with C++ code in the future, which should make this 
> easier rather than harder.
> 
> This link says that C++ support is now marked "out of scope" in Swift 3.0:
> https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift
> I didn't find any mention of future support being planned.

Sure, that may well be the case. I can’t imagine anyone thinking it isn’t a 
desirable feature for Swift to have at some point, though, and Swift being Open 
Source, any of a very large pool of people and companies could work on this if 
they wanted. I think it’s inevitable that Swift will at some point develop 
better support for C++ objects.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 18 Aug 2018, at 20:45, Mike Crawford  wrote:
> 
> "older OS versions", porting to 10.6 or later vs. 10.10 or later:
> 
> I at first intended all the drivers I write for my clients to work on
> Snow Leopard 10.6, but after actually attempting to do so I settled
> upon supporting El Capitan 10.11, sometimes just Sierra 12.6.

Slightly off topic, but drivers are definitely the worst case, as sometimes you 
need to use the old SDKs to build them, and the Xcode team is, in my view, 
somewhat overenthusiastic about dropping support for them… the Deployment 
Target setting isn’t always sufficient. I do wonder, actually, how much thought 
is given to those of us who have KEXTs to build when pondering whether or not 
to drop an SDK from Xcode. There have been some other pain points in recent 
macOS versions relating to KEXTs also (changes to driver signing, the recent 
blocking of third-party KEXTs until the user visits System Preferences to 
confirm their installation, etc.). One would almost think Apple didn’t want us 
writing low-level code…

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Carbon -> Cocoa

[Alastair Houghton]

On 17 Aug 2018, at 17:45, Casey McDermott  wrote:
> 
>>> By now, Cocoa may be the new Carbon.   if your app is large, I'd wait to 
>>> see what happens with Marzipan.
> 
> This is true, and very scary.  Makes us wonder about sunk cost fallacy.

I don’t actually think it’s very likely that Marzipan will replace Cocoa 
(except possibly for things like calculator, to-do list and notes type apps). 
My impression is that it’s really a way to run iOS apps, which typically have a 
much simpler UI and far fewer features, on the macOS. That makes sense for some 
types of software, for sure, but I think larger packages are likely to want to 
stick with AppKit.

> It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.

Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” and 
then use C++ wherever you wish.

> Throw in Swift and future APIs that are Swift-dominated, and it becomes 
> harder.  How soon will it be impossible?

It’ll never be impossible, but you’re right at the moment you’ll need either an 
Objective-C or vanilla C API to wrap your C++. I’d tentatively suggest that 
it’s likely that Swift will develop some means of interfacing more directly 
with C++ code in the future, which should make this easier rather than harder.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: NSComboBox

[Alastair Houghton]

On 26 Jul 2018, at 01:18, Casey McDermott  wrote:
> 
> We have a 1/2 decent version working right now based on NSTextField. It shows 
> a scrolling table
> with a NSWindowController, and selects from the table (and beeps if not 
> there). It also
> has a NSPopUpButton on the side to use as an additional option (handy for 
> short lists
> or if the user is already mousing).  Basically, that is the same approach we 
> use/used in the 
> C++ version (PowerPlant, Carbon).
> 
> But, getting all the details to work just right has been extremely difficult. 
>  NSComboBox
> is so close, and so much less futzing.  Also, the combo box in Windows 
> MFC 
> does exactly what we need, and it would be nice if both platforms looked the 
> same.
> 
> One big beef I have is that it's not possible to step into Cocoa source, 
> unlike PowerPlant
> or MFC.  It makes it much harder to understand what's going on inside Cocoa.

To be fair, in the case of MFC some of it (like the combobox) relies on 
underlying Windows controls that you also don’t have the source for.

NSComboBox is pretty unusual in a Mac application; you don’t see many of them 
about, and I think that’s because there are often better options (particularly 
in cases like yours where you say there may be thousands of possible choices), 
not to mention the fact that historically the NSComboBox looked rather ugly 
compared to other Aqua controls. You might also consider using something like 
NSTokenField (check out the To and Cc fields in Apple Mail for an idea of what 
that might look like).

Someone suggested looking at the Cocotron source; that isn’t a bad idea — 
though Cocotron’s implementations are sometimes rather simpler than the ones in 
the Cocoa framework — and you could also look at GNUStep’s sources to see how 
it does things. Neither, of course, guarantees that Apple/NeXT chose the same 
approach, although in many cases the API itself does dictate some of the 
details of how it works under the covers; if you want to know how it really 
works, grab yourself a copy of Hopper > (or IDA, or even just do it the old fashioned way 
using otool) and disassemble the relevant framework.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: NSDrawer

[Alastair Houghton]

On 3 Jul 2018, at 03:08, Casey McDermott  wrote:
> 
> NSDrawer is deprecated, but it's also perfect for our application.
> We still haven't found a good substitute.

[snip]

> Is there a work-around for an attached window that pops out on the side,
> and acts like a drawer?  

NSDrawer isn’t particularly special; it’s just a child window set to order 
below its parent (see [NSWindow addChildWindow:ordered:), with some views 
inside it.  You can easily create something that works just like NSDrawer if 
you really want to.

> Any idea when deprecation turns into total non-support?

Well, I think NSDrawer was deprecated because the UI people felt it didn’t fit 
in with the current UI design, rather than for any technical reason, and as 
such I’d suppose that eliminating it would be a low priority.  But the only 
people who could tell you Apple’s intentions are those people who work for 
Apple, and, sadly, they often aren’t able to because they aren’t allowed.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Scrolling differences when using Trackpad or Mouse-Wheel

[Alastair Houghton]

On Jun 19, 2018, at 2:56 AM, Michael Starke 
mailto:michael.sta...@hicknhack-software.com>> wrote:
> 
> Hi list,
> 
> I'm currently trying to find the bottleneck in my app MacPass that's causing 
> the scrolling in the main table to be sluggish.
> 
> Before diving deeply into Instruments to find the culprit I realized that 
> scrolling with the trackpad is butter-smooth but scrolling using the mouse 
> wheel is rather slow. When I start to scroll down, there's a slight delay but 
> then the scrolling works smooth. This is not the case when scrolling up or 
> when scrolling using the trackpad.


On 20 Jun 2018, at 05:03, Jack Brindle  wrote:
> 
> What’s the mouse? It’s not from Apple, so what is it, how is it connected and 
> does it use any software to help it work?

This is a very good point. I have mice from a number of vendors (including 
Apple), and scroll wheel behaviour definitely differs significantly in some 
cases; also, it can matter whether or not you install the vendor’s software 
(mice usually work reasonably well without, but installing and running the 
vendor’s software can change things significantly).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Exception handling

[Alastair Houghton]

On 15 Jun 2018, at 19:30, Jens Alfke  wrote:
> 
>> On Jun 14, 2018, at 5:58 PM, Quincey Morris 
>>  wrote:
>> 
>> as someone already mentioned, NSExceptions can’t successfully cross 
>> dylib/framework boundaries.
> 
> They can, actually; there is no problem with this at the ABI/runtime level.
> 
> I think what you mean is that most libraries/frameworks don't make guarantees 
> about properly handling exceptions thrown into them, i.e. from a call into 
> external code. Some C++ libraries do guarantee this (especially libc++), and 
> even without guarantees a typical C++ lib using RAII will be relatively safe, 
> but Objective-C code usually isn't written to be exception-safe, and C code 
> of course can't be.

Quite, though in principle there’s no reason C code couldn’t be exception safe, 
it’s just that there’s no language support for it (except on Windows where 
there are extensions to support SEH), so the C code would have to know about 
the relevant runtime data structures and associated behaviour.  In practice, 
it’s very unlikely you’d ever find exception-safe C code, except in a language 
runtime or - rarely - on Windows when it’s been written to use SEH.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Exception handling

[Alastair Houghton]

On 14 Jun 2018, at 18:00, Jens Alfke  wrote:
> 
>> On Jun 13, 2018, at 7:22 PM, Casey McDermott  wrote:
>> 
>> Our Carbon event loop had a try/catch block, which caught most exceptions, 
>> and then
>> continued.  It started as an expedient in early production, but it remained 
>> in production code 
>> since it often allows users to continue, save their work, etc.  
> 
> That's actually how Cocoa used to work. I can't recall whether an alert panel 
> popped up or if it was just silent. The behavior changed to crashing sometime 
> in the past, um, 8 years or so.

I don’t think it’s changed in any obvious way; the framework has always 
swallowed exceptions in certain contexts, but not in others. Obviously the 
precise detail may have changed over time, but it’s certainly crashed on 
exceptions for as long as I remember, outside of the places where they get 
ignored for whatever reason.

>> Is there a way to override the event loop in Cocoa?  Some other way we can 
>> escape to 
>> the event loop and then continue from there? 
> 
> There used to be either a callback or an overridable NSApplication method to 
> handle an uncaught exception, but looking at current headers I can't find 
> what I'm looking for; maybe it's been gone for a long time and removed?

Perhaps you’re thinking of NSSetUncaughtExceptionHandler()? I don’t think 
there’s much you can usefully do from that, though, besides logging the 
exception.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Exception handling

[Alastair Houghton]

On 14 Jun 2018, at 03:53, Quincey Morris  
wrote:
> 
> On Jun 13, 2018, at 19:22 , Casey McDermott  wrote:
>> 
>> Nearly always, the event loop is the best place to escape to.
> 
> This is not how current thinking goes, unless you mean something different 
> from what I think you’re saying.

Agreed, but with the proviso that the Cocoa framework actually catches and 
ignores exceptions itself in various contexts. This can be quite annoying when 
it happens, because it can result in odd behaviour and it isn’t always obvious 
that the cause was an exception.

> I may be out on my lonesome here, but if you want a robust app, I really 
> think you have exactly 2 error handling patterns:
> 
> 1. Returning false/nil with an outError parameter for recoverable errors, and 
> always testing the result at every level.
> 
> 2. Throwing NSExceptions for unrecoverable errors, and letting the app crash 
> immediately.

No, you aren’t out on your own.  That’s the tradition in the Objective-C world; 
either return a nil or NO result with an NSError parameter filled in 
appropriately, or throw an exception where a crash is probably appropriate.

There are a couple of places in the Cocoa frameworks where things don’t quite 
work that way; notably, Distributed Objects can throw exceptions when you send 
messages to remote objects — this makes sense, because the local proxy object 
is supposed to behave pretty much the same as the remote object, and could in 
general be of any type (therefore doesn’t necessarily have an NSError parameter 
available, or even a return code that could be used to indicate failure). If 
you’re using DO, you might therefore use Objective-C exceptions for some 
recoverable error handling (e.g. where a remote server has “gone away” and you 
therefore need to reconnect somehow or connect somewhere else).

> The situation with C++ exceptions is a bit different. You can basically do 
> whatever you want with those (including using them for flow control), but 
> there’s still nowhere central to catch uncaught exceptions, and you still 
> have to worry about multithreading.

More to the point, there’s nowhere safe to catch uncaught exceptions; you can’t 
assume that you can safely throw a C++ exception through any library or 
framework, including the Cocoa and Core Foundation frameworks, even though on 
the 64-bit runtime Objective-C and C++ exceptions are (kind of) unified, 
because Objective-C code generally doesn’t expect exceptions and so if you 
throw them through it it’s unlikely to be in a good state afterwards.

Basically, if you’re calling C++ code from your Objective-C code, and that C++ 
code might throw exceptions, you’re going to want to call it within a try 
statement (you *can* use an Objective-C @try, in which case the @catch(…) case 
will catch C++ exceptions; but that probably won’t give you the granularity you 
want).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Crashes inside CFStringDeallocate

[Alastair Houghton]

On 10 Jun 2018, at 19:14, Dave  wrote:
> 
> Override the dealloc method and log when its called - its probably being 
> over-released!

That isn’t quite as simple as it sounds, because this is NSString we’re talking 
about, which is a class cluster.  Most actual NSString instances are really 
NSCFString, though there’s nothing stopping other things from cropping up.  To 
make this work, you’d have to change the class of the string object for your 
own subclass (quite possibly using object_setClass(), because there’s a good 
chance the string object either didn’t come from your code).

It’s probably better to use the built-in debugging features (zombies and the 
various memory debugging tools in Instruments, not to mention the debugging 
features in malloc). 

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Crashes inside CFStringDeallocate

[Alastair Houghton]

On 25 May 2018, at 22:18, Vojtěch Meluzín  wrote:
> 
> Ok so I got a solution - it's the utf16 indeed. When I use [NSString
> stringWithUTF8String] instead, it doesn't crash. Considering it does that
> only on 10.10 (and probably older), it seems like OSX malfunction... oh
> well... Fortunately no big deal.

That’s extremely unlikely.  Plenty of code constructs NSStrings from UTF-16 
data, and the rest of us aren’t seeing crashes in CFStringDeallocate.

There’s clearly some kind of bug in your code, but it doesn’t appear to be in 
the lines you showed us.  If I had to guess, I’d say you’ve over-released your 
NSString somehow (leading to an attempted double free of the underlying 
storage); turning on Zombies in your Xcode build scheme is not a bad idea, and 
turning on the malloc debugging features (MallocStackLogging and 
MallocStackLoggingNoCompact might be helpful) might be a good fallback option 
if enabling zombies doesn’t show you precisely where things are going wrong.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Implementing an import command in NSDocument-based app

[Alastair Houghton]

On 16 May 2018, at 08:55, Pascal Bourguignon  wrote:

>> Le 16 mai 2018 à 09:26, Rick Mann  a écrit :
>> 
>> I'm working on a little NSDocument-based app. The documents are packages (a 
>> directory containing multiple files). One of the operations is to import a 
>> music file into the document, which should copy the music file into the 
>> package, and set it as the track for the document.
>> 
>> Undoing this operation is somewhat complex (where do I store the previous 
>> track if any?). So for now, I want to ignore undo.

The user’s temporary folder would be a good place to store the previous track 
(you probably want to delete it when the program terminates).

> You have a choice, for « unsaved » documents:
> - either you keep them only in memory, or
> - you record them in a « untitled » file package, perhaps in /tmp.

I wouldn’t recommend /tmp. The trouble with /tmp is that it’s global, not 
per-user, and so if you’re using that location you typically need to take steps 
to make a per-user subdirectory in order to keep others from tampering with the 
current user’s files; there are a lot of ways to get that wrong and end up with 
a security hole.

However, you can use NSFileManager’s 
-URLForDirectory:inDomain:appropriateForURL:create:error: method to obtain an 
appropriate per-user temporary folder that you can use instead.

> I guess you see where I’m drifting to: it’s best to keep your document saved 
> on disk all the time, even before it’s saved explicitely by the user.

Agreed.

>  The bonus feature, is that if your application crashes, or the system is 
> powered off, you can restore the unsaved document (if you don’t put it in 
> /tmp, but eg. in ~/Documents/Unsaved\ Documents/).

But please don’t create your own subfolders in the user’s Documents folder. The 
Documents folder belongs to the user — it isn’t yours to tinker with as you 
please, and I know I’m not alone in feeling a visceral hatred when I see that 
software has, without asking, created its own subfolders there. If you want 
somewhere to store these, I’d suggest putting them in ~/Library/Application 
Support//Unsaved Documents (or similar) instead.

>  Then you can copy the imported data to a file as soon as the import function 
> is activated, so even if the imported file is deleted, the imported data will 
> be there.  And then you don’t have to implement in-memory data structure for 
> unsaved documents, since by definition all documents are backed by files the 
> same way (only a different path), whether they’re « saved » nor not « saved 
> ».  Much simplier.  When you launch the application, scan the unsaved 
> documents folder for unsaved document,  and re-open them, to let the user 
> choose whether to close (and delete them), or to save them.

If you’re going to open them automatically, it is a very good idea to prompt 
the user first — i.e. let them know they have unsaved documents from a previous 
session and offer to open them. Why? Because if the thing that caused your 
application to terminate was a crash caused by some problem with the document 
structure, then auto-opening will likely cause your application to crash again 
— and that will be quite infuriating for the end user.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Avoiding link conflicts with a static library

[Alastair Houghton]

On 4 Apr 2018, at 17:25, Redler Eyal  wrote:

> 
> We're developing an SDK for iOS, the SDK is delivered in a statically-linked 
> framework. Our library uses openCV and we link OpenCV into the delivered 
> framework binary.
> 
> This SDK was deployed successfully with some clients but we're having an 
> issue with one client whose application also links indirectly (via card-io) 
> with openCV. The version of openCV they're using is different then then one 
> we use and as a result of this conflict, the application crashes upon use of 
> our SDK.
> 
> We are aware that the following are possible solutions to the problem:
> a. Switch to use the same version of OpenCV as our client.
> b. Build our framework as a dynamic library (where we a supposed to be able 
> to hide openCV inside)
> Both of these options are not optimal for us and we trying to see if we have 
> any other option.

You could rename the symbols in your copy of OpenCV so that they don’t match 
the standard ones. One way to do that is with the preprocessor (use #defines to 
change the names of the OpenCV functions you use), which potentially avoids 
altering the OpenCV sources themselves (you can use a prefix header to get your 
#defines into the OpenCV build process if necessary).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Creating NSTableView programmatically

[Alastair Houghton]

On 11 Dec 2017, at 13:53, Eric Matecki  wrote:
> 
> Thanks Jonathan,
> 
> I got a lot further now.
> So it is NSTableCellView, not NSTableViewCell as stated in the doc !

FWIW, NSTableViewCell is the old way to do it, before view-based tables were 
the norm, which probably explains your confusion here as the documentation most 
likely still covers both techniques.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: NSString equivalent of CFSTR macro?

[Alastair Houghton]

On 4 Dec 2017, at 22:47, Rick Mann  wrote:
> 
> I have to use some C header file that #defines some string constants. Is 
> there an equivalent to CFSTR() that constructs NSString literals? E.g.,
> 
> 
> #define NSSTR(s)  (@ ## s) <-- magic; this 
> doesn't work
> #define kSomeCStringConstant  "foo"
> ...
> NSSTR(kSomeCStringConstant)

Why not just do

  #define NSSTR(s)  ((NSString *)CFSTR(s))

After all, constant NSStrings are the same as constant CFStrings, right?

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Inserting a button into another application's toolbar

[Alastair Houghton]

> On 19 Sep 2017, at 06:01, Jack Brindle  wrote:
> 
> Actually, there may be a way. It all depends on exactly where in the menu bar 
> you want to place the menu item.

I think the OP wanted to inject a *toolbar* item into another app’s window’s 
toolbar, not a menu bar item/status item.

FWIW, a status bar item might be an appropriate alternative, depending on what 
the app does and how it works.  Other alternatives worth considering are the 
Scripts menu (this is AppleScript, so if you go to Script Editor’s Preferences 
window, you’ll see you can turn on the Script menu in the status bar), and 
making your code run as a system service (so you can choose it from App > 
Services).

> On Sep 18, 2017, at 4:15 PM, Jens Alfke  wrote:
> 
>> Sorry, there's no reasonable way to do that if the app doesn't already 
>> support plugins. There used to be some awful hacks that patched into the 
>> app-launching mechanism and made it possible to inject code into other apps, 
>> but that approach causes stability problems and is in general terrible for 
>> security.

There were also quite a number that abused the Input Manager mechanism as if it 
was a general purpose way of plugging in to other applications.  On the one 
hand, some of these extensions were fine, worked nicely, and didn’t cause 
problems.  On the other, *some* of them did cause trouble on a fairly routine 
basis.

Certainly I’d caution against writing anything other than a personal-use-only 
project or some kind of debug tool that does things like that; at the very 
least, your users are going to find that many developers take one look at their 
crash logs and reply that you’ve got some kind of system hack installed and 
that if you can reproduce it without that, they’ll look at it.  That’s a little 
unfair, of course - many times these system hacks weren’t to blame at all - but 
after the handful of cases where they *are* to blame hit your desk, sending you 
on a wild goose chase until you finally realise that some kind of tampering has 
been going on, you’ll probably end up as grumpy about them as Jens :-)

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 15:24, Jeremy Hughes <moon.rab...@virginmedia.com> wrote:
> 
>> On 10 Aug 2017, at 15:15, Alastair Houghton <alast...@alastairs-place.net> 
>> wrote:
>> 
>> On 10 Aug 2017, at 15:09, Charles Srstka <cocoa...@charlessoft.com> wrote:
>>> 
>>> 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.
>> 
>> Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
>> that case.
> 
> Are you sure?

Yes, I’m sure.  At the call site, ARC causes the compiler to emit a call to 
objc_retainAutoreleasedReturnValue() or 
objc_unsafeClaimAutoreleasedReturnValue(), while in the method itself, ARC will 
use objc_autoreleaseReturnValue() or objc_retainAutoreleaseReturnValue().  The 
latter looks at the code for the call site and, assuming it matches, it will 
*not* do the autorelease and will set a flag that causes 
objc_retainAutoreleasedReturnValue() to eliminate the retain.

> We had a discussion about autorelease pools recently, and it seems that 
> they’re still used by Cocoa APIs (to support ARC and non-ARC code).

Yes, autorelease pools still exist and are still used.  Not all code uses ARC, 
and for the above optimisation to happen, the code needs to use the functions 
mentioned, which will only happen if either (a) it’s compiled with ARC, or (b) 
those calls are used explicitly.  You can see the code for this in the 
Objective-C runtime code, https://opensource.apple.com/source/objc4/objc4-709/runtime/objc-object.h.auto.html>
 (search for SUPPORT_RETURN_AUTORELEASE).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 15:09, Charles Srstka  wrote:
> 
> 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.

Not with ARC they don’t.  The ARC logic circumvents the autorelease pool in 
that case.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 14:57, gerti-cocoa...@bitart.com wrote:
> 
> On Aug 10, 2017, at 02:18, Alastair Houghton <alast...@alastairs-place.net> 
> 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.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is "-init" really needed?

[Alastair Houghton]

On 10 Aug 2017, at 00:28, Doug Hill  wrote:
> 
>> - Performance - it incurs an extra message send (which would have been an 
>> issue back in the day)
> 
> +new requires no extra message. It's just a shorthand for [[SomeClassname 
> alloc] init]

Er, yes it does.  It sends a +new message to the class object, which, in turn, 
sends -alloc and -init messages.  So that’s three messages rather than two.  
It’s no big deal on current machines, but it would have been back on the old 
68K boxes.  It isn’t just syntax.

>> - Clarity - [[… alloc] init] shows clearly that it’s a two step operation 
>> (some classes support being *re*-initialized, so you can call initialisers 
>> more than once; other classes don’t actually need initialising)
> 
> Some say that it's far more confusing and hard to read the alloc/init syntax.

:-D Some people say all kinds of things.  Anyway, you’ve misunderstood my list 
as *my* arguments.  I don’t necessarily agree with all of them - I was just 
pondering why it might have been discouraged.

>> - If +new was the way to go, you’d need variants of +new for each variant of 
>> -init (or you have to use [[… alloc] init] anyway)
> 
> There has never been an issue with this. +new saves you some typing for one 
> syntax but has no impact on anything else.

Except it isn’t just syntax, and having +new but then e.g. +stringWithFormat 
while not having +newWithFormat: makes little sense.

>> - The fact that convenience constructors were often written naming the 
>> object, e.g. [NSString stringWithFormat:…], [NSArray array].  +new would 
>> duplicate that, but isn’t as nice to read or look at.  OK, +new doesn’t 
>> autorelease, but still.
> 
> With ARC, autorelease behavior is essentially hidden from the developer and 
> doesn't really matter any more.

Agreed.  But I wasn’t talking about a time in which ARC even existed.  I was 
trying to suggest reasons why it might have been discouraged in the past.

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).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is "-init" really needed?

[Alastair Houghton]

On 8 Aug 2017, at 17:38, Doug Hill  wrote:
> 
> As others have mentioned, I too have never seen any evidence or statements 
> from Apple that discourages +new or -init.

I suspect it was ObjC programmers themselves rather than Apple/NeXT that 
discouraged it.  As for why, well I can imagine a few reasons:

- Performance - it incurs an extra message send (which would have been an issue 
back in the day)

- Clarity - [[… alloc] init] shows clearly that it’s a two step operation (some 
classes support being *re*-initialized, so you can call initialisers more than 
once; other classes don’t actually need initialising)

- If +new was the way to go, you’d need variants of +new for each variant of 
-init (or you have to use [[… alloc] init] anyway)

- The fact that convenience constructors were often written naming the object, 
e.g. [NSString stringWithFormat:…], [NSArray array].  +new would duplicate 
that, but isn’t as nice to read or look at.  OK, +new doesn’t autorelease, but 
still.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Best practice with NSProgressIndicator

[Alastair Houghton]

On 28 Jul 2017, at 16:57, Mark Allan  wrote:
> 
> I'm wondering if anyone has any thoughts about or links to best practices 
> when using determinate NSProgressIndicators.

[snip]

> I'm debating doing it with an NSTimer firing every second, but wondered if 
> anyone had any other suggestions?

I’d advise you to do just that - use an NSTimer.  You could fire it faster than 
once a second, mind; 10Hz is perfectly reasonable, for instance.  I’m not sure 
exactly how often the progress indicator is redrawn by the system (but it’s 
drawn on a background thread, so if you wanted it’d probably be quite easy to 
check), but it’s unlikely to be faster than 60Hz (IIRC the macOS will throttle 
applications that try to do normal drawing - as opposed to OpenGL - faster than 
that), so it’s probably not worth bothering updating faster than that, *even 
if* you want it to be as smooth and responsive as possible.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Who owns a child view controller?

[Alastair Houghton]

On 14 Jul 2017, at 12:03, Jeremy Hughes  wrote:
> 
>> On 13 Jul 2017, at 20:29, Alex Zavatone  wrote:
>> 
>> One thing that I had to learn was to break my expectations of when a view 
>> controller (one that is tied to a navigationController) is deallocated.
> 
> I’m not sure that view controllers are special. My understanding is that 
> objects that are instantiated from a nib are not (usually or ever?) 
> deallocated

Strictly, it depends which method you used to load the nib file.  The older 
(and IIRC deprecated?) methods used to load the top-level objects in a nib with 
a non-zero retain count, which meant that they’d survive unless you explicitly 
-release them (retain cycles notwithstanding), in spite of the fact that you 
usually only have a reference to them if you’ve wired up an IBOutlet.  The 
newer methods don’t do that - instead, they pass out an NSArray containing 
references to all of the top-level objects; any objects you don’t hold on to 
directly (either by retaining the array or by retaining specific top level 
objects) will be destroyed, either by ARC or via the surrounding autorelease 
pool.

Both methods, strictly speaking, follow “normal” memory rules... which makes 
more sense mainly depends on your view of what a nib file is.  If you regard 
the objects in the nib file as actual instances, then it makes sense that 
they’d have a non-zero retain count - after all, they’re in the nib file, 
right?  If, on the other hand, you think of the nib loading system as 
*creating* objects based on a nib file, the newer way makes more sense. The 
newer approach also, I suspect, plays nicer with ARC and makes it less likely 
you’ll accidentally leak objects from nibs you load.

> In addition to autorelease pools there could be other behind-the-scenes 
> mechanisms (caches etc.) that have retain counts.

Indeed, and you might also find that some objects are singletons behind the 
scenes, so could end up with quite unexpected retain counts.  For instance, 
there’s little point in having thousands of empty NSString instances, or 
thousands of NSNumber instances containing 0 or 1.  (I haven’t checked to what 
extent this happens, but I imagine it does.)

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Increasing stack size of NSDocument's open file thread

[Alastair Houghton]

On 6 Jul 2017, at 16:33, Graham Cox  wrote:
> 
> I appreciate your answer, and I realise there’s no API that could set the 
> stack size after the thread is created.
> 
> But presumably the stack size of the thread is set somewhere as a parameter 
> to the thread when it’s created - certainly if I create a thread myself it’s 
> one of the attributes. So the question is is there a way to set up a value 
> that NSDocumentController will use when opening a file? The default stack 
> size seems very small, considering that dearchiving can be quite recursive in 
> nature.

Disassembling it, it looks to me as if NSDocumentController uses GCD, and I 
don’t think there’s any way to set the stack size for threads created by GCD 
(correct me if I’m wrong).  I imagine this used to be an ever bigger problem in 
the past - IIRC when Mac OS X originally shipped, threads other than the main 
thread had *very* small stacks by default.

> I understand the hack you posted, but there’s no way I’m going there, sorry ;)

:-D  Not surprised.  It may well be the only way without rewriting the code to 
not use recursion, however.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Increasing stack size of NSDocument's open file thread

[Alastair Houghton]

On 6 Jul 2017, at 06:57, Graham Cox  wrote:
> 
> I’m wondering if there’s a way to increase the stack size of the thread that 
> opens my NSDocument in the background.

There’s no way an API could exist that did that - in general it’d have to copy 
the entire existing stack to a new location, then update a load of pointers 
that it has no obvious way to find (otherwise the moment you return, everything 
will go wildly wrong).

*However*, within a function that you control, you *can* do the following:

1. Allocate a block of read-write non-executable memory (using e.g. mmap()).
2. Set the stack pointer to point at the end of that block.
3. Push the old stack pointer value.
4. Do whatever work you need to do that requires a larger stack.
5. Pop the old stack pointer value into the stack pointer.
6. Release the memory.

Now, writing such a function in C, C++ or Objective-C is, well, going to rely 
on undefined behaviour, and the compiler could break your code at any time.  
The safest way to do this is to write a call-with-new-stack function in 
assembly language, something like (for x86-64)

; WRITTEN IN MAIL OTOH - NOT GUARANTEED TO BE CORRECT!
;
; Arguments: rdi - argument for function
;rsi - function to call
;rdx - new stack pointer
;
_call_with_new_stack:
movq  %rsp, %r8; Remember the old stack pointer
movq  %rdx, %rsp   ; Install the new stack pointer
pushq %r8  ; Push the old stack pointer to the new stack
jsr   (%rsi)   ; Jump to the function (argument is already in rdi)
popq  %rsp ; Pop the old stack pointer value
ret; Return

Which in C you’d declare as

  uintptr_t call_with_new_stack(uintptr_t arg, uintptr_t (*fn)(uintptr_t arg), 
void *new_stack_top);

then you can call any function you wish with a new stack pointer.  Calling 
functions that way *should* be safe for any compiler I can think of; there’s no 
way it could make assumptions about the behaviour of the function 
call_with_new_stack().

Note also that on x86-64, the stack must be aligned on a 16-byte boundary.  I’m 
not sure OTOH what the default stack alignment is for ARM; if this needs to be 
portable you’ll have to look that up, and you’ll need to write an ARM 
equivalent of the above routine also.

> (The reason is that sometimes my documents can get very recursive during 
> dearchiving - occasionally extremely large ones can hit the stack limit. 
> Rather than redesign the scheme to be flatter, simply increasing the stack 
> limit would probably get me out of this on the rare occasion it bites. After 
> dearchiving, the object graph is flat, so the stack limit increase only needs 
> to be temporary during dearchiving on the background thread).

Removing recursion might actually be a better idea.  It’ll certainly be 
*cleaner* and won’t be processor specific at all.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is cloning the same as copying in APFS?

[Alastair Houghton]

On 27 Jun 2017, at 22:45, Rick Mann  wrote:
> 
> Agreed. Thanks for the code, and for showing the other techniques. In my 
> case, I still have to support HFS+, and I want to do that with hard links. I 
> wish there was an API to clone-or-hardlink, but I can do that.

Perhaps worth emphasising here, since you mention hard links, that the 
difference between hard links and clones is that clones are copy-on-write.  
i.e. if you hard link a file, and then change the data, *all of the linked 
copies will change too*.

I’m sure that’s not an issue in your application, but if someone later happens 
across this thread and thinks “What a great idea!”, mentioning that the two are 
only equivalent for the read-only case might avoid some pain.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Is cloning the same as copying in APFS?

[Alastair Houghton]

On 27 Jun 2017, at 06:28, Jens Alfke  wrote:
> 
>> On Jun 26, 2017, at 7:38 PM, Rick Mann  wrote:
>> 
>> But there's actually a POSIX "clone" API, and so I wonder if a copy is 
>> different from a clone.
> 
> The low level file copying API that I’m aware of is , which is 
> Apple specific. It has options for doing copy-on-write.
> I don’t know if NSFileManager’s copy method clones files. I would assume that 
> it does, on APFS.

That certainly seemed to be what the WWDC video suggested.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: file encription/decriptoin iOS

[Alastair Houghton]

On 27 Jun 2017, at 03:25, Sandor Szatmari  wrote:
> 
> 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’.

There’s no need to encrypt the note for that, though - just storing a password 
hash would be sufficient.

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

That’s a risk, albeit a small one, and you have control over that risk (you can 
set both the passcode and also the time the phone remains unlocked for).  Yes, 
cryptography could mitigate that risk, though as I said in my previous post, 
you’d need to use a KDF, so effectively you’d have a separate passphrase for 
your data.  If someone can force you to unlock your phone, they can also force 
you to unlock your cryptographic store.

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

There are certainly reasonable use-cases (apps like 1Password spring to mind) 
where doing your own crypto might make sense.

My guess, though, is that the OP was asked to implement a system for 
distributing paid-for PDFs such that the user couldn’t extract them from the 
device - essentially a DRM system for PDFs from a particular source.  I’d 
generally try to dissuade people from such a scheme - it makes little sense 
displaying the information to a user and then refusing to allow them to copy it 
(except via screenshots or possibly copy and paste), but the fact remains that 
the first step in implementing such a system is to carefully define what the 
system is, who the trusted and untrusted parties are, and what kind of attacks 
you’re trying to protect against.  *If* cryptography is required at that point, 
it needs to be done by someone who is sufficiently competent that they aren’t 
going to render the exercise pointless.  You can certainly learn what you need 
to be competent in this area; it isn’t, contrary to what some might claim, some 
kind of high voodoo only available to carefully selected initiates.  But it 
*is* complicated *and* generally speaking, poorly documented, so the risk of 
mistakes is high - you probably shouldn’t learn on a shipping product.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: file encription/decriptoin iOS

[Alastair Houghton]

On 24 Jun 2017, at 21:12, yu...@aim.com wrote:
> 
> I hope i am at the right place to ask for help on file encryption/decryption 
> for iOS.
> 
> I need to encrypt a pdf file during download and to decrypt it for display 
> later on.  Can i get some pointers about implementing the 
> decryption/encryption part ?  or if there is any existing 
> decryption/encryption package or code i can use ?

Step back a bit; what’s the use-case for this?  If you’re worried about 
protecting data at rest, iOS already does that automatically; see
  


Applications can’t directly access other applications’ files anyway, so the 
only remaining use-case would appear to be preventing someone else with 
physical access to the device *and* the ability to unlock it from downloading 
the data.  Additionally, if you use a crypto layer on top of that, you’re going 
to have a problem, namely where to store the key.  The only way you’re going to 
be *more* secure is if you derive the key from a passphrase using a Key 
Derivation Function (PBKDF2, for instance) and then ask the user for that every 
time - but it isn’t clear to me what the advantage of doing that is over 
getting the user to use a secure passcode for their device in the first place.

If you *really* must do this, well, it’s quite complicated.  You’ll want to use 
CommonCrypto (see “apropos 3cc” or “man CC_crypto” in a Terminal window) with 
AES, which is a block cipher, so you’ll need padding (see 
), which you’ll need to 
implement carefully and check when you’re reading the file - any errors with 
the padding should be a hard fail.  If you just want to read the entire file in 
as one blob, you could use the default mode (CBC mode), but if you need random 
access for any reason you’ll need to build an implementation of CTR mode on top 
of CommonCrypto’s ECB mode (see 
).  You’ll also 
need to generate an IV (Initialization Vector) or nonce using a suitable random 
number source (/dev/random or SecRandomCopyBytes() are appropriate choices 
here; rand() or random() are not, nor is some dodgy function you came up with 
yourself, or *any* non-cryptographic RNG you looked up in a textbook); DO NOT 
USE ALL ZEROES FOR YOUR IV.  You’ll need to store the IV with the file (e.g. as 
the first chunk of data).  You’ll also need a nonce for your KDF, which also 
needs to be secure and also needs to be stored somewhere.  You’ll need to think 
about whether there’s a single passphrase that unlocks all the data in your 
application (in which case you then need to consider whether using a single AES 
key for everything is good enough, or whether you want per-file AES keys, and 
in *that* case you need to know either (a) how you’re going to derive all those 
keys from the one passphrase, or (b) if you’re going to store them encrypted 
with a key derived from the passphrase).  There’s a whole heap of complexity to 
think about here, and some of the answers may depend on exactly how your 
application works (e.g. whether an attacker could conceivably supply a PDF to 
it for encryption, or whether you can guarantee somehow - e.g. using SSL 
certificate pinning - that the PDFs only come from a trustworthy source).  This 
is tricky stuff and given the question you asked, I’m honestly not certain 
you’re the right person to be implementing it --- I’d tend to recommend that 
you find someone with expertise in this area to help you, or at least give you 
some advice --- and you’ll need to start by carefully examining the entire 
system you’re building and looking to see what threats you’re trying to protect 
against.

Personally, I strongly suspect that all of the above is unnecessary and that 
you can just let iOS protect your data for you.  On the plus side, you’re 
unlikely to make your data any less secure than it is by default, and the 
default level of security is, I suspect, already sufficient for your needs.  On 
the minus side, if you make a mistake anywhere in all of this, it might render 
the entire exercise totally pointless (i.e. you’ll have written an obfuscation 
layer, rather than something that genuinely provides extra security); in the 
very worst case, you might actually enable an attacker to cause your code to do 
something unexpected, though iOS does do various things (ASLR, non-executable 
memory) that make that harder.

TL;DR: You probably don’t need to do this; what iOS does already is probably 
good enough for you.  If you really *do* need to do this, given the question 
you asked, you should consider hiring an expert to help you to understand the 
threat model, to help you make appropriate choices, and perhaps even to 
implement the encryption 

Re: How to create an animated gif?

[Alastair Houghton]

On 21 Jun 2017, at 16:09, Jens Alfke  wrote:
> 
> On Jun 20, 2017, at 11:17 PM, Gerriet M. Denkmann  wrote:
>> 
>> Assume that I have two NSImages, both with the same size, how can I create 
>> an animated gif which alternates between these two images?
> 
> You might have to use a 3rd party image library to do that; I’ve never heard 
> of animated-GIF (GIF89) encoding being in Mac frameworks.

Can’t you use ImageIO to do that?  See



ImageIO definitely supports GIF, and it also supports multi-image file formats; 
there’s an example of creating an APNG, but I imagine it’ll work for animated 
GIF just as well.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: NSTimer or what?

[Alastair Houghton]

On 20 Jun 2017, at 04:04, Gerriet M. Denkmann  wrote:
> 
> macOS 11+
> 
> Some Cocoa app which has to do:
> 1. something a few seconds later

The main issue here isn’t energy use so much as whether you want to be able to 
cancel the operation.  If you need to be able to cancel it before it fires, 
you’ll want to use NSTimer or a CFRunLoopTimer.  Energy wise, the fact this is 
to happen “a few seconds later” would seem to imply that it isn’t going to 
happen often, so it’s probably irrelevant and which you choose is a matter of 
taste.

> 2. some other thing repeatedly about every 0.1 second.

Personally, I’d choose an API that directly supports repeating timers, so I’d 
prefer NSTimer or CFRunLoopTimer over the other options, all else being equal.  
I’d imagine that’s most likely to result in the lowest energy usage (repeated 
use of one-shot timers, it seems to me, is much more likely to result in 
dynamic memory allocation happening every time the timer fires, and it’s more 
complicated in your code because you’ll have to manage your next fire time).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Repository of older (outdated) PDF Guides?

[Alastair Houghton]

On 19 May 2017, at 15:17, Richard Charles  wrote:
> 
>> Honestly. The fact that Apple now actively prevents us from having access to 
>> such lovely, useful, EASY TO UNDERSTAND AND SEARCH documents like these is 
>> just so disappointing.
> 
> Very well said.

The sad part is that there’s still a lot of great documentation there; it’s 
just been made much harder to use ever since it was overhauled to add the 
Swift-centric version.  My particular pet peeve is if you look up a constant - 
in the older docs, it used to take you to a list of related constants, which 
often had references to the functions they were used with in the description at 
the end.  Now you just get a (typically) one line description of that constant, 
with no useful links to anything else.

IMO whoever at Apple is responsible for documentation has dropped the ball.  
Let’s hope they can turn it around.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Does file-mapping a memory allocation work around RAM limits?

[Alastair Houghton]

To answer the OP’s original question, I’m not sure about the exact rules Apple 
is using on iOS, but I’d expect the memory limit to apply to *private* memory, 
namely that allocated using malloc() et al, plus dirty pages mapped with 
mmap()’s MAP_PRIVATE flag.  Read-only and shared mappings that are backed by a 
file or by swap wouldn’t count; nor would non-dirty pages mapped with 
MAP_PRIVATE, because in all of those cases the data can be purged from RAM and 
retrieved from storage (disk or Flash) when needed.

On 4 May 2017, at 07:27, Doug Hill  wrote:
> 
> The limits of mmap should be the limits of the file system. Well, technically 
> it’s limited by the size_t parameter which I guess is OS specific. But these 
> days it should be what the VFS can handle.

It’s limited by:

- The length of files allowed by the filesystem
- Available, suitably aligned, contiguous address space in the virtual memory 
map
- Available space in the page table (usually this shouldn’t be an issue on 
normal operating systems)

size_t is generally specified to be the same width as a pointer on the target 
architecture - otherwise it would unnecessarily restrict all kinds of things.  
Strictly speaking, the C standard only requires that size_t be at least 16 bits 
in size (and says it’s the type of the result of the sizeof operator), but in 
practice on a 32-bit machine it’ll be 32-bit, and on a 64-bit machine it’ll be 
64-bit.  AFAIK the only time things might get complicated is if you were 
dealing with hairy old segmented x86 code, which you aren’t.

Note that the filesystem may well allow files larger than the address space, 
particularly on 32-bit systems.  That isn’t necessarily a problem - you cannot, 
after all, mmap() more of the file than you have address space, and if you are 
particularly set on using mmap() even in that case you can use the “offset” 
argument to choose which part of the data you’re mapping in.

On a 64-bit system, mmap() is a reasonable thing to do even for large files.  
On a 32-bit system, I’d steer clear of using mmap() for anything large; it 
still has its uses, but you can run out of address space too easily.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Current, preferred way to add help to your Mac app?

[Alastair Houghton]

On 9 Apr 2017, at 23:00, Richard Charles <rcharles...@gmail.com> wrote:
> 
>> On Apr 9, 2017, at 11:55 AM, Alastair Houghton 
>> <alast...@alastairs-place.net> wrote:
>> 
>> The documentation isn’t exactly great (at least, the last time I had to use 
>> it).  You might find the following article interesting/useful:
>> 
>> <https://alastairs-place.net/blog/2015/01/14/apple-help-in-2015/>
> 
> The help file for iDefrag 5 is very impressive! I really like the clarity of 
> expression, fonts and font sizes, layout and style of presentation, etc. I 
> think this is a great example of a well written and executed help file. So it 
> looks like the Sphinx documentation generator worked well.

:-)  I can’t take too much credit for the layout - I used a modified version of 
the ReadTheDocs theme (http://readthedocs.org).  The original version is here: 
<https://github.com/rtfd/sphinx_rtd_theme>.

> I have only one minor issue. The topics and content are in the same scroll 
> view rather than being in two seperate scroll views. Is this something that 
> Sphinx can or can not handle or is it unrelated to Sphinx?

It isn’t really related to Sphinx; you can do what you ask for either using CSS 
(setting the height of the topic list to match the window and enabling the 
vertical scroll bar for overflow), or using frames (this was the traditional 
approach, back in the day).

Sphinx will just generate the files you tell it to, so you’ve got fairly good 
control over exactly how your help file ends up.  It’s also (usefully) able to 
generate plain HTML or PDF output or similar from the same sources.  FWIW, I 
chose Sphinx to do the help for iDefrag 5 because I’d already used it with some 
Python projects and liked the way it worked, but there are all kinds of other 
tools you *could* use to do something similar; anything that can generate a set 
of static HTML files will work (so any static site generator or documentation 
generation tool that you like) and from there it’s just a matter of setting it 
up to generate the kind of output you want.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Current, preferred way to add help to your Mac app?

[Alastair Houghton]

On 9 Apr 2017, at 10:31, J.E. Schotsman  wrote:
> 
> On 08 Apr 2017, at 21:00,Jeff Szuhay wrote:
> 
>> Nevermind. I found the “Apple Help Programming Guide.”
> 
> Good luck. That’s a weird mix of obsolete and newer API descriptions. The 
> newer ones don’t work for me.
> openHelpAnchor:inBook: fails to open help pages for me. Or maybe the Help 
> Indexer is just broken.
> I’ve submitted a bug report months ago. No reaction so far.

The documentation isn’t exactly great (at least, the last time I had to use 
it).  You might find the following article interesting/useful:

  

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: disable group of controls

[Alastair Houghton]

On 5 Apr 2017, at 12:05, J.E. Schotsman  wrote:
> 
>> On 05 Apr 2017, at 11:48, Jack Carbaugh  wrote:
>> 
>> Get a list of the controls then loop through it, setting each enabled 
>> property to false. The container holding them will hold a reference to them
> 
> That way you lose the latent enabled state.
> When the embedder is set to disabled some of the sub controls may already be 
> disabled.

As a general principle, the UI shouldn’t be being used to store things; it 
should instead reflect the internal state of your program.  Put another way, 
*your code* should keep track of which controls are supposed to be enabled at 
any point, and you shouldn’t rely on the user interface layer to store that 
information for you.  I know *some* Cocoa controls can be used to store state, 
but IMO that’s a bad design pattern, not least because it means the UI could 
diverge from your program’s internal state; and it won’t work for all controls 
in any case as some of them fetch data from your code on the fly (e.g. 
NSTableView or NSOutlineView).

Whether you use bindings or whether you explicitly update your UI is up to you. 
 Neither is hard.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: disable group of controls

[Alastair Houghton]

On 5 Apr 2017, at 10:45, J.E. Schotsman  wrote:
> 
> On 03 Apr 2017, at 21:00, J.E. Schotsman wrote:
>> 
>> What is the Cocoa way of enabling/disabling a group of controls?
>> In Carbon I used to use a user pane for that.
>> I thought I would try an NSBox but then I realized it is not a control.
> 
> Nobody?
> I thought this would be a simple and solved problem.
> I tried subclassing MyEmbedder:NSControl and embedding in a custom view of 
> class MyEmbedder.
> Alas, setting the isEnabled property of the custom view has no effect on the 
> embedded controls.
> What am I missing?

I started writing a reply, then decided I was too busy and others would 
respond.  Since they haven’t, here’s my two cents:

1. AFAIK there isn’t a mechanism to disable all controls in a given subview.  
You could write code to do this easily enough, e.g.

  for (NSView *child in [groupView subviews]) {
if ([child respondsToSelector:@selector(setEnabled:)])
  [child setEnabled:NO];
  }

  or you can bind all the Enable properties in the UI editor to the same value 
using bindings.

2. For some types of control, for instance toolbar buttons and menus, there’s a 
validation mechanism; you can just implement -validateUserInterfaceItem: and 
return YES or NO as appropriate.

3. It’s possible, at least in theory, to make your own controls conform to 
NSValidatedUserInterfaceItem, if that seems appropriate.  (This is kind of a 
gold-plated solution, and only applies in any case to controls with a target.)  
You’d probably want to start by reading about user interface validation:



Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Normalisation of filenames

[Alastair Houghton]

On 5 Apr 2017, at 09:09, Jean-Daniel  wrote:
> 
>> Le 5 avr. 2017 à 07:49, Gerriet M. Denkmann  a écrit :
>> 
>> 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.

IIRC this happened because HFS+ predates the stability rule in Unicode; as a 
result, Apple had to fix the normalisation form it used in HFS+, and 
subsequently Unicode diverged from that *before* the stability rule came into 
effect.

A new filesystem with the same problem could probably rely on the normalisation 
stability rule to avoid this problem.  It would probably need to indicate in 
the filesystem header the highest version of Unicode that has been used, mind.

>> 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).

The problem is that when normalisation *wasn’t* stable, it caused problems 
whenever any changes were made.  So it was “stabilised”, but that meant 
accepting that anything that wasn’t ideal at that point had to remain that way.

The way this is handled in URLs is perhaps informative; IDNA actively prohibits 
some code points, and then browsers should really also follow the rules in UTS 
#39 to detect “confusables”.  Whether that helps in your specific example case 
I don’t know.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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

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

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

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

Re: Can't use +initialize, now what?

[Alastair Houghton]

On 29 Mar 2017, at 21:17, Jens Alfke  wrote:
> 
>> On Mar 29, 2017, at 10:52 AM, Quincey Morris 
>>  wrote:
>> 
>> If willFinishLaunching is not early enough, then you can put code in your 
>> “main” function, but I don’t know how feasible that is in Swift.
> 
> Another trick to run stuff earlier at launch is to add an -awakeFromNib 
> method to your app delegate, or any other object in your main nib. This can 
> be dangerous, though, because you can’t count on any other object in the nib 
> already being awoken, since the -awakeFromNib methods are called in random 
> order. (I once had a very hard to debug intermittent crash due to an ordering 
> dependency between two -awakeFromNib methods.)

It’s also important to note that your -awakeFromNib method may be invoked more 
than once, in particular if the object is the owner of a nib file, *and* it can 
sometimes be invoked at surprising moments (for instance, a recent auto layout 
problem in iDefrag turned out to be caused by the initial layout pass 
triggering -outlineView:viewForTableColumn:item:, which in turn caused a nib to 
load for the view, triggering an -awakeFromNib call *before the “normal” 
-awakeFromNib for the object in question* and worse, that -awakeFromNib was 
called *during layout*, and did things that triggered re-layout; the resulting 
layout glitch was quite hard to track down).  The upshot is that it isn’t 
necessarily even sufficient to ensure that your -awakeFromNib remembers whether 
you’ve initialised your object; you need to be very careful about what can 
trigger it and under what circumstance.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 23 Mar 2017, at 17:57, Ed Wynne  wrote:
> 
>> Shouldn’t the VFS layer actually be doing this? It is part of its whole 
>> raison d’être, no? Just have -[NSURL fileSystemRepresentation] normalize 
>> things according to the correct Unicode rules, and let the VFS layer 
>> translate that to HFS+’s normalization style when dealing with HFS+.
> 
> Yes, this.
> 
> Having the conversion only available up in the Cocoa layer is an incredibly 
> poor choice. It effectively means nothing at the BSD layer will be able to 
> properly normalize file names. Having it at the VFS layer is the most sane 
> option, even with the problems that causes.

It can’t really take place at the VFS layer, because the appropriate 
normalisation is filesystem specific - some filesystems don’t normalise, others 
do, and the exact rules differ.

It *could* take place in the filesystem driver, as happens currently for HFS+.  
The problem with that is that while your software will work fine on HFS+, it 
might break if given a different filesystem to run on, which is kind of what 
this thread is all about, no?  (And we already had similar problems with 
case-sensitive HFS+ too, which usually breaks certain big brand-name 
applications software.)  I have to say I’m generally in favour of APFS 
normalising Unicode names, but I can understand that there are reasons the APFS 
team might have decided not to (it’s really up to them to elucidate what those 
reasons were).

This is a rather horrible area of filesystem work, made worse by the fact that 
many historic filesystems don’t even bother storing what character encoding was 
used.  Indeed, on such systems it’s even possible that users will use different 
encoding in different directories (:-()

Clearly, encoding detailed knowledge of appropriate normalisation on a 
per-filesystem basis in end-user applications is not a sensible approach here.  
Apple suggesting that we normalise filenames before passing them to the BSD 
layer wouldn’t be the end of the world, but it might result in some 
applications not being able to cope with some otherwise valid filenames because 
the name on disk differs from the chosen normalisation.

Another option might be to add some flags to the BSD open() API (for instance, 
O_UNICODE and O_CASEFOLD) that cause it to use a Unicode-aware comparison 
routine inside the filesystem implementation, the idea being that it will open 
a file with the exact name passed if it exists, or, if that file doesn’t exist, 
it will enumerate the containing directory looking for one that matches.  
Sadly, this enumeration would need to be recursive (since the directory name 
might have the same problem).  The Foundation framework could then use the new 
flags to obtain reasonable behaviour.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 22 Mar 2017, at 18:00, David Duncan  wrote:
> 
> So there was another explanation posted on the bug that I’m not certain you 
> got, but which I think may explain.
> 
> Basically the concept is that since APFS doesn’t normalize file names, if you 
> store file names in some other storage (say in your preferences) then what 
> could happen is this:
> 
> 10.2: File is saved with a file name handed to the file system in NFC form. 
> File system converts the file name to NFD. You store it as NFC.
> 10.3: File system is converted to APFS, and the file name is NFD. You try to 
> look up the file as NFC, and it fails.

This is going to cause problems, though, when things migrate from HFS+ to APFS, 
because the HFS normalisation *isn’t* a standard one.  In particular, it 
certainly *isn’t* NFD for the current version of Unicode.

The only obvious solution for that would be to have the HFS+ to APFS migration 
tool *re-normalise* the filenames (maybe it does?), but that’s bound to break 
things in the (presumably quite common) case where the filename stored in e.g. 
a plist was originally obtained from the filesystem.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 22 Mar 2017, at 19:13, Chris Ridd <chrisr...@mac.com> wrote:
> 
>> On 22 Mar 2017, at 09:05, Alastair Houghton <alast...@alastairs-place.net> 
>> wrote:
>> 
>> In the context of filesystems (and specifically filenames), the phrases “bag 
>> of bytes” and “bunch of bytes” have a fairly specific meaning.  The point is 
>> that the filesystem doesn’t inspect the bytes it’s given, and doesn’t care 
>> what they represent (about the only exception is that it probably doesn’t 
>> support embedded NULs).  It isn’t suggesting that the names are treated as 
>> an unordered set of bytes (that’d just be silly).  It’s just expressing the 
>> fact that the filesystem doesn’t care what they are - it may compare them, 
>> and if it does so, it will use binary ordering (not some other collation 
>> sequence) and won’t worry about things like case or encoding at all.
> 
> That doesn’t sound sensible at all. It means you can create a filename with a 
> byte sequence that isn’t valid UTF-8 and which likely then cannot be accessed 
> by MacOS/iOS processes.

That isn’t possible on macOS - there’s a percent escaping mechanism built in to 
the kernel to prevent this problem.

> It means that you could create multiple files with the “same" name, and that 
> doesn’t sound like a win either. e.g. Aandi’s examples of LATIN SMALL LETTER 
> E (U+0065)
> COMBINING ACUTE ACCENT (U+0301) and LATIN SMALL LETTER E WITH ACUTE (U+00E9)

Yes, it does.

> How can a “next gen” filesystem avoid using Unicode rules when handling 
> filenames?

Well, if I had designed it, it wouldn’t.  But I didn’t.

To be fair, I can see arguments in favour of the bunch of bytes approach; the 
existing approach has created a problem in HFS+, in that the normalisation is 
essentially fixed for all time, and doesn’t correspond to the current version 
of Unicode.  It’s actually worse than it might be, because (IIRC) they fixed 
the normalisation *before* Unicode adopted a stability policy for 
normalisation...

But if the filesystem (or kernel) isn’t doing it, then IMO the Cocoa frameworks 
certainly should.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 21 Mar 2017, at 20:49, Quincey Morris  
wrote:
> 
> On Mar 20, 2017, at 14:23 , davel...@mac.com wrote:
>> 
>> "iOS HFS Normalized UNICODE names , APFS now treats all file[ name]s as a 
>> bag of bytes on iOS . We are requesting that Applications developers call 
>> the correct Normalization routines to make sure the file name contains the 
>> correct representation."
> 
> I’ve been letting this simmer for a couple of days now, and I’ve come to the 
> conclusion that it’s — sincere apologies to the unnamed Apple engineer who 
> wrote it — as dumb as dirt.
> 
> — It’s not a "bag of bytes”, because bags of stuff are generally understood 
> as unordered sets, and I doubt that’s what’s intended. It has to be a 
> sequence of bytes.

In the context of filesystems (and specifically filenames), the phrases “bag of 
bytes” and “bunch of bytes” have a fairly specific meaning.  The point is that 
the filesystem doesn’t inspect the bytes it’s given, and doesn’t care what they 
represent (about the only exception is that it probably doesn’t support 
embedded NULs).  It isn’t suggesting that the names are treated as an unordered 
set of bytes (that’d just be silly).  It’s just expressing the fact that the 
filesystem doesn’t care what they are - it may compare them, and if it does so, 
it will use binary ordering (not some other collation sequence) and won’t worry 
about things like case or encoding at all.

> — It’s not just a string, it has to be a string in a known encoding. 
> Otherwise, how could you ever mount an external drive on a different 
> computer? The encoding has to be pre-specified for APFS, or it has to be 
> stored in metadata on each volume.

Agreed, that’s where the “bunch of bytes” approach falls down.

> — It’s not just going to be a string of known encoding, it’s going to be 
> Unicode. That’s going to be true even if the fact is specified in volume 
> metadata and it’s theoretically possible to create APFS volumes with 
> non-Unicode file names. Anything other than Unicode would, at this point, be 
> a crime against humanity.

If I’d designed APFS, it probably would use Unicode names (and it’d store the 
version of Unicode it used in the filesystem header, to avoid having to 
hard-code it).

But I didn’t design it - Dominic Giampaolo and his team did - and we still 
don’t have that much information about how APFS works.  I’m sure they had their 
reasons for whatever decision they’ve made here.

> Is *that* the bottom line? I doubt it. I don’t believe the above quoted 
> statement can be correct. I could believe that normalization is being moved 
> out of the file system code, but it would have to be moved to (e.g.) the 
> Cocoa frameworks, still “downstream” of the file-handling APIs. It can’t go 
> upstream of the public APIs without breaking an API contract that has existed 
> for the 16+ years since OS X 10.0.

This is a tricky area.  The problem with what we have at the moment 
(-fileSystemRepresentation) is that it *assumes* HFS+ semantics.  That isn’t 
always going to be correct for existing non-HFS+ filesystems, let alone in the 
future.  Of course, if you’re using the NSURL or NSString methods, rather than 
calling the BSD or C library APIs yourself, this is all hidden from you anyway 
(you certainly shouldn’t, IMO, be required to do anything unusual at Cocoa 
level - the Foundation framework should just make this all work, rather in the 
same way it presently does for numerous other things).

It’s also complicated by the fact that, unlike on DOS or Windows, UNIX-like 
systems use a unified filesystem - that is, other filesystems are joined on at 
mount points.  Thus you could have a name like

  /Volumes/Foo/Bar/Baz/Blam

where (say) both Foo and Baz are mount points, and the rules about filenames 
could differ markedly, at least in principle; that is, /Volumes/Foo would have 
to conform to HFS+ (or APFS) rules, Bar/Baz to whatever rules govern the 
filesystem mounted at Foo, and Blam to whatever rules govern the filesystem 
mounted at Baz.  And remember, not every filesystem will be using a well known 
encoding - macOS already has code to add and remove percent escapes (I kid you 
not) for this very reason.

I’d like to hear what Dominic has to say (at least what he *can* say) about 
this, since he’s likely in a position to shed some light on it - or at least to 
take on board that we’re worrying about it.  At the very least it’d be nice to 
see some more detail about APFS published somewhere *soon*...

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

This email sent to 

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 21 Mar 2017, at 12:33, Jean-Daniel  wrote:
> 
> 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.

Agreed, IMO the framework should be responsible for Unicode normalisation.  
It’s only at the BSD layer where you *might* be responsible for it yourself, 
but this isn’t about making BSD API calls, right?  It’s the Cocoa API we’re 
dealing with here.

This *should* be abstracted.  If it isn’t, it’s a bug.

(Having vaguely followed this thread for a while, if I had to guess what 
happened here, I’d guess there’s some kind of bug in the HFS+ to APFS upgrade 
routine that’s causing the Unicode filenames from the HFS+ system to get messed 
up somehow.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 7 Mar 2017, at 12:47, Jean-Daniel  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.

--
http://alastairs-place.net


___

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

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

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

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

Re: Unicode filenames with Apple File System and UIManagedDocument

[Alastair Houghton]

On 7 Mar 2017, at 18:00, Jens Alfke  wrote:
> 
> On Mar 7, 2017, at 8:13 AM, davel...@mac.com wrote:
>> 
>>   NSFileManager *fm = [[NSFileManager alloc] init];
>>   const char *data = [name fileSystemRepresentation];
>>   NSString *filename = [fm stringWithFileSystemRepresentation:data 
>> length:strlen(data)];
> 
> This is a no-op, since you’re calling two methods that perform inverse 
> operations — `filename` will end up being identical to `name`.

AFAIK it isn’t a no-op (at least at present).  Right now, I rather suspect 
it’ll lead to decomposition and the replacement of Hangul characters in the 
range U+AC00 through U+D7A3, according to the rules in TN1150.

Unfortunately, because -fileSystemRepresentation doesn’t really know the 
underlying filesystem, this may or may not be appropriate, and I’d expect *in 
future* at some point the above really will be a no-op as a result.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Sometimes all my menus are disabled

[Alastair Houghton]

On 14 Feb 2017, at 22:15, Graham Cox  wrote:
> 
>> On 15 Feb 2017, at 12:39 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> I knew how to use IB on the old PowerPC Mac,
>> but that was 10 years ago.
> 
> Well, it hasn’t changed that much in principle. In fact it’s got a lot better 
> in most respects because it stays in sync with your code and is not a 
> separate app. Some things are worse though, like the pick list for UI 
> elements, which makes you do a lot of scrolling to get to the one you want.

Personally I preferred it as a separate app; the “staying in sync with your 
code” part wasn’t such a huge problem in practice and could probably have been 
fixed without integrating it (which, particularly because it went 
single-window, forces people to use Xcode as their editor).  I also liked 
having the separate window for the nib file structure - the side bar can get 
quite cluttered in more complicated nibs.

But I’m not going to turn this into a critique of Xcode design decisions.

> Now I'm trying to compile this old project on a
>> 10.12 system with the latest Xcode but somehow the project was messed up by
>> Xcode when converting it from the old format to the new one and now it 
>> shows weird issues.
> 
> So it messed up. That’s annoying, but should be fixable by spending half an 
> hour in IB to identify and fix the broken connectins (or whatever).

You will also need to check API behaviour.  Cocoa behaves quite differently in 
some places depending on the system version and Xcode version used to build 
code; I’m not sure if there’s a list of all of these places anywhere - it’d be 
quite useful for this kind of situation.  (Formatters in particular have rather 
different behaviour.)

When I first saw Apple doing this, I thought it was a good idea.  I now think 
otherwise.  It should have based behaviour changes on a separate API level 
setting, which would have meant Xcode could issue warnings when an API level 
stopped being supported so that you’d know what to focus on.  I know we’ve 
managed to ship bugs on a couple of occasions because of API behaviour changes 
that we didn’t appreciate or spot; thankfully these have tended to be cosmetic 
(e.g. percentages were being formatted incorrectly), but it’s still worth 
checking *everything*.

> Of course, I could just dump the old project and start a new one with the
>> latest Xcode, re-creating everything from scratch. But do you really think
>> that is a satisfactory solution?
> 
> It isn’t the ideal solution, but sometimes you are faced with hard choices.
> 
> One problem sounds like you’ve put a lot of interfaces into one nib file, so 
> that’s going to make life harder than necessary,

That isn’t a big problem in practice.  iDefrag and iPartition have quite a few 
things in a single main nib file that would probably be split out into multiple 
nibs in a more modern code base; I’ve had no reason to change that (they don’t 
use window controllers or view controllers, so it just isn’t a problem).

> and another is that you’ve gone against the usual conventions with menu 
> actions and targets, so that’s going to make life harder than necessary.

[snip]

> The obvious thing to me was to get into IB and start figuring out the 
> problem. Instead you ranted about how much of a time sink it was being 
> because IB was different and you’d forgotten how to use it. Not only that but 
> the way your project is organised is unconventional, to say the least. If you 
> prefer to swim upstream, you only have yourself to blame.

To be fair to Andreas, the stream has changed direction somewhat over the 
years, and I’d be lying if I said I’d never found updating projects to be 
compatible with the new version of Xcode I was forced to use because of OS 
compatibility issues was not an annoyance.

(Indeed, the last round of Xcode’s automatic project upgrades caused yet 
another problem, this time with code signing.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: setFontManagerFactory:

[Alastair Houghton]

On 26 Jan 2017, at 19:06, Raglan T. Tiger  wrote:
> 
> According to the docs if one does:
> 
>   [ NSFontManager setFontManagerFactory:[ EFontManager class ] ];
> 
> before the main nib file is loaded and where EFontManager is a subclass of 
> NSFontManager and EFontManager does implement init as its designated 
> initializer.
> 
> My problem is that my init method for EFontManager is never called.

Are you running any other code before your -[NSFontManager 
setFontManagerFactory:] invocation?  Note that “any other code” may include 
e.g. constructor functions from libraries you’re linking with... while I 
wouldn’t expect system libraries to be invoking [NSFontManager 
sharedFontManager] at that point, it’s possible some third-party library does 
that.

I’d try moving it to near the start of your main() function and see if it 
starts working.  If it does, there’s probably some code somewhere that’s asking 
for the font manager early on.

The other thing you could do is, in the debugger, set a breakpoint on 
[NSFontManager sharedFontManager] then start your program and see what the 
backtrace looks like (that will tell you where the first invocation is; you’re 
going to have to ensure that you call -setFontManager: *prior* to that somehow).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: On NSIncrementalStore UUID Uniqueness

[Alastair Houghton]

On 14 Jan 2017, at 10:41, 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?

FYI, you can base a UUID off any identifier you please, so if you have *any* 
stable identifier, you can use that.  The way you do so is:

1. Generate a UUID for your namespace, if there isn’t a standard one.  
(Standard ones exist for domain names, URLs, OIDs and X.500 DNs.  Otherwise 
just generate a version 1 or 4 UUID, as appropriate.)

2. Use that and your identifier to compute an SHA-1 hash.

3. Use the SHA-1 hash to generate a version 5 UUID.

I think you mentioned e-mail as an example; well, if you’re using Core Data to 
hold a mailbox, you could regard the user’s e-mail address as a stable 
identifier for that purpose, in which case you can use that to generate a UUID.

> On 16 Jan 2017, at 01:50, Daryle Walker  wrote:
> 
> If I continue this idea, I’ll stick in a constant UUID and hope Core Data 
> doesn’t really need universally-unique IDs for all potential stores.

It seems not unlikely that Core Data might be upset/confused if for any reason 
you had two separate sets of data open in the same process and the persistent 
store had the same UUID for both.  That might happen if you were doing some 
kind of migration or copy between two of your data files, no?

Personally, if I was going to use Core Data, I’d make my “file" a bundle rather 
than a flat file anyway, which makes it easy to store a UUID (and indeed other 
metadata) in it.  That also has the advantage that any large objects you need 
to save can be referred to by reference from the Core Data store, as opposed to 
being embedded in it, which is likely to be more efficient in almost all cases.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: NSNetServiceBrowser vs. mDNSResponder

[Alastair Houghton]

On 13 Jan 2017, at 09:40, Gerriet M. Denkmann  wrote:
> 
> iOS (10.2) app does:
> 
> SERVICE_TYPE =  1 to 63 ascii chars; no spaces; no ‘.’; no ‘[‘; can use ‘_' 
> or '-'; case insensitive
> Note: I did not find these rules documented anywhere, they are just the 
> result of trial and error.

[snip]

> If SERVICE_TYPE is more than 63 chars, then 
> -[NSNetServiceBrowserDelegate netServiceBrowser:didNotSearch:] will complain 
> with BadArgument.
> 
> Now I see in iOS 10.2 (maybe was there before):
> com.apple.mDNSResponder AllINFO 
> Bad service type in ._GmdEcho890123456._tcp.local. Application protocol name 
> must be underscore plus 1-15 characters. See 
> 
> 
> But it still works.
> 
> So:
> 
> 1. what is the real constraint of SERVICE_TYPE:
> 1a: underscore plus 1-63 characters (NSNetServiceBrowser)
> 1b: underscore plus 1-15 characters (mDNSResponder)
> 
> 2. is this documented anywhere?

The 63 character limit is from the DNS, specifically RFC 1035 section 2.3.1, 
which says:

  Labels must be 63 characters or less.

This applies to each label in a domain name.

The 15 character limit is specific to SRV records and comes from RFC 6763, 
section 7.2, which says:

  The Service Name  may be up to 15 bytes, plus the underscore…

I don’t know if *Apple* has documented these anywhere in its documentation, but 
they are certainly in the relevant RFCs.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: On NSIncrementalStore UUID Uniqueness

[Alastair Houghton]

On 11 Jan 2017, at 00:16, Saagar Jha  wrote:
> 
> Small quibble: UUIDs are not guaranteed to be unique. It's just extremely 
> likely they will be, and they be sufficient for almost all applications, 
> including this one.

If we’re going to be pedantic, properly issued version 1 and 2 UUIDs *are* 
guaranteed to be unique - but that means (a) you have a properly issued MAC 
address that hasn’t been spoofed, and (b) you aren’t generating more than the 
rate limit for the UUID version (this should be prevented by the generating 
code; sometimes the generator has a lower rate limit because of the low 
precision of the system clock).  The downside is that version 1 and 2 UUIDs 
have privacy implications - they leak the MAC address of your device.  For some 
applications, though, this is not a problem and you may want to use a version 1 
UUID in that case.

Versions 3 and 5 are subject to hash collisions (MD5 and SHA-1 respectively), 
and version 4 (the one you should probably use as a sensible default) is random 
and so subject to statistical collisions.  It isn’t recommended to use version 
4 unless you have a source of high quality randomness available, to avoid 
collisions caused by poor quality random number generation (this won’t be a 
problem if you’re using the system APIs to generate them on Mac OS X or iOS).

Version 5 UUIDs can be useful if the thing you want to identify has e.g. a URL 
or FQDN or similar, as you can directly construct them from that, which might 
let you avoid e.g. another database lookup in some cases.  I would avoid 
version 3 (besides MD5 being weak to begin with, it’s also vulnerable to a 
length-extension attack; SHA-1 normally would be too, but in a version 5 UUID 
it isn’t because too many bits of the SHA-1 hash are missing... you’d need to 
try 275 billion different alternatives).

Also worth noting that different versions cannot collide with one another - 
there are version bits in the UUID.

TL;DR: Version 1 and 2 UUIDs should be unique.  Versions 3 through 5 can in 
most cases be assumed to be unique.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Requires High Performance Graphic Card - Why?

[Alastair Houghton]

On 16 Dec 2016, at 04:11, Gerriet M. Denkmann  wrote:
> 
> macOS 12.2; MacBook Pro (Retina, Mid 2012).
> 
> Activity Monitor → Energy tells me that my app requires a "High Performance 
> Graphic Card”.
> 
> The problem: it has absolutely no reason to do so.
> The app does some WiFi stuff and displays the result in a window. There is 
> almost no graphics (except from some sliders, buttons, a colour well, etc.) - 
> and there definitely is no need for “High Performance Graphics” of any sort.
> 
> How to debug this?

This is one of those things that you just need to know.  You need to add the 
key NSSupportsAutomaticGraphicsSwitching to your app’s Info.plist; see

  https://developer.apple.com/library/content/qa/qa1734/_index.html

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Large "Data" support

[Alastair Houghton]

On 6 Dec 2016, at 01:15, Jens Alfke  wrote:
> 
>> On Dec 5, 2016, at 4:12 PM, Daryle Walker  wrote:
>> 
>> For the Swift 3 "Data" type, if I want to represent a multi-gigabyte file, 
>> it won't try to do it all in memory, would it?  
> 
> The Data type specifically represents in-memory data, so yeah, it would. 
> (Where by “memory” I mean “address space”, which is not at all the same thing 
> as physical RAM on macOS, though it is on iOS. You haven’t specified which 
> platform you’re interested in.)
> 
>> Or would I have to manage a memory-mapped NSData and somehow connect it to a 
>> Data object?
> 
> On Mac this would be of limited use; all it changes is that when your data 
> gets paged out it will be written to your custom file instead of the OS’s 
> usual swap file. It probably won’t improve performance although it would help 
> keep the swap file from growing as much.

Strictly speaking, it may well improve performance, for two reasons:

1. If you mmap() data, you don’t actually have to read all of it; it’s read 
from disk on demand.

2. If the system needs to page your data out and you haven’t dirtied it, if 
it’s mmapped() it can just dispose of the pages; no need to hit the disk.

Compare with malloc()ing a buffer and reading a file into it (which NSData will 
do if you just read a file into it):

1. You need to read all the data from disk into your buffer.

2. If it’s too large to fit in memory, or some of it needs to be paged out, it 
will need to be written to the swap file.

Note that these are mainly advantages for large data sets, particularly those 
that are sparsely accessed and/or written to.  If you’re dealing with small 
files, mmap() may well be slower because of the overhead of page fault handling.

(Aside: a historical irony here is that on 32-bit platforms, software that 
dealt with exactly those kinds of data sets often couldn’t use mmap() because 
there wasn’t enough address space, but on 64-bit systems that’s unlikely to be 
true for most files most people care about.)

Kind regards,

Alastair

--
http://alastairs-place.net


___

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

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

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

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

Re: Vertically Centered Colon

[Alastair Houghton]

On 1 Dec 2016, at 19:05, Doug Hill  wrote:
> 
> Just made another breakthrough. I finally figured out why we have the 
> vertically centerd colon (I’ll now call it VCC) by default but has 
> requirements of numbers on either side of the colon.
> The SF font setting is “Contextual Alternatives” (I’ll now call it CA). When 
> CA is on, it will use the logic of numbers on either side of a colon to get 
> VCC. Turning off CA turns off this logic and no VCC. But even if CA is on, 
> and you have a character stream that isn’t :, you can turn on 
> VCC explicitly with it’s own selector to get that behavior.
> 
> Other than VCC I’m not sure what other contextual alternatives there are. 
> Fractions didn’t seem to do anything differently.

I think we’ve headed off topic somewhat, so this is likely my final word on the 
subject.  Contextual alternates’ usual abbreviation is “calt” (which is its 
OpenType tag).  It might also, at this point, be worth pointing you at the 
OpenType specification

  https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx

and in particular the registered features page:

  https://www.microsoft.com/typography/otspec/featurelist.htm

The pages on advanced layout may also be informative.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Vertically Centered Colon

[Alastair Houghton]

On 1 Dec 2016, at 15:57, Alex Zavatone  wrote:
> 
> If we are able to do it right, then we don't have to worry about waiting for 
> it or aren't put behind an 8 ball if Apple decides to pull the rug out from 
> under us if it decides to change the feature (which happens).
> 
> With these features in text styling, we have all the metrics that we need and 
> as long as the font we want to use supports what we want, these features can 
> be implemented without waiting for someone else to do it for us.

Up to a point.  Sometimes there is special support in a font for some 
particular feature, which will provide better results than naïvely moving or 
scaling a glyph.  A case in point is small caps; you can simulate small caps by 
using capitals from a smaller point size, but doing so will affect the weight 
of the strokes.  Dedicated small caps support tends to look a lot better — the 
stroke weight will match, but also sometimes changes are made to the glyphs to 
better fit into the available space and/or to better align with other 
characters in the font.

Vertically centring a colon is towards the simpler end of things and should be 
doable “by hand”, though there might still be gotchas with some fonts (e.g. 
where digits are not the same height as capital letters or where “old style” 
digits are in use).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Vertically Centered Colon

[Alastair Houghton]

On 30 Nov 2016, at 18:33, Doug Hill  wrote:
> 
>> On Nov 29, 2016, at 11:06 PM, Alex Zavatone  wrote:
>> 
>> On Nov 30, 2016, at 12:10 AM, Doug Hill wrote:
>> 
>>> After some trial and error, I figured out how to accomplish the San 
>>> Francisco font features described below. I updated my document to include 
>>> the code to turn on each feature.
>>> 
>>> http://breaqz.com/font/AlternateStylisticForms.pdf 
>>> 
>>> 
>>> I should make a sample app or blog post but time doesn’t permit at the 
>>> moment. Hope this all helps!
>>> 
>>> Doug Hill
>> 
>> This doc might help
>> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html
>>  
>> 
> 
> A lot of good stuff there. It appears to be some documentation for what's in 
> SFNTLayoutTypes.h which is helpful.
> However, all the alternate stylistic forms are still numbered selectors so 
> not a lot of new information.

The problem with the alternate stylistic forms (“salt”) feature is that there 
are twenty sets and they’re only defined by a number.  Moreover, they’re font 
specific (or, more accurately, typeface specific, because they’re encoded 
separately in each OpenType font file).  Hopefully Apple will document the 
stylistic alternates in question and won’t change them, but until and unless 
they do, using them is slightly risky.  (I think there’s a good chance they 
won’t change them, as they probably do the same thing in their own code, but 
I’d rather see them explicitly documented.)

> Still hoping Apple will make SF font specific features part of the SDK.

Agreed.  At the very least it needs to explicitly document the set of stylistic 
alternates for the SF font family so that we know what they all do (it looks 
like there might be more than in your document too; I can’t think of a reason 
for using one, two, three and then seven without also using four, five and six).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Vertically Centered Colon

[Alastair Houghton]

On 28 Nov 2016, at 16:18, Gerriet M. Denkmann  wrote:
> 
> 
>> On 28 Nov 2016, at 22:13, Eric E. Dolecki  wrote:
>> 
>> You could probably use an attributed string and add an attribute for the 
>> last colon: NSBaselineOffsetAttributeName
> 
> Yes; but this would be some rather desperate work-around.
> 
> I was rather thinking of UIFontDescriptorFeatureSettingsAttribute with some 
> Feature type from SFNTLayoutTypes.h (in CoreText).
> I tried a few types, but no success so far.

The problem you’ve got is that unless the font has a feature that specifically 
allows you to change *any* colon (as opposed to a colon between two numerals), 
you aren’t going to be able to do it by turning on an OpenType feature.  Even 
if you can, there doesn’t appear to be a standard feature code for this, so 
you’d be reliant on Apple not changing it in the future.

What you *could* do instead is get Core Text (or Cocoa Text) to lay out a 
string e.g. "12:00”, then grab the glyph for the centred colon directly from 
that string and use it explicitly, e.g. by attaching a 
kCTGlyphInfoAttributeName attribute to your string with the value set to an 
appropriately constructed CTGlyphInfoRef.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Fonts in TableView

[Alastair Houghton]

On 6 Nov 2016, at 06:18, Quincey Morris  
wrote:
> 
> 5. It’s rather indeterminate what glyphs the bounding box should reflect. In 
> particular, in digital typography using Unicode characters, a font as 
> perceived by the user may be a composite of multiple actual fonts. For 
> example, there’s likely code in the text system that provides a Euro glyph 
> for every font that doesn’t have it. 

What happens on macOS and iOS is that *all* characters that are 
out-of-repertoire are rendered using an alternative font automatically.  By 
default, this uses the system default “font cascading list”, which is language 
specific.  This isn’t specific to the Euro character (indeed, most modern fonts 
already have that glyph), but covers everything that can’t be found in the 
currently selected font.

> There is probably no perfect strategy that works for every font. However, for 
> the kinds of design decisions that Apple made when it started doing 
> typography properly (in the early 1990s, the days of the Font Wars between 
> Apple and Microsoft), I recommend you use the following calculation to 
> compute the line height of text:
> 
>   line height = font ascender + font descender + font leading
> 
> using the 3 values reported by the NSFont. (I can’t remember, the descender 
> may be negative, in which case you’d invert the sign.) Depending on your 
> goals, you might also add some margin above and below the line height (1 or 2 
> points top and bottom) to prevent your rows from looking cramped.

You might also consider using NSLayoutManager’s -defaultLineHeightForFont: 
method, which does pretty much the above calculation - you can see exactly what 
it does in the following Stack Overflow post.

http://stackoverflow.com/questions/5511830/how-does-line-spacing-work-in-core-text-and-why-is-it-different-from-nslayoutm/5635981#5635981

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Prioritizing drawing of the important stuff

[Alastair Houghton]

On 29 Oct 2016, at 10:37, Jonathan Taylor  wrote:
> 
> This is a bit of a general question, but hopefully people may have some 
> suggestions. I've got some drawing code that synthesizes an image in a 
> window, which will change in response to sliders (e.g. changing the camera 
> perspective). My problem is how to make it so that the redrawing of the image 
> is as responsive as possible as the slider moves.
> 
> At the moment I just respond to KVO notifications from the slider by 
> redrawing. This works fairly well. However, after further development work my 
> program is now a bit more complicated. Effectively, I have two images, one of 
> which is expensive to draw and one less so. What I would like is to have the 
> quick-to-draw one update fairly often, and the more expensive one at lower 
> priority. Does anyone have any suggestions about how to achieve this?

A couple of comments:

1. Have you checked how frequently the KVO notifications fire as you move the 
slider? If the answer is more than 60 times a second, you should probably think 
about triggering only the *first* view update from the KVO notification, with 
subsequent view updates running on a timer until the slider has stopped moving.

2. For the “slow” image, you could run it at lower priority, but as you have 
noticed that might result in starvation if there is a higher priority thread 
that is always ready to run. An alternative would be to run in a normal 
priority thread; if that uses up too much CPU (for instance), you could 
consider explicitly sleeping occasionally (with e.g. nanosleep()).  Another 
option that sometimes works well in these kinds of situations is to start a 
timer when the slider first moves, resetting it every time you get a move 
notification, and only do the expensive drawing when the timer completes; you 
can obviously adjust this policy for your specific circumstances.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: How to count Atoms

[Alastair Houghton]

On 7 Oct 2016, at 08:19, Gerriet M. Denkmann  wrote:

> So what is the proper way to count something atomicly and undeprecatedly?

 or  is the approved source for this kind of thing.

In C++, you might write

  #include 

  std::atomic counter;

then you can just do

  ++counter;
  --counter;

as usual, while in C you’d have to write

  #include 

  atomic_int counter;

  atomic_fetch_add(, 1);
  atomic_fetch_sub(, 1);

See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf for the C11 spec 
(section 7.17 is the part you’re interested in), or 
http://en.cppreference.com/w/cpp/atomic for C++11 documentation (you could look 
in the spec also, but personally I find the C++ specification hard to read).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Where are the ICU Headers?

[Alastair Houghton]

On 6 Oct 2016, at 10:43, dangerwillrobinsondan...@gmail.com wrote:
> 
> Pretty sure the reason is a simple one. 
> If you look at the history of open source in the OS on the Apple open source 
> page, you'll notice they pretty much bump the ICU version they use annually. 
> Although unlikely, ICU might change in ways that breaks your app. They don't 
> want to support ICU directly. It's a pretty tough API in C or C++ 

Also, historically, C++ ABI compatibility has been a thorny issue.  Even now, 
if you want a C++ dynamic library to provide binary compatibility you have to 
be pretty careful.

ICU is largely a C++ library.  It does have a C interface, but I’m not sure the 
entire feature set is available without using C++, and ICU explicitly doesn’t 
provide for binary compatibility at the C++ API level (or even for some of its 
C API(!)) - see

http://userguide.icu-project.org/design#TOC-ICU-Binary-Compatibility:-Using-ICU-as-an-Operating-System-Level-Library

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

On 27 Sep 2016, at 05:31, Britt Durbrow  
wrote:
> 
> FWIW, it’s currently an implementation detail that SELs do map into the 
> global address space in a way that doesn’t collide with anything else; but 
> technically, they are in their own address space and the system could map 
> them otherwise in a manner that does have collisions with other stuff.

That’s true.  IIRC GNUStep SEL values don’t work the same way as they do with 
the Apple/NeXT runtime, so this trick wouldn’t work there.

> In practice, I don’t think that will ever happen, because a) too much 
> existing code makes the assumption that a SEL is de-referenceable or 
> otherwise depends on this implementation detail; and b) we have 64-bit 
> addressing, so we’re not going to run out of address space such that making 
> that change would be advantageous.

Agreed, it seems unlikely that Apple would change it; not impossible, but quite 
unlikely.  As I say, relying on it means your code won’t straightforwardly port 
to GNUStep, but most of us don’t care too much about that.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

On 27 Sep 2016, at 02:17, Slipp Douglas Thompson  
wrote:
> 
> I'm just going to throw this out there as a solution, not because I recommend 
> this approach (it's API misuse after all) but because it would work.
> 
> Instead of using an `NSString *` you could use a `SEL` (AKA `struct 
> objc_selector *`) since SELs are guaranteed to be unique for each given 
> string they represent (within a process; AFAIR).

Indeed, they’re interned by the Objective-C runtime.  However, this is a 
blessing and a curse; it’s a blessing in that comparing with a selector will be 
fast, you can use “==“ to do the comparison, and the resulting code will be 
easy to read.  It’s a curse in that it means you must choose a unique selector. 
 So @selector(mediaLibraryLoaded) is unlikely to be a good choice; something 
like @selector(com:mycompany:mediaLibraryLoaded) might be.

> My 2¢: I'm still in favor of making all usages of `context` in your app 
> `NSObject *`s or `nil` because sometimes you do want to store an 
> `NSDictionary *` or other data in `context` that's meant to be read later.

The context value is not retained (and there’s no obvious guarantee about when 
you can expect that it won’t be used again; assuming that you won’t be called 
with your context value immediately after deregistering for KVO notifications 
will probably result in the creation of a subtle race condition).  Also, other 
code might result in you receiving a non-nil pointer that doesn’t point to an 
object.  The safest way really is to take the address of a static variable in 
your code and use that; there are, as you rightly suggest, alternative 
addresses you could use (a selector, or a function address would both work, as 
would a dynamically allocated address, provided you stored it somewhere).

> But if you're stuck with using other libs that don't use `NSObject *`s or 
> `nil`, or if you really want to ensure your code won't crash because its 
> making assumptions about what's in the  `context` your code registered, then 
> I acknowledge your case.  Key point: I personally wouldn't use the `SEL` 
> approach, but still.

The SEL approach is better, modulo the requirement for the name to be unique.  
But the idiom used by most of us is to take the address of a static variable, 
and I’d recommend sticking to that.

The important point in all of this, though, is that you can’t safely 
dereference the context pointer, because you don’t know what it is.  You may 
*think* you do, because you’ve supplied *one* possible value for it, but other 
code that you don’t control can supply other non-nil values and they will point 
at whatever that code chose to point them at, which probably wasn’t the same as 
your choice.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

On 23 Sep 2016, at 10:04, Quincey Morris  
wrote:
> 
>> static void* kMyContext = 
> 
> That makes the “&” optional (at comparison time), and it should even avoid 
> the coalescing problem if it’s declared const.

Yes, that’s a good way to do it.

It might be a good idea for Apple to have a macro for this purpose, so you 
could write

  NS_DECLARE_KVO_CONTEXT(kMyContext);

as that would avoid any confusion whatsoever (filed as rdar://2842).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

On 23 Sep 2016, at 09:36, Alastair Houghton <alast...@alastairs-place.net> 
wrote:
> 
> Note that you can use *any* type for your variable; in some ways, it might 
> make sense to use a non-pointer type, just to make clear that it’s the 
> address that matters, e.g.
> 
>  static const int kMyContext = 0xabadf00d;

On second thoughts, it might also be best not to use “const”, as that might 
conceivably also get coalesced.  So

   static int kMyContext;

would do.  No need to initialise - you don’t care about the value.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

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

KVO is an OS X thing, introduced in 10.3.

Why it uses this approach rather than taking a selector is a good question.  I 
imagine it’s motivated by the desire to allow subclasses to override 
superclasses’ observation behaviour, and perhaps there might also be a 
performance argument (it *might* make it more likely that the 
-observeValueForKeyPath: method hits the method cache, and/or provide 
additional opportunities to use IMPs).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Stupid objective-c question

[Alastair Houghton]

On 23 Sep 2016, at 00:19, Sandor Szatmari  wrote:
> 
> I wanted to get some opinions on the following which I have done in the past 
> and perceive as different because the string constant is introduced and 
> defined once and only once.
> 
> // my .m file
> static NSString * const kMyContext = @"my fantastic context";
> 
> // later on
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>   change: (NSDictionary *) change context: (void *) 
> context
> {
>  if ( context == kMyContext )
>  { // do my stuff }
>  else
>  // call super
> }
> 
> My interpretation of how to use context has been as an arbitrary pointer...  
> Does this run afoul of anyone's sensibility?

Yes, it’s wrong.

The compiler and linker perform an optimisation known as string coalescing.  
What this means is that if *anyone* else uses the string @"my fantastic 
context" in their code and it just happens to get (statically) linked to yours, 
the address will not be unique.  Given the string you picked, it isn’t unlikely 
that the same string could be used elsewhere as a KVO context.

At present, the risk is confined mainly to your own codebase because string 
coalescing isn’t performed by the dynamic linker and the system doesn’t intern 
string constants.

The correct approach is to take *the address of a static variable* and use 
that, as that’s guaranteed to be unique.

i.e. you need to do this:

  static NSString * const kMyContext = @"My fantastic context";

  ...

[foo addObserver:myObject forKeyPath:@"some.key.path" options:0 
context:];

  ...

  - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
  change:(NSDictionary *)change context:(void *)context
  {
if (context == ) {
  // Do my stuff
} else {
  [super observeValueForKeyPath:keyPath ofObject:object change:change 
context:context];
}
  }

Note that you can use *any* type for your variable; in some ways, it might make 
sense to use a non-pointer type, just to make clear that it’s the address that 
matters, e.g.

  static const int kMyContext = 0xabadf00d;

Otherwise some smart-ass might go and delete the “&” operators from your code, 
and that makes it vulnerable to problems.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Normalising file names on macOS

[Alastair Houghton]

On 22 Sep 2016, at 16:30, Ken Thomases  wrote:
> 
> Without undermining Alastair's recommendations, you can achieve what you want 
> by round-tripping the string through -[NSString fileSystemRepresentation] and 
> -[NSFileManager stringWithFileSystemRepresentation:length:].  That handles 
> the normalization, but it doesn't do anything about characters that aren't 
> legal in file names on a given file system.

:-)  I pondered mentioning -fileSystemRepresentation but decided it didn’t 
really solve the problem.  Right now, you’re right, it does normalise strings, 
but that isn’t documented and it’s probably undesirable - the HFS 
implementation can already cope with precomposed characters and by decomposing 
before passing to the BSD APIs there’s a risk that the present implementation 
will prevent a Cocoa program from opening the correct file (or any file at all) 
on some filesystems.

(It also has no way to know what filesystem’s rules it’s supposed to use, so it 
isn’t as if Apple could selectively disable normalisation to resolve this 
problem.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Normalising file names on macOS

[Alastair Houghton]

On 22 Sep 2016, at 12:46, John Brownie  wrote:
> 
> OK, the situation is that the user provides a name, which comes in through a 
> standard text field in a dialog. That name is used as a key for a dictionary 
> which gives a collection of information about that item. It is also used to 
> create a file, hence it becomes a file name (with an appropriate extension). 
> A complication is that the document is stored as a bundle, and the name is 
> used as a file name for a file in the Resources directory and referenced in 
> the info.plist file.
> 
> When reading the document from disk, I need to match up the file name with 
> the appropriate entry in the info.plist. Currently that works as long as I 
> don't hit the normalisation issue. If I get a precomposed character given to 
> me, then the file name becomes the decomposed version, and I've lost the 
> mapping.

My recommendation would be as follows:

1. If possible, don’t base the filename on the user’s input.  Instead, generate 
your own filename (one option might be to use a UUID) and then store a 
dictionary mapping the user’s input to the filename somewhere in your bundle.  
This avoids any problems with filename encoding completely.  You will still 
have to worry about normalising the user’s input, but that’s then just a matter 
of choosing a normalisation.

2. If you must base the filename on user input, do so by stripping out 
non-ASCII characters and replacing them with e.g. ‘_’s.  You’ll also need to 
make sure that the result is unique, otherwise a user might specify two names 
that both map to the same ASCIIfied name.  You’ll still want to store the 
dictionary mapping the user’s input.

The benefit of the second approach is that your bundle is more easily 
understood by a human being.  The downside is that it’s more complicated to 
implement.

Both will work, whatever the filesystem is, as they don’t rely on filesystem 
encoding behaviour.

(You might also then ponder whether you want things to be case-sensitive or 
not; the above will be.  Making it not case-sensitive is a little tricky in 
that just converting to upper or lower case doesn’t *quite* work; the correct 
approach would be to use CFStringFold() to case-fold the string, *after* 
normalising, before using it as a dictionary key.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Normalising file names on macOS

[Alastair Houghton]

On 22 Sep 2016, at 12:04, John Brownie  wrote:
> 
> I find that I am in need of dealing with versions of strings that may be 
> turned into file names, and thus I need to be comparing normalised forms. 
> However, according to 
> https://developer.apple.com/library/content/qa/qa1173/_index.html, "For 
> example, HFS Plus (Mac OS Extended) uses a variant of Normal Form D in which 
> U+2000 through U+2FFF, U+F900 through U+FAFF, and U+2F800 through U+2FAFF are 
> not decomposed (this avoids problems with round trip conversions from old Mac 
> text encodings)."
> 
> Is there a way to get at this variant? [NSString 
> decomposedStringWithCanonicalMapping] returns "A string made by normalizing 
> the string’s contents using the Unicode Normalization Form D." That seems not 
> to give what I need, but I haven't seen a better option. Is there such a 
> method?

This is rather a hairy problem, actually.  You don’t know that the filesystem 
is actually HFS+.  The filename in question could refer to a file on an NTFS 
volume, or (in future) an APFS volume.  It could also be a network filesystem, 
which could be mounted on a system running a completely different operating 
system with unknown character encoding behaviour; typically UNIX behaviour, for 
instance, is to completely ignore the filename encoding problem and treat 
filenames as a string of bytes (thus you are free to interpret them as UTF-8 if 
you so wish, but the filesystem will regard U+00E9 as different from U+0065 
U+0301, even though the two names will display the same on screen).

Additionally, the version specified in HFS+ was based on a particular version 
of the Unicode standard (I forget which), but importantly *not* the current 
version, which is what the NSString APIs will use.

Perhaps we should start by understanding the context of your question.  Is 
there a specific reason you want to match the filesystem behaviour precisely?

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: loadNibNamed deprecated, but newer version crashes

[Alastair Houghton]

On 19 Sep 2016, at 10:02, Gabriel Zachmann  wrote:
> 
> Thanks a lot for your response.
> 
> When I replace this line 
>   [NSBundle loadNibNamed: @"ConfigureSheet" owner: self];
> by this:
>   NSBundle * bundle = [NSBundle bundleForClass:[self class]];
>   [bundle loadNibNamed: @"ConfigureSheet" owner: self topLevelObjects: 
> nil];
> 
> then System preferences crashes with this stack trace:

The problem is likely that you aren’t retaining all of the top level objects in 
the nib file, and something you’re relying on is being disposed of.  The 
simplest fix for older code that was using the original -loadNibNamed:owner: 
method is often just to add an NSArray member variable to your class to hold 
the top level object references.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: How to make Xcode launch a different app when "Running" my code?

[Alastair Houghton]

On 18 Sep 2016, at 14:54, Uli Kusterer  wrote:
> 
> On 18 Sep 2016, at 12:02, Gabriel Zachmann  wrote:
>> When I "Run" my code in Xcode (i.e., hit CMD-R), I would like Xcode to build 
>> the code, copy the product to its destination,
>> and then run a *different* application, not the product it has built.
>> (all on macOS, not iOS)
> 
> Sure! Pick "Edit Scheme..." from the target selection popup in your Xcode 
> window's toolbar. There, select the "Run" entry on the left. In the "Info" 
> tab, you can set the executable to run to any executable in your project, or 
> another arbitrary one. 

This is IMO the best approach, but as an addendum you probably want to think 
about whether the scheme should be shared or not.  By default, build schemes 
are per user, so if you have multiple people working on your project you’ll 
need each of them to set this up, and depending on how you’ve set your source 
control up it might also not check in per-user things in the project file (I 
know I tend to set things up so per-user stuff isn’t saved, to avoid bloating 
commits with random Xcode state that nobody else cares about).  There’s a 
“Shared” checkbox on “Edit Scheme…” sheet for that purpose.

IMHO this is quite a confusing area, because by default Xcode auto generates 
schemes and they’ll look them same for everyone who opens a project, which 
leads people to expect that changes they make will persist for everyone else.  
That isn’t the case.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Swift and Threads

[Alastair Houghton]

On 13 Sep 2016, at 05:29, Jens Alfke  wrote:
> 
> The Bool type is one byte in size.
> 
> C++ has a specialization for std::vector that makes it a true bit 
> array, but I’m not sure if Swift’s generic system is powerful enough to be 
> able to entirely switch out the implementation based on the parameter type.

Before anyone thinks it’s a good idea to copy that idea straight into Swift’s 
standard library, std::vector doesn’t behave quite the same as the other 
std::vector<> implementations, and the specialisation is widely regarded as a 
mistake.  It’d be a *really* good idea to avoid making similar mistakes in 
Swift.

(Also, there’s a strong argument for having a separate bit vector type, with 
set-like operations, support for sparse bit vectors and the like.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Why doesn't this crash?

[Alastair Houghton]

On 10 Sep 2016, at 12:39, Andreas Falkenhahn  wrote:
> 
> To open a video, I do the following:
> 
>AVPlayer *p = [[AVPlayer alloc] initWithURL:url];
> 
> I'd expect this code to crash on 10.6 because 10.6 doesn't have AVPlayer.
> To my surprise, however, the code doesn't crash and it just returns NULL.

[snip]

> However, I'm wondering whether it is ok to execute this code on 10.6 without
> any safeguard. I thought I'd have to do something like this instead:
> 
>if(floor(NSAppKitVersionNumber) >= NSAppKitVersionNumber10_7) {

Testing against version numbers should be a last resort; it’s considered good 
practice, generally speaking, to explicitly test for the feature you’re after 
instead of doing that.  In this instance, you’re weakly linked against the 
framework, so just doing

  AVPlayer *p = [[AVPlayer alloc] initWithURL:url];

is absolutely fine; it will return nil because sending messages to nil is 
defined to do that in Objective-C.

Sometimes you might want to test for a particular method rather than a class, 
and you can use -respondsToSelector() for that.

(I’ll add that in a general sense, it makes no sense testing the AppKit version 
number to see whether AVFoundation is available.  While the Objective-C part of 
your program *probably* only targets Mac OS X and this will probably work for 
you, should you ever want to use the same code with e.g. GNUStep or Cocotron, 
you’ll be out of luck.)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Progress Indicator

[Alastair Houghton]

On 10 Sep 2016, at 15:38, Peter Hudson  wrote:
> 
> I have a simple view with a progress indicator in it.
> Simple circular type - indeterminate.
> 
> I start it with   [progInd  startAnimation:self];
> I end it with[progInd  stopAnimation:self];
> 
> After a couple of years of running just fine, it now simply does not appear 
> onscreen at all - or run.
> 
> I’ve tried removing the object from the view and dropping in a new one - and 
> reconnecting.
> Everything looks fine - it appears to be connected up correctly.

Have you tried looking at its frame at runtime?  If you converted your 
application to use auto layout, it’s possible that (if the constraints are 
ill-specified) the progress indicator is being resized or moved so it isn’t 
visible on screen.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Linking against AVKit breaks app on 10.6

[Alastair Houghton]

On 10 Sep 2016, at 12:47, Andreas Falkenhahn  wrote:
> 
> When I link my app against AVKit using
> 
>-framework AVKit
> 
> it fails to load on 10.6 claiming
> 
>dyld: Library not loaded: 
> /System/Library/Frameworks/AVKit.framework/Versions/A/AVKit
>Referenced from: ...
>Reason: image not found
>Trace/BPT trap

This is probably happening because AVKit doesn’t declare its symbols as weakly 
imported, while the other frameworks do.  You can force weak linking for that 
particular framework using

  -weak_framework AVKit

instead of just using the normal “-framework”.  Note that you will need to make 
sure that the functions and classes you’re going to use actually exist if you 
rely on weak linking.  See 
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: C callbacks with NSNotificationCenter?

[Alastair Houghton]

> On 7 Sep 2016, at 22:11, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Sep 7, 2016, at 10:03 AM, Alastair Houghton 
>> <alast...@alastairs-place.net> wrote:
>> 
>> All of it can.  Objective-C is just C with some syntactic sugar on top.  
> 
> There’s a large amount of semantic sugar too, i.e. the runtime libraries. (If 
> you think the runtime part must be trivial, go read some of Mike Ash’s posts 
> about the implementation of objc_msgsend. That’s some of the most insanely 
> optimized code I’ve ever seen.)

Mike’s site is generally a good read for that kind of thing.  For those who 
don’t know:

  https://mikeash.com/

Incidentally, on the how-fast-is-objc_msgSend(), according to Mike’s latest Mac 
figures, it costs on average less than two C++ virtual method calls, and indeed 
less than division.  See

https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-comparisons-of-common-operations-2016-edition.html

>> Really.  There’s nothing magic going on.  (In fact, the original compilers 
>> were really just preprocessors that churned out C code.)
> 
> You can say this about nearly any compiler, though.

Sort of, yes, but in the case of Objective-C I think there was a conscious 
intention to keep the Objective part separate from the C part.  Put another 
way, you could make Objective versions of most other languages, if you wanted, 
by making similar syntactic additions to them to the ones made for Objective-C, 
and that looks to me to be a deliberate design decision.  That’s not quite the 
same as C++ or Go, which were always intended to be complete languages of their 
own.

Anyway, the point I was trying to make (to Andreas) was that he shouldn’t be 
scared of using Objective-C because it’s going to do all kinds of magic in his 
program that he doesn’t understand.

> But yes, you can use the Obj-C runtime API from C to do pretty much anything 
> you can do in Obj-C, like calling methods and implementing classes. It’s just 
> much, much messier, error-prone, and difficult to read compared to writing 
> the damn code in Obj-C.

Absolutely.  IMO Andreas really *should* just use Objective-C for the 
Mac-specific bits of code.

> There’s no pride in refusing to switch languages. I abjured C++ a long time 
> ago, but guess what, my current project is 99% C++ because that language best 
> meets the performance and portability requirements.

Same here, as it happens.  C++11/14 is *much* better than the previous 
iteration, though it’s still lacking in some areas.

> Next time maybe I’ll be using Swift, or Rust, or Pony. C is an ancient, 
> primitive language and it’s not a good career move to refuse to move past it 
> :)

Agreed.  I’d love to be using Swift right now, actually, but I have portability 
concerns it doesn’t address and the language itself is still not stable.  Both 
will resolve themselves.  Rust and Pony look interesting also.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: C callbacks with NSNotificationCenter?

[Alastair Houghton]

On 7 Sep 2016, at 17:09, Andreas Falkenhahn  wrote:
> 
> As a C programmer I'm trying to avoid Objective C whenever and wherever 
> possible.

Don’t.  Where there’s an Objective-C equivalent, it’ll be less error prone, 
shorter to write and easier to debug.

> The good thing is that I can do most interaction with Cocoa from normal C 
> functions.
> I only had to write very few classes. Most of the Cocoa stuff can be done
> from normal C functions just fine.

All of it can.  Objective-C is just C with some syntactic sugar on top.  
Really.  There’s nothing magic going on.  (In fact, the original compilers were 
really just preprocessors that churned out C code.)

> Now I'd like to subscribe to the AVPlayerItemDidPlayToEndTimeNotification
> notification. In an Objective C class, this is purportedly done like this:
> 
>[[NSNotificationCenter defaultCenter] addObserver:self 
> selector:@selector(itemDidFinishPlaying:) 
> name:AVPlayerItemDidPlayToEndTimeNotification object:playerItem];
> 
> This will call the "itemDidFinishPlaying" method in class "self" whenever
> an AVPlayerItem has finished playing.
> 
> Of course, I can't use this code in a normal C function because there are
> references to "self" and the selector thing doesn't look like it's compatible 
> to
> C. So I could just subclass AVPlayerItem and voila, everything's fine.
> 
> Still, I'm wondering: Is it also possible to have NSNotificationCenter call
> a C function for me whenever the notification triggers? Can this somehow
> be achieved or am I forced to use full Objective C here?

Yes, it’s possible, because Objective-C is built on C.  Historically (this is 
not entirely true now), Objective-C objects were just a struct like this:

  struct object {
struct class *isa;

/* Member variables */
  };

where the class struct is similar to a C++ vtable in purpose.

So, to get it to call a C function, you’d just build an equivalent data 
structure and put the pointer to your C function into the class structure in 
the appropriate place.

The Objective-C runtime library has some (C) APIs that do all of these kinds of 
things for you and mean you don’t even need to worry about the underlying data 
structures (which have, in any case, changed somewhat since the above).

But why not just write it in Objective-C in the first place?  The compiler will 
then handle all of that *for you*.

If you think Objective-C isn’t fast enough, think again; objc_msgSend() is very 
highly optimised and if you have a tight loop where it *really* matters you can 
even drop down to using an IMP to call functions directly.

And if it’s just that you don’t want to learn Objective-C, well, the amount of 
work you’re doing to avoid it is probably a great deal more than the amount 
you’d need to learn enough Objective-C to do whatever it is you’re trying to do.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Running apps compiled for newer OS X versions on older versions (rant)

[Alastair Houghton]

On 5 Sep 2016, at 13:48, Mark Allan  wrote:
> 
> It's probably also worth noting that you *can* compile for 10.6 using the 
> tools on 10.11 by adjusting the deployment target.

This is *usually* but not always true.  There are sometimes backwards 
compatibility problems that require you to use older build tools or SDKs.  (The 
most annoying case is if you need a KEXT for some reason, in which case you 
definitely can’t build KEXTs compatible with 10.6 using the 10.11 SDK; in fact, 
you can’t even build KEXTs compatible with *10.10* with the 10.11 SDK, which is 
a PITA because Xcode 7 dropped the 10.10 SDK and Xcode 6 won’t even run on 
10.11...)

Another thing to watch out for is that some APIs change behaviour based on the 
system on which your code was built; this happens because of backwards 
compatibility measures built in to OS X itself, but can be a problem if you 
take older code and just rebuild it with a newer Xcode without going through 
checking everything.  Often the changes are subtle and won’t matter too much, 
but you can’t assume that will always be the case - e.g. I remember one 
instance where a load of percentages magically multiplied themselves by 100 
because of changes in the way NSNumberFormatter works.

So, yes, this is your first point of call, but you will need to go and check 
that your code genuinely does work on the system you’re targeting because 
occasionally things are not quite as simple as they seem.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Pixel-perfect migration from ATSUI to Core Text

[Alastair Houghton]

On 1 Sep 2016, at 14:38, Andreas Falkenhahn  wrote:
> 
> The problem is most likely that the “W” doesn’t start at x = 0
>> (have you tried calling CTLineGetOffsetForStringIndex(line, 0, NULL)?)
> 
> That returns 0, that's why I was using 1.

Hmmm.  OK, well looking at the documentation I suppose that makes sense (that’s 
apparently supposed to be used for caret positioning, so it might not even 
equal the advance width in general; in particular, ligature glyphs may well 
cause you problems).

Have you tried getting the CTRun using CTLineGetGlyphRuns() and using 
CTRunGetPositions/CTRunGetAdvances()?

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Pixel-perfect migration from ATSUI to Core Text

[Alastair Houghton]

On 31 Aug 2016, at 19:24, Andreas Falkenhahn <andr...@falkenhahn.com> wrote:
> 
> On 31.08.2016 at 20:08 Alastair Houghton wrote:
> 
>> On 31 Aug 2016, at 15:52, Andreas Falkenhahn <andr...@falkenhahn.com> wrote:
> 
>>> But I still don't understand how computing glyph positioning manually
>>> should work around the fact that there are no APIs that measure the text
>>> like ATSUI. I mean, internally, CTLineGetOffsetForStringIndex() probably
>>> does exactly that, it returns the positioning obtained from 
>>> CTRunGetAdvances().
> 
>> You need to get the advances of individual glyphs, and sum the rounded 
>> values.
> 
> Look at the example code I posted. It's just a single glyph in the string.
> The string is just a "W”.

The problem is most likely that the “W” doesn’t start at x = 0 (have you tried 
calling CTLineGetOffsetForStringIndex(line, 0, NULL)?)

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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

Re: Pixel-perfect migration from ATSUI to Core Text

[Alastair Houghton]

On 31 Aug 2016, at 15:52, Andreas Falkenhahn  wrote:
> 
> But I still don't understand how computing glyph positioning manually
> should work around the fact that there are no APIs that measure the text
> like ATSUI. I mean, internally, CTLineGetOffsetForStringIndex() probably
> does exactly that, it returns the positioning obtained from 
> CTRunGetAdvances().

You need to get the advances of individual glyphs, and sum the rounded values.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

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

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

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