OpenXTalk RC4 testing...

[richmond62]

Aha, the 'problem' with the Dark/Light button seems to that it will perform Dark > Light on the fly, but for Light > Dark the IDE needs a restart.

[richmond62]

Code: Select all

I see over in LC-land, they "backported" a bug fix into Livecode 9.6.9 to allow it to run under Sonoma

Wouldn't it be super to know how that were done, and whether it was something horribly complicated, or merely "the flick of a switch."

[tperry2x]

Wouldn't it be super to know how that were done, and whether it was something horribly complicated, or merely "the flick of a switch."

Wouldn't that be nice, but as LC will probably not divulge that information willingly, we'll have to find that fix for ourselves. (The same when they recreate the engine & IDE for ARM-based chipsets).

[richmond62]

Mark W has 'leaked' at least once, God bless him.about importing coloured SVG images, so, possibly . . . .

[tperry2x]

I'll make a few updates after I read through your reports and then reupload a new RC4 dmg.

Sorry to dig up an old quote, just re-reading bits I may have missed on 1st pass.
I changed a 'true' to a 'false' in this file
https://tsites.co.uk/sites/openxtalk/ch ... script.zip
(line 66), which gets rid of the notification showing. (Doesn't break anything as it's still there, and the standalone builder helpfully adjusts everything upwards in the dialog accordingly).

[tperry2x]

