Re: Need for Swift

> On 15 Oct 2019, at 18:27, Turtle Creek Software via Cocoa-dev > wrote: > > MVC is an excellent design paradigm. The M and V layers were no problem at > all to set up. The C started out easy, but ended up being a big problem. > Quite a bit of the business logic is not just data, but fancy

Re: Need for Swift

Maybe it’s also worth noting that WebKit (the browser engine used by Safari) is written in C++ Safari’s UI is probably written in Obj-C(++) or a mixture of Obj-C(++) and Swift. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please

Re: Thoughts on Cocoa

> On 4 Oct 2019, at 11:43, Dragan Milić via Cocoa-dev > wrote: > >> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote: >> >> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until >> 2007, when Apple suddenly abandoned 64-bit C

Re: Thoughts on Cocoa

Hi Jens, > On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev > wrote: > > The people I hear complaining about this are those who, like you, didn't move > to Cocoa. Carbon was a _temporary_ transition API*. It wasn’t clear to us (outside Apple) that Carbon was a temporary API until 2007,

Re: printing black

> On 22 Jan 2019, at 18:23, Alastair Houghton > wrote: > > There’s often a printer setting on users’ printers to tell them to use (just) > black ink. This also shows up in Cocoa Print dialogs under “Printer features” or as a “Greyscale” checkbox. I have it turned on by default. Jeremy

Re: Carbon -> Cocoa

> Of course, the C++ business logic doesn't need any changes. The concern is, > how long will it last? Seems like the future is an entirely Swift-based API > that replaces Objective-C Cocoa in 5 years, with no easy way to link to other > languages. Core parts of Webkit are written in C++, so I

Re: Carbon -> Cocoa

> Our app has 6 or 8 programmer-years of C++ cross-platform business logic. > Accounting software is complicated. Rewriting that in another language would > be hard work, and tons of testing. More than Mac sales would justify, so it > would be time to go Windows-only or just fold. If you have

Re: Carbon -> Cocoa

> By now, Cocoa may be the new Carbon. The crucial difference is that Cocoa supports 64-bit applications, and Carbon doesn’t. > If you haven't switched to Cocoa after all these years, and if your app is > large, I'd wait to see what happens with Marzipan We don’t have time to wait for

Re: Carbon -> Cocoa

We found it very difficult. This was for a large C++ Carbon application. We’re now rewriting in Swift + Cocoa, starting from scratch. Jeremy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator

Re: Persistent User Defaults

Killing cfprefsd seems unnecessarily drastic. Why not use: defaults delete as Gary Wade mentioned earlier? is a reverse-dns string such as “com.company.appname” — > On 30 Apr 2018, at 15:31, Alex Zavatone wrote: > > Is it worth it (or wise) to zero out preferences and write

Re: Size of compiled NIBs in Xcode 9 (10.13 SDK)

> On 24 Jan 2018, at 19:46, Dragan Milić wrote: > > BTW, in both cases (Xcode 9 - 10.13 SDK and Xcode 8 - 10.12 SDK) the > deployment target is macOS 10.11, so I don't think that setting matters. Vince has explained why it does matter. If you change the deployment target to

Re: Size of compiled NIBs in Xcode 9 (10.13 SDK)

> I posted a related question in https://apple-dev.groups.io/g/xcode/ > ("Assets.car is much larger for High Sierra builds”) but I didn’t get much in > the way of a reply. https://apple-dev.groups.io/g/xcode/message/396 > It seems that Assets.car is much larger when it is built with the 10.13

Re: Size of compiled NIBs in Xcode 9 (10.13 SDK)

I posted a related question in https://apple-dev.groups.io/g/xcode/ ("Assets.car is much larger for High Sierra builds”) but I didn’t get much in the way of a reply. It seems that Assets.car is much larger when it is built with the 10.13 SDK than when it is built with the 10.12 SDK. I don’t

Re: Scroll views

Hi Quincey, I saw Kyle Sluder’s post some time ago, but it’s quite old and I’m not sure how relevant it is now. My complaint about scroll views is not that they don’t work, but that they’re confusing and I struggle each time I use them. My initial email was an attempt to summarise what I’ve

Re: Scroll views

> On 19 Jan 2018, at 22:15, Quincey Morris > wrote: > >> Interface Builder complains if I don’t also add vertical constraints, so >> I’ve done that, but made the bottom constraint into a placeholder (“Remove >> at build time”). Your email suggests that I

Scroll views and autolayout

This is a follow-up to my previous email on Scroll views. What I actually want to is be able to swap different views (with different heights) in and out of the scroll view. To do this, I’m adding the different views as a subview of the “document" view (called contentParent below):

