Comments on 1.0

[richmond62]

Oh well, it doesn't matter.
I've had enough.

Because of the criticism?

Surely not: that will always be a necessary part of any interface development.

After all: if you had not achieved so much (which you have) there would be nothing to criticise.

[richmond62]

As tomorrow is my 'free' (vacuuming, laundry) I shall install OXT Lite on Xubuntu and see what's what, and report back here.

[richmond62]

Installing OXT Lite on Xubuntu with the 'sh' script was wonderful.
-

systemDetails.png (39.56 KiB) Viewed 568 times

-
Slight pity that the OXT icon did not 'stick' in the menu:
-

OXT1.png (44.39 KiB) Viewed 569 times

[richmond62]

Absolutely no problems whatsoever setting the Preferences to the way I like things.

Wonder why the icons on the Tools palette are orange (do like them):
-

ToolsOrange.png (27 KiB) Viewed 568 times

[richmond62]

messageBox receives focus with no fiddling around: fantastic:
-

messageBox.png (41.35 KiB) Viewed 567 times

[richmond62]

There are colour contrasts in the Dictionary that make things difficult to see:
-

Dict.png (109.9 KiB) Viewed 564 times

-
Areas in red boxes.

[richmond62]

Oddly enough, when I went to the DropBox place to download the Linux version of OXT Lite 1.0 it, and the Windows version, were no longer visible (only the macintosh version was there): BUT, fortunately, it turned out that for some completely daft reason I had downloaded the Linux version (and the Windows one) onto a 32-bit polycarbonate iMac running macOS 10.6.8 (obviously I was 'multi-tasking' in some odd way).

[richmond62]

As far as I have gone (not far) with OXT Lite 1.0 as it currently stands, on Xubuntu (that's Ubuntu + XFCE) I will say "Yes".

[tperry2x]

With things disappearing, that was probably due to me messing about with the versions in there
I'd changed the dictionary amongst other things:

The title is still white. It needs setting in the dgDataProps as it's a data grid, but I'll do this at some point when I get a moment.

[richmond62]

Should I download from the DropBox now, or go and getting the washing machine filled up and running first?

https://youtu.be/SGBqns3fWGk

[tperry2x]

That's entirely your decision.
I took v0.99, and added the edits I made to make 1.0 back in, thus producing a new 1.0. The dictionary bugs me - it's not perfect, but getting better. I'm "standing on the shoulders of giants" there.

I've not removed any of the resources within stacks, so nothing should be broken. This dictionary stack does have a weird habit of overriding the cursor for some reason - when you hover over the column headings on the data grid). But other than that, I was able to rejig it a bit.

The mac version isn't done yet. Only because I'm not sat at the mac, but I want to try and recompile the engine for Mac OS. The windows recompile is going to be a nightmare, but I think I've fixed the C++ gyp tool that does the pre-compiling and linking.

edit: The Linux one is now reuploaded, the Windows one I'll start now. The Mac one will follow probably later tonight / tomorrow at some point (note, the Windows and Mac ones won't have a recompiled engine as I'm still working on that).

[OpenXTalkPaul]

but I want to try and recompile the engine for Mac OS. The windows recompile is going to be a nightmare, but I think I've fixed the C++ gyp tool that does the pre-compiling and linking.

I think you'll find getting it to compile as-is on macOS will be a bit of a pain in the arse too. You'll need to manually install into X-code several old macOS versions SDKs (like 10.9 Mavericks SDK), But it is doable.
For starters, the current version of command line tool that is used to generate the User Guide and release notes PDFs from the bunches of separate markdown files doeno longer works, the build scripts need updating for that.

[richmond62]

Did I just see a north American spell 'arse' that way?

Building engines is defo post-graduate stuff.

[OpenXTalkPaul]

Did I just see a north American spell 'arse' that way?

Building engines is defo post-graduate stuff.

I'd say that modifying the source that builds the Engines, like for another significantly different architecture probably is CompSci grad work, but building binaries from the already coded source, that was already set up to build, only requires following the building instructions (and updating some build scripts in our case) and having all the required packages/binaries (dependencies) that the linker needs to merge in.

I do think there seems to be a certain amount of mysticism that surrounds compilers and what they do that prevents some people from even considering giving it a go.

[richmond62]

a certain amount of mysticism

Indeed: but this is a human tendency. Recently I wandered into the English Philology Department at the University of Plovdiv (my wife being the boss), and came across 3 'academics' (and I use those quotes to demonstrate something) engaged in a reasonably abstruse argument anent semantics: so I made some comments and watched their lips curl: at which point I pointed out that I held 2 academic degrees (both from Universities listed higher than where they were sitting) that dealt with semantics (= meaning), and lobbed them some of the funky-monkey jargon: wow, did those intellectual snobs fall over backwards to apply "the brown tongue".

All those insecure types try to keep as much of the "arcane lore" as close to their chests as possible unless, heaven forfend, we hoi polloi might find out that they have feet of clay and anyone with a reasonably serviceable brain can probably get their head round "it" in about 30 minutes.

I went round the corner and sank a refreshing glass of brown beer: without inviting them.

[OpenXTalkPaul]

a reasonably serviceable brain can probably get their head round "it" in about 30 minutes.

Understanding the concepts is only the first part, having the patience and perseverance and tools to deal with large complex projects that need constant updating, after first figuring out what exactly needs updating, is a whole other level.

Although these days you could ask ChatGPT for help, or look up the answers to problems on Stackoverflow, or one of hundreds of other sites.

Something about 10,000 hr rule goes here.

Picasso was at a Paris market when an admirer approached and asked if he could do a quick sketch on a paper napkin for her. Picasso politely agreed, promptly created a drawing, and handed back the napkin — but not before asking for a million Francs. The lady was shocked: “How can you ask for so much? It took you five minutes to draw this!”
“No”, Picasso replied, “It took me 40 years to draw this in five minutes.”

I have no idea if that story is true, I've seen it in meme form, but it certainly rings true.

[OpenXTalkPaul]

I tested macOS version of OXT Lite 1.0 (build uploaded yesterday)...
Testing on Big Sur.
First off, I get scary 'app damaged' message. I see you included a authentication cert and instructions on how a user can add that cert to their keychain. That seems like a bit much of an ask for end users to do just to run the app. When I first installed OXT Heavy (DPE) on a fresh install of macOS Sonoma, when I ran the app I was presented with a much different dialog that asked if I wanted to allow the software to run with a note something like 'Signed by developer Paul McClernan' and that the cert will expire in 2025 (which reflects the arbitrary date I used when I made my signing cert). Installer disk images can be signed and bundles can be signed. However, my main executable binary and the externals binaries, inside this app bundle, have all been stripped of code-signing (which I only did because I couldn't get mergRecord external to ask for microphone permissions, but now I've built an extension to replace that external). I'm still not sure which of there things makes the difference, or wether to leave the binaries unsigned or to use the custom made cert to sign them along with signing the .dmg and/or .app bundle (which is signs the bundle-folder itself, use the 'deep' option switch signs binaries in sub directories too). I don't think you should zip up the .app bundle like that, It's going to trigger the gatekeeper when it's unzipped, and a dmg disk image will likely already be compressed so there would be no point to zipping it too. That could be the problem.

Anyway I self signed it, adhoc sig using a drag drop utility called CodeSigner.app (useful) ...

Most serious issue is that if I click on the 'Window' menu or the 'Help' menu the engine sort-of half chrashes:

OXTL1.0Crash.jpg (26.25 KiB) Viewed 431 times

Interestingly it offers the choice to continue running, but the Engine is either now locked up or unstable.
This seems to be initially triggered by there being nothing in the Window menu before any stack windows are open?
This is what the crash log says at the top:

Exception Name: NSInternalInconsistencyException
Description: Invalid parameter not satisfying: index >= 0
User Info: (null)

This doesn't happen on OXT Heavy, and it' only happened in the 'Windows' and 'Help' menus, so I'm guessing you've been tinkering around in the revMenuBar scripts

NEXT, my old favorite, Dark Mode!

At first I couldn't find darkMode which made me sad, but then I found that you moved it to a different tab.
However when I enable it, it does an emulated pseudo dark-mode, the window frames do not become dark.

DarkModeNeedsMacLib.jpg (37.55 KiB) Viewed 431 times

As I've said, native 'darkMode' on macOS requires a bit more than just swapping fore/backGround colors.
I see that OXT macOS Native tools is included, but its native darkMode functionality is not being used.
If it's not done at the system API level (Apple's way) it's going to causes issues with other things like not having contrast making things unreadable or even appear to be invisible.