Also, @OpenXTalkPaul, I remembered you mentioning if I could let you know about any changes I make to the RC4 version while testing things.
I've made a new splash to replace the Tesla-don't-panic one, and I made a new OXT icon (1024x1024 pixels as required by MacOS for it's icon-sizes now).
My changes, as ever, are here:
https://www.tsites.co.uk/sites/openxtalk/changes.php
I tried to use github, but failed miserably - it's too over-complicated for it's own good, so I'm tracking my own changes. This way , you can pick-and-choose what you want.

[tperry2x]

[...another option is to use packaging tools that create installers that place the file where it looks for it during the installation process.

That's fairly easy on Linux, and on the mac dmg you could have a 'double click to install' that just copies the application to /Applications after it does the workarounds for the registration stack to prevent it appearing.

Just to keep you up-to-date, I've also changed the tool icons in my lite-hack and the RC4 ones for Mac and Linux:

OpenXTalk Lite toolbar icon testing:
https://tsites.co.uk/sites/openxtalk/ch ... ool-icons/

OpenXTalk RC4 toolbar icon testing:
https://tsites.co.uk/sites/openxtalk/ch ... s-RC4-mac/

[tperry2x]

Installer script, testing with OXT Lite hack on Linux.
This is roughly what I'm thinking. Just unpacks the 7z archive to /opt
Creates the icons, desktop shortcut, and deals with the user registration so it doesn't appear:

bash-linux.png (41.83 KiB) Viewed 3643 times

All you really need on the mac to stop that registration window is:

mac-shell.png (8.59 KiB) Viewed 3643 times

[tperry2x]

I'm also thinking about a change to how OXT loads the dictionary.
It seems to generate the dictionary afresh, each time the dictionary button is clicked on the toolbar.

Also, there's this disparity between how it displays on Mac (within OXT itself) but on Linux it opens a browser.

What I propose is the following when the dictionary is clicked:
Rather than the dictionary folder being created each time, check to see if the 'documentation cache" folder exists.
If it doesn't, then regenerate it as normal.
If it already exists, then load the API.html file within a stack window on all platforms.

I'm not suggesting 'recreating the wheel' - if you know what I mean.
I'm just wanting to change this to give a unified behaviour on all 3 platforms, and to eliminate the delay each time this is generated - particularly on slower computers.

(I like to test on fast and slow computers, so I can get a better idea of the user experience).

[richmond62]

LC 961 would seem the best BASE for OXT in that it offers 32-bit Mac builds which 9.6.2 and 9.6.3 don't: another of those seemingly random decisions: why the 32-build capability should have suddenly have been abandoned there is anybody's guess.
-

SummerOfLunch.png (636.53 KiB) Viewed 3584 times

-
I wonder what policy meetings look like.

[tperry2x]

Haha, sounds like a plan. @OpenXTalkPaul – if you are reading this, are you happy with applying your github changes to a 9.6.1 Livecode base?
Next question - can we track down the source code for 9.6.1 anywhere?

[richmond62]

I think our friends are legally required to supply the source code to anyone who asks for it.

[tperry2x]

Well, I just found out why LC opted to use an external browser in Linux.
Because while displaying a browser might work in MacOS, (and perhaps in windows *haven't tested*), but in Linux the browser widget is extremely broken.

It just freezes the program, which then has to be killed with a task manager.
The inspector also doesn't know how to set properties of it either.

To say it's half-baked is an understatement.

I've been experimenting loading the dictionary in an external browser on all platforms, which works reliably. Not the direction I wanted to go with it though.

[OpenXTalkPaul]

My changes, as ever, are here:
https://www.tsites.co.uk/sites/openxtalk/changes.php
I tried to use github, but failed miserably - it's too over-complicated for it's own good, so I'm tracking my own changes. This way , you can pick-and-choose what you want.

Oh this is good stuff, thanks! I just wish I could download it all as one big zip file.
I'm pretty sure we could incorporate a shell script in the .AppImage run loader that checks for the registration file and creates it if its not there before launching the IDE.

Have you tried using GitDesktop or one of the other GUIs that are around? It makes syncing your projects files as easy as pushing a button.

[OpenXTalkPaul]

Well, I just found out why LC opted to use an external browser in Linux.
Because while displaying a browser might work in MacOS, (and perhaps in windows *haven't tested*), but in Linux the browser widget is extremely broken.

It just freezes the program, which then has to be killed with a task manager.
The inspector also doesn't know how to set properties of it either.

This seems to depend, at least in part, on what window manager your Linux distro is using. Using 64bit Ubuntu Studio with KDE plasma works fine for me, as did running under Xubuntu, but Elementary OS with its Pantheon WM exhibited some really wacky behaviors (but sort of worked some of the time).

I wonder if we couldn't make an OpenXTalk-Linux JeOS (just enough OS) distro specifically tailored to perfectly run OXT, ensuring all dependencies and resources are included in the build.

I've been experimenting loading the dictionary in an external browser on all platforms, which works reliably. Not the direction I wanted to go with it though.

I think we could and should make this a Preferences option on all platforms. I also did some work on a small 'dictionary browser' a regular stack that reads the syntax entries from the SQLlite db directly. Its based on a stack from MaxV, and its fast. It could use some nicer (html/rtf) text formatting for syntax display. But Unlike tinyDictionary stack from BN, this stack does not add in all of the other APIs from Externals and Extensions which significantly slows down tinyDictionary stacks loading time (maybe that could be cached, so its a one-time delay?)
It also doesn't display any of the guide files that are also part of the Dictionary stack. Those are simply markdown files + image folder so I don't think it would be too difficult to make a script that displays those directly from those raw .md files too.

[tperry2x]

My reason for looking at this was to get a uniform approach to how the dictionary was displayed.
I would have ideally liked to have it load in a browser widget (really, is this the best we can do) - unfortunate there isn't native browser support.
My current theory is using your dictionary changes from RC4 (with all livecode branding and mentions removed).
When the dictionary button is pressed, copy this to ~/.openxtalk/OXT_Guide and load the api.html in a browser. It's substantially faster than recreating it from the sql database each time.
thus:

modded-dictionary.png (77.58 KiB) Viewed 3534 times

I also found if you rename the 'Documentation' folder in whereever the Livecode program folder is (depending on your platform of course), it improves the startup speed of LC / OXT as it's not trying to regenerate the dictionary at startup.

Rather than renaming this Documentation folder (which is a bit heavy-handed), I'd like to look for a line I can comment out. It's probably in the home or splash stack, just to stop the dictionary-building handler being run.

In the OXT_Guide folder, I have made a few changes to the html code. It no longer tries to reference CSS and JS files from various locations, it includes the CSS and JS files as relative links, not absolute links. I'll post updates to this when I've got it finalised. My solution sounds more complicated than it is.

edit: Have modified this a bit from this morning, and the above.
This will reliably load the OXT Dictionary when clicking the 'Dictionary' icon on the toolbar.
https://tsites.co.uk/sites/openxtalk/ch ... ictionary/ and is the same on Mac and Linux (yes, I'll need to create a Windows version too).


You can now hold the shift key when clicking on the dictionary icon on the toolbar (if you really want the old behaviour). This will load the dictionary the old way - generating the dictionary from the database afresh (probably using the Livecode one, showing references to Livecode still).

[tperry2x]

Oh this is good stuff, thanks! I just wish I could download it all as one big zip file.

You can:
https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z

[OpenXTalkPaul]

Oh this is good stuff, thanks! I just wish I could download it all as one big zip file.

You can:
https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z

Great, thanks!
Something I'm not sure that you have considered is that the Dictionary is dynamic, it doesn't simply use that sqlite db to generate the web cache version for display, it also looks for any installed libraries/widgets 'extensions' including some essential components of the IDE (libURL and SVG Drawing library for examples are 'extension' libraries) and parses them for their inline documentation and guide files (if included) too. If you install or otherwise load into memory an Extension widget or library, its docs are added to the dictionary then.

[tperry2x]

This is kind of my thinking in keeping the older dictionary-showing method as an option.

That is still available, you just hold the shift key when clicking the dictionary button on the toolbar. It'll then use the original method to show the dictionary where it loads everything from the database.

[richmond62]

I'm 'Dynamic' insofar as I get up in the morning [admittedly, as my wife will tell you, with late-middle-aged groans and curses], go downstair, make the coffee, give my wife a whistle when it is ready . . . BUT

Surely, the OXT/LC/Whatever dictionary is ONLY dynamic if it is receiving constant modifications from a 'mother-ship' or somesuch.

LC 961 [note subtle change from '963'] is even less dynamic than I am . . . so a 'FIXED' dictionary should not be seen as any sort of problem.