OpenXTalk RC4 testing...

[tperry2x]

Thank you Paul,
Much appreciated for pointing me in the right direction.

excellent.png (152.37 KiB) Viewed 1292 times

I will make this a toggle in the preferences stack I think.

[tperry2x]

I was thinking a 'darkMode' aware, IDE theming library could be added this way.

That would be amazing, if only to give some much needed consistency on the Mac and Windows versions (as they are lagging behind compared to their appearance on Linux). Any app should at least respect the default OS theme in my opinion.

I don't see this as an additional feature per-se, more of a basic prerequisite that all apps should adhere to out of the box.
I don't know why LC left it out as back when 9.6.3 came out (30-07-2021) as far as I can tell (source: https://www.forums.livecode.com/viewtopic.php?t=36155), people had the option to switch between dark and light modes for 2 years before LC 9.6.3 was released. (Windows 10 had the option from April 2019, and Macs didn't get the option until October 2019).

I have another question for you Paul if I may.
With the inks, you can set srcCopy and such. Is there any way to control the saturation of a graphic? Such as a desaturate mode? The reason I ask is I'd like to offer the option of choosing between colour and mono icons. Rather than loading in various images, having to restart the GUI possibly, and having the added bloat of extra button images everywhere (which Richmond rightly points out, will add quite a lot of heft to the size of the program), I'd like to be able just to set the saturation to 0 so that I can take the saturation out of the graphics via script and toggle it back on again if needed.

[FourthWorld]

I was thinking a 'darkMode' aware, IDE theming library could be added this way.

That would be amazing, if only to give some much needed consistency on the Mac and Windows versions (as they are lagging behind compared to their appearance on Linux). Any app should at least respect the default OS theme in my opinion.

I don't see this as an additional feature per-se, more of a basic prerequisite that all apps should adhere to out of the box.

I'm not sure a library alone would be sufficient. Controls are sometimes drawn differently, in ways beyond the script interface.

The engine should be modified to use OS rendering for the specified mode.

[OpenXTalkPaul]

I was thinking a 'darkMode' aware, IDE theming library could be added this way.

That would be amazing, if only to give some much needed consistency on the Mac and Windows versions (as they are lagging behind compared to their appearance on Linux). Any app should at least respect the default OS theme in my opinion.

I don't see this as an additional feature per-se, more of a basic prerequisite that all apps should adhere to out of the box.

I'm not sure a library alone would be sufficient. Controls are sometimes drawn differently, in ways beyond the script interface.

The engine should be modified to use OS rendering for the specified mode.

I'm not sure what you mean here, the engine should already inherit fore/back colors from the system. The Fonts can be tricky because of variations of sizes, but the 'system' font selections (which seem arbitrary on Linux, and should changed based on macOS version on mac) are already currently in the IDE as scripts / string literals (not part of the engine).

Unless you're talking about the built-in "standard" controls which appear to be emulations of 'native' control appearance (and still includes emulated macOS classic and Windows 95 appearances if anyone wants to use those). Those we could sculpt to include variations for various OS versions. I included a NEW-'classic' control in OXT DPE (my attempt at matching a modern BigSur macOS gray-filled button) as a sort of proof of this concept, created merely by editing a few IDE default property files (those tab-separated-values files, which can be edited in a Datagrid, in Apples Numbers, in MS Excel or similar).

[OpenXTalkPaul]

