OpenXTalk RC4 testing...

[OpenXTalkPaul]

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.

The Dictionary is only not dynamic if you aren't ever going to add anything to the IDE as far as libraries, extensions, and widgets, which I've actually done a lot of and plan to continue doing (I do have something in the way of a road map in my head, albeit a flexible one).
And the extension manager stack does now have a 'Repo' tab which replaces the in-IDE, previously non-functional LCC 'Extension Store' where you can download some community-made things (widgets/libraries, but could add stacks and other content), served up compliments of GitHub. This card does use a browser widget though (same as the LCC version did), so might need to make a non-web page stack version. But I have used it successfully on several 64bit Linux distros.

[tperry2x]

I'm not sure if it has been picked up on, but you know you can shift-click that dictionary button to still use the sqlite method of generating the dictionary?
Just making sure you knew that it does still exist. So any dictionary edits can work as before, and just means that I only have to save a flat (non-db) copy in my "OXT_Guide" if the sqlite gets modified with any additional features we want to build in - which takes only a couple of minutes work. Should mean the best of both worlds re compatibility and at least makes it work the same across all platforms.

[OpenXTalkPaul]

I'm not sure if it has been picked up on, but you know you can shift-click that dictionary button to still use the sqlite method of generating the dictionary?
Just making sure you knew that it does still exist. So any dictionary edits can work as before, and just means that I only have to save a flat (non-db) copy in my "OXT_Guide" if the sqlite gets modified with any additional features we want to build in - which takes only a couple of minutes work. Should mean the best of both worlds re compatibility and at least makes it work the same across all platforms.

