Late to the 108 Linux party

[richmond62]

JUST installed the Linux 64-bit version of 1.08 on a Xubuntu laptop.

Went to update and got this:
-

prob.png (224.1 KiB) Viewed 1441 times

[tperry2x]

I can confirm that file is there, and is available - so perhaps your connection was interrupted?

Screenshot at 2024-11-04 21-50-03.png (49.09 KiB) Viewed 1439 times

[OpenXTalkPaul]

I got my old laptop setup with MX Linux on it. I'm still not sure if I like the MX distro or not but it can read Apple HFS+ volume format 'out of the box' which was nice...

Of course OXT (.appimage) and OXT Lite 1.0.8 were the first things that I installed.

Updater run for 1.0.8 + patches and chose the 'update' button in post-download dialog, entered admin pw and then quit but did not relaunch.

The Browser Widget version Dictionary works in the AppImage but has the IDE window focusing problems (which I think we should look into adding some traverseOn-toggling, forced-focusing 'on resumeStack' handlers for our IDE stacks).

I was a bit surprised that the fluidSynth extension that's in the Linux .appImage version OXT worked with MX Linux out-of-the-box. Well almost... the OXT General Music library in that needs to be updated to my newer version to better locate the included fallback sound bank. But once I manually pointed it to a soundfont on disk it worked fine and I could do 'playSentence' music directly from the message box! For some reason I thought fluidSynth I packed in wasn't working 'out of the box' at least not on certain distros (like elementaryOS), maybe I'm mis-remembering?

OXT Lite 1.0.8 I tried loading the Browser Widget version Dictionary using key-combo but it doesn't load anything, nor does open in external browser, the URL seems to be empty, not pointing to the Dictionary generate web-pages cache. But the focus issues seem to be sorted and the sqlite-based dictionary stack works well. I'm going to try to merge the two versions to make a new .appImage version.

[richmond62]

perhaps your connection was interrupted

After a third attempt I got fed up and went and did something else.

[tperry2x]

Updater run for 1.0.8 + patches and chose the 'update' button in post-download dialog, entered admin pw and then quit but did not relaunch.

Just to clarify, I didn't bring the relaunch part into play until after build 20241006 (6th oct 2024), so updates after this should make the IDE respring / relaunch.

after-this.png (52.19 KiB) Viewed 1400 times

[tperry2x]

After a third attempt I got fed up and went and did something else.

I've just tried with a completely fresh install of 1.08 - and took it all the way up to the current build of 202410081914

rechecked-everything.png (15.81 KiB) Viewed 1399 times

In fact, looking into this - it shouldn't be trying to download that folder under 1.08 of oxt lite - because that 202409280728 folder is part of v1.07 of OXT Lite.

hmmm.png (2.75 KiB) Viewed 1396 times

Bear with me, and I'll see if things got confused around the time of doing beta versions...

edit: just checked and seems to all be okay
I'd probably advocate you download an entirely fresh copy (link here).
Also, when you install - are you opening a terminal window and dragging the "run-install-in-terminal.sh" into that terminal window as per the instructions?

drag.png (33.41 KiB) Viewed 1374 times

It should be asking you if you want to wipe your previous installation, which you can say Y to.

confirmation.png (19.89 KiB) Viewed 1389 times

There's only actually 3 updates to do, to take you to the latest build after that.

only 3.png (30.17 KiB) Viewed 1386 times

[tperry2x]

OXT Lite 1.0.8 I tried loading the Browser Widget version Dictionary using key-combo but it doesn't load anything, nor does open in external browser, the URL seems to be empty, not pointing to the Dictionary generate web-pages cache.

Yes, I actually got rid of the web approach entirely back in v1.07, in favour of a text based approach to the dictionary. I was fed up with flaky (and slow) databases.

So, if you have your dictionary prefs set as per this - you'll get the text-only & stack version of the dictionary.

dict.png (22.77 KiB) Viewed 1383 times

I know this isn't an approach you'd favour, and this is definitely where our two versions will go off in different tangents.
This is extendable though - as if you were a plugin developer, you can easily add your text definitions to a custom dictionary - that's what the OSversion function does too.

Screenshot at 2024-11-05 10-41-34.png (86.95 KiB) Viewed 1362 times

