OpenXTalk 'Lite' 0.91, .oxtstack recognition & download links

[tperry2x]

This gives OpenXTalk the ability to open and save oxtstack files.
It'll then recognise them in open dialogs, and allow you to save .oxtstack files as default.
credit to Paul McClernan for this, because I used his method from the RC3 / RC4 versions of OpenXTalk

01_new-open-linux.png (57.77 KiB) Viewed 9445 times

02_new-save-linux.png (46.6 KiB) Viewed 9445 times

This doesn't do anything about file associations or icons. That'll be in another change.
Speaking of changes, you can download my list of changes at:
http://tsites.co.uk/sites/openxtalk/changes/

If you open the Changes.livecode stack, you can see the changes in the right order. This also allows you to apply changes to an unpatched version of Livecode Community 9.6.1, so you can start afresh with the changes you want. (it builds a set of terminal commands in a new window as you choose which modifications you want and don't want). A note about this though: I'd recommend applying them in the order listed. (This is a work in progress, so please make sure you experiment on a copy of the Livecode community app / program).

I've not implemented anything for Windows yet. That will follow some time soon.

I've also included the oxtfile recognition changes as 4 stacks:

home.livecodescript

(84.09 KiB) Downloaded 274 times

revcommonlibrary.livecodescript

(58.26 KiB) Downloaded 271 times

revidelibrary.8.livecodescript

(419.25 KiB) Downloaded 276 times

revsaveasstandalone.livecodescript

(113.21 KiB) Downloaded 273 times

Finally, you can download the already-patched (complete with installers) versions of OpenXTalk Lite 0.91 here for Mac and Linux:
http://tsites.co.uk/sites/openxtalk/ope ... 0.9-osx.7z
http://tsites.co.uk/sites/openxtalk/ope ... 9-linux.7z

Many thanks.

[OpenXTalkPaul]

I think it would be better for efficiency reasons, if we try to coordinate our efforts better so we aren't doing the same work over again.

There's some decisions you've made in your changes that I probably wouldn't want to add to my builds, which of course is fine, but the for the stuff we agree on it doesn't make sense to being doing it twice.

For example this is code I wouldn't want in my build:

Code: Select all

   filter lines of tFontNames without "@*"  --filter out 144 unnecessary fonts
   filter lines of tFontNames without "amiri*"
   filter lines of tFontNames without "arabic*"
   filter lines of tFontNames without "arial *"
   filter lines of tFontNames without "bahnschrift *"
   filter lines of tFontNames without "courier new *"
   filter lines of tFontNames without "dejavu*"
   filter lines of tFontNames without "*ming*"
   filter lines of tFontNames without "microsoft*"
   filter lines of tFontNames without "ms**"
   filter lines of tFontNames without "noto*"
   filter lines of tFontNames without "segoe ui *"
   filter lines of tFontNames without "source*"
   filter lines of tFontNames without "times new roman *"
   filter lines of tFontNames without "yu*"

Because why remove installed fonts from the available fonts list?
What if I want to use 'Courier new' because I'm going for an old-school typewriter-type look?

Also I'm trying NOT to replace references to 'LiveCode' with OpenXTalk, wherever possible I'm using generic terms like 'xTalk', 'Script','Extension Builder', 'the IDE', or 'the engine', that way if someone wants to remake this thing later, as SuperHyperMetaMediaCard or whatever, they don't have to go through the same nonsense of going through the entire IDE hunting down a million references to OpenXTalk.

[tperry2x]

Okay, this makes sense.
However, the font name filtering wasn't added by myself. It was actually a LC code change. I think I noticed it myself at some point and I assumed they'd done it because LC has problems displaying some types of cyrillic fonts?

[OpenXTalkPaul]

Code: Select all

   -- just means it's reading from the same place as the about stack, so one place to change everything when it comes to modifying version

I'm skeptical about this approach.

The old start center (for example) builds this IDE name+version dynamically on preOpenStack. IMO anything that needs to display the name + version should build the string as needed like that, or just go ahead and hard code it in like I did

The IDE has a bunch of utility handlers built into it already for doing IDE related things (Hint: I added docs for some of them to the dictionary), getting name + build number is such a case, there's really useful handlers for getting certain IDE directory paths, like the Toolset path.

Looking at your dictionary opening changes, it looks like you're making an additional copy of the dictionary cache, and I don't understand why. The dictionary already gets cached as HTML/JS format. I just changed some boolean variable to toggle the opening behavior, launching the web version into the systems web browser from the existing cache folder or show in IDE stack browser widget.

[tperry2x]

Yes, that only opens the copy if the 'open in external browser' is ticked in the preferences.
Otherwise it'll use the default behaviour. (API method) - or you can hold shift and click to always use the API method regardless.
I used this approach for the instances where the button just doesn't work on some Linux systems. It's a fallback measure more than anything.

On Devuan at least (perhaps also true for others), it doesn't even seem to generate properly using the api from database method. It doesn't error, and I'm not sure why it doesn't work. For those instances, I'm using a pre-cached version. I know this is far from ideal, but better to display something rather than nothing was my thought process.

[tperry2x]

The IDE has a bunch of utility handlers built into it already for doing IDE related things... getting name + build number is such a case, there's really useful handlers for getting certain IDE directory paths, like the Toolset path.

That would be good, and I'd preferred to use that approach. Is that something you'd added to the RC versions, or was it there before that?
If you can tell me how I'd get those variables, I'll use that method instead.

Edit: I think I found it:

message-box.png (8.83 KiB) Viewed 9374 times

But, as I mention here, (viewtopic.php?p=3844#p3844) I'd need to find where these variables are being populated from and change them there.

[tperry2x]

I think it would be better for efficiency reasons, if we try to coordinate our efforts better so we aren't doing the same work over again.

I absolutely second this, so I think when I next embark on a major change, I'll let you know so we don't end up both tackling the same problem in a different way.

There's some decisions you've made in your changes that I probably wouldn't want to add to my builds...
...
Because why remove installed fonts from the available fonts list?
What if I want to use 'Courier new' because I'm going for an old-school typewriter-type look?

As mentioned, that's not one of my edits, but I can see why they might want to do this:

fontnames-toomany.png (66 KiB) Viewed 9353 times

Admittedly, this is in Libreoffice, but pruning font names can definitely be a good thing.
And yes, I realise this is totally hypocritical of me with my never-ending choice of colours in the preferences dialog.
As Richmond rightly points out, I do need to reduce this down to perhaps primary colours. (or maybe primary colours, greyscale shades, pastel colours) and not however many are in there at the moment (funny, because this is already a reduced set from what is available).

[tperry2x]

Needlessly long colours option fixed.
(a problem of my own making, and my mistake to have left it in)
https://www.openxtalk.org/forum/viewtop ... 3879#p3879