Hosing the IDE with a 2 line delete

[richmond62]

Well, that was, as they say, "a right pox" . . .

Here I am trying to be clever (obviously not clever enough) in an attempt to remove / hide the 'New widget' menu item:
-

Screenshot 2023-10-29 at 19.34.58.png (392.94 KiB) Viewed 2786 times

-
By editing out 2 lines of the revmenubar.livecodescript file:
-

Screenshot 2023-10-29 at 19.39.28.png (111.6 KiB) Viewed 2785 times

-
and getting THIS:
-

Screenshot 2023-10-29 at 19.41.04.png (47.06 KiB) Viewed 2785 times

-
Which, while having a certain charm . . .

Is totally useless.

Does anyone know how to mess around with the menu items in the menuBar stack?

[richmond62]

Banging on anent this one as really need an answer.

[tperry2x]

Looks like you've used underscores instead of dashes to comment, which will cause an error

[richmond62]

Let's hope it was ONLY me being foolish: we shall see when I try things again in, erm, 2 ticks time . . .

You are completely right, and I feel like a right "Ucking Fidiot" quite frankly . . . probably not enough coffee.

As you will have guessed this is part of my effort to 'castrate' your OpenXTalk to make an 'OpenXTalk Kiddie-version' without widgets.

I would also be grateful if you could tell me one other thing:

How to change the name of the IDE from 'OXT Lite' to something else.

I assure you in my 'branchline' I will give you full credit.

Branchline:
-

lazybeach01.jpg (17.54 KiB) Viewed 2757 times

[tperry2x]

Oh, okay.
No problem at all. Don't feel you need to give me credit as you are doing the work on that particular build
If you right-click the .app that you are building, and choose 'Show Package Contents', you can change the name shown in the MacOS menubar by editing the info.plist

where.png (80.42 KiB) Viewed 2752 times

Change the next line under "CFBundleName"

edit the plist.png (12.02 KiB) Viewed 2752 times

Whatever you change it to will be shown in the menubar, next to the Apple menu:

afterwards-example.png (57.83 KiB) Viewed 2752 times

[richmond62]

Thank you very much. That is exactly the information I needed.

[tperry2x]

No problem.
If you also choose 'Reset Preferences' from the preferences window, you should also find that it sets the tools to 2 column and hides the widgets as default.

So, if you wanted to build this into a default behaviour, you could use something like:

Code: Select all

on mouseUp
   revInternal__ResetPreferences
   -- however, substitute with these instead
   revIDESetPreference "revTools_show", "paintcontrols,graphictoolscontrols,classic,graphictools,runedit,graphic,paint"
   revIDESetPreference "revTools_columns", 2
   revIDESetPreference "cStartPageShow", false
   revIDESetPreference "cBackdropColor", "Gray40"
   revIDESetPreference "cToolSelectorColor", "Gray50"
   -- end substituted prefs
   updateIDEWithNewPreferences
end mouseUp

[richmond62]

I have mucked around with the Tools thing so the widgets are not offered as an option via the 'cog', so the only way they will show is if some end-user has used another version of OXT and exposed the widgets so the general, shared preferences expose them.

I am wondering if I change the name of my variant to 'OXT Elementary' or even 'xTalk Learner' that might result in a separate prefs file being saved somewhere.

In the middle of last night I thought of renaming the thing 'xTc', but realised that that would go down a bomb with some humourless school teachers.

[tperry2x]

..the widgets are not offered as an option via the 'cog', so the only way they will show is if some end-user has used another version of OXT and exposed the widgets...