Scroll views

Does anyone understand scroll views? I struggle every time I use them, and it seems that I have to go through a process of trial and error to get them working properly. If I drag a scroll view into another view in Interface Builder, I get a “Bordered Scroll View” that contains a “Clip View”

Re: Pasteboards and NSSecureCoding

-- > On 20 Dec 2017, at 05:03, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Dec 19, 2017, at 18:32 , Jeremy Hughes <moon.rab...@virginmedia.com> wrote: >> >>> On 20 Dec 2017, at 02:22, Jeremy Hughes <moon.rab...@virginmedia.co

Re: 10.13 printing problem

> On 19 Dec 2017, at 18:03, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > I have a problem printing an autolayout view in 10.13.2, and I’m wondering if > there is something wrong with my code or if Apple broke something in 10.13 or > a more recent update. > &

Re: Pasteboards and NSSecureCoding

> On 20 Dec 2017, at 02:22, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > What I don’t like about [NSArray.self] is that it’s an artefact of bridging. > I’m not actually using it in the encoder: > > coder.encode(arrayOfInts, forKey: kArrayKey) The declaratio

Re: Pasteboards and NSSecureCoding

> On 20 Dec 2017, at 02:07, Quincey Morris > wrote: > > The class must be a kind of AnyClass, so you can’t specify a struct type. > Sorry I sent you off in the wrong direction on that. That’s what I just concluded in an email I started writing. >> The

Re: Pasteboards and NSSecureCoding

> On 20 Dec 2017, at 01:25, Quincey Morris > wrote: > > You’ll have to figure out what type to use for the Ints. If they were > actually saved compatibly with Obj-C, the Ints will actually be NSNumbers, > and you’ll need to say “NSNumber.self”. If the Ints

Re: Pasteboards and NSSecureCoding

Thanks, Quincey. > That looks like Swift 3 code. The current version of the function is like > this: > >> @nonobjc func decodeObject(of classes: [AnyClass]?, forKey key: String) -> >> Any? @nonobjc means this is Swift-specfic then? The init function I’m using is marked as @objc: @objc

Re: Pasteboards and NSSecureCoding

, right? Jeremy -- > On 20 Dec 2017, at 01:09, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > The release notes for 10.13 say: > > If your application is linked on macOS 10.13 SDK or later, classes that > return NSPasteboardRe

Pasteboards and NSSecureCoding

The release notes for 10.13 say: If your application is linked on macOS 10.13 SDK or later, classes that return NSPasteboardReadingAsKeyedArchive from readingOptionsForType:pasteboard: must support secure coding, and will be decoded with a coder that requires secure coding. So I’m updating

10.13 printing problem

I have a problem printing an autolayout view in 10.13.2, and I’m wondering if there is something wrong with my code or if Apple broke something in 10.13 or a more recent update. I’m using the same view class for printing and screen, but I have a separate view object for printing. I’m

Re: Is "-init" really needed?

> On 10 Aug 2017, at 15:15, Alastair Houghton > wrote: > > 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

Re: Who owns a child view controller?

> On 14 Jul 2017, at 14:40, Steve Christensen <puns...@mac.com> wrote: > > On Jul 14, 2017, at 3:50 AM, Jeremy Hughes <moon.rab...@virginmedia.com> > wrote: >> >> I’m still not entirely clear on when autorelease pools are used in Swift. >> There is

Re: Who owns a child view controller?

> 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

Re: Who owns a child view controller?

> On 12 Jul 2017, at 17:41, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jul 12, 2017, at 9:34 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >> // Prints "Why is childReference not nil?” > > There may still be a reference i

Re: Who owns a child view controller?

> On 13 Jul 2017, at 19:43, Quincey Morris > wrote: > > Here’s how I understand the situation in Swift. As usual, I may have some > things a bit wrong, but I think this is right. There are four kinds of > reference variable (or stored property) in Swift: >

Re: Who owns a child view controller?

> On 13 Jul 2017, at 11:26, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > So perhaps the difference between safe and unsafe unowned is that safe > unowned generates a runtime error (but doesn’t crash) while unsafe unowned > crashes? Or perhaps they both crash, but

Re: Who owns a child view controller?

> On 13 Jul 2017, at 10:57, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > Apple’s Swift book says: > > "The examples above show how to use safe unowned references. Swift also > provides unsafe unowned references for cases where you need to disable > r

Re: Who owns a child view controller?

> On 13 Jul 2017, at 01:32, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >> I’m trying to understand memory management so I can avoid retain cycles and >>

