What I'm adding, and what I'm planning next...

[tperry2x]

Between other jobs, I'll probably add this as an option (last on the left, of the preferences window).
Inspired by Firefox's about:config page, or Chrome's chrome://flags page
Just as a way to verify prefs are set correctly if nothing else. (might be helpful if anyone is debugging stuff).
I put this together (link here).

screenshot.png (71.86 KiB) Viewed 2236 times

It also times how fast it does the data fetching, the sorting, and the colouring - so I suppose you could also use it as a kind of benchmarking tool too.

[OpenXTalkPaul]

Hah! I found why the debugger comes up harmlessly on LC launch. In your home stack script in the IDEToLightMode handler you now have several lines of the sort

Code: Select all

set the opaque of group "background" of stack "revTools" to false
set the backgroundColor of group "background" of stack "revTools" to White
set the foregroundColor of group "background" of stack "revTools" to Black

and so on, which fail because these exist in your version of the revTools stack but not in PowerTools (which renames itself and replaces the existing revTools stack. Solving this would just be a matter in the home stack of

Code: Select all

if there is a group "background" of stack "revTools" then
	set the opaque of group "background" of stack "revTools" to false
	set the backgroundColor of group "background" of stack "revTools" to White
	set the foregroundColor of group "background" of stack "revTools" to Black
end if

or better yet, place a command "setGroupParams" in your revTools stack that handles the property settings and then in the home stack

Code: Select all

dispatch "setGroupParams" to stack "revTools"

Yes, as you could probably see there was lots of code I commented out too, from when I was trying different things to make revTools look OK in macOS 'darkMode', once I got it to look OK on all desktop platforms, I moved on to other things without adding any sort of error checking. At minimum those should be wrapped in try/end try structure to ignore errors like that. I never would have considered replacing an IDE stack In-Memory with a different stack (seems like maybe could be security issue).

The 'darkMode problem' is common with a lot of community made stacks where authors applied a light color background but didn't apply a foregroundColor / textColor, assuming that the default foregroundColor will always be black is a bad assumption as, at least on macOS, the Engine inherits the defaults for fore/back colors from the operating system, which toggling between light/dark mode changes these colors and then all that text becomes white 'on the fly' if the text chunk is at its default ('empty'), which of course is much less readable when its a top a light background color.

I've been thinking I'd like to have unified Color Library, to which I would facilitate detecting 'dark' mode on ALL platforms (including web), and that GIMP Color Palette file reader (there's even Pantone color match sets available for Print pros) that I posted months back, plus some functions from OXT Color Swatches Palette (like web hex<>RGB triplet). Additionally there's two open-source color libraries on gitHub, Quatram Color Lib (LGPLv3) which has handlers for converting RGB<>CMYK (printing), HSL, etc., and also TinyColor ported from a JS lib by the Ferrus Logic guys (MIT license) (includes 'darkMode detection' on Win/Linux). Both also nice for making color variation sets, get complimentary colors, etc. I would however prefer one unified library for all these color related things.

[mwieder]

I never would have considered replacing an IDE stack In-Memory with a different stack (seems like maybe could be security issue).

Heh. Yeah - I had to brain my way around how that mechanism was gonna work. Renaming in place was/is necessary though because of the unfortunate interactions with other system stacks: set the blah of stack "revTools" to blah. For instance the control-tab toggle between edit and browse modes not only explicitly references the revTools stack by name but also references the names of the controls used to display the current mode, so I'm stuck with those.

I tend to use the "dispatch" command a lot (a LOT) in order to avoid that kind of coupling. If the command was handled then the proper recipient handler was in the target. If not then no harm, no foul.

[OpenXTalkPaul]

Between other jobs, I'll probably add this as an option (last on the left, of the preferences window).
Inspired by Firefox's about:config page, or Chrome's chrome://flags page
Just as a way to verify prefs are set correctly if nothing else. (might be helpful if anyone is debugging stuff).
I put this together (link here).

screenshot.png

It also times how fast it does the data fetching, the sorting, and the colouring - so I suppose you could also use it as a kind of benchmarking tool too.

This is something very similar to a stack I threw together that uses the Tree View widget to display that Array:

View revPrefs.oxtstack

(69.39 KiB) Downloaded 76 times

[OpenXTalkPaul]

I'm getting that issue where there's two stacks with the same name with PowerTools 'revtools' and my modified OXT 'revTools' and the IDE goes all loopy.

Might be PowerTools is assuming that the pre-existing Tools palette filename is 'revTools', currently in my OXT DPE ('heavy') this stack file is actually named 'oxtTools.oxtscript' and there is no file with the name revTools.

[mwieder]

Might be PowerTools is assuming that the pre-existing Tools palette filename is 'revTools', currently in my OXT DPE ('heavy') this stack file is actually named 'oxtTools.oxtscript' and there is no file with the name revTools.

Yes, that's correct. And it does the right thing in the OpenXTalk-x86_64.AppImage you posted a couple of years ago. I'll cobble together an experimental version that checks that out and send it your way. Can I assume that 'oxtTools.oxtscript' is the filename and 'oxtTools' is the stack name? Have you renamed the Preferences stack as well?

Ah. Your code that deals with the dark mode (see above ideToLightMode, ideToDarkMode) is preventing my stack from doing the full replacement thing in preOpenStack. That's not a problem in my AppImage but I do see both PowerTools and an invisible revTools stack in memory.

[mwieder]

I'm confused about where to submit pull requests. You have two similarly-named repositories on github. Should I be issuing pull requests to OpenXtalk-IDE-DontPanicEdition or to OpenXTalk-Community-DPE? Looks to me like maybe the DontPanicEdition repo is more up to date. Is the other one just a legacy repo now?

[OpenXTalkPaul]

I'm confused about where to submit pull requests. You have two similarly-named repositories on github. Should I be issuing pull requests to OpenXtalk-IDE-DontPanicEdition or to OpenXTalk-Community-DPE? Looks to me like maybe the DontPanicEdition repo is more up to date. Is the other one just a legacy repo now?

Right, I've kinda made a mess of the repos, sorry, but there is some method to the madness...

OpenXtalk-IDE-DontPanicEdition: renamed and rearranged branch off of the 'livecode ide' repo. This is where most changes I've made are, in the IDE scripts. This repo is not really up-to-date with my current testing copy on my SSD. As I've said I'm not real good about syncing to GitHub, and currently I'm trying to incorporate changes from Tom's OXT Lite builds. There's also a bunch of experimental stacks, artwork folders, reminders and other notes in various folders in the main directory.
I rearranged the main directory so that there is an 'IDE Bundle' folder. Inside that there is a 'Contents' folder, the same name of subdirectory you'll find inside any macOS .app bundle, inside that are macOS app-specific files: modified PkgInfo, info.plist, _CodeSignature folder, Resources folder with OXT .icns, 'macOS' folder that contains the Mac-version of IDE binary and revsecurity.dylib, then there is the 'Tools' folder which is actually 'the IDE' folder, inside of this is the Windows AND Linux IDE executable binaries. The sub-directories from this point are largely common as far as directory structure between the macOS, Win, and Linux versions of the IDE. I merged installed copies from all three platforms together from that point, so for example if you go into the 'Externals' folder you'll find revzip.bundle (Mac) AND revzip.dll (Win) AND revzip.so (Linux). This means you could, theoretically, download that Repo and then run the IDE from that same directory whether you're booted into MacOS, Windows, or Linux. One install to rule them all! At least that was the theory but I had to compress some installed bit of CEF Framework that were larger than 100MB due ti GitHub individual file size limitation.
My reasoning in arranging it this way was that I could alias/shortcut/symlink to this directory, having it sitting on a universally readable FAT32 drive partition that would be a common 'Tools' folder to use with my tripple-OS-boot set-up or with VM installs, in order to test drive the same exact IDE scripts on almost any desktop OS. This structure also makes it easier to do a directory-walking 'DIFF' to bulk-compare all of my changes to the last released LC CE 9.6.3 IDE.

OpenXTalk-Community-DPE: is a renamed branch off of the 'livecode' repo, which is main 'Engine' repo and also the dictionary data builder. That contains a submodule-pointer to the ide repo but on GitHub that still points to the last 'livecode ide' branch, which needs to be fixed. The changes I've made in this repo are a version numbering change (v.1.963.1), in the dictionary deleting or replacing the word 'livecode' with either a generic, such as 'Livecode Script' -> 'xTalk script', 'livecode' -> 'the IDE', etc. wherever possible. Preference is given to generic terms, 'De-branding' over 'Re-Branding'. I've also made a few corrections and additions to the Dictionary, like adding in / updating the in-line documentation from the 'revIDELibrary' (very helpful if you're rebuilding the IDE, or making IDE Add-Ons), names of other xTalk dialects and a few glossary terms (Example new sound/music terms: MIDI, SoundFonts, playSentence).

[OpenXTalkPaul]

I spent some time this morning making PowerTools 'dark mode' friendly.
It loads OK with my current OXT IDE as long as I open PowerTools stack after the IDE is already launched.

PowerTools.rev

(1.38 MiB) Downloaded 80 times

Screen Shot 2024-06-17 at 1.55.11 PM.png (155.67 KiB) Viewed 2158 times

Screen Shot 2024-06-17 at 1.55.20 PM.png (160.13 KiB) Viewed 2158 times

[mwieder]

So... I've been submitting my pull requests to the OpenXtalk-IDE-DontPanicEdition repo, and from your description it sounds like that's the correct place to put them. Some of the older ones might be a bit out of date now since they've been sitting around and you may have made other changes since the submission date.

I'll start a new thread for PowerTools since this topic is getting a bit long in the tooth.

[OpenXTalkPaul]

Here's what I currently have in my Home stack for dark/light mode:

Code: Select all

on IDEToLightMode
   lock screen
   --- it might be better to have a generic script that swaps foreground and background colors on objects
   if the platform is "MacOS" then put true into isMac
   --- for macOS --- NOTE: This uses the OpenXTalk.org macOS Native Library if available - Paul McClernan - 1/16/22
   
   -- put false into isMac -- for testing other OS styling on macOS IDE
   -- try
   --- Tools Palette ---
   -- set the opaque of group "background" of stack "revTools" to true
   -- set the backgroundColor of group "background" of stack "revTools" to 59,63,63
   -- set the opaque of group "contents" of stack "revTools" to true
   -- set the backgroundColor of group "contents" of stack "revTools" to "Gray25"
   -- set the foreGroundColor of group "contents" of stack "revTools" to "White"
   -- set the opaque of group "runedit" of stack "revTools" to false
   -- set the backgroundColor of group "runedit" of stack "revTools" to "Gray25"
   -- set the foreGroundColor of group "runedit" of stack "revTools" to empty -- "White"
   -- set the backgroundColor of graphic "tool_hilite" of stack "revTools" to 120,63,170
   -- set the backgroundColor of graphic "tool_hover" of stack "revTools" to 80,23,150
   if isMac is true then
      try
         --- for macOS ---
         setAppToLightMode
         -- setWindowToLightMode
         set the backGroundColor of stack "revTools" to empty -- "Gray30"
         set the foreGroundColor of stack "revTools" to empty -- "White"
         -- set the opaque of group "widget" of stack "revTools" to false
         set the foreGroundColor of group "widget" of stack "revTools" to  "Black"
         set the backgroundColor of group "widget" of stack "revTools" to empty -- "Gray50"
         set the foreGroundColor of group "background" of stack "revTools" to "White"
         
         -- set the opaque of group "classic" of stack "revTools" to true
         -- set the foreGroundColor of group "classic" of stack "revTools" to "White"
         set the backgroundColor of group "classic" of stack "revTools" to empty -- "Gray60"
         
         -- set the opaque of group "graphictoolscontrols" of stack "revTools" to true
         -- set the backgroundColor of group "graphictoolscontrols" of stack "revTools" to "Gray25"
         -- set the foreGroundColor of group "graphictoolscontrols" of stack "revTools" to "White"
         
         -- set the opaque of group "graphictools" of stack "revTools" to true
         -- set the backgroundColor of group "graphictools" of stack "revTools" to "Gray25"
         -- set the foreGroundColor of group "graphictools" of stack "revTools" to "White"
         
         -- set the opaque of stack "Message Box" to false
         set the foreGroundColor of stack "Message Box" to "Black" -- empty
         set the backGroundColor of stack "Message Box" to "White"-- "Black"
         
         -- set the opaque of stack "revPreferencesGUI" to false
         set the backgroundColor of stack "revPreferencesGUI" to "White"
         set the foreGroundColor of stack "revPreferencesGUI" to "Black"
      end try
   else
      try
         set the foreGroundColor of stack "revTools" to "Black"
         set the backGroundColor of stack "revTools" to "White"
         set the foreGroundColor of group "widget" of stack "revTools" to "Black"
         set the backgroundColor of group "widget" of stack "revTools" to "White"
         set the foreGroundColor of group "background" of stack "revTools" to "Black"
         set the backgroundColor of group "classic" of stack "revTools" to "White"
      end try
      if the systemVersion is "NT 10.0" then set the textColor of group "revMenuBar" of stack "revMenuBar" to "Black"
      try
         -- set the opaque of stack "revMenuBar" to false
         set the foreGroundColor of stack "revMenuBar" to "Black" -- empty
         set the backGroundColor of stack "revMenuBar" to "White"-- "Gray25"
         
         -- set the opaque of stack "Message Box" to false
         set the foreGroundColor of stack "Message Box" to "Black" -- empty
         set the backGroundColor of stack "Message Box" to "White"-- "Gray25"
         
         --- revMenuBar Toolbar palette ---
         -- set the opaque of group "toolbar" of stack "revMenuBar" to false
         -- set the backgroundColor of group "toolbar" of stack "revMenuBar" to "Gray25"
         -- set the foreGroundColor of group "toolbar" of stack "revMenuBar" to "White"
         
         set the backgroundColor of stack "revPreferencesGUI" to "White"
         set the foreGroundColor of stack "revPreferencesGUI" to "Black"
         
         set the backgroundColor of stack "revIDEProjectBrowser" to "White"
         set the foreGroundColor of stack "revIDEProjectBrowser" to "Black"
         
         set the foregroundColor of stack "revOnline" to "Black"
         set the backgroundColor of stack "revOnline" to "White"
         
         set the foreColor of stack "revIDEExtensionManager" to "Black"
         set the backColor of stack "revIDEExtensionManager" to "White"
         
         set the backColor of stack "revExtensionBuilder" to "White"
         set the foreColor of stack "revExtensionBuilder" to "Black"
         
         set the foreColor of stack "revDictionary" to "Black"
         set the backColor of stack "revDictionary" to "White"
      end try
   end if
   try
      set the foreColor of widget "header_background" of stack "revTools" to black
      
      set the backColor of field "contents" of card "Global Variables" of stack "message" to Black
      set the backColor of field "type" of card "Global Variables" of stack "message" to Black
      --put set the foreColor of me to White
      set the foreColor of field "contents" of card "Global Variables" of me to White
      set the foreColor of field "type" of card "Global Variables" of stack "message" to Gray80
      
      set the backColor of field "contents" of card "Global Properties" of me to Black
      set the backColor of field "type" of card "Global Properties" of stack "message" to Black
      --put set the foreColor of me to White
      set the foreColor of field "contents" of card "Global Properties" of stack "message" to White
      set the foreColor of field "type" of card "Global Properties" of stack "message" to Gray80
      
      set the cDarkMode of stack "revPreferences" to false
      unlock screen
   end try
end IDEToLightMode

on IDEToDarkMode
   lock screen
   --- it might be better to have a generic script that swaps foreground and background colors on objects
   if the platform is "MacOS" then put true into isMac
   --- for macOS --- NOTE: This uses the OpenXTalk.org macOS Native Library if available - Paul McClernan - 1/16/22
   
   -- put false into isMac -- for testing other OS styling on macOS IDE
   -- try
   --- Tools Palette ---
   -- set the backgroundColor of group "contents" of stack "revTools" to "Gray25"
   -- set the foreGroundColor of group "contents" of stack "revTools" to "White"
   -- set the opaque of group "runedit" of stack "revTools" to false
   -- set the backgroundColor of group "runedit" of stack "revTools" to "Gray25"
   -- set the foreGroundColor of group "runedit" of stack "revTools" to empty -- "White"
   -- set the backgroundColor of graphic "tool_hilite" of stack "revTools" to 120,63,170
   -- set the backgroundColor of graphic "tool_hover" of stack "revTools" to 80,23,150
   if isMac is true then
      try
         setAppToDarkMode
         -- setWindowToDarkMode
         set the backGroundColor of stack "revTools" to empty -- "Gray30"
         set the foreGroundColor of stack "revTools" to empty -- "White"
         -- set the opaque of group "widget" of stack "revTools" to false
         set the foreGroundColor of group "widget" of stack "revTools" to  "White"
         set the backgroundColor of group "widget" of stack "revTools" to empty -- "Gray50"
         set the foreGroundColor of group "background" of stack "revTools" to "White"
         
         -- set the opaque of group "classic" of stack "revTools" to true
         -- set the foreGroundColor of group "classic" of stack "revTools" to "White"
         set the backgroundColor of group "classic" of stack "revTools" to empty -- "Gray60"
         
         -- set the opaque of group "graphictoolscontrols" of stack "revTools" to true
         -- set the backgroundColor of group "graphictoolscontrols" of stack "revTools" to "Gray25"
         -- set the foreGroundColor of group "graphictoolscontrols" of stack "revTools" to "White"
         
         -- set the opaque of group "graphictools" of stack "revTools" to true
         -- set the backgroundColor of group "graphictools" of stack "revTools" to "Gray25"
         -- set the foreGroundColor of group "graphictools" of stack "revTools" to "White"
         
         -- set the opaque of stack "Message Box" to false
         set the foreGroundColor of stack "Message Box" to "White" -- empty
         set the backGroundColor of stack "Message Box" to "Gray35"-- "Black"
         
         -- set the opaque of stack "revPreferencesGUI" to false
         set the backgroundColor of stack "revPreferencesGUI" to "Gray20"
         set the foreGroundColor of stack "revPreferencesGUI" to "White"
      end try
   else
      try
         set the foreGroundColor of stack "revTools" to "White"
         set the backGroundColor of stack "revTools" to "Gray20"
         set the foreGroundColor of group "widget" of stack "revTools" to  "White"
         set the backgroundColor of group "widget" of stack "revTools" to "Gray20"
         set the foreGroundColor of group "background" of stack "revTools" to "White"
         set the backgroundColor of group "classic" of stack "revTools" to "Gray20"
         
         if the systemVersion is "NT 10.0" then set the textColor of group "revMenuBar" of stack "revMenuBar" to "Black"
         -- set the opaque of stack "revMenuBar" to false
         set the foreGroundColor of stack "revMenuBar" to "White" -- empty
         set the backGroundColor of stack "revMenuBar" to "Gray30" -- empty -- "Gray25"
         
         --- revMenuBar Toolbar palette ---
         -- set the opaque of group "toolbar" of stack "revMenuBar" to false
         -- set the foreGroundColor of group "toolbar" of stack "revMenuBar" to "White"
         -- set the backgroundColor of group "toolbar" of stack "revMenuBar" to "Gray30"
         
         -- set the opaque of stack "Message Box" to false
         set the foreGroundColor of stack "Message Box" to "White" -- empty
         set the backGroundColor of stack "Message Box" to "Gray30"-- "Black"
         
         -- set the opaque of group "background" of stack "revPreferencesUI" to true
         set the backgroundColor of stack "revPreferencesGUI" to "Gray20"
         set the foreGroundColor of stack "revPreferencesGUI" to "White"
         
         set the backgroundColor of stack "revIDEProjectBrowser" to "Black"
         set the foreGroundColor of stack "revIDEProjectBrowser" to "White"
         
         set the foregroundColor of stack "revOnline" to "White"
         set the backgroundColor of stack "revOnline" to "Gray25"
         
         set the foreColor of stack "revIDEExtensionManager" to "White"
         set the backColor of stack "revIDEExtensionManager" to "Gray20"
         
         set the foreColor of stack "revExtensionBuilder" to "White"
         set the backColor of stack "revExtensionBuilder" to "Gray25"
         
         set the foreColor of stack "revDictionary" to "White"
         set the backColor of stack "revDictionary" to "Gray30"
      end try
   end if
   try
      set the foreColor of widget "header_background" of stack "revTools" to white
      
      set the backColor of field "contents" of card "Global Variables" of stack "message" to White
      set the backColor of field "type" of card "Global Variables" of stack "message" to Gray80
      --put set the foreColor of me to White
      set the foreColor of field "contents" of card "Global Variables" of stack "message" to Black
      set the foreColor of field "type" of card "Global Variables" of stack "message" to Black
      
      
      set the backColor of field "contents" of card "Global Properties" of stack "message" to White
      set the backColor of field "type" of card "Global Properties" of stack "message" to Gray80
      --put set the foreColor of me to White
      set the foreColor of field "contents" of card "Global Properties" of stack "message" to Black
      set the foreColor of field "type" of card "Global Properties" of stack "message" to Black
      
   end try
   set the cDarkMode of stack "revPreferences" to true
   unlock screen
end IDEToDarkMode

   -- on iconMenuOpening
   --   -- lock screen
   --   if the cREVLaunching of me is true then exit iconMenuOpening
   --   set the iconMenu to (tab & "Utilities" & cr & tab & tab & "Gather Windows")
   --   -- set the icon of this stack to image id
   --   -- set the statusIconMenu to iconMenuSpec
   --   -- set the statusIconToolTip to "app toolTip here"

   --   -- put "Home Stack Message Recieved:" &cr& "IconMenuOpening" & cr after msg
   --   -- pass iconMenuOpening
   --   -- unlock screen
   ---- end iconMenuOpening

   ---- on iconMenuPick pParamMaybe
   --   if the cREVLaunching of me is true then exit iconMenuPick
   --   put "Home Stack Message Recieved:" &cr& "iconMenuPick" & cr after msg
   --   if pParamMaybe is not empty then
   --      put pParamMaybe after msg
   --   end if
   --   -- pass iconMenuPick
   -- end iconMenuPick

on systemAppearanceChanged
   put the systemAppearance into tAppearance
   -- put "Home Stack Message Recieved:" &cr& "systemAppearanceChanged" && tAppearance & cr after msg
   if tAppearance is "dark" then
      send "IDEToDarkMode" to stack "home" in 1 milliseconds
   else
      send "IDEToLightMode" to me in 1 milliseconds
   end if
   pass systemAppearanceChanged
end systemAppearanceChanged

There's lots of lines commented out, the result of my indecisiveness.
The 'on iconMenuPick' thing that's commented out was about creating a custom Dock menu on macOS, but it kind of doesn't work too well on my macOS 11 OXT testing Mac. I think it was marked 'experimental' when support for that was added to the Engine, which was long before the Open-Source edition ( like RunRev version 4 or 5).

[tperry2x]

Coming back to what I'm adding next, I'm now working on the FX-section of my new inspector.
I knew the fx popup (for drop shadows etc) was broken, but I forgot just how broken it was.

So, thought I'd post an example of setting drop-shadows. This (along with all the other fx possible) is what's going into my inspector tab (this is a simplistic proof-of-concept version), but it doesn't freak out after a couple of uses like the current one does.

(It also doesn't make your CPU fans come on, and processor use stays low - unlike the current one)

(example stack link here)

screenshot-v1.png (51.82 KiB) Viewed 2085 times

edit (a bit further forward) - multiple effect handling idea:

fx-tests-v3.gif (222.65 KiB) Viewed 2008 times

[OpenXTalkPaul]

Coming back to what I'm adding next, I'm now working on the FX-section of my new inspector.
I knew the fx popup (for drop shadows etc) was broken, but I forgot just how broken it was.

So, thought I'd post an example of setting drop-shadows. This (along with all the other fx possible) is what's going into my inspector tab (this is a simplistic proof-of-concept version), but it doesn't freak out after a couple of uses like the current one does.

(It also doesn't make your CPU fans come on, and processor use stays low - unlike the current one)

(example stack link here)

screenshot-v1.png

Excellent! I've gotten used to closing and then reopening the existing FX editor, which fixes that stack's layout 'freakout', but it's a super-annoying bug.

I've been looking at some of your other changes. This morning I tried to merge our different revMenuBar stacks into one, was trying to include even the stuff I'm not planning on implementing (like the revMenuBar 'dragbar'), but it kept failing to fully launch the IDE for some reason so I backed off on including a bunch of those changes. Mostly just added Key-Combo listings in the menus.

I added in that that shift-click dictionary ('marked as 'for Paul', thanks), but on OXT Lite when I shift-click the Dictionary stack does come up as normal with the web-page layout showing, but NO Dictionary is linked up to it, it's an otherwise blank page with two divs and single popup menu button, and in that 'API' popup menu the only thing listed is 'LiveCode Script', which in my build should read as just 'Script'. I had to altered the html-template file that revDocs uses to build its webpage so that it would be linked to the un-branded files. So if you just grab my version of the HTML-template it should work again. here's the file I'm talking about in my GitHub repo: https://github.com/OpenXTalk-org/OpenXt ... l.template

EDIT: Nope that's not the file! It's probably best to just take my whole /Tools/Documentation/ folder.
https://github.com/OpenXTalk-org/OpenXt ... umentation:
I think that the crucial edits were actually made in the other repo that has the doc's builder, I'll try to find the exact edits later. Basically I searched for "'LiveCode Script"" in all of the HTMLtemplate/JS/CSS files to find where it needed un-branding, then changed removed "LiveCode ". So the API "LiveCode Builder" became just "Builder" and "LiveCode Script" API became just "Script".

Also, I have good function (in my GIF Parser stack) that can quickly check if an image control contains GIF data or not, might want to use that for your 'Rotate Animated GIF Bug" stop gap fix. For that I was simply going to check the frameCount and if it's greater than 1 raise an alert box explaining the super-lossy effect of the rotating any animated GIF with the IDE.

[tperry2x]

EDIT: Nope that's not the file! It's probably best to just take my whole Tools/Documentation folder.
https://github.com/OpenXTalk-org/OpenXt ... umentation:
I think that the crucial edits were actually made in the other repo that has the doc's builder, I'll try to find the exact edits later. Basically I searched for "'LiveCode Script"" in all of the HTMLtemplate/JS/CSS files to find where it needed un-branding, then changed removed "LiveCode ". So the API "LiveCode Builder" became just "Builder" and "LiveCode Script" API became just "Script".

Ah, that explains it - as I was just about to post that it didn't work.
Will try that tomorrow.
Was just trying to download that one directory, but (this old chestnut again), can't seem to do it on one directory, so had to run it through a github downloading site (link)
It produced a zip file which I'll try tomorrow.

Regarding the menubar stuff. I got the same issue whenever I tried to comment out a certain section in the home stack. It's actually your menubar stack taken from OXT heavy, (it's got all your additional stack preset sizes in there). I think it's something inter-related/inter-woven related to the home stack (how they are inter-related), as commenting out the part about "switch pEdition" and all the indy / community plus / commercial stuff - as soon as I do, it bawks and won't relaunch properly. I wonder if it's something related to that we are running into? If you'd already commented that out in your home stack in 'heavy', you may be running into the same issue now if that makes sense. (line 2026)
That's why it's not removed in Lite, as doing so seems to break everything at the moment.

[tperry2x]

I'm also going to have to try that dictionary folder swapout on a different linux machine that I'm writing this on.
Currently I'm writing this on xubuntu, running xfce. Because of Ubuntu / Xubuntu's insistence on installing snap (which I hate as it's laggy and many other reasons), I'm using appimages for Firefox. The downside of this is that OXT and LCC can't understand how to find those (probably because they aren't in /usr/bin), so just fail to launch.

(This is entirely my fault) - an issue of my own making, but I dislike snap with a passion. Anyway, sorry to bore you.

I'll try it again on a linux distro that doesn't push snap in my face, and with a conventionally installed browser through a package manager as normal, then go from there.

[OpenXTalkPaul]

EDIT: Nope that's not the file! It's probably best to just take my whole Tools/Documentation folder.
https://github.com/OpenXTalk-org/OpenXt ... umentation:
I think that the crucial edits were actually made in the other repo that has the doc's builder, I'll try to find the exact edits later. Basically I searched for "'LiveCode Script"" in all of the HTMLtemplate/JS/CSS files to find where it needed un-branding, then changed removed "LiveCode ". So the API "LiveCode Builder" became just "Builder" and "LiveCode Script" API became just "Script".

Ah, that explains it - as I was just about to post that it didn't work.
Will try that tomorrow.
Was just trying to download that one directory, but (this old chestnut again), can't seem to do it on one directory, so had to run it through a github downloading site (link)
It produced a zip file which I'll try tomorrow.

I was correct the second time, the 'API' 's get set on each entrees as the dictionary data files are built, so the crucial change is in that Engine/Docs Building Repo, in the file docs_builder.livecodescript here:
https://github.com/OpenXTalk-org/OpenXT ... cript#L278

But if you don't want to rebuild the Dictionary from source (.lcdocs, and guide .md files) , then you can just pick-up my built files. I believe (can't check right now) that I also un-branded the web page <Title> too so that window frame is just titled "Dictionary" when viewing in a Web Browser.

[tperry2x]

One issue with doing that, is that I'll pickup your mysql database - and this will contain things like references for your music library and other bits you've added to 'heavy' These won't apply to lite, so I didn't want to introduce stuff that isn't available. Would that be the case, or are all the dictionary changes called in from libraries you've added instead? (meaning the SQL doesn't contain things specific to 'heavy')?

[OpenXTalkPaul]

Regarding the menubar stuff. I got the same issue whenever I tried to comment out a certain section in the home stack. It's actually your menubar stack taken from OXT heavy, (it's got all your additional stack preset sizes in there). I think it's something inter-related/inter-woven related to the home stack (how they are inter-related), as commenting out the part about "switch pEdition" and all the indy / community plus / commercial stuff - as soon as I do, it bawks and won't relaunch properly. I wonder if it's something related to that we are running into? If you'd already commented that out in your home stack in 'heavy', you may be running into the same issue now if that makes sense. (line 2026)
That's why it's not removed in Lite, as doing so seems to break everything at the moment.

In my current file I've only left in the "Community" portions of that long switch/case, if it's the same handler I'm thinking of, that mostly just builds a color-sets for use in various IDE stacks, so 'Community" was a lite-green color set, community-plus was darker-green colors, "indy" was blue colors , etc. But there's one or two lines about things like "auto-complete-pro" like in the commercial sets. I was thinking it might be the lines in your revMenuBar that read properties from revPreferences.rev file that were failing for me, because I didn't have all of the same properties in my revPrefs as you have for OXT Lite. I suppose it might be helpful to uncomment the Home script lines that created a start-up log file for debugging, which I had commented out to try to speed up launch times.

[OpenXTalkPaul]

One issue with doing that, is that I'll pickup your mysql database - and this will contain things like references for your music library and other bits you've added to 'heavy' These won't apply to lite, so I didn't want to introduce stuff that isn't available. Would that be the case, or are all the dictionary changes called in from libraries you've added instead? (meaning the SQL doesn't contain things specific to 'heavy')?

Correct, my Dictionary builds it do contain APIs from libraries and Widgets I've added to the IDE. It also includes docs for some of the IDE libraries' handlers (to help anyone who wants to contribute). I've also added a few glossary terms and removed all the stuff that was about commercial externals and extensions (most of Monte's externals, XPDF external, LC's PDFium wrapper widget, their commercial revLibURL-thing 'tsNet', etc.).

But it's pretty easy to build the dictionary data files from that stack in there called 'Builder.rev'. Builder.rev has a drop down menu to select what you want it to try to build for you, with choices such as 'LiveCode Server' (and there's a platform and build type drop down menus), an d one of menu's choices is "Docs" or "Documentation", then you click build button and it try to fins the Documentation and .lcdocs, notes and guide files within the repo. The stack can also be used to build a User Guide from aggregated with 'Release Notes' files in those folders.

https://github.com/OpenXTalk-org/OpenXT ... .1/builder
https://github.com/OpenXTalk-org/OpenXT ... uilder.rev

You could just remove the few extra things I added like xTalk 'playSentence' support, related glossary terms, etc. and then rebuild the Docs data from the builder stack, takes a minute or three at most.

I will say again that there is absolutley no reason the OXT General Music library should be considered 'heavy', the bulk of it was written for the 200MHz CPU era computing, the idea of it is that it tries to degrade gracefully, so that if we had a super-ancient-retro-edition the library would drop down to using MCISend MIDI to a Soundblaster for playback on a Win95 box, if you aren't making music-education stack notes then this library doesn't do anything and should never effect anything else. It's a fairly small script-only library, NOT the 'heavy' libFluidSynth library that I'm talking about, although it can use that as a playback engine if it's installed. I hope to eventually add a wrapper for Drumstick.framework, JACK and/or full ALSA support, etc. for my eventual migration to Linux

https://github.com/OpenXTalk-org/OpenXT ... 963.1/docs
Looking at the Docs directory on that repo right now it looks like I really never pushed some of those additional .lcdoc files to the repo? It might be a good time to grab that folder before I fix that later, probably tonight. IIRC I had a git conflict from pushing changes from two different machines, so some files in that repo are actually newer than what's on my dev laptop and some newer files are missing. I really that things go for a while there, it's a bit of a mess.

[mwieder]

Soundblaster! Having a flashback here.