Ah, one thing to consider there.
If I assume you are dealing with a multi-user setup, so that students log into the computer with their own username or password:
If that's the case, they won't have the file "livecode7.rev" in their ~/Library/Preferences/Runrev/ folder, so it will show the widgets and default back to I think a 3 column layout (as well as showing the registration screen as it also won't have the "livecode-firstrun.lcf" present for that user.

If you are dealing with a guest login, (so all students use a shared account), then you can copy the "livecode7.rev" and the "livecode-firstrun.lcf" files from your profile to their guest one to stop these things from appearing.

Unfortunately the registration screen is buried within the engine, and can really only be removed by recompiling.
or by having the "livecode-firstrun.lcf" in the expected location when it first runs.

[richmond62]

You expect far too much from me as pupils (no students) will NOT log in to anything: they will sit in front of machines with a single user account running Xubuntu, so xTalk can be set up when it is installed by the lab-manager (me) so that nothing whatsoever will show up that I don't want to.

HOWEVER, what is important is if someone else wants to use my educational variant somewhere else.

[tperry2x]

Ah, in that case, have a poke around in my Linux installer script file.
(Fully commented), but you can incorporate the copy and the touch commands used for copying the preferences, and creating a blank firstrun file.

You could trigger this on user login fairly easily on ubuntu.

[richmond62]

Can you tell me where to find the "livecode-firstrun.lcf" file?

[tperry2x]

Can you tell me where to find the "livecode-firstrun.lcf" file?

Certainly:

Screenshot_2023-10-31_17-24-59.png (43.94 KiB) Viewed 2705 times

[richmond62]

I am now poking around inside the 'Home' stack to see if there is any code that tells it to look for the 'livecode7.rev' file in the User's folders, and whether or not we can squash that and replace it with something called, say 'OXTsettings.rev' that is app-specific rather than a general prefs file for all installations of OXT and LC.

No.

There must be some sort of 'hook' somewhere in the IDE which can be redirected to a different file.

Oh, and by-ther-way, just to be a complete and utter swine, the script of the 'Home' stack is chockablock full of stuff such as:

Code: Select all

case "Linux"
      local tOldFolder
      put the folder into tOldFolder
      set the folder to "~"
      put the folder & slash & "my_livecode" into sCustomizationPath
      set the folder to tOldFolder
      break
    case "Windows"
      put specialFolderPath(0x0005) & "/My LiveCode" into sCustomizationPath
      break
    case "MacOS X"
      put specialFolderPath("docs") & "/My LiveCode" into sCustomizationPath
      break
    end switch

Do we need a folder called 'My LiveCode' clogging up our arteries?

[tperry2x]

That is in the engine I'm afraid, you won't find any mention of that in script.

[tperry2x]

Oh, and by-ther-way, just to be a complete and utter swine, the script of the 'Home' stack is chockablock full of stuff such as:

Code: Select all

case "Linux"
      local tOldFolder
      put the folder into tOldFolder
      set the folder to "~"
      put the folder & slash & "my_livecode" into sCustomizationPath
      set the folder to tOldFolder
      break
    case "Windows"
      put specialFolderPath(0x0005) & "/My LiveCode" into sCustomizationPath
      break
    case "MacOS X"
      put specialFolderPath("docs") & "/My LiveCode" into sCustomizationPath
      break
    end switch

Do we need a folder called 'My LiveCode' clogging up our arteries?

Yes, as this is where plugins can be placed on a per user basis, rather than by trying to install in the application directory which most users won't have access to as default necessarily. That's why it seems to exist.

That above snippet of script is also where it sets up the folder path, which you can later find in the preferences:

Screenshot_2023-10-31_17-46-24.png (63.23 KiB) Viewed 2697 times

[richmond62]

Indeed: but could we not change the folder from 'My LiveCode' to something like 'OXT Plugins' [also a rather more informative name for the folder than the slightly juvenile 'My Problem' type name]?

[tperry2x]

I have done already.
This is now called "My OpenXTalk" instead.
It's listed in my changes:
https://www.openxtalk.org/forum/viewtop ... 4267#p4267

So you can completely change this default by editing line 500, 504 and 507. (1 line for each platform)

[richmond62]

That is in the engine I'm afraid, you won't find any mention of that in script.

Um!

But there should be no earthly reason why one cannot have code in, say, the 'Home' stack that over-writes / bypasses something set in the engine: as, at least as far as I understand, given the hierarchical, inheritance structure of the IDE, just as while one may inherit a white background in a field from a card, or a stack, one can set it to orange; so we should be able to set where we read our preferences to somewhere 'other' than where the engine tells us to look as the first stacks of the IDE load.

[tperry2x]

True, although it's down to the order things load.
Because as far as I can tell, the engine deals with these things before it even starts reading stacks, so it always looks for these things before the home stack loads - so you'll always end up with these files needing to exist even if you were to override it later in the home stack.

This needs changing at compiler level in the engine to truly change it.