Comments on OXT Lite 1.02

[tperry2x]

The other thing you mentioned is called 'Night Shift' but actually seems to be separate from darkMode. That's in the 'Displays' control panel. It can auto-change the color 'temperatures' to the 'warmer'/'cooler' side of the spectrum for like whites / lighter colors, based on the time of day.
To be honest I never even consider the 'night shift' mode because I don't use that feature at all, I'm always in 'darkMode'.

Oh, I know what you mean about night shift - kind of where it removes blue hues and swaps to orange ones.

What I mean is in the appearance prefpane, that's the bit to change system theme dynamically based on the time of day:

Screenshot 2024-03-27 at 18.27.31.png (43.56 KiB) Viewed 440 times

(or, unhelpfully enough - just labelled as "Auto").

On the other point, I had the check to see if the IDE was starting up for the benefit of other stacks such as the tools palette. My tools palette uses this to automatically change the tool icons based on if you are in dark / light theme.
If a user was to hide / show the tools again, you don't want to have to reload all the theme icons, so this is why it checks if the ide is booting - so it only has to load it once.

I also already did what you've done to the extensions library, with the "Project Browser" stack.

Screenshot 2024-03-27 at 18.30.48.png (114.08 KiB) Viewed 437 times

[OpenXTalkPaul]

Also, I agree that the IDE should have the ability to override the system setting for dark/light because as developers we may need to frequently toggle it to check our stacks look ok in either mode. So maybe a settings should be something like 'Use System Preference for DarkMode' or "Override System DarkMode Preference'? On macOS you can actually set the mode on a per-Window basis, which prompted me to add a 'darkMode' property to the stack properties with the intention that would someday be managed / implemented via a separate library. There's a demo stack included with the Mac Native Tools Extension with buttons that demonstrates this feature. The syntax is like: setWindowToDarkMode the windowID of this stack

[richmond62]

Indeed: any dark/light mode MUST:

1. NOT be dependent on the dark/light mode of the end-user's OS (personally I keep both of my recent Macs in dark mode, but favour using OXT in light mode).

1.1. That should mean that OXT does NOT have to detect whether the end-user has dark or light mode set as a system-wide setting, just remember which way the end-user set the dark/light mode last time they used OXT.

2. It would be lovely if, somewhere on the tools palette there were a couple of buttons to switch back and forth between the modes.
-

tbMockup.png (26.15 KiB) Viewed 448 times

[tperry2x]

As mentioned, you can switch this in the edit > preferences.

[richmond62]

you can switch this in the edit > preferences

Indeed you can, but were one to be able to do that from the Tools palette it would be useful for a quick impression before belting off a standalone.

[tperry2x]

If you wanted a quicker way to toggle between things, you can already do so from the View menu.

appearance-toggle.png (858 KiB) Viewed 442 times

[OpenXTalkPaul]

If you wanted a quicker way to toggle between things, you can already do so from the View menu.
appearance-toggle.png

I think I would prefer that it be a preference to either behave in the Apple recommended way, or overide system.
There is also a related app info.plist on/off key that is 'prefer dark mode' or something to that effect, but its not clear how that effects an app if at all.
You can also toggle the system theme mode from the global system menubar, but that only works with the IDE if there's a handler 'on systemAppearanceChanged' in the Home stack that responds to it. That's how I normally toggle it from in any app.

System_menuBar.jpg (28.61 KiB) Viewed 435 times

[tperry2x]

How does that display menubar item / menuextra deal with 'Auto'' mode, or doesn't it support that?

I guess it's all a matter of user preference, each to their own, and all that.
I always think of 'displays' of where you manage multiple displays, or change brightness/contrast, or change how additional displays are arranged, or change resolution, or change display scaling... anything but 'themes'. System appearance themes - Isn't that what the appearance prefpane was for?... unless that's gone now in recent MacOS?

Apple did the exact same thing in iOS. It used to make sense where everything was. They used to say that everything was in a logical place. Now I have to search for a setting, and more often than not, it doesn't find it - and I have to locate it manually (only to find it's called what I typed, but search just.... doesn't).
As predicted with one of the 10th gen iPads, I had a teacher come to me today asking how they turn one of their new iPads off they use for attendance, as it didn't make sense. "Am I just supposed to let it run out of charge or something?"

