What I'm adding, and what I'm planning next...

[tperry2x]

Well, this is unexpected - and quite welcome.
By using my custom window buttons on the inspector, it has the side-effect that it also fixes the effects palette (it no longer glitches out with repeated uses). I've been back in to edit this drop shadow about 7 times now

unexpected.png (214.18 KiB) Viewed 1545 times

[micmac]

Sorry to say Tom, but it is the same as before.

I might work if you repeatedly open and close with the same object selected.

But if you click in the stack the same problems arise a I reported before:

Shadow option window will not come to front and the shadow option window becomes unresponsive.

Mic

[tperry2x]

Sorry to say Tom, but it is the same as before.

Hi Mic, That's not in v1.10 - it's in my upcoming v1.11 version (where I swap the window controls). I haven't tweaked this in v1.10 - so yes - that will be exactly the same as it was before.

[tperry2x]

Just to save confusion, anything I added to v1.10 is detailed in the release notes on the download page.
These posts are additional progress after the release of v1.10. (stuff I'm working on and adding next)

I won't do the window tweaks through the updater - I'll probably do new downloads for v1.11 (as I want to include engine changes too).

[richmond62]

I am just downloading 1.10 onto my MacOS 12 machine at home.

I will be extremely surprised (given its trouble-free behaviour on MacOS 15) if it misbehaves on MacOS 12.

By way of a pat on the back: despite all your "frothing at the mouth" about MacOS (quite a lot of which is justified), I am sure that you can safely feel that you have done a fantastic job getting over those hurdles.

[richmond62]

The only thing I would query (you have to allow me one thing) is this:
-

Screenshot 2025-01-08 at 12.10.21.png (459.48 KiB) Viewed 1430 times

-
"engine: 9.6.3"

I understand WHY you have done that, but I wonder if it is really necessary (especially as for Mac users it really should not matter at all that the Windows and Linux versions use engine 9.7.0) as what really matters is that the IDE functions almost perfectly.

I don't know if the GPL3 licence requires you to display that information, but I doubt it.

Also: should you, or Paul, get to the stage of getting your own engine(s) up and running how are you going to number them ?

* 9.7.0-and-following (which could be a bit problematic re LiveCode), or

1.0.0-and-following (which might make more sense: although having previously displayed 9.6.3 / 9.7.0 it might look odd).
-

Коте-мюсюлманче.jpg (68.23 KiB) Viewed 1430 times

[micmac]

Its time to add a donate button for Tom!

Mic

[richmond62]

Its time to add a donate button for Tom!

Indeed!

But that is ONLY half of it:

It is time to DONATE to Tom.

It is "dead easy" to set up a button to a PayPal account: AND I for one can see nothing wrong about having a splash screen when OXT Lite is opened asking for donations. I have one on both my Devawriter and my Sheba:
-

Screenshot 2025-01-08 at 12.31.38.jpg (280.08 KiB) Viewed 1426 times

-

Code: Select all

on mouseUp
   launch URL "https://paypal.me/DevawriterPro?locale.x=en_USPro"
end mouseUp

[tperry2x]

Thank you, that's very kind.
I'm not doing this for any financial reward though, purely because I want to see the xtalk language and a capable IDE continue to exist.

Speaking of which, you are right Richmond - I probably don't have to display the engine version in the About window - and I'm sure it's not a license requirement to do so. However, it does make troubleshooting a potential issue easier if I know what version, engine, and build people are running if they report a problem.

There are plans afoot to modify (modernise) my mac setup, and this should help with compiling the engine on MacOS (I hope) - if not, it'll at least allow me to test in a version above Catalina. I do expect a couple of codesigning issues when I move mac setup to a new dev machine, but the aim will be to get MacOS onto a matching engine - so that not just Linux and Windows are on build 9.7.0-x, but MacOS will be too. That's the plan, even if there are seemingly large hurdles to overcome.

I'm wondering about build numbering. I'm a bit stuck between a rock and a hard place here.
It's technically an engine derived from LCC, however the 'Community' aspect ceased in 2021. Having removed the "livecode" naming you'd see in a task manager (hopefully), I think I can start afresh with versioning.
However, if I gave it a v1 label - it would break a few things. There's stuff built into the engine itself, and a few IDE scripts, which check to see if the engine >6 - then do this... if it's 8 then do this... and if 9.x - do the other.... so naming it anything lower than 9 will cause issues.
I didn't want to label it v10 as this might be misinterpreted that I'm using some non-open-source version of the engine by mistake. Someone might get the idea that I somehow modified v10 engine source (which I haven't of course), but calling it 10 might raise a few eyebrows (or do I not worry?)?

At the moment, my current engine identifies itself as "9.7.0-OXT-1" which I'll be the first to admit, is a bit of a mishmash. But it sets it apart from the DP release (developer preview) and makes it clear that it's not a newer engine than I'm permitted to use, obtained via open-source license.

I'm working through the engine in my spare time, trying to spot any obvious issues. It's a slow process though.

[richmond62]

I'm not doing this for any financial reward though

That reminds me of something my Granny, from Emneth, in Norfolk, used to say:

"Don't marry FOR money, but marry where money IS."

So: if you choose to spend any donations on some LEGO for your children (one of the best ways to spend money), or to take your wife out for a good feed (another very good way to spend money), that is up to you.

This does NOT stop me having a feeling that you deserve "something" for your work . . .

[richmond62]

Wow! Whaddya-know?

I have just received an e-mail from LiveCode entitled: "Adapt Your App for 2025".

It is, of course, full of the same slightly mindless obviousnesses as 90% of the stuff in LinkedIN, but that is NOT the point.

"Success means riding that wave and adapting. How is your business evolving this year?"

No: surely not?

-

mail.gif (1.09 MiB) Viewed 1386 times

-
My problem with this animated GIF is that the person second from the right looks far fitter and better equipped for everything than the one at the end of the line, at the right.

How about adapting OXT Lite at least to the extent that it might attract a spot of revenue to allow "the person we know and love" to pop out and buy themselves an M4 Mac Mini!

[tperry2x]

"Success means riding that wave and adapting. How is your business evolving this year?"
No: surely not?

Was that email really sent out with that badly looped gif in?
(who wants to receive a 1MB gif in an email.. uh, nope)

It's a very tenuous link, and I would agree - the second from the right looks more capable than the one at the end. What that has to do with anything is very vague.

"How our business is evolving this year", as it turns out, is that there's a huge tightening of budgets and the minimising of subscriptions. There's a return to on-prem solutions where possible to keep everything in house (as employing someone who's more responsive to deal with issues, is better than having a contractor on standby who might only get the issue resolved after a week). An about-turn away from cloud-hosted anything, where privacy and security matters. Keeping it in the building means you can keep an eye on it.

[tperry2x]

How about adapting OXT Lite at least to the extent that it might attract a spot of revenue...

It's an idea, but I didn't want OXT lite to become a program that is requesting funding. I didn't want it to become 'needy'.
It's quite a rarity these days to open a program and not have it beg for a donation, or to send a whole dump of telemetry information about the user's system back to the developer when it tries to 'phone home'.
Or for it to stop working, because it demands you MUST do an update to continue running it, or some other BS tactic.

OXT does none of those things, and I'm keen to keep it that way. You could download 1.10 for example, and use it until it would no longer work (because of something else changing on your system, but not because of built in obsolescence or any forced mandatory upgrade shenanigans) I want it to be an 'open it, use it, make stuff with it' kind of program, and want it to keep itself out of the way as much as is needed.

My opinion is that we should save the donation messages to these forums, and keep OXT Lite free of requests for donations (that's just my opinion). That's the exact reason I really detested that great big green "Upgrade" button that comes as part of LCC. An open source program should not be begging for money in my opinion. At that point it becomes 'nagware' at best, or a 'pup (potentially unwanted program)' at worst - and would be headed for the bin.

That might sound like I'm trying to be some kind of purist or something, but I'm keen to keep the IDE as light and minimal as possible. Partly why I'm going through the engine, but I'd ideally love to refine what's actually needed and what's not used. I have an idea for this actually. An "IDE Handler Log" mode. I'll create a post and go on about that more in a moment...

[tperry2x]

Sorry - real life occurred.

IDE Handler Log
My idea was that, a bit different to the way the message watcher works, I wanted a preference you can turn on.
Probably under a new section called "IDE Properties".

Then a checkbox which says "Store IDE handler usage".
If this is turned on, it'll collect a text log of what handlers and functions are called during normal operation of the IDE. The idea of this being, that I can then see "EVERYTHING" that actually gets called - all functions, all handlers etc.
Then - if something isn't in the list - I can look at deleting it. I think that's going to be the only way I make sense of this 'interwoven' approach the IDE uses. (It sends so much to revIDELibrary that editing that stack is now getting a bit laggy).
Rather than overloading the IDE with functions and things, I want to start de-junking it as much as possible.

The idea is this would also include a timestamp (the ticks) or even (put the milliseconds) && handlerName - into the log file. This way, I can also sort by the milliseconds to see the 'chain of events' if you like - what happened when you chose a certain thing in the IDE, where it went off next in the script path and what chain of events it followed.

The aim of that would be helping me / anyone to actually debug the IDE somewhat. Also handy if there's a spontaneous crash as you'd just look at the last few lines of the "IDE handler usage.txt" file.

[tperry2x]

It might work if you repeatedly open and close with the same object selected.
But if you click in the stack the same problems arise as I reported before.
Shadow option window will not come to front and the shadow option window becomes unresponsive.

Hi Mic. Please see this post. I think I've fixed it, and the update should be available now.

[OpenXTalkPaul]

Got this pup today from a mega-corp software updating on latest macOS and then using the eyedropper tool, this is a freedom problem, not just an OXT problem.

Even Adobe gets this alert.png (293.16 KiB) Viewed 1027 times

[richmond62]

That stinks, frankly.

The "least pleasant" thing about it is that it does NOT give you CANCEL / IGNORE as an option: although, I suppose, once you open the System Settings you can just close it again.

[richmond62]

I suppose, in a very warped sort of way, I should be glad that the Gods of Rock and Roll made me notice that 'Barn Door' was missing, because knowing that I found out that the OXT Lite Dictionary is NOT doing what it is supposed to be doing.

[tperry2x]

While this document inside the IDE: /Documentation/html_viewer/resources/data/api/exports/xtalk/resaved/visual effect command.txt DOES list the visual effects listed in the LC 963 Dictionary that does NOT show up in the OXT Lite 1.10 Dictionary (which probably means 2 things:
1. The OXT Lite Dictionary is NOT reading the documents in /Documentation/html_viewer/resources/data/api/exports/xtalk/resaved

It is. Rest assured it's reading your edits from your changed file. What it's not doing is displaying them.
Why not?
Because I've not told it to. I forgot about checking for 'params'

assumptions.png (13.59 KiB) Viewed 918 times

2. All my edits to the Dictionary were a complete WASTE OF EFFORT as the OXT Lite Dictionary is NOT reading them. )

No, not wasted effort at all - and highly appreciated actually.

Point #1 is merely annoying.

Yes, sorry!

Point #2 really gets my goat as I spent hours editing those things!

Thankfully, point 2 is not what is occuring.

I'll do an update to fix the dictionary very shortly.

[richmond62]

I'll do an update to fix the dictionary very shortly.

Super.

At the risk of annoying you: KISSES!

As I encounter more 'Wrongnesses' in the Dictionary I shall issue corrected/improved documents.