@mrcarlberg Could you look at merging #3028, #3029 to master (they’re narwhal only). I now have a pressing need to finalize the corresponding toolchain work on node. Not having these commited to narwhal adds otherwise unneccesary friction to branch switching.
I believe @michaelbach has tested and confirmed they’re working.
@michaelbach Xcode editor tip, if you were unaware.
In Python files, #MARK: Some comments
syntax provides bookmarks, just as #pragma
marks do when for files using the C pre-processor.
This is probably true for at least some other popular languages too. I suspect it’s controlled by the syntax highlighting implementations for each language. Python is included by default, of course.
I am leaning on Xcode increasingly for editing — it has become quite stable and is feature-rich. Vim mode works well, too.
[[CPBundle alloc] initWithURL:aURL]
appears to handle only the case with filesystem URLs.OBJJ_INCLUDE_PATHS = ["Frameworks/Debug", "Frameworks", "/path/to/your/plugins"];
. Normally this is set in the index.html file. Just make sure you included the path to your plugin bundles (frameworks). When you want to load your bundle (framework) just call objj_executeFile("YourPluginBundle/MyPlugin.j", NO);
. This is equivalent with @import <YourPluginBundle/MyPlugin.j>
except you will control when and what will be called. This will load your bundle and load your class(es). It will even compile your Objective-J files if they are not prebuilt.
@mrcarlberg Ideally, we will load at least some frameworks from a remote endpoint (https://app.servingdomain.com/plugins/…), depending on a user’s privilege profile (downloaded after successful login).
I don’t see any why this shouldn’t work (in theory, at least). What isn’t obvious is what the remote URL(s) and hosting configuration should look like.
Simply serve up the Framework directory (they would be the built versions)?
I'm developing a hybrid iOS-Cordova-Cappuccino app for primary school children.
Development work is done on a M1 Mac running ...
The problem:
We need to upgrade to macOS Monterey because some of our development has to be upgraded to
Xcode 13.3 or higher.
The question:
Is it possible to upgrade to Monterey and have Xcode 13.3+ and nib2cib/XCodeCapp up and running?
Didn't find a recent post here ...
@peterbaral: I know your pain. Sadly, nib2cib has not been sufficiently upgraded to work in Monterey. The reason as you probably know: Python deprecation by Apple, and newer Pythons differ sufficiently in syntax to break nib2cib.
Solution for me: I have written a fairly simple shell script, which (for my purposes) sufficiently mimics nib2cib so IB-based development (Xcode 13.4.1) works just fine in Monterey using the new Node version of Cappuccino on ARM Macs. More when you need it.
Ah, saw the post about your XCodeCapp replacement here flying by, but I can't find the repo anymore. IIRC you tailored it for your project structure. My project consist of more than 40 xibs and 120+ Obj-J files. An automatic approach where xibs and source code files are handled automatically (using fs events) is very much preferred.
Do you think tools like Hazel for Mac or watchman from Facebook could be used to detect file changes and call nib2cib or the Obj-J source file converter (can't remember the name, is it objj2objcskeleton?) automatically?
MainMenu.xib
.
I have been thinking of the next release for Cappuccino (version 1.3). Here are some thoughts:
Any comments or suggestions on this?
@daboe01 I’m skeptical the source code for Atlas will ever resurface, let alone with an open license - Motorola/Google must surely own it now.
Even given that, I don’t believe we have the resources to develop and maintain and effective IB replacement. On top of that, Xcode now is my preferred GUI editor. There is certainly a risk of Apple deprecating IB and eventually removing it, given their obvious focus on SwiftUI. If that happens, Objective-C and AppKit will be removed at the same time — which seems unlikely within the next decade (ever, imo)
The source of unreliability is not IB or Xcode, but nib2cib’s reliance on Apple’s internal toolchain (ibtool and plutil), which they consider internal.
I’m increasingly leaning toward an XSLT transform to bypass these completely when transforming xibs to cibs.
fwiw, I have just confirmed that nib2cib works just fine with #3028 and #3029 applied to the master/narwhal branch when using Xcode 14 beta 5 (the latest). XcodeCapp continues to be a problem — not just when calling nib2cib, but in its overall architecture. I’m increasingly believing using shell calls and stdin/out for message passing just isn’t a good mechanism in this case.