by OpenXTalkPaul » Sat Jan 15, 2022 5:35 am
I'd like to implement this:
- impliment this! systemColorSelector.png (104.74 KiB) Viewed 8676 times
The reason I want to do that is because systemColors can change over time, or due to user changing settings, so if you're using "systemBlue" in a "ViibrantDark" window on macOS, it will be a slightly brighter blue than if it's in a regular light mode NSview. There is more to the 'darkMode' appearance than the casual observer might notice, it's subtle things.
I'm really curious how or if Team LC will handle it. Take for example the blurred frosted glass look that's become prevalent on macOS, which is a visual effect that's applied by the OS to NSViews and subviews that ask for it, which looks like this:
- Screen Shot 2022-01-15 at 12.17.33 AM.png (65.51 KiB) Viewed 8676 times
The macOS blurs in realtime the foreground and background composted together into the background layer of an NSVisualEffectView. You can't get the same effect just using alpha channels and and stack trasparancy, I've tried! You can get something similar but static without the blur of the content behind the window. Going forward, if you want your app to look like a 'real' Mac app, you might want to implement this.
Another problem is the engine does a lot of custom drawing of "classic" controls (non-"native"ly drawn buttons, text flds, etc.), but these "Mac Native" Widget controls included with the IDE (which are NSViews wrapped in a Builder "native view") draw in a layer ON TOP of the stack/card layer (also on top of the Widget's 'canvas' layer, so you can't mix system+custom-drawing there either), so if you place a classic button on top of a "Mac Native" Text Field" widget, in browse mode you won't see the "classic" control, it will be drawn BELOW the native button, regardless of the layering on the stack/card. It's a problem for anything mixing system-drawn and custom-drawn elements to layers in a window. Crossplatform GUI Control Toolkits such as Qt or FPC Lazarus' LCL would have the same issues. Still I've been looking into this, and plan to do some tests creating an NSVisuealEffectView inside a widget, and/or applying appearance properties to the stack's NSWindow's background... hopefully this weekend.
Speaking of those "Native" widgets, those could easily be expanded. I was thinking I might just wrap macOS 'NSAlert' to get access to native "Answer" dialogs (that comes in a frosted glass window as a bonus!), which is a fairly simple Cocoa API. I'd like to wrap a lot of Cocoa actually, but later on. Look at XOJO, they've get access to lots of the system APIs, I want that for xTalk!
I've also done some tests with System Fonts, in particular getting the ACTUAL System font, which on BigSur IS NOT the "LucidaGrande" that is hardcoded into the IDE (which applies fonts based on the OS/version). The macOS system fonts are now special fonts that are invisible, even to Apple's FontBook utility! These include the "San Fransisco" SF sets, which includes Apple's proprietary answer to FontAwesome "icons". I CAN get the file:// URL path to those font files (via Builder Extension), but have not yet tested if the engines Font loading routines can load them.
I'd like to implement this:
[attachment=1]impliment this! systemColorSelector.png[/attachment]
The reason I want to do that is because systemColors can change over time, or due to user changing settings, so if you're using "systemBlue" in a "ViibrantDark" window on macOS, it will be a slightly brighter blue than if it's in a regular light mode NSview. There is more to the 'darkMode' appearance than the casual observer might notice, it's subtle things.
I'm really curious how or if Team LC will handle it. Take for example the blurred frosted glass look that's become prevalent on macOS, which is a visual effect that's applied by the OS to NSViews and subviews that ask for it, which looks like this:
[attachment=0]Screen Shot 2022-01-15 at 12.17.33 AM.png[/attachment]
The macOS blurs in realtime the foreground and background composted together into the background layer of an NSVisualEffectView. You can't get the same effect just using alpha channels and and stack trasparancy, I've tried! You can get something similar but static without the blur of the content behind the window. Going forward, if you want your app to look like a 'real' Mac app, you might want to implement this.
Another problem is the engine does a lot of custom drawing of "classic" controls (non-"native"ly drawn buttons, text flds, etc.), but these "Mac Native" Widget controls included with the IDE (which are NSViews wrapped in a Builder "native view") draw in a layer ON TOP of the stack/card layer (also on top of the Widget's 'canvas' layer, so you can't mix system+custom-drawing there either), so if you place a classic button on top of a "Mac Native" Text Field" widget, in browse mode you won't see the "classic" control, it will be drawn BELOW the native button, regardless of the layering on the stack/card. It's a problem for anything mixing system-drawn and custom-drawn elements to layers in a window. Crossplatform GUI Control Toolkits such as Qt or FPC Lazarus' LCL would have the same issues. Still I've been looking into this, and plan to do some tests creating an NSVisuealEffectView inside a widget, and/or applying appearance properties to the stack's NSWindow's background... hopefully this weekend.
Speaking of those "Native" widgets, those could easily be expanded. I was thinking I might just wrap macOS 'NSAlert' to get access to native "Answer" dialogs (that comes in a frosted glass window as a bonus!), which is a fairly simple Cocoa API. I'd like to wrap a lot of Cocoa actually, but later on. Look at XOJO, they've get access to lots of the system APIs, I want that for xTalk!
I've also done some tests with System Fonts, in particular getting the ACTUAL System font, which on BigSur IS NOT the "LucidaGrande" that is hardcoded into the IDE (which applies fonts based on the OS/version). The macOS system fonts are now special fonts that are invisible, even to Apple's FontBook utility! These include the "San Fransisco" SF sets, which includes Apple's proprietary answer to FontAwesome "icons". I CAN get the file:// URL path to those font files (via Builder Extension), but have not yet tested if the engines Font loading routines can load them.