DarkModeNeedsMacLib2.jpg (46.12 KiB) Viewed 431 times

[tperry2x]

I'm very confused by this.
Did you download the 1.0f in dropbox for the mac?

if you look at the script of the home stack, and the "IDEtoDarkMac" handler, you should see:

Screenshot_2024-02-01_17-04-20.png (19.59 KiB) Viewed 423 times

This then calls your setAppToDarkMode handler, in your stack which uses the API method - so it should be doing it the supported way. I certainly get the dark window titles and everything on Catalina in this way.

I had the menu problem in an earlier MacOS build of OXT Lite (v0.98) and thought I'd fixed it in 0.99 upwards.
What do you think is making the menus so flaky on MacOS?

Later on, I'll go back on the mac and get some screenshots of it in Catalina. Can't now because kids

[OpenXTalkPaul]

I tested macOS version of OXT Lite 1.0 (build uploaded yesterday)...
Testing on Big Sur.

Continuing on...

So I go to look up the command from OXT Native tools so I can turn on native darkMode window frames.
It opens a Syntax browser stack. Which lists the library under 'script' API, but doesn't show the list of handler definitions associated with that library it (in either 'script' or 'builder' api listings).
The listing text style formatting is a bit off with the window is resized smaller.

Dictionary.Browser2.jpg (101.04 KiB) Viewed 422 times

This is what those extension manifest and .lci files are generated for.
Here is where the IDE expects to find the .lci files:

LCI files.jpg (44.09 KiB) Viewed 422 times

The .lci interface file for an extension library must go into this folder in the app bundle, for the IDE to be fully aware of the extension, as far as the Dictionary knowing about it (these are normally installed when an extension is first installed, or dynamically with script loaded extension module), you may notice there are .lci files in there that are from Extension Builder 'built-ins' and language modules too (this is useful when extending the IDE and for extending the Extension Builder language itself).

[tperry2x]

That's handy to know.
Is that documented anywhere, as I wasn't aware of that.

Wow! That text formatting is seriously mangled. That's not what I see, but that's screenshots on Sonoma again I assume?

fonts.png (11.4 KiB) Viewed 419 times

"After you go to the ." - go to the what I wonder?

It almost looks like the font leading is out. I'll just check if it's got a fixed line height. (I didn't make that stack - It's one from the alternatives I found).
Edit: yeah, it has a fixed line height on the field "testo" of 18px. So this wants changing. (Apparently 'Testo' is Italian for 'Text') - which I could of guessed, but checked via Google translate to be sure.

Mentioning the dictionary: You'll find the dictionary sqlite database doesn't include all your midi / audio definitions as they aren't available in OXT lite. I'm using the sqlite file originally supplied from TerryL