OpenXTalk Lite 0.92 Download Links...

[OpenXTalkPaul]

I think that we can heighten the revPreferencesGUI stack to 600 pixels without any worry.

The requirements 9.6.3 are still 1024x768 and I'd like to stick with that, 600px vert. should be fine unless you have like a Netbook from around 2010 (1024x640 IIRC). I think I made it just slightly larger than it originally was, but it would be nice to have more room for more preference controls.

[tperry2x]

If you build something to replace it that's entirely new from scratch that would be great. I'd be interested in testing that.

I wouldn't get your hopes up too much.
I'm not yet sure I have the necessary skills.

Screenshot 2.png (57.69 KiB) Viewed 3821 times

It's nice and responsive at picking up on whatever object is selected, across whatever stack is open in the background though.

[OpenXTalkPaul]

Not used here but just a reminder that : put the systemVersion, may not return correct info, on Mac BigSur+ it returns 10.16) in OXT. In macOS Native Tools there is a replacement: macOSversion() that is accurate (returns 11.x on BigSur).

Sorry, I'm being incredibly dense - whereabouts would I find that?

I rolled that into OpenXTalk DPE (should be in the DP4 dmg build), it's the extension builder library that enables macOS native darkMode (amongst a handful of other misc. macOS specific tricks). One of the things I put in there (and then forgot to add inline docs for) was a function macOSversion() that, behind the scene, uses the shell function to get the accurate info (from the same place macOS installer gets it). I just did that as a stop gap measure, Apple should have that all straightened out by now in newer macOS (12+)

Here is my Repo for 'Mac-Native App Tools":
https://github.com/PaulMcClernan/OpenXT ... -App-Tools

[OpenXTalkPaul]

I suppose you make this stored in an external file and load the name from there, but that seems like unnecessary disk file read operation to me.

True, although it could be argued that the about file is being read anyway to populate the text in the about stack, so that is when it sets this variable. So, no additional disk-read and it takes less than 500 milliseconds. (in fact, there were additional & unnecessary waits in the home stack which I've removed, so it more than compensates for this).

Yeah, I've noticed those long waits in there, why not just use wait 0 seconds to queue whatever send message? it seems like they may be in there to ensure there's no locking problems (?) and/or to delay the saving of revprefrences stack, I guess so that it's less noticeable when it saves? I too have tried to shorten or take some unneeded (lots of log file writing commented) that stuff out in order to speed up launch time...with mixed results. The behavior scripts for the original Start Center, which would previously launch immediately after Start Up chain finished, did not seem to like it when I adjusted some of those delays. That was a catalyst for creating a brand new Start Center (I based that more on 'Welcome to HyperCard' than it is the LCC Start Center, although I did try to incorporate the demos and such from that as well).

But if it all gets read in at the same time as the about.txt into a global property or whatever then that could be helpful when making variation builds (OXT Retro PowerPC ), or any other time that we want to use the IDE variation's name in a Stack (perhaps something like: put the cIDEName of stack revpreferenes into tMyIDEsName).

[OpenXTalkPaul]

Well, this is something I raised in the past on here. In fact, I think it was one of my first posts.
I am pessimistic until proven otherwise when it comes to people I'm afraid, so I did mention about the fact there is no legal reason as to why they can't just borrow what they feel like. Morally, it's objectionable, but then nobody can take them to task over that.

I doubt that they would, but they are perfectly welcome to pinch whatever they like from OXT as long as they publicly release any modifications to those files that they make, in accordance to the GPLv3 license the Community code base operates under...

Actually, that REALLY makes me wonder about the legality of any changes to any of the IDE scripts that they may have made changes to between Sept. 2021 and now that haven't been made pubic? I mean I assume they're working from the same IDE files, correct? So those files are still subject to GPLv3, No? There's a few changes that I know that they've made, that we can make, eventually will make, but haven't yet, that could save us some time and trouble. I'm thinking of things like the Android standalone building scripts that utilize Androids SDK, that have been updated for Google's latest Play store requirements (I actually want to go the other way a bit and maintain support of OLD android devices).

Like Gaskin said, IINAL! But there may be lawyers that help FOSS projects ( I'm think of FSF or EFF people ) that we might be able to get help from? I don't know. I think I would prefer to go it alone and not worry about what they're doing 'over there', and not complicate things.

[FourthWorld]

I wouldn't lose any sleep over imagining LC Ltd will be pilfering code. This code base is GPL, so any new additions are GPL. Sure, it's expensive to litigate, but what would be so valuable here that they'd even risk it, or the reputation hit?

Besides, they don't even accept tested some tested bug fixes. I can't imagine anyone there has time to bother poking around in this old code base.