Plus the browser widget has multiple 'use-after-free' [memory exploits] in that version of CEF, so I'd really not advocate using it.

Probably until we can include a new CEF version anyway.

I'm not dismissive of using a web approach, but perhaps instead of a faux-cef browser - we have the dictionary as a HTML page that a 'real' browser (the user's system-installed browser) visits. Hosted online somewhere.
Edit: Oops! you already mentioned that here.

Yes I mean allow the 'Dictionary' to point to a URL (maybe file:// URL too?) or a remotely hosted copy of the dictionary. I mentioned that because it was noticeably faster to load the Dictionary from Brian Milby's site then it was to load it from the the local cached pages on this elderly worn-out eMMC internal storage on this el-cheapo laptop. Of course I'd still want it to be possible to load it from cache if no internet connection were available. I'm pretty sure I could host it on a GitHub 'pages' site, that seems pretty reliable.

I agree, but there's issues with styling it properly if in Github. Probably best to have it as a standalone site. (Something not LC-host-affiliated).

For those cases where people don't have internet access, then they can use the stack / text / DB method still. This doesn't stop anyone being able to browse the dictionary, but using a more updated system browser means that the honus is on the user to keep it updated - and we aren't going to be blamed for opening security holes with an ancient version of CEF.

If people didn't want to use the text version, and still use the DB version - that's still there and turning on 'use quick dictionary' will use that method - although there were a few issues with that stack... I'll see if I can find the post on that one.

[richmond62]

The whole thing is very odd:

I dargged the install script into a terminal window with SUDO and got NO Y/N question.

The thing installed & replaced 1.07.

Will try again tonight as you suggest, when I get home.

[tperry2x]

That is odd.
I have some demo installation videos, of how it should work, but if it's not working that way for you - then I'll look into it further.
Just to confirm, you shouldn't have to sudo in the terminal or anything first before dragging the script in. The script will ask you to authenticate anyway.
(demo installation videos)

[richmond62]

Sorry I didn't manage that last night: Having a sort of sub-flu bug.

Anyway . . . installed as per your instructions, and:
-

6_Nov.png (91.54 KiB) Viewed 1305 times

-
Right, 'off' to the Mac 12 machine for a spot of Amharic.

[tperry2x]

Well, the updates at present aren't really much to worry about, so I'll produce a v1.09 with all this bundled together at some point. (Which will contain the newly compiled engine for Windows x64) - I'm just working on adding bits into the font menu, as per TerryL's suggestion here - as time allows.

[OpenXTalkPaul]

I agree, but there's issues with styling it properly if in Github. Probably best to have it as a standalone site. (Something not LC-host-affiliated).

There should be no styling issues at all with using Github Pages. You don't have to use Github's markdown (although it is easier to work with than full-on HTML is), Github Pages can host regular HTML/JS web pages fine (with the exception of any server-side stuff like PHP). That's how the 'Playground' stack is being hosted: https://openxtalk-org.github.io/OpenXTalk-Playground/ I should be able to dump that whole web-cache version into a repo and use it from anywhere there's a browser. One thing that would be cool is if there were a CSS web layout for when the browser is on a mobile devices.

[tperry2x]

That's cool. Handy it can render normal HTML.
Happy to style or add any CSS bits as I don't mind doing that, testing in various browsers etc.

I'd even contemplated making an OXT dictionary apk (this was my motivation in getting the android building working across all platforms - or at least making it less of a mystery) - as there's LCC dictionary APKs already, but no OXT ones of course.

[OpenXTalkPaul]

I'd even contemplated making an OXT dictionary apk

An iOS app version of OXT's dictionary would be handy too. I think that would be easiest for being able to update the content without having to rebuild and deploy new mobile apps, and a standalone mobile app could download that remote web content and cache it for offline viewing.

[richmond62]

Were OXT's Dictionary available as a webpage neither an iOS or an Android 'thang' would be necessary except for those of us who sit in caves in deep valleys in the mountains.

[tperry2x]

Were OXT's Dictionary available as a webpage neither an iOS or an Android 'thang' would be necessary except for those of us who sit in caves in deep valleys in the mountains.

But people who sit in caves in deep valleys, or in the mountains, how many of them have even heard of OXT (or even Livecode for that matter).

[richmond62]

None.

So, a webpage Dictionary should suffice.