You'll have to do that manually. Maybe add a "selected" flag to each item. Then if an item is expanded, then you can instruct it to re-select any items whose "selected" flag was true. Remember that an outline view is just a fancy table view. When you collapse and item, those rows are gone, so it isn't possible to maintain their selection within the table itself.

For that kind of advanced behaviour, you'll have to implement the logic in WebKit yourself using the delegate methods.

[quote='861567022, JWWalker, /thread/803249?answerId=861567022#861567022, /profile/JWWalker'] No idea what you mean by that? [/quote] It looks like an autocorrection. It should have been "overflow". But that's irrelevant. I was just confused by your GitHub link. It was GitHub that printed properly. Now that I know what you're doing, I can reproduce the problem. It seems clear that it's the dynamic markdown that's causing all the trouble. If you look closely in the print preview, you can see that the top margin on page 1 is wrong. The first element is right up at the top of the page. That throws off the page count because the full print does it properly. I was also able to easily hack up my older app and have it swap out its own data for your markdown-html. The first time I tried it, both the preview and the output came out short, at only 8 pages. But all subsequent attempts worked properly, printing all 13 pages (with my headers). I think WebKit is caching this data. That's why it only fails the first time. When I swapped out the legacy for the new, all I could only ever get was a single page. I think the new renders much faster and that's why it only has a single page at print time. This old app does both the legacy and the new WebKit, so it has a lot of overhead. That explains why I can only get a single page whereas a simple app gets 11. I'm taking care to avoid printing until the document ready event in Javascript. So this markdown parsing must be happening after that. That would explain these results. It simply hasn't finished rendering the page when it gets the page count. And I ran the rendered HTML from Safari through the W3C HTML validator. It's not valid HTML. Like any browser, WebKit tries to compensate. But combined with the Javscript rendering, it seems to be too much for it to handle. Good luck on your bug report. But until that's fixed, I recommend static HTML.

I was just about to give up and tell you to create a demo project that just opened one web view and printed it. But I thought I should try that first myself. I did and also got 2 blank pages. There are lots and lots of possible options. But in this demo app, here is how I fixed it using a Swift Storyboard document-based app: In Xcode Interface Builder, find the print menu item. Change its sent action from "print:" to "printDocument:" in NSResponder. Observe that the app now prints correctly. I tried this with your sample and got 12 pages, including the last. Nothing seems to be missing except horizontal overview inside a div in the web view, but that's a different problem. I poked around for a bit. It looks like the old XIB templates in Xcode used "printDocument:" as the sent action. For some reason, in the newer Storyboard templates this was changed to just "print:", which doesn't seem to work. No clue about SwiftUI. I have a newer app in Swift that isn't document-based. In this app, I seem to have already changed the print action to "printView:", which I implemented in my view controller. My old Objective-C app uses printDocument, which the XIB template also uses. So this solves your blank page problem with "printView:". This is also complicated by the NSView and NSWindow Objective-C methods "print:" that are re-defined in Swift as "printView:" and "printWindow:". I'm still not sure why you're getting partial output. My demo app uses your code and prints fine. I played around with it a bit, putting the print method in both the view controller and the document. Worked fine either place. Perhaps the demo app would be a good place to start after all.

