@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.
Would like to load frameworks dynamically from a remote URL. Trying to follow through source for CPBundle and CFBundle hasn’t helped.
[[CPBundle alloc] initWithURL:aURL] appears to handle only the case with filesystem URLs.Even if that isn’t true, it isn’t obvious how a compiled framework bundle should be served to load it from a remote endpoint.
First set the global
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 ...
- macOS Big Sur
- Xcode 12.5 and Xcode 13.2 with 12.5.1 command line tools
- Cappuccino 1.0.0 and XCodeCapp 4.0.1
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 ...
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.
1 reply
2 replies
@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?
I have a loop that finds all Obj-J files and converts when necessary – very fast, should be fine even or 120+ files. You could make a similar loop for your many xibs rather than my simplistic approach to only look for
MainMenu.xib.
I have been thinking of the next release for Cappuccino (version 1.3). Here are some thoughts:
- Beta version in the beginning of September. Release in the beginning October.
- Based on the node branch.
- We do a new branch called narwhal forked from master. Then we merged in the node branch into the master branch.
- The release will include new compiler with support for ECMAScript 2022 and two pull request about Python and XcodeCapp from @enquora.
- What is the status on the Aristo3 branch? Is it ready or should it wait for a later release?
- Anything else that is ready to be included in the release?
- We need to update http://cappuccino.dev with new instructions how to install the new Node version. Do we have anyone that wants to do that? I will be too busy with the new release. The website with instructions how the website works is here https://github.com/cappuccino/cappuccino.org. Instructions how to install the Node version of Cappuccino is here https://github.com/cappuccino/cappuccino/wiki/node
Any comments or suggestions on this?
The release should also include the CPSlider fix #3045 and the (trivial) _ephereralSubviews → _ephemeralSubviews fix #3041.
When we're done I'm willing to see what needs to be changed at http://cappuccino.dev.
@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.