on darkMode
# code goes here
end darkMode

dispatch "darkMode" to stack <stacknamehere>

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]on darkMode
# code goes here
end darkMode[/code]

so on resume the home stack could
[code]dispatch "darkMode" to stack <stacknamehere>[/code]
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.

[quote=mwieder post_id=9221 time=1718996452 user_id=1734]
But yes to having a stack custom property.
[/quote]

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?

[quote=mwieder post_id=9235 time=1719011017 user_id=1734]
...If not then the stack designer no doubt intended a different visual aspect.
[/quote]

:| 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 :lol:

Well, there's clear and there's clear.
[quote]That's not something I added. That's what the engine on Linux does[/quote]

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.

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 [i]other[/i] 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.

[quote]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.[/quote] :shock:

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.

[quote=mwieder post_id=9229 time=1719003469 user_id=1734]
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.
[/quote]

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 - [url="https://www.tsites.co.uk/otherstuff/linux-updates.mp4"]but it should[/url]).
Afterwards you'll have this new option:
[attachment=2]a.png[/attachment]

If you have the stack open that you have set specific colours on, then choose this option - you'll get:
[attachment=1]b.png[/attachment]

If you say "Proceed", then the custom property is set on that stack:
[attachment=0]c.png[/attachment]

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.

[quote]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.[/quote]

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.

Okay, will definitely implement the custom property thing.

Here's my logic on it.
If you were in any other IDE, you'd expect your interface to follow what the rest of the system was doing. You'd expect it to match. (xCode for example) - Apple have been going to great lengths to stamp out custom theming as much as they can for example, as they wanted the programs to match the system.

You'd only specifically opt-out of following the rest of the system and the matching IDE if you wanted to implement a custom theme.

For example, like various music synth programs that have a completely custom interface - they've opted out of following the system scheme and purposefully programmed their own interface. These are the exception though, and not the norm.

This was my logic with the theming. The IDE should match the OS where at all possible (and should at least have an option where the user can choose to match the system theme as closely as possible) - which it does - hence my options of appearance mode choices. You can match the OS (manually), or you can at least test what your stack would look like in light / dark mode.

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 chosen IDE theme in this stack". That way you could apply it to [i]your special use case[/i] - your tools, where you perhaps always want it in dark mode, as you are [potentially] overriding what the rest of the system and IDE is doing if the user has the rest of the system & the IDE in light mode.

In the same way that you set an itemdelimiter - you don't automatically assume that its set to , or / instead you intentionally specify it so you know it's set correctly. Same logic with designing an interface? If you want a custom appearance, you'd either set these colours with the inspector or in script, and choose "ignore chosen IDE theme in this stack".

If your stack absolutely had to look the same across all platforms, surely you'd specifically set it that way, rather than gamble that the IDE would set it identically for each platform (because it won't) - consider all the possible themes a linux user might have installed for example.

That was my reasoning - there was logic to it, I promise :)

Why I'd go the other way:

I'd want to bring in my set of plugins (I use somewhere around two dozen) from other developers without making them change their stacks to add a custom property. I'd instead want a property that said "use the IDE theme". That way we could add it to all the OXT stacks and they'd all follow the theme change, and thirdparty developers would have the option.

But yes to having a stack custom property.

I'd probably go the other way and suggest that all stacks should match whatever the rest of the IDE is doing.
Whatever colour is chosen, which is what happens in OXT Lite.

However, what I might think would be worthwhile is having an override.

I could have a custom property set on the stack called "dontTheme". If it's set to true, then oxt lite skips it.

There's lots of custom properties set already as default on new stack creation. Loads involving revGeometry - something I noticed when building my new properties inspector which the standard inspector tries to hide from view.
Having a custom property set does not slow it down and won't incur any extra messages being sent.

However it would allow you to completely skip theming for any given stack really easily without needing to tweak the ide code.

Just a suggestion.

[quote]FYI, the IDE will likely spontaneously quit if you switch themes in Linux with it open.[/quote]

Note to self...

Yes, exactly. If you run OXT Lite in MacOS or Windows, you'll be able to choose the light or dark options.

