Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 26 08:37
    hmelder starred cappuccino/cappuccino
  • Jul 19 11:37
    colbyrussell updated the wiki
  • Jul 16 19:34
    PowerPCx86 starred cappuccino/cappuccino
  • Jul 13 05:44
    TylerJaacks starred cappuccino/cappuccino
  • Jul 04 21:29
    omasanori starred cappuccino/cappuccino
  • Jul 04 18:45
    malcolmstill starred cappuccino/cappuccino
  • Jun 10 07:09
    daboe01 synchronize #3038
  • Jun 09 20:57
    daboe01 synchronize #3038
  • Jun 09 16:13
    daboe01 synchronize #3038
  • Jun 08 07:27
    cappbot commented #3045
  • Jun 08 07:10
    cappbot labeled #3045
  • Jun 08 07:10
    cappbot milestoned #3045
  • Jun 08 06:56
    michaelbach synchronize #3045
  • Jun 08 06:50
    michaelbach opened #3045
  • Jun 07 15:37
    michaelbach closed #3044
  • Jun 07 15:37
    michaelbach commented #3044
  • Jun 07 13:21
    michaelbach commented #3041
  • Jun 07 13:05
    cacaodev commented #3041
  • Jun 07 08:28
    cappbot commented #3044
  • Jun 07 08:22
    cappbot labeled #3044
David Richardson
@enquora
Xcode 14 still allows setting the xib compatibility for very old OS versions. I don’t expect this to change - it needs, minimally, to be able to open very old xibs.
I don’t like the usage of Apple’s tools by nib2cib — it is a dangerous external dependency. I’ve been wondering for some time how difficult using XSLT to transform xibs directly would be. We’ve been transforming HTML to non-trivial JSON structures for a decade and a half — it works extremely well. I noticed a suite of XML tools while searching NPM not that long ago.
David Richardson
@enquora
The only item of note with Xcode 14 is the absence of SDKs earlier than High Sierra.
NPM does, indeed, list multiple XSLT implementations, both bindings to libxml/libxslt and native. Given a source XML document such as a xib, this is the only way which makes sense, imo
Michael Bach
@michaelbach
Xcode 14 still allows setting the xib compatibility for very old OS versions. I don’t expect this to change - it needs, minimally, to be able to open very old xibs.
Thank you! That dispels immediate concerns. But agree totally re long-term issues you also mention.
David Richardson
@enquora

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

David Richardson
@enquora

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

Xcode 14 stability is fine for daily use, in my experience.
Martin Carlberg
@mrcarlberg
@enquora I will take a look at those pull request in the next couple of days.
Yes, the Xcode editor is evolving in a very positive way... I have not had the time to try Xcode 14 yet but I looking forward to it. :smile:
David Richardson
@enquora
Does anyone have a succinct explanation of how bundles are loaded?
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.
Would also like to load as early as practicable in the app lifecycle - these frameworks/bundles would be plugins providing essential functionality.
Martin Carlberg
@mrcarlberg
@enquora It is easy to load frameworks (plugins bundles) dynamically:
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.
David Richardson
@enquora

@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)?

Martin Carlberg
@mrcarlberg
@enquora It might be tricky if you have a remote endpoint with another domain name. You have to setup some kind of Cross-Origin Resource Sharing (CORS).
enquora
@enquora:matrix.org
[m]
It will be the same domain that served the host app
Martin Carlberg
@mrcarlberg
Good, should not be any problems.
David Richardson
@enquora
@mrcarlberg The example you typed is for a local, on-disk framework path. It’s the remote URL case I’m not understanding. When the framework is built for release, for instance, there is not root MyPlugin.j file — it’s compiled into the bundle’s sj file.
Martin Carlberg
@mrcarlberg
You have to setup your webserver that you have the same base url for your application and your plugins
David Richardson
@enquora
k. That means it’s possible to continue loading the app in Safari using file:// for testing. Makes caching for offline use (service workers) not terribly complicated, as well. Thks.
Martin Carlberg
@mrcarlberg
We have a very positive outcome from our tests with ecmascript 2022. I hope I will have great news about this in august. Stay tuned for more updates. :smiley:
daboe01
@daboe01
@mrcarlberg this is wonderful news! thank you for pursuing this important task.
peterbaral
@peterbaral

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

