Tools palette options

[mwieder]

If developers want to opt out of that, as a special use case for example like the synth programs I mention above - or even toast / nero, games, anything really... Richmond's Devawriter stack for example... then perhaps I'll simply add an option to that appearance menu the user can choose called "ignore default IDE theme in this stack". That way you could apply it to your special use case - your tools, where you perhaps always want it in dark mode, as you are overriding what the rest of the system and IDE is doing.

That's what I did in my experimental patch to you OXTLite home stack. Set a custom property (uDontSwitchDarkMode but that isn't supposed to be a definitive property name) which if true will ignore the setting. I'd still rather do things the other way around (if the uAllowThemeSwitching or whatever is true then...) because it makes it easier to bring things over from the LC ecosystem, especially stacks I didn't create myself.

But either way, dispatching a message to whatever stack asking it to switch themes is the way to go. If the stack supports switching then it will, otherwise the message just gets ignored. So it goes.

[tperry2x]

I'd still rather do things the other way around (if the uAllowThemeSwitching or whatever is true then...) because it makes it easier to bring things over from the LC ecosystem, especially stacks I didn't create myself.

With that situation, here's some more random logic of mine - please don't take offence, this isn't meant to come across as abrupt, ascerbic or terse:

How many other stacks do you think users will potentially bring over from Livecode? - (A genuine question) especially with it already being potentially incompatible in lots of ways. (They will likely have to make changes to their stacks anyway) - especially as the gap between LC and OXT widens.

Within that number of stacks being brought over, how many of those that rely on being in dark mode do not have these set in script or via the inspector? Additionally, how many stacks with a custom theme are just relying on it looking that way by a happy accident? - probably none I'd guess as they would have been designed to look a certain way.

It wouldn't seem unreasonable for a user to have to choose to opt-out of the defaults, rather than opt-in to the defaults. To me, opting out of the defaults (the system theme and the rest of the IDE) makes more sense. No different than when you choose to override the default stack colour, at that point the user has consciously made a decision to go for a non-standard interface.

Edit: Perhaps you can give it a go and see what you think.
(I'm hoping at the very least, it gives you a way to feel reassured that your stack will look how you set the colours in future).
As I'd particularly like to incorporate your work on the script editor, and probably other things in future.

If you run the updates, it'll take you to build 202406212252 of OXT Lite 1.05 (please quit and relaunch if it doesn't do this for you - but it should).
Afterwards you'll have this new option:

a.png (49.08 KiB) Viewed 4434 times

If you have the stack open that you have set specific colours on, then choose this option - you'll get:

b.png (18.92 KiB) Viewed 4434 times

If you say "Proceed", then the custom property is set on that stack:

c.png (14.38 KiB) Viewed 4434 times

You can then add custom colours to your stack - designing your own interface, without OXT Lite attempting to match the IDE / or system theme for it in future.

Edit: just spotted I've mixed my American and UK English spellings of colours in the alert. I wish OXT was localised. I'll go set them both to 'colors' in those dialogs now.

[mwieder]

Edit: just spotted I've mixed my American and UK English spellings of colours in the alert. I wish OXT was localised. I'll go set them both to 'colors' in those dialogs now.

Are you still planning on following the path of setting all the object color properties to empty on compliant stacks? That's the behavior I'd like to quash. I think the actual changing of visible coloration etc should be up to the stack itself, and the only task for the IDE is just to dispatch the message to tell the stack to change. Don't even need a custom property for that.

Just dispatch a "themeChange" message to all stacks with true|false or with a theme name and you're done.

[tperry2x]

To be clear, it only removes custom colours of stacks (the nullify message) if you have it set to default, or if you are on Linux where the system colour theme is adhered to and followed throughout the entire IDE as it's default behaviour. That's not something I added. That's what the engine on Linux does (like any other program), and I wish MacOS and Windows versions of the engine did the same.

I'm just trying to think how I can phrase this in a better way. I'm interested with the various parts of the IDE looking like they belong together. Not one stack that's part of the IDE hardcoded to be white, when the user has chosen dark mode (or even vice-versa).
Let's say a Mac user has their machine in standard light mode. They open OXT Lite for the first time. The initial impression should be one of consistency. Not "why are some bits in light mode and some bits in dark mode?" All various parts of the IDE should at least match.

If the user is designing a stack with custom colours in mind (I'll use Richmond's devawriter stack as a good example again) where he might have a custom stack colour - because he wanted it set that way, and designed it that way on purpose - then he made a deliberate decision to set the backgroundColor of his stack to something other than the default. This is all well and good. I've got a few stacks / projects where I've purposefully done the same thing. But, I made that conscious decision when I was designing it to go with a non-standard theme. This was an exception, not the norm. The norm would be to inherit the system theme (matching the colours of the system - the same way other programs do).

With this override option, If you set the override (once) on your stack if you are using a custom interface, then you are good to go. I honestly don't see the issue with that. OXT Lite won't tinker with your colours after that, no matter if you are in default, light or dark mode - because you told it not to with the override...

Why go through all the stacks in the IDE, specifying them to 'Allow' a change when that's already the default behaviour? The abberation is the niche cases where you'd want something different to the norm, in which case you use the override.

But it's quarter to midnight here, so probably best I pick this up another time if need be.

[mwieder]

Well, there's clear and there's clear.

That's not something I added. That's what the engine on Linux does

What the linux engine does *not* do is change the properties of applications. Simple inheritance does the trick.
What you're explicitly doing, and what I'm pushing back against, is going through every object of every stack and setting the color properties to empty. If they're already empty in the stacks then theme changing will happen as expected. If not then the stack designer no doubt intended a different visual aspect.

That's all for now. Get some rest.

[tperry2x]

...If not then the stack designer no doubt intended a different visual aspect.

Yes, that's where they'd set their own visual theme.
Where they'd use the override once.

Irrespective, when designing a stack - should it not be able to change it's colours on-the-fly anyway to match what the rest of the system is? For example - the Inspector I'm making, it changes the buttons to light or dark depending on what the background colour which it inherits from the rest of the IDE is. Inheritance only works after all if the object does not have it's own custom colour property, which would override any inheritance.

Or just set everything to a neutral grey of 127,127,127 and be done with it

[OpenXTalkPaul]

But yes to having a stack custom property.

So if it's going to be a stack property but different from 'darkMode' as boolean, I'll remove that. Nothing was ever implemented that actually used it anyway, adding the 'darkMode' property was more or less a proof-of-concept / placeholder for the idea.

A theming or color-oriented library could check for theme changes from the OS level on resume, then if need be it would check all open stacks for this property and send them 'whatever' (systemThemeChanged ? ) message depending on that properties (boolean) value. That was kind of the way I thought it might work. Alternatively it could use a publish/subscribe pattern?

[mwieder]

While I like the publish/subscribe option, I'm in favor of the approach that has the least impact on existing stacks.
Pubsub would require each stack that gets the mode switch message to explicitly subscribe to it.

And that's ok if our approach is to send the darkmode switch *only* to stacks that requested it.

I'm fine with"darkMode" as the boolean, but I don't really care what we end up calling it.
The way I implemented darkMode in PowerTools is just

Code: Select all

on darkMode
# code goes here
end darkMode

so on resume the home stack could

Code: Select all

dispatch "darkMode" to stack <stacknamehere>

with no boolean needed. Dispatch is nice that way.
And note that parameters could be added to set the foreground/background colors to something else as well.