FYI, the IDE will likely spontaneously quit if you switch themes in Linux with it open.

Ah. You mean this one?

[attachment=0]defaultonly.png[/attachment]

Um, I don't know if this has been overlooked - but on OXT Lite - have you tried setting appearance themes from either the Preferences > Extras, or via the View menu > Appearance?
That way you aren't stripping the foreground and background colors from all stacks and thus inheriting the colorization from the IDE.

Oh, and as Linux inherits colours from the underlying OS, that's why the options in Linux are disabled on purpose. (Handled by the system appearance).

[/attachment][quote]Anyway I can't worry too much about what LC is doing, although I don't think they would break backward compatibility with v9 engine for no good reason. OpenXTalk here is a separate xTalk project now so I'm not going to worry too much if something I do breaks compatibility with LC, although I do want to avoid that if possible.[/quote]

To get things back on track...

I'm not concerned with LC compatibility for its own sake. What concerns me is the community that's built up over the last 20 years and what might interest someone who's invested time/money/resources/etc in stack development to possibly look at OXT. If the first impression is that things are breaking right from first launch then there are maybe a half dozen of us here who are even going to take a second look.

Given OXTLite's experiment of stripping the foreground and background colors from all stacks and thus inheriting the colorization from the IDE, here's what 4wdevolution looks like and what it *should* look like

[attachment=1]4wOXTLite.png[/attachment][attachment=0]4wNormal.png[/attachment]

When LC gives up the ghost I'd like to see OXT being the carrier of the flame. (sheesh... any more metaphors I can mix into that?) And to do that I think we need to make as seamless a transition as possible. Yes, there are a lot of system messages being passed around but I don't really see much of a way around that.

So while I see supporting dark mode as a worthwhile goal I think we should provide the mechanism for it (i.e., Paul's idea of catching the resumeStack message) and then leave it to stack designers whether to support it or not.

Looking at my ancient copy of the HC documentation the "show cards" command was indeed in v1. I don't remember ever coming across it before and can't conceive of a use for it with or without a number specified.

[quote=richmond62 post_id=9197 time=1718972159 user_id=53]
Dictionary; "Use the show cards command to do "flipbook"-style animation or to display a number of cards quickly to the user."
...
Or, put another way: let's list 'improvements' that have little or no significance so things look impressive.
[/quote]
What you have is a question: "Why was the 'show cards' command included?"

That command was introduced in very early versions of HyperCard, possibly as early as v1.

It was seldom used even there. I think it may have been used in "Inigo Goes Out", and I've seen it in at least one other stack, but not many.

Later xTalks included it for the sake of completeness, to maximize compatibility with the Mother Tongue.

SuperCard may have included it, and IIRC OMO did.

And so did MetaCard when it came along years later in 1992.

In 2003 MetaCard was acquired and renamed Revolution, since renamed by the same company to become LiveCode.

The culprit here, if there needs to be one, would be Apple.

Implementation in any later xTalk isn't an "improvement" at all, just a good faith effort to reduce pain points when importing stacks from the first xTalk.

The dictionary would suggest:
[quote]Use the show cards command to do "flipbook"-style animation or to display a number of cards quickly to the user.[/quote]
Probably why I never used it.

Haha, ditto.
Certainly not worth the hassle of trying to pull any part of 9.6.12 apart as far as I'm concerned.

Dunno what this is meant to do:
-
[attachment=2]SShot 2024-06-21 at 15.15.11.png[/attachment]
-
This does nothing:
-
[attachment=1]SShot 2024-06-21 at 15.16.57.png[/attachment]
-
[attachment=0]SShot 2024-06-21 at 15.18.41.png[/attachment]
-
Why was I born so beautiful?

Dictionary; "Use the show cards command to do "flipbook"-style animation or to display a number of cards quickly to the user."

Well, I got a wee, almost undetectable 'flash' from card 2 (a 2 card stack with the second card coloured red).

Obviously a load of Bollo at the best of times. 8-)

Or, put another way: let's list 'improvements' that have little or no significance so things look impressive.

I tweaked a hair out of my left ear this morning. 8-)