I caught that, I just would prefer which method to use by defualt be a preference setting (with perhaps add a 'flush dictionary caches' button too), that way you set it to your (or your Distro's) liking and forget about it. Also, Extensions that are loaded 'on-the-fly' via Extension Builder or via script syntax:

Code: Select all

 load extension {from file filePath | from data moduleData} [ with resource path resourcePath ]

don't (currently) get added to the API sqlite db, they're parsed and loaded or unloaded (important for developing) separately on demand, either from an included API.lcdoc or from in-line documentation built into an Extension Module's code. They converted and added or removed (sometimes) to/from the web versions in that cache folder.

If you look at my edits to Dictionary, I re-enabled the stack/browser widget version on Linux simply by setting one variable, IIRC (I think I added a check for 64bit arch as well), a check button to set that variable or not could easily be added to the revPreferencesUI.rev stack.

[OpenXTalkPaul]

I've noticed that earlier versions of the web based Dictionary had all the various APIs listed, such as DataGrid, in the API popup menu in the Dictionary where it currently lists only two choices (Script or Extension Builder). It would be nice to get that behavior working again.

I'll try to remember to upload my (unfinished ) attempt at fast, non-web "Dictionary Browser" stack later tonight, I was thinking of adding this stack as an alternative (maybe with a random syntax display on start up).

[tperry2x]

I just would prefer which method to use by default be a preference setting...

prefs-dict.png (22.68 KiB) Viewed 13577 times

I've now added this, and it's listed within my changes at:
https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z

[richmond62]

I've now added this, and it's listed within my changes at:

Does that mean we have to exchange files inwith your OXT version, or is there a complete file including those changes available for downloading?

And, if so, where?

[tperry2x]

Does that mean we have to exchange files inwith your OXT version

-- adds the preference option for toggling the dictionary to open in the old method (generating by API), or by opening in an external browser (more compatible across all OSs).
-- Note: you can still shift-click the dictionary button to ignore whatever preference is set and open via the API method.


File: home.livecodescript

[Mac:] Place in: (right-click app icon, "show package contents" > Contents/Tools/Toolset/
[linux:] /opt/livecode/livecodecommunity-9.6.x/Toolset/
[win:] C:/RunRev/LiveCode Community 9.6.x/Toolset/


File: revmenubar.livecodescript

[Mac:] Place in: (right-click app icon, "show package contents" > Contents/Tools/Toolset/palettes/menubar/
[linux:] /opt/livecode/livecodecommunity-9.6.x/Toolset/palettes/menubar/
[win:] C:/RunRev/LiveCode Community 9.6.x/Toolset/palettes/menubar/


File: revpreferencesgui.rev

[Mac:] Place in: (right-click app icon, "show package contents" > Contents/Tools/Toolset/palettes/
[linux:] /opt/livecode/livecodecommunity-9.6.x/Toolset/palettes/
[win:] C:/RunRev/LiveCode Community 9.6.x/Toolset/palettes/


If you don't want to download the entire changes file, I've added just the last part since my last 0.92 upload to my site.

2023-10-04-0946.7z

(160.83 KiB) Downloaded 365 times

[micmac]

It would be nice if you just used zip tperry2x

Mic

[richmond62]

It would be nice if you just used zip tperry2x

Indeed it world: as, on Saturday I will have about 6 hours free to do some testing.

[tperry2x]

It would be nice if you just used zip tperry2x

It would be nice, however zip is about 30% to 50% less efficient at compressing and space on my site is limited. As is bandwidth, so getting each version down to less than 350MB is a must.

Plus, 7z is free and available for all platforms. (comes as standard with most mainsteam linux distros too). Natively supported in MacOS 12. The only one you have to add it for is Windows

[tperry2x]

...on Saturday I will have about 6 hours free to do some testing.

haha, I'll get my stab-vest ready in that case...

[OpenXTalkPaul]

I just would prefer which method to use by default be a preference setting...

prefs-dict.png
I've now added this, and it's listed within my changes at:
https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z

Awesome, thanks!

[OpenXTalkPaul]

It would be nice if you just used zip tperry2x

It would be nice, however zip is about 30% to 50% less efficient at compressing and space on my site is limited. As is bandwidth, so getting each version down to less than 350MB is a must.

Plus, 7z is free and available for all platforms. (comes as standard with most mainsteam linux distros too). Natively supported in MacOS 12. The only one you have to add it for is Windows

I've been a big fan of 7zip since it came to be for those very reasons. The advantage to regular/PK Zip is more it's more readily accessible on most platforms (I just now found out that macOS 12+ has built in support for 7z, thanks) and also takes less time/CPU power to decompress vs .7z.
For Mac the .dmg is compressed (and you can run the IDE from it).
Likewise Linux .AppImage are compressed disk images, which the main reason why I like that format along with being able to bottle up dependencies along with the app.
Is there a Windows equivalent?

[tperry2x]

Is there a Windows equivalent?

The only thing I can think of is a compressed ISO which can be double-clicked to mount, but only on Windows 10 and above.
There were various attempts in Windows at commercial products which would mirror the dmg and appimage functionality (virtualCD) comes to mind. I'm not sure if this is still going as I can't find a link.

Looks to have been replaced by the (free) Virtual CloneDrive
https://www.elby.ch/en/products/vcd.html
(doesn't look like this may offer any compression though).

Plus it involves a third-party download on every version of windows, so no closer to a 'native' compressed solution than 7zip.
I had a look at various installer tools. There was one that TerryL sent my way for consideration, but it is not clear how to actually use it.
I think the simpler solution would just be to make the 7z file self-extracting, then run the bat script from wherever it's extracted from.

Like a DMG on MacOS, the install files can either then be backed up for archival purposes or binned to save space.

[richmond62]

haha, I'll get my stab-vest ready in that case...

Only if you have a guilty conscience.

I have nothing but admiration for 99% of your work, and the 1% I don't admire is well within the margin of human error.

[richmond62]

To return to the

The Dictionary

. . .

Surely,as such, it does NOT have to be dynamic, just as long as it's "vessels" (fields?) can be refilled each time OXT has an upgrade.

[OpenXTalkPaul]

To return to the

The Dictionary

. . .

Surely,as such, it does NOT have to be dynamic, just as long as it's "vessels" (fields?) can be refilled each time OXT has an upgrade.

Thanks to some recent retro-interests in early versions ( MC RR) I know there's been at least three completely different approaches that have been used for the Dictionary, XML Based, all Stacks based, and DB + Web Browser based. I'm not at all against adding in some alternative method for fast syntax browsing as long as it shows all available syntax. The problem is 'all available syntax' has always been dynamic in most, if not all xTalk/xCard environments. Copy an XCMD/XFCN into you Hypercard v1 stack and the environments available syntax has changed, circa 1987. xTalks extensibility is one of the things that made it insanely great from the onset.

If our Dictionary was reverted to being non-dynamic how would someone developing a library or extension check that the inline documentation that they're adding to their code will be displayed correctly while they're still developing their thing? Personally, I've warmed up to this inline method of documenting. The parsing method allows some things to be inferred and automagically added to docs, saving some time and probably preventing some human error.

Sure, once an extension or library is worthy of being added to the IDE, then its docs can be static, added to the IDE distributions Dictionary files, but there would need to be included some tool for previewing while a thing is still work-in-progress. There's been one or two community attempts at tools like that. Brian Milby has previously consented to adding his .LCDOC previewing tool to OXT, so that could be useful.

[tperry2x]

If our Dictionary was reverted to being non-dynamic how would someone developing a library or extension check that the inline documentation that they're adding to their code will be displayed correctly while they're still developing their thing?

I'm all for keeping the dictionary a dynamic generated-by-database thing.
So, what I suggest is an option in the preferences to open via an external browser. You have to specifically go looking for that option when the dictionary button doesn't work (ties in to viewtopic.php?p=3836#p3836)

The default is to use the generated API (old original method). On some systems, this plain does not work. But you can always shift-click and get the old API behaviour regardless of what's set in the preferences. I only offer my pre-cached non-dynamic OXT_guide option as a fallback for when the dictionary button doesn't work. It would be good just to fix the browser widget on linux so it worked reliably, quickly, efficiently and securely. But that's out of scope of what I'm able to do.
(having said that, I originally thought I wouldn't have been able to do half of what I've already done).

Sure, once an extension or library is worthy of being added to the IDE, then its docs can be static, added to the IDE distributions Dictionary files, but there would need to be included some tool for previewing while a thing is still work-in-progress. There's been one or two community attempts at tools like that. Brian Milby has previously consented to adding his .LCDOC previewing tool to OXT, so that could be useful.

If we can't fix the browser widget on Linux, I'm all for having some different (more reliable?) method of displaying this that works across all platforms seamlessly. That way, could it be kept as a non-static thing, generated and adaptable depending on what xcmds someone might have installed. I realise there are drawbacks with having a static dictionary, so this was a last-resort option rather than something I considered a replacement to the api method.

In fact, where would anyone get additional XCMDs that work across all platforms these days?

[tperry2x]

Something else I wondered about, Paul.

In your RC versions, I noticed that when you are designing a UI involving buttons and fields etc, it very helpfully draws positioning guides such as rulers on the card as an overlay.

I really like this feature, and would like it to be an option that can be toggled in the preferences.
Can you tell me where I can find this bit you added - was it hard to do?

I'd like to add this feature into the Lite version so it's at least on-par with this functionality-wise.

[OpenXTalkPaul]

Something else I wondered about, Paul.

In your RC versions, I noticed that when you are designing a UI involving buttons and fields etc, it very helpfully draws positioning guides such as rulers on the card as an overlay.

I really like this feature, and would like it to be an option that can be toggled in the preferences.
Can you tell me where I can find this bit you added - was it hard to do?

I'd like to add this feature into the Lite version so it's at least on-par with this functionality-wise.

Yes, I like the feature a LOT too ( I've used a similar feature in Adobe Illustrator for decades), which is why I integrated it in OXT DPE. This feature is handled by a script-(no LCB)-library-extension by the guys at Ferrus Logic (Source: https://github.com/Ferruslogic/DevGuides). Bernd Niggermann (BN) had built a similar thing as an IDE plug in, but the Ferrus version was built like an extension library, which made integrating it into the IDE a breeze (just drop in in the appropriate folder in the extensions folder). I then just needed to make some slight modifications to toggle it on and off (which is a little wonky, I'm not sure why) from a IDE menu.

Worth noting that any script libraries could be integrated into the IDE in this way, just needs initialize / uninitializer handlers (look at the Drawing Library for another example). I was thinking a 'darkMode' aware, IDE theming library could be added this way.