They have a point of course, but they came to me red-faced and embarassed - as they said they "felt such an idiot for having to ask". Like you said the other day Paul, I have always said there's no such thing as a silly question. There's plenty of 'silly design' out there - so perhaps I shouldn't be surprised with Apple's layout choices starting to make little to no sense where preferences are ordered these days.

Short version: I'm keen to try and make the layout of things within 'OXT Lite' at least make sense. Even if the rest of the underlying MacOS is getting itself all "iOS-ified".

[OpenXTalkPaul]

How does that display menubar item / menuextra deal with 'Auto'' mode, or doesn't it support that?

I guess it's all a matter of user preference, each to their own, and all that.
I always think of 'displays' of where you manage multiple displays, or change brightness/contrast. Not system appearance themes as that's what the appearance prefpane was for... unless that's gone now in recent MacOS?

I'm not sure that 'Auto Mode' is quite the same as 'Night Shift', Night Shift is not in the Appearance Panel, it's in the 'Displays' Panel. Also if you have an iMac computers, Studio Display, and Apple Pro Display XDR then there's also another toggle setting called 'True Tone' that: "uses advanced multichannel sensors to adjust the color and intensity of your display and Touch Bar to match the ambient light so that images appear more natural". These settings seem to be more related to the overall Color Profile / Gamma settings for Display(s). They never particularly interested me. Maybe if I needed to use my laptop outside in the sunlight then these might be useful?

Screenshot 2024-03-27 at 3.11.30 PM.png (154.34 KiB) Viewed 423 times

[tperry2x]

Do any of those settings also change the colours used to draw windows in light / dark mode?
If in light-mode, the windows have an orange-ish tint, then do we need to check that OXT support that somehow too?
By the way, why are screenshots produced by Mac users (MacOS 11+ I assume) double the size (resolution) when posted?

I'm now wondering if Apple changed display resolution along the way somewhere too - meaning we have to support higher resolution graphics in all stacks to look half-decent for ...(whatever came after 'retina' screens)?

Ugh, - MacOS: Such a moving target. Almost impossible to keep up and develop for.

edit: yes, using your screenshot as an example (almost 144 dpi):

Screenshot 2024-03-27 at 19.34.25.png (204.35 KiB) Viewed 416 times

Whereas MacOS 10.15 (anything before MacOS 11) did these at 72dpi (which was standard web and screen-resolution).

Screenshot 2024-03-27 at 19.37.30.png (145.24 KiB) Viewed 414 times

[OpenXTalkPaul]

Do any of those settings also change the colours used to draw windows in light / dark mode?
If in light-mode, the windows have an orange-ish tint, then do we need to check that OXT support that somehow too?
By the way, why are screenshots produced by Mac users (MacOS 11+ I assume) double the size (resolution) when posted?

I'm now wondering if Apple changed display resolution along the way somewhere too - meaning we have to support higher resolution graphics in all stacks to look half-decent for ...(whatever came after 'retina' screens)?

Ugh, - MacOS: Such a moving target. Almost impossible to keep up and develop for.

These are features that migrated to macOS from iOS, 'True Tone' was only recently added with Ventura. macOS has been becoming more like iOS for a long time now (personally I think it should be the other way around).

Night shift was added to macOS with 10.12.4.

Looking around at a few articles I don't think app developers have any programatic control over 'night shift' or 'true tone', they likely effect the display in a global way. But 'night shift' can auto toggle 'darkMode' on/off. No answer to this question: https://apple.stackexchange.com/questio ... -dark-mode
https://discussions.apple.com/thread/25 ... ortBy=best

It doesn't look like 'Night Shift' sends any separate notification sent to apps, but when darkMode gets turned on it should send systemAppearanceChanged notification, unless Apple missed that nuance (its probably a bug). I'm not sure if there's even a programmatic way to check if it's on. iOS has app info.plist related to this.
https://developer.apple.com/library/arc ... 09252-SW31

"designers or photographers who are working with color directly can't use True Tone or Night Shift all the time. If you are needing to care about color accuracy in your work, but not all the time, then it's annoying to have to turn True Tone or Night Shift on and off. If developers had access to these settings, they could override them while an app like Photoshop is in use."

That's exactly why I turn it off and forget about it. I don''t even use it on my laptop or mobile devices iPad / iPhone where I guess it makes more sense to use it. I'd rather stick with neutral tones and just decrease increase brightness to adjust for ambient lighting.

