On CPView the
setFrame: method will call the setFrameSize:method. The later will call setFrame: on all it's subviews. It will travel down the view hierarchy on all the subviews. Each setFrame: method will update the tracking areas. Each update on the tracking areas will travel down the view hierarchy on all the subviews. So the tracking areas will be updated many many times.
I just do it once. :smile:
I will prepare a pull request that you can review.
Iām adding missing methods to
CPView and want (initially) to edit/test in an existing app without recompiling Cappuccino with every change. In the past Iāve simply imported an app-local version of the Cappuccino file. Is it possible to use an app-local version which contains only the additions/changes (CPView is quite large)?
@didierkorthoudt We canāt reformat using it though ;-) At least until I complete that syntax definition :-( I, too, use Xcode sometimes just for code review. When Xcode 11 isnāt sulking and refusing to go to work (which is still all too often, even with 11.3). Perhaps Iām the target market for the new Mac Pro
Iām tempted to build an AMD Ryzen Hackintosh just for Xcode 11
How do you get Xcode to work? I tried it a while ago and it couldn't grok the syntax...
Both handle
pragmamarks
And I use Sublime Merge as a git client
Havenāt tried Sublime Text for several years. I couldnāt get over the non-native look (as with VS Code)
Have not yet made the switch to Xcode 11
:smile:
@mrcarlberg While youāre still around, can you provide a quick refressher on
NSView vs Cappuccino? There was a discussion some time ago but I donāt remember the details. The SourceList framework Iām porting uses NSCell and associated compositing methods/constants which donāt seem to be available in Cappuccino. I had hoped to avoid grokking the code completely from entry point onwards but that is what Iām faced with doing now
@aksuska Yes, that requires a language-specific definition. Can be done although itās nowhere documented. And needs to be added to Xcode itself each time itās updated. The extension mechanisms which once existed are no longer supported. It is possible though.
Xcode is working towards Language Server Protocol definitions (for everything, I presume, rather than just Swift and Objective-C). Not much public progress since this announced last year though
@enquora Some views in Cocoa uses a cell below the actual view. I guess you can call a cell a light weight view. It was needed 30 years ago when the CPUs where slower and it was expensive to handle a view. Cappuccino does not implement cells. All the functionality is in the view itself.
Itās tedious but I donāt know of a better approach. I had thought the work would be in porting the datasource this framework provides rather than drawing the outline.
Well, I also have problems with Xcode 11, so I use Xcode 10.1 under High Sierra (in a Parallel VM, which is almost OK but the GitHub Desktop client. Was under VMWare Fusion but Parallel is better and speedier for what I can see). I also use the āexported UTIsā trick to have automatically Objective-C syntax treatment for Objective-J fileā¦ Works like a charmā¦ I wonāt consider upgrade to Catalina and Xcode 11 before finishing Aristo3 (my guest OS is Catalina)
@daboe01 xcrun has serious problems with the new filesystem layout. Itās capable of introducing orders of magnitude increases in I/O latency. It is the mechanism which dynamically resolves the tools instance being used (as specified by Xcode-select). I you donāt do anything which invokes the toolchain you wonāt see it. You also have a much faster machine!
The Swift compiler has always been lethargic, but SwiftUI Previews seems to have been designed with the assumption of zero latency. It uses a simulator, which has always taken forever to launch. There seems to be no supervisory co-ordinating process worth the name and the simulator or preview task is forever crashing.
And, Xcode 11 seems to have forgotten how to perform incremental builds, expecially for Objective-C. Those are starting to look more like the coffee breaks Swift builds can be.
@daboe01 I'm sorry to have suggested bezel-color on the textView. When I look at NSTextView they have not a bezel style as NSTextField have. So after a short discussion with @mrcarlberg we have agreed that the attribute should be named "background-color" instead. This should also been better for the CPTextField, who uses bezel-color. But we leave that for now.
@daboe01 We also need a "content-inset" since now the Text starts exactly where the bezel ends on the left side.