Re: Who owns a child view controller?

> On 12 Jul 2017, at 23:18, Doug Hill wrote: > > While this discussion has been good at understanding underlying ARC and > manual ref-count issues, my guess as to what's causing these issues is that > you shouldn't just assign nil to the childViewControllers array.

Re: Who owns a child view controller?

> On 12 Jul 2017, at 22:07, Quincey Morris > wrote: > >> Or there's something else going on under the covers. > > Yes, you are correct, betting *against* this assumption is a really, really > terrible idea. Reasoning about the point at which objects

Re: Who owns a child view controller?

Thanks for elucidating! > On 12 Jul 2017, at 22:03, Greg Parker wrote: > > ARC does add an optimization where a cooperating caller and callee can safely > avoid the retain/release pair around the return operation, effectively > transforming that call into the

Re: Who owns a child view controller?

> On 12 Jul 2017, at 19:24, Jens Alfke wrote: > >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the object’s lifetime is that non-ARC code may be calling >> the method. In an all-ARC world, a method could always just return

Re: Who owns a child view controller?

> On 12 Jul 2017, at 19:25, Jens Alfke <j...@mooseyard.com> wrote: > >> >> On Jul 12, 2017, at 10:57 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >> Wouldn’t it be ARC (rather than the consumer) that is balancing retains? > &g

Re: Who owns a child view controller?

> On 12 Jul 2017, at 18:38, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Jul 12, 2017, at 12:23 PM, Jens Alfke <j...@mooseyard.com> wrote: >> >>> On Jul 12, 2017, at 9:54 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >>>

Re: Who owns a child view controller?

> On 12 Jul 2017, at 17:41, Jens Alfke wrote: > > There may still be a reference in the autorelease pool. Check childReference > again ‘later’, i.e. on the next user event or after a timer/delayed-perform. Thanks. I’d forgotten about autorelease pools - but I guess they’re

Who owns a child view controller?