[tperry2x]

Something else I just thought of, this will affect getting the mousecolor via script as well I assume? It'll return the wrong colour values if one of these modes are on under MacOS. I suspect there's no way to sample a colour 'underneath' the colour filter overlay layer the OS applies.

[OpenXTalkPaul]

Still looking for answers on getting 'Night Shift' notification, a few things I've read mention these being private Apple APIs.
https://stackoverflow.com/questions/455 ... -macos-ios

macOS has supported pixel densities greater than 72pixels per inch, (2x) 144ppi AND (4x) 288dpi, for quite a while now (since 10.0 actually). This is part of why I wanted to make ALL of our UI icons be SVG based, resolution independence.

There is also a related app info.plist key and there was (it seems to be gone in now) a 'Open In Low Resolution Mode' checkbox in the 'get info' window for macOS apps.
https://developer.apple.com/documentati ... guage=objc
https://developer.apple.com/documentati ... guage=objc

But the Engine does have some support for this since v.5.5 (mobile) and 6.5/6.6 (desktop):
get the systemPixelScale -- Returns the default pixel scale of the system.
get the screenPixelScales -- Returns a return-delimited list of the pixel scale of each connected display.
set the usePixelScaling to false - Determines whether or not the IDE will automatically apply pixel scaling.
Also on mobile:
get mobilePixelDensity() -- Returns the pixel density of the device screen (relative to a non-Retina display)
set the pixelScale to the systemPixelScale

And there's Extension Builder syntax too, which is 'my pixel scale'.

The possibility of running on a higher resolution display is also why there's two different splash screens, one that gets used on HiDPI / 'Retina' / 4K or better displays, and the regular 72 ppi version.

[OpenXTalkPaul]

Something else I just thought of, this will affect getting the mousecolor via script as well I assume? It'll return the wrong colour values if one of these modes are on under MacOS. I suspect there's no way to sample a colour 'underneath' the colour filter overlay layer the OS applies.

I'm not sure how exactly the Engine samples screen pixels or how Apple applies these adjustments on Displays, but unless it's done in hardware effecting pixels after they were put on screen (which could be the case), then I would imagine it might effect the RGB values from sampling a pixel on the display, as it probably should.

[tperry2x]

I just wondered if the user were relying on working with colours in OXT / LC, - let's say they were making something that represented swatches accurately, it just adds another layer of things to bear in mind.
It might be too 'niche' for anyone to care about, or maybe anyone depending on colour accuracy will turn all the interference by the OS off?

Anyway, you gave me an idea - just a simple colour swatch / picker stack (which I'll use in my properties inspector)
https://www.openxtalk.org/forum/viewtop ... 7694#p7694
Perhaps I'll also have it so you can store custom swatches, or have it suggest palettes of complimentary colours or something.

[OpenXTalkPaul]

I just wondered if the user were relying on working with colours in OXT / LC, - let's say they were making something that represented swatches accurately, it just adds another layer of things to bear in mind.
It might be too 'niche' for anyone to care about, or maybe anyone depending on colour accuracy will turn all the interference by the OS off?

Anyway, you gave me an idea - just a simple colour swatch / picker stack (which I'll use in my properties inspector)
https://www.openxtalk.org/forum/viewtop ... 7694#p7694
Perhaps I'll also have it so you can store custom swatches, or have it suggest palettes of complimentary colours or something.

I still work in a not-too-small of an industry that does care very much about color accuracy, and we have that stuff turned off on workstations. Then again with print there's never really been accuracy between RGB screen color and printing colors (CMYK+Spot colors). Even if you've used all sorts of X-RITE colorimeters and such to calibrate everything, there is always a conversion from additive color (RGB) to subtractive color (CMYK+) happening at some point, with some sort of gray component replacement (GCR) and/or under color removal (UCR) formulas, to determine 'black' component generation, also being involved. With some special inks, like reflective or metallic inks, there's simply no way to represent that on a screen accurately.

However, I don't think anyone is going to be trying to use OXT for color accurate printing stuff. Heck, as good as it is, I wouldn't try to use GIMP for that either (last I checked it still didn't even have a built-in CMYK color mode).

I think HH did some work on that sort of thing, generating color sets, complimentary colors and such.