needed consistency on the Mac and Windows versions (as they are lagging behind compared to their appearance

The problem with Windows 10 AFAICT, is that there's no real API for dark windows frames, only the included MS apps have that (private) feature. Windows 11 however, I believe does have a system-wide API for darkMode available for devs to use.

[FourthWorld]

I'm not sure a library alone would be sufficient. Controls are sometimes drawn differently, in ways beyond the script interface.

The engine should be modified to use OS rendering for the specified mode.

I'm not sure what you mean here, the engine should already inherit fore/back colors from the system.

What the engine should do and what it did as of Aug 31, 2021 may not be the same thing. My request is that they become so.

[richmond62]

I have a feeling that a lot of people round these parts are being plagued by a large dollop of 'should'.

[OpenXTalkPaul]

The engine should be modified to use OS rendering for the specified mode.
---
What the engine should do and what it did as of Aug 31, 2021 may not be the same thing. My request is that they become so.

What I'm saying is that it already does this for the most part, at least it does on macOS, as long as the text chunks, fld objects/stack/card are set up to allow for the inheritance to happen. A lot of changes I made for 'darkMode' were removing colors / setting colors properties to empty. This way when the OXT Native tools lib applies the native macOS 'darkmode', and there's actually been two variations of these 'modes' from Apple, like dark regular and nowadays dark 'vibrant' (because it's not just about changing colors, there's things like luminosity and contrast, dynamic system palette colors etc.). It seems many UIs these days are made up of line-art glyphs, I suspect dark/light toggling is the underlying reason.

Widget extensions can be crafted in such a way that they can inherit this drawing fill color auto-toggling, by using Builder's shadowing of 'foreColor', 'backColor' etc. using LCB's 'my foreground paint'/'my background paint' as fills/strokes in the widget.

In the repo I found there were example widget controls that would change appearance based on the platform and platform version. It seems as though at some point their idea was to replace the 'classic' controls with widgets that could be more dynamic and/or consistent appearance wise. I actually started to build up a collection of classic controls as widget redux, checkboxes, radial btns, slider, progress bar, etc.

[tperry2x]

Thanks Paul
I've been looking through the code and it does all make sense.
I've now added dark mode support to OpenXTalk lite (In the MacOS dmg version I uploaded this evening), based on your code from the RC4 version, so thank you for that.

I can see what you mean, you'd essentially cleared any custom colour settings and set them to empty.
I have since found a weird thing in dark mode on the Mac. When dark mode is on, the preferences stack looks weird. I think that's because for some reason it's set to render in 'legacy mode' (whatever that is). I don't know why the folks at LC decided that was needed, but I'll have to have a further ponder on that one.

As always, my changes are on my site, so someone can always build their own if they don't want dark mode or want to miss certain bits out. They can start with LC Community 9.6.3 (https://community.livecode.com/9_6_3/) and make their own from there as they see fit.

All I'd ask is we continue to do what we are all doing, and anything good or noteworthy, we carry on posting on this forum.

[richmond62]

Sometime aspects of the LC IDE such as rendering in legacy mode seem not so much conscious decisions on LC's part so much as oversights.

The IDE in the version 9 series contains stuff left over from the version 2 series, which in some cases is clearly redundant.

This, I think, should be ascribed to carelessness resulting in bad housekeeping, as the team have run hell-for-leather to introduce new capabilities rather than retrenching and putting their existing house in order.

[overclockedmind]

I have two machines; the quick one is Windows 10 Pro x64 (and when it's not supported, I'm going back to Linux. Blasted gaming.) The other is a 2015 MBA 8GB/512GB running Monterey.

What do I need to do for the Monterey Mac, will it Just Work?
What do I need to do for Windows, run the Lite variant?
Been gone a loooong time.

I have another post that I'm gonna delete.

EDIT1: Deleted
EDIT2: Of course, I don't mind testing on both platforms, and reporting back.
EDIT3: Went to Lite for Windows. Seems plenty workable for me, atm.

[overclockedmind]

I dunno what happened there.

Run Me First was "damaged," so I killed Gatekeeper and used another browser for download. Disc verification proceeds just fine, btw. Tried Run Me First in Applications, nah bro still damaged. So I just ran the main app and got the LiveCode thing, with skipping registration a possibility... like I'm sure you're NOT supposed to see.

Maybe not runnable on runnable on Monterey 12.7.2 (21G1974)?

EDIT: There was something different between those two apps that I remember seeing in Get Info, a Universal one, and something else. I'm guessing you probably know this and it is because of the build-target for the two of them, but I digress.

[tperry2x]

Hi Joshua,
Welcome back and happy new year.
I've just uploaded version 0.98 of OpenXTalk Lite.
Please can you give that a go and let me know how you get on.

Many thanks.
https://www.openxtalk.org/forum/viewtop ... f=16&t=590

[overclockedmind]

Hi Joshua,
Welcome back and happy new year.
I've just uploaded version 0.98 of OpenXTalk Lite.
Please can you give that a go and let me know how you get on.

Many thanks. En route, anything I'm poking at in particular?

https://www.openxtalk.org/forum/viewtop ... f=16&t=590

[tperry2x]

Good question. It really depends on where you are picking up from and what version you'd used last.
I've popped the changes here
https://www.openxtalk.org/forum/viewtop ... 4646#p4646

This should give you a rough idea what's been changed and where. (Please run the updater if you are on 0.98 as there's been some additions since it's release).

I'd be grateful to know of anything you find that's not working. While I do have a focus on developing something else 'long-term', I do still want to support OpenXTalk Lite for as long as I can. I just might not be taking such a dedicated role in it as I was and will let someone else put their name against the v1.0 moniker for reasons I've rambled on about elsewhere.

TLDR version: because I still believe it to be at beta quality, despite all my work. There's only so much I can achieve.
Anyway, it's half-past midnight here, so I'm going to call it a night. (morning )

[tperry2x]

Hi Paul, I was just thinking about the RCx versions of your OXT build.
I'd be interested to try it out, no matter what state it's in. As you know, I spend 85% of my time in Linux, 10% in Windows and probably %5 in MacOS.
I wondered if making appimages is a bit of a pain for Linux, I'd be happy with just a 7z directory (which is essentially what my OXT Lite builds are), with everything inside as normal.

Or alternatively, if we could have a Linux and Windows release of RC5, alongside the MacOS one when the time comes, that would be hugely appreciated.

Many thanks.

[overclockedmind]

I assume you two are rather casual with each other. I asked him about this on Facebook and got:

https://github.com/OpenXTalk-org/OpenXt ... n/releases

I'm sure it's fine for you to have it.

[richmond62]

September the tooth is a fair way back in terms of what has been done since then:
-

SShot 2024-01-10 at 11.11.44.png (5.96 KiB) Viewed 609 times

[richmond62]

And this made me feel a bit odd:
-

SShot 2024-01-10 at 11.22.56.png (109.18 KiB) Viewed 604 times

-
MacOS 14 Sonoma

Started up RC4, which, after the splash screen crashed.