I’m trying to understand who owns a child view controller after it has been removed from its parent view controller. The following code (which doesn’t involve view controllers) behaves as I would expect: import Cocoa class Element { var children = [Element]() weak var parent:

Re: Calculating intrinsicContentSize for a NSTextField

> On 18 Mar 2017, at 04:45, Daryle Walker wrote: > >> This works, but if I remove the call to attributedStringValue (whose result >> is discarded) the result of the following line fails to reflect changes in >> the bounds of the text, and the field fails to grow or shrink. >>

Calculating intrinsicContentSize for a NSTextField

I have a text field that I want to grow and shrink while it is being edited. In order to do that, I have overridden intrinsicContentSize and textDidChange in a subclass of NSTextField: override var intrinsicContentSize: NSSize { if let cell = cell, cell.wraps

Re: needsDisplay and subviews

> On 9 Mar 2017, at 18:32, corbin dunn <corb...@apple.com> wrote: > >> >> On Mar 8, 2017, at 8:46 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >> If needsDisplay is set to true for an NSView, does that also cause subviews

Re: needsDisplay and subviews

> On 9 Mar 2017, at 10:24, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > So it seems that for layer-backed views, setting needsDisplay does cause the > view to be redrawn - but the value is never actually set. If I needed to work > with layer-backed views, it mig

Re: needsDisplay and subviews

> On 9 Mar 2017, at 01:49, Quincey Morris > wrote: > > So, the correct answer to your original question, I think, is that if your > model data has changed in such a way that the representation in custom views > no longer reflects the data, then you should

Re: needsDisplay and subviews

drawn - except when “wantsLayer” has been set to true. Does that make sense? Jeremy -- > On 8 Mar 2017, at 17:12, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > Thanks - that seems reasonably clear, and it agrees with what I previously > thought, but I’ve got a sit

needsDisplay and subviews

If needsDisplay is set to true for an NSView, does that also cause subviews to be redrawn? I’ve seen conflicting statements about this, but haven’t found anything in Apple’s documentation. Jeremy ___ Cocoa-dev mailing list

Re: Binding NSTextField to an array

> On 6 Mar 2017, at 17:34, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > It all works now. Actually, it works as far as the text field displays “Multiple” (placeholder) for multiple values, but it doesn’t work when I set a value in the text field. In that case I get:

Re: Binding NSTextField to an array

hat the array controller has a selection to > generate values from. > > Mike. > >> On 6 Mar 2017, at 17:44, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: >> >>> On 6 Mar 2017, at 14:30, Jonathan Mitchell <li...@mugginsoft.com> wrote: >>&

Re: Binding NSTextField to an array

> On 6 Mar 2017, at 14:30, Jonathan Mitchell wrote: > > Sounds like NSValueTransformer is in fact what you need. > It can take in your NSArray ref and spit out a single NSString that the > NSTextField binding can live with. I think I must be missing something obvious.

Re: Binding NSTextField to an array

> From what I understand of your example, you’re not “binding” anything in a > Cocoa sense. In the case of the single value, the text field is set up via the Bindings pane of Interface Builder so that “Value" says “Bind to File’s Owner” with a model key path of self.value. (And “value" is

Binding NSTextField to an array

Hi, This seems like an elementary question. I’d like to bind an NSTextField to an array of numerical values, so that the text field will either display a single value if the values are identical or will display a multiple values marker if the values are different. Using Swift, I can bind a

Re: didPrint selector not called

> On 16 Dec 2016, at 21:54, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > >> In that case, you don’t know for sure who calls it and when. It appears to >> documented that it’s called as part of the standard implementation of >> “printDocument”, but you

Re: didPrint selector not called

> On 16 Dec 2016, at 21:40, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Dec 16, 2016, at 12:01 , Jeremy Hughes <moon.rab...@virginmedia.com> wrote: >> >> It’s just an application method, which overrides the method that the system >

Re: didPrint selector not called

> This is what I’ve currently got. It works OK, but the dictionary conversion > seems clunky to me. > > override func printDocument(sender: AnyObject?) > { > let didPrintSelector = #selector(document(_:didPrint:contextInfo:)) > > let dictionary = printInfo.dictionary() >

Re: didPrint selector not called

> On 16 Dec 2016, at 20:17, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: >>> I'm not an expert in this part of Cocoa. Are there implicit system >>> *callers* of this method, or is it more of a system *utility* that you're >>> expected to call fro

Re: didPrint selector not called

> On 16 Dec 2016, at 20:01, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > >>> OK - I misunderstood what Quincey was saying. >>> >>> The passed-in delegate and selector are nil, but I obviously can’t be sure >>> that they will alway

Re: didPrint selector not called

>> OK - I misunderstood what Quincey was saying. >> >> The passed-in delegate and selector are nil, but I obviously can’t be sure >> that they will always be nil. >> >> All I’m actually trying to do is to clean up some objects that need to exist >> during the print operation. Is this the best

Re: didPrint selector not called

Also, NSInvocation (used in the release notes sample code) is unavailable in Swift. Jeremy -- > On 16 Dec 2016, at 19:33, Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > >> >> On 16 Dec 2016, at 19:29, John McCall <rjmcc...@apple.com> wrote: >> >

Re: didPrint selector not called

> On 16 Dec 2016, at 19:29, John McCall <rjmcc...@apple.com> wrote: > >> On Dec 16, 2016, at 11:24 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> Thanks for the link. >> >> I’ve looked at it, and I don’t think it applies in th

Re: didPrint selector not called

can call through to. I suppose it would apply if I had a subclass (of my document class) that needed to override the callback. Does that seem right to you? Jeremy -- > On 16 Dec 2016, at 18:26, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Dec 16, 2016,

Fwd: didPrint selector not called

Sorry - I forgot to copy to the list. Jeremy -- > Begin forwarded message: > > From: Jeremy Hughes <moon.rab...@virginmedia.com> > Subject: Re: didPrint selector not called > Date: 16 December 2016 at 19:15:10 GMT > To: John McCall <rjmcc...@apple.com> >

didPrint selector not called

Hi, I’m overriding printDocumentWithSettings in order to get a notification for when printing has finished, but the didPrint selector is never called. This is the code: class func document(document: NSDocument, didPrint: Bool, contextInfo: UnsafeMutablePointer) { print("document was

Re: Dismissing Open dlog before doc actually opens

Graham Cox (14/8/13, 06:51) said: They did, which is why first modeless dialogs (from System 1? 2?) and then sheets (OSX 1.0) were developed. Even as far back as the original Inside Macintosh the use of modal dialogs was strongly discouraged when it was possible to use something else. The

Re: Overwhelming Options

Quincey Morris (1/9/11, 21:42) said: If it should happen that there was a practical need to change the column display frequently (dozens of times per day), choosing individual columns from a context menu would get very old very fast. In that case, the only practical choice might be an array of 39

Re: devil of a time with an NSImageView

Quincey Morris (20/8/09, 19:31) said: On Aug 20, 2009, at 11:02, I. Savant wrote: I missed that thread. Do you happen to know some keywords from the subject? No, I've looked for it but I can't find it. It was one of a number of similar questions around that time, possibly about iPhone views,