OpenXTalk Forums

Umm... did I miss something?

Yes, you did: the 'packaging' bit was for what the late lamented Dame Edna Everage termed 'the tinted races'.
- -
And I understand to mean would-be OXT programmers of any colour, gender, sexual preference, and all the rest of the politically correct bumf, who do not have access to the internet most of the time: so they are guaranteed a web-browser that can sit on their 'box' and work with their browser-based version of OXT.

For the sake of argument, I can see myself in 7-8 years time sitting in Port Logan (my fantasy retirement location) with a totally crap (come on, BT . . . I mean, and the much vaunted 'Broad Band' that is about 10% of the speed of the cheapest internet I have in Bulgaria) internet "service" wobbling away with a browser-based version of OXT . . .

https://en.wikipedia.org/wiki/Port_Logan

Back to our reading:

Using the show cards command to show less than one card will no longer cause a crash

Erm: how can 'show cards' show LESS than one card?

richmond62 wrote: ↑Fri Jun 21, 2024 10:50 am Erm: how can 'show cards' show LESS than one card?

Can't say I've ever tried it. However, I'll give them that one: it does indeed crash immediately.

So, we can learn from across the river.

richmond62 wrote: ↑Fri Jun 21, 2024 11:09 am So, we can learn from across the river.

All that's really relevant in that release note blurb is, dont attempt to show a card by referencing it with a negative number. The rest seems a bit... meh. It's largely irrelevant because we don't know what they did to fix it, and they aren't going to tell us. So I don't see what we can learn.

Which, is exactly the situation we are in with the menus and MacOS Sonoma +

It's largely irrelevant because we don't know what they did to fix it, and they aren't going to tell us.

Well, I would assume that IFF they can 'fix' (as in 'sort out') it, so can someone else.

AND, I would not doubt that were one to download 9.6.12 one could poke around inside and learn one or two things, which one, of course, would not copy, but could effect in a slightly different way . . .

richmond62 wrote: ↑Fri Jun 21, 2024 11:45 am I would not doubt that were one to download 9.6.12 one could poke around inside and learn one or two things...

Unless of course they fixed that in the engine, because that is effectively closed-source now. Which, again - is exactly where we are with the MacOS menu issue.
Oh, and also the systemversion as far as MacOS is concerned too.

As myself and Paul have mentioned many times, this is why we are in favour of externalising everything - moving everything out of the engine as much as possible. So if you need to change something, you don't need the recompile.
Yes, I know you can use my tsystemversion But, not everyone may know that.

Well, unless you look you won't know.

Personally I use a disposable email each time to have a peep at each commercial release.

Dunno what this is meant to do:
- -
This does nothing:
- - -
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.

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.

The dictionary would suggest:

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

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.

richmond62 wrote: ↑Fri Jun 21, 2024 12:15 pm 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.

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.

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.

[/attachment]

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.

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
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.

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).

Ah. You mean this one?

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.

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

Note to self...

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.

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.

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 your special use case - 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