If you run "codesign" on your executable, it tells you exactly what the problem is: /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /private/tmp/renderrob.app/Contents/Frameworks/Python.framework If you explore that framework using Terminal, you'll see what it's complaining about: /tmp $ find /private/tmp/renderrob.app/Contents/Frameworks/Python.framework ... /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python Remove those files and try again: /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: a sealed resource is missing or invalid file added: /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc file added: /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib Almost there. Keep removing those dot files... /tmp $ rm /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib /tmp $ codesign -vv -R="anchor apple generic" renderrob.app renderrob.app: valid on disk renderrob.app: satisfies its Designated Requirement renderrob.app: explicit requirement satisfied Now you're good to go. Or at least, ready to notarize. Something in your toolchain is trying to create resource forks inside a zip file incorrectly. Are you building some of this on a non-Mac platform? I made a point to double-click your zip file to unzip using the expected procedure. I think you can use "ditto" on the command line to achieve the same result, but not "unzip". When using Finder, I shouldn't ever get those kind of dot files. (And for the record, they aren't even correctly structured dot files.) I understand a lot of internet folks don't like Xcode. I've got a long list of Xcode complaints myself. But I still use it because, even at its worst, it's better than anything else. I have a very complex project under development that was designed to use some of the most gnarly Linux/open-source build platforms ever known. It's bit the bullet and took the time to port it all to Xcode. It just insane how much better Xcode is at this. Those poor Linux masochists have no idea.

I swapped out my old deprecated code for the new WKWebView code similar to what you're using. It was surprisingly easy. It does require macOS 11. And I lose my custom headers and footers. But otherwise, it works fine. In my code, I'm using fit pagination for both horizontal and vertical. I think that may fix your ridiculously tall pages. Safari also generates such pages when exporting to PDF, so perhaps "automatic" is what's doing that. Otherwise, I have a document-based app and I don't call runModal on the print operation. As I said above, I'm using NSDocument's "printDocumentWithSettings:..." after the web view has completely loaded.

My code is much more elaborate than that. To start with, I create my own print operation via "printOperationWithSettings:error:" (still Objective-C). I don't call "runModal" at all. WebView is really tricky with printing, at least for me. I create a new view just for printing, then load it, and print in my load completion using NSDocument's "printDocumentWithSettings:...". And of course, all this still uses the long-deprecated WebView class. I don't know if Apple ever added print support WKWebView. Still works in Tahoe. You seem to be trying to use the new logic. I don't plan on using WKWebView in the future anyway. So if Apple eventually removes the old WebView I won't be affected.

While you can't control when people review or what they say, you can control when they're prompted to post a review. Make sure to only prompt them when your code detects that they are getting real value from your app. Don't just pop it up at launch time. Wait until they're (done) using a key feature. Also monitor the reviews closely. For a real, non-scam app, 3.5 is pretty good. You're always going to get 1-star junk reviews saying, "the app works great but costs too much", or worse. While you can't stop those, you can turn them into your favour. Reply to those reviews and turn them into an advertisement for your app. Show how responsive you are. Point out valuable key features. Etc. If the haters see that you can effectively turn their 1-star reviews into useful advertisements, they won't bother.

First of all, never use comments for replies. Apparently they don't trigger notifications, for people who use them. But they also don't get noticed at all. WGS 84 is a large and complex standard, among many similar large and complex standards designed for dealing with coordinates on the earth. However, because WGS 84 is such a broad standard, it isn't going to have much practical meaning in more specific contexts like a map display. When it does have a specific meaning, it will typically have some kind of qualifier. It is usually better to refer to EPGS identifiers. Apple Maps is a good example. The Apple Maps display uses EPGS:3857, AKA "WGS 84 / Pseudo-Mercator". But most government and professional mapping systems like ArcGIS use EPGS:4326, AKA "WGS 84". You can easily see the difference between these two systems in an image or map. The above references to CLLocationCoordinate2d using WGS 84 is also true, but the significance there is related more to where a particular lat/long coordinate is on the earth, rather than the overall map display. However, I don't know which interpretation is relevant for this question regarding China. China itself doesn't use WGS 84 or the EPGS system. They have their own, proprietary system that purposefully obfuscates locations on the map. China is very strict about mapping. They don't allow foreign companies, like Apple, to display maps in China. That's why Apple has to use Amap. Why does any of this matter? What is the OP trying to determine with question #1? Is question #2 even legal? I can't answer either and I recommend just ignoring these literal "edge" cases. If someone has a more specific need that seems like it would be 1) worth digging into and 2) legal, then maybe add a new reply instead of a comment.

Using Instruments, I see that the view seems to recreate the subviews three times per keyboard event, so I'm clearly doing something wrong. Not necessarily Most SwiftUI stuff on the web is iOS-oriented, and typically has a focus on fairly simple apps, so the whole topic of dealing with menu commands doesn't get a lot of coverage Correct What I've been able to find is not particularly helpful for a full-fledged application like mine, so I'm looking for advice on how to structure the app. You don't have to use SwiftUI.

What kind of information are you looking for that you can't access? You tagged this post with AppKit. And you also mentioned Alfred and Raycast, which appear to be macOS apps. That means you're talking about macOS, where all this information is readily available. From what I understand, you can even get this information on iOS, but it's more difficult there. But on macOS, (almost) anything you want is right there.

All you need to do is take some existing icon image as use it as a background template. You can even use your existing, post icon-jail image on Tahoe. Make sure that your content doesn't extend beyond the edge of the squircle. You'll probably want to add a thin shadow border so the icon looks decent on older versions of macOS. On Tahoe, if your squircle is good enough, then it will only its own border - kind of an icon ankle-monitor rather than icon-jail. But it looks fine. You could even Liquid Glass your icon to the max in Icon Composer, then export it as PNG images and use them on old Xcode/OS versions. The only thing you really lose with this approach is the dynamic dark version. Even the clear and tinted versions looks decent.

Obviously the developers felt they needed it. You'd have to ask them for details. Obviously you haven't included it in your project. Freetype is a 3rd party framework. It's commonly used with open source tools, but relatively rare on macOS.

Don't use comments to reply. They get lost and no one ever sees them. Freetype is a commonly used library for certain open-source projects. In that context, it could be used as a static library. However, if your case, the dynamic library libsfml-graphics.2.6.2.dylib is trying to load it as a dynamic library.

The operating system is ready It is not. Xcode barely runs on macOS as it is. Xcode is the single most crash-happy app I have. It crashes on me at least 3-4 times per day, every day. Xcode on iPad would not be a pleasant experience.