Find and Replace

[richmond62]

This is a badly made stack and I would like to have a bash at improving
the thing: but I cannot for the life of me work out where it is so that
I can raise it to an editable level:
-

SShot 2022-01-12 at 10.38.16.png (132.51 KiB) Viewed 8686 times

-
I mean the stack on the right.

[richmond62]

Right . . .
-

SShot 2022-01-12 at 11.25.15.png (44.23 KiB) Viewed 8682 times

[OpenXTalkPaul]

Right . . .
-

With macOS darkMode appearance applied on that stack looks like:

FindReplaceRichmond.png (107.78 KiB) Viewed 8674 times

I made some minor mods to that stack a while back for the sake of darkness

FindReplacePaul.png (129.1 KiB) Viewed 8674 times

[OpenXTalkPaul]

I'd like to implement this:

impliment this! systemColorSelector.png (104.74 KiB) Viewed 8673 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 8673 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.

[OpenXTalkPaul]

Another idea that came up while playing with transparency / alpha channels is a widget that can create alpha channel-only imageData from live vector drawn shapes, that imageData could then be passed back to the engine and then applied to the stack as a window shape very quickly. This would help a LOT with creating custom windows because you wouldn't have to go back and forth between the IDE and your image editor, making it more of a "Live" process.

This screenshot is really long because the alpha channel applied to the stack extends beyond the stack's current height setting. To fix that I'd have to edit the alphaChannel and then reapply it to the stackShape again to see if it's good, rinse and repeat until satisfied. It gets tiresome fast!

Screen Shot 2022-01-14 at 1.57.32 PM.png (53.97 KiB) Viewed 8672 times