Michael Bach
@michaelbach
@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.
1 reply
@peterbaral: Question from me. Is Cordova working for you to create Cappuccino-based apps for MacOS & Windows on MacOS? I've tried NW.js & Electron, but have had no success to create "stand-alone" exe files (one of the reasons: Mono no yet available for ARM machines). If I read the Cordova docs right it's not the case. Also they say "OS X platform is now deprecated…"
2 replies
daboe01
@daboe01
@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.
@michaelbach if i remember correctly, the issue is not nib2cib but XCodeCapp
David Richardson
@enquora
@peterbaral Two pull requests are sitting in the queue (#3028 & #3029) which update Cappuccino tools for Monterey. They work only with the master branch, not node.
Michael Bach
@michaelbach
@daboe01 : YES! Thank you for correcting! Nib2cib runs fine, XcodeCapp is the problem.
1 reply
peterbaral
@peterbaral

@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?

David Richardson
@enquora
@peterbaral It seems easier to apply patches #3028 and #3029, and to stick with Narwhal until the Node changes are ready. Is that a problem for your environment?
I'm away from my desk this week, but can probably walk you through any problems setting up for Xcode 13.3
peterbaral
@peterbaral

I'm away from my desk this week, but can probably walk you through any problems setting up for Xcode 13.3

@enquora I will gladly come back on you eventually - thank you very much!

Michael Bach
@michaelbach
@peterbaral : You asked about my shell script to "emulate" XcodeCapp. I've split into 2 files, this one sits in each project's directory, and the "MAIN" part can sit at a common place for all project (last line in the first file here links; here assuming same directory).
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.
peterbaral
@peterbaral
@michaelbach Clever work! Will definitely give it a try.
I wonder if I can get XcodeCapp-like automatic cib and .h/.m generation using watchman's folder watching and script execution feature.
Michael Bach
@michaelbach
@peterbaral : Thank you. Folder watching is cleverer, but a shell script is so fast when comparing file change dates that I'll stay with my simple loop for now. My workflow: change anything in the GUI with IB or in an obj-file with the Xcode source editor, and with a global shortcut key (which I implement with Alfred) the shell script is started. It saves any changed files in Xcode, and then goes on to compare change dates and creates all Cappuccino files, finally starting the index.html file in the browser; even with my ≈30 J files project this takes typically only a few seconds.
peterbaral
@peterbaral
@michaelbach Fine automation. Hitting this shortcut key surely became a reflex :)
Martin Carlberg
@mrcarlberg

I have been thinking of the next release for Cappuccino (version 1.3). Here are some thoughts:

  1. Beta version in the beginning of September. Release in the beginning October.
  2. Based on the node branch.
  3. We do a new branch called narwhal forked from master. Then we merged in the node branch into the master branch.
  4. The release will include new compiler with support for ECMAScript 2022 and two pull request about Python and XcodeCapp from @enquora.
  5. What is the status on the Aristo3 branch? Is it ready or should it wait for a later release?
  6. Anything else that is ready to be included in the release?
  7. 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?

daboe01
@daboe01
@mrcarlberg these are wonderful news!
with respect to aristo3 i will fix the issues with combobox that i am seeing on FF/win and a few other issues in the next few weeks hopefully.
i think we should ship what we have in Aristo3 but not make it the default for now. @didierkorthoudt what do you think?
Michael Bach
@michaelbach
@mrcarlberg : Great news indeed! I know David will hate me for this, but it does not look like we have the manpower to keep the non-node version working. And the 2 pull requests about Python and XcodeCapp hadn't worked for me, that's why I replaced XcodeCapp with a shell script.
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
@daboe01
just to add my two cents: we should gradually move away from the apple toolchain given the issues that pop up on every macos release.
atlas may be a good replacement for IB. IIRC @tomalsky any news on open sourcing this excellent project?
David Richardson
@enquora

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

I would much prefer to see #3028 and #3029 merged into master before tackling the updates needed for the node branch — it’s a significant friction point switching branches without them applied and reduces my enthusiasm for starting on the necessary node branch work.
David Richardson
@enquora
wrt XSLT for transformating xibs to cibs, we have been using it for transforming HTML to JSON directly since 2005 and have processed hundreds of thousands of extremely complex form-based documents in that time. Reliability is extreme, even in the face of source document structure changes over time. This declarative approach has allowed handling structure changes over time in a way that imperative code in any language would not be happy with.
Even with the limitations of XSLT 1.0, it has proven time again to be the happy path. I don’t see why the same wouldn’t be true for xib transformations.
David Richardson
@enquora
A long shot, but has anyone overridden CPTableHeaderView to allow either collapsible columns or super-headers which span multiple columns (to indicate they belong to a group?