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

[tperry2x]

Just added another option in Preferences > Extras, to close unnecessary stacks after the IDE starts.
(This only closes the "RevSplash, RevSplashStackBehavior, revOnlineLibrary, revExtensionBuilder and revExtensionBuilderBehavior" stacks at the moment). It closes and removes them from memory after the IDE has loaded.

If you were to choose "Tools" menu > "Extensions Builder", then the "revExtensionBuilder" stack is reloaded. This seems to have no negative impact, but it does make the IDE a little more 'snappy' and responsive.

close-after-startup.png (31.38 KiB) Viewed 2048 times

[richmond62]

Good stuff, especially for use on less 'spiffy' computers.

I teach with machines with between 256 and 512 MB RAM.

[tperry2x]

I teach with machines with between 256 and 512 MB RAM.

So anything that can be saved here would be good. I can make it more 'ruthless' and prune out a lot more than the stacks I mention above, but I'm worried I may start to affect functionality.

Having 512MB of RAM is quite a barrier. I thought even xubuntu required at least 1GB now
(edit: https://xubuntu.org/requirements/) - yes, they even recommend 2GB for a 'smooth experience'.

I remember when 256MB was considered a lot of RAM. Simpler times, with simpler (arguably more efficient) operating systems (but then, they were tasked with doing a lot less back then).

I think even something like LxPup (Puppy Linux with LXDE) needs 1GB of ram.

Not that I'm being nosy (well, perhaps I am), but what OS can you run on these machines?
I ask as I probably have a few like this kicking around somewhere at our school. I'd like to know what the experience is like on a low-end machine, as I don't want to assume everyone has oodles of hardware resources to play with. I could then think about how to improve it, and see if anything else can be done to make it more efficient.

Are these 32bit machines?
As mentioned on here previously, I'm a big fan of things not going to landfill, while if possible also being updated. That generally means replacing the stock OS with something that's still being worked on. I think it would be possible to take a 32bit version of LCC 9.6.3 for linux and carry all our changes up to 0.95 over, so that you'd have something that would run on these older computers.

[richmond62]

Those are 20 year old 32-bit machines running Xubuntu 18.04, and, to be honest, are my 'second cohort' after my main machines with 4 GB, 64-bit, running Xubuntu 22.04 LTS.

However, have a load of skint Ukrainian refugees living in an old lung hospital down the road who are perfectly happy with those old machines, which I give them for nix.

[tperry2x]

That's good, so at least the 64 bit machines will be able to run OpenXTalk Lite I'd imagine.
The 32bit ones, probably not.

Spotted some other bits that are 'getting to me':

xp-geom.png (69.45 KiB) Viewed 2021 times

Not sure why the Geometry pane uses a Windows-XP graphic in Linux, so I'll swap this out.

Also, how far do we go with removing old LC references?

html-donate.png (62.86 KiB) Viewed 2021 times

"cround" funding.

[tperry2x]

..Give an object geometry settings and then move it to a different location or resize. Navigate to another card and back or resize the stack, and the object jumps back to it's original position or size where the GM settings were made.
The solution is to run in msg box before nav or resizing stack: revCacheGeometry.

Hi Terry, just to revisit this.
(hence why I've quoted you above, so anyone reading this has the context)

I can indeed replicate the issue on Linux, mac (and I'd assume Windows).
Set the geometry to scale this button on card 1.
Go to card 2 and resize the stack.
Go back to card 1 and the button isn't aware of the size change.

geom-issue.gif (358.05 KiB) Viewed 2015 times

This has now been fixed in revgeometrylibrary.livecodescript
Same stack, geometry set to scale the button on card 1.
Go to card 2, resize the stack
Switch back to card 1 and the button is now aware of the size change

geom-fixed.gif (274.38 KiB) Viewed 2015 times

This fix will appear in version 0.96

[richmond62]

Well, any "Gimme the moolah" images have to go, that at least is clear.

[TerryL]

@ tperry.

Looking at all the resources available on your site, this is all great readily downloadable sample content. So much so, I wonder if it's a good idea to produce some of the videos also using these stacks as tutorials?

Attached is a new stack "Quick Start" tutorial, as entry-level basic as I could make with six cards. I was thinking you could make 3-4 minute silent videos of each card, like your download videos. (I tried with Window's Step Recorder but it just makes screen shots.) Modify the stack as desired, maybe save as .oxt. I suggest light-mode, decrease screen resolution to about the width of the menubar, move cursor slowly while performing "Try It" tasks, show the next card at the end of each video as a tease to keep watching.

The idea is to let people peer around and see what OXT can do, which might encourage them to download Lite. They could also download the stack and do the lessons themselves as they watch you do a lesson. The OXT YouTube page would need DropBox links to OXT Lite and the stack I suppose. Any thoughts? Maybe too basic and lame? Richmond's game idea is good too.

I also wanted to reinstate the sample stacks in OXT lite at some stage, and wanted it to no longer reference any LC servers. So, I wondered if you wouldn't mind me using these and linking them as downloadable with thumbnail previews from within OXT Lite?

Link away, OK by me. Are you thinking of a self-service repository like revOnline, or a curated DropBox where stacks are submitted for approval to be posted, or a webpage with links to public stacks like mine?

On Geometry, nicely done. That may not be the bug fix, but was an annoying problem. I was thinking of a Development > Geometry Refresh menuitem that sends "revCacheGeometry" to every card of the topstack within a repeat loop? Apparently just making a GM setting and then undoing it works too. Maybe there's a secret global that's called in the geometry library? I don't know, I'll poke at it some. Terry

[tperry2x]

Tweaked the geometry settings this morning:
Instead of them using these out of date graphics:

old-wds.png (5.27 KiB) Viewed 1990 times

... they now use something a bit more fitting and a bit more up-to-date:

new-wds.png (9.63 KiB) Viewed 1990 times

(Linux gets some love here too, as there wasn't a separate style for this before, so it would use the 'windows-xp' looking one previously). It now has it's own ubuntu-esque one.

I am currently looking at the inspectors, and can see why it generates multiple copies of itself. This is next on my to-do-list.
Edit: https://www.openxtalk.org/forum/viewtop ... 4981#p4981

[tperry2x]

Hi Terry.
I hope you don't mind me quoting you, but there's a lot to unpack here:

@ tperry.
Attached is a new stack "Quick Start" tutorial, as entry-level basic as I could make with six cards. I was thinking you could make 3-4 minute silent videos of each card, like your download videos.

I do mean this in a completely non-confrontational way, so please see it as a genuine comment, rather than a dig. I would love to do this, but I just genuinely do not have the time. Any time I spend doing that is time spent not fixing the bugs that are preventing me getting OXT Lite to a point where I feel a lot happier with it. I really do need someone else to take on ownership of producing videos, help guides, documentation... all of that... (That's not a dig at anyone)

(I tried with Window's Step Recorder but it just makes screen shots.)

Yes, I could never get any built-in Windows tools to function the way I wanted. I also tried with the game recorder built into Windows, but this proved inadequate too. The videos I produce, you'll notice are either all on the mac (using Quicktime > "File Menu" > "New Screen recording"), or on Linux (Using "Simple Screen Recorder"). Don't know what I'd reliably use to produce Windows videos if I had to. (The install video I did of OpenXTalk Lite in windows - I kind of cheated. I ran it in a VM while recording the screen in Linux).

• Modify the stack as desired,

• maybe save as .oxt.

• I suggest light-mode,

• decrease screen resolution to about the width of the menubar,

• move cursor slowly while performing "Try It" tasks,

• show the next card at the end of each video as a tease to keep watching.

Again, not meaning to be difficult, but if someone else would like to take on this task - it would be hugely appreciated. Please see above re the time issue.

The idea is to let people peer around and see what OXT can do, which might encourage them to download Lite. They could also download the stack and do the lessons themselves as they watch you do a lesson.

Absolutely, I could not agree more. This would be great - a bit like the way linkedinlearning (what was lynda.com before linkedin bought it and turned it into a social media clone) - you could follow along with downloadable examples for each video. These could all be in the description of each video uploaded, and hosted (location tbc)

The OXT YouTube page would need DropBox links to OXT Lite and the stack I suppose. Any thoughts? Maybe too basic and lame? Richmond's game idea is good too.

No, I like it. I think dropbox links to OXT Lite would not be a bad thing - just want to eradicate these last few glaring interface deficiences if at all possible (inspector palette currently)

Link away, OK by me. Are you thinking of a self-service repository like revOnline, or a curated DropBox where stacks are submitted for approval to be posted, or a webpage with links to public stacks like mine?

Bits of all of that potentially. Something that is a gallery with content, like revOnline used to present itself, but an external web page (would do it inside OpenXTalk lite, but would rather do it in browser via php, html-5, and https for security - plus I don't want to draw attention to *ahem* OXT's webpage rendering prowess (or lack thereof). I'd like to link to public-facing stacks, like the ones you have on your site - so thank you for agreeing to that in principal, and also to any additional user created content / teaching and learning materials, such as Richmond is producing).

On Geometry, nicely done. That may not be the bug fix, but was an annoying problem. I was thinking of a Development > Geometry Refresh menuitem that sends "revCacheGeometry" to every card of the topstack within a repeat loop?

Thank you. That was the approach I first tried, but I found that to be 'expensive' as they say (read: laggy). If I set this to loop through all open stacks, there are plenty of IDE-generated stacks / pre-included stacks that contain custom geometry. This results in about a 2 second pause while it looped through everything, so I chose not to use that approach.
How I have it currently set, is as the closecard handler is triggered, only if the card has geometry defined, then it sends revCacheGeometry to that card. Likewise, upon preopencard, it ensures the card gets updated if custom geometry is set. This all happens in less than 20 nanoseconds in average, and is a small price to pay. You'd only see a cumulative delay of about half-a-second for multiple stacks all containing custom geometry. Navigating through cards that do not have any custom geometry set, the handler doesn't fire, so nothing different is triggered in those cases.

I found it interesting how LC document it, and that they admit to the problem of having to run revCacheGeometry to effectively tidy up behind the custom Geometry. I was not happy with an end-user having to do that, so with my approach - the user does not have to do anything. Set and forget kinda thing.

At the risk of me going off on a LC-bashing tangent, (which I won't), I guess I should be grateful with what I have, as Richmond points out elsewhere, and as I've alluded to elsewhere on this forum. It's a bit of a miracle it all works as well as it does on all 3 major platforms. What we have inherited is good in some parts, really bad in others. My focus is to at least fix the bugs I can, document the rest, and go from there initially.

[TerryL]

@ tperry. Thanks for comments. Hopefully someone will try making a youtube video with the stack I posted. A few things I found for you to consider.

1) Object > Card Inspector Bug? In Win10, object > card inspector flashes the stack inspector before changing to the card inspector. Could this be a bug? I thought a lock screen / unlock screen might work but no, and someone at LC had the same thought. Couldn't fix.
x. In the script of stack "revMenuBar", line 2954, add: lock screen / unlock screen [Did Not Work]
x. In the script of stack "revIDELibrary", line 3572. Already is lock screen / unlock screen.
x. In the script of stack "revIDELibrary", line 4682. Already is lock screen / unlock screen.
x. In the script of stack "revIDELibrary", line 9289, add: lock screen / unlock screen [Did Not Work]

2) I also noticed in the Object menu there's a keyboard shortcut for the stack inspector (ctrl+K) but not for the card inspector. I checked and nothing uses "J" so how about using ctrl+J? Also, card script and stack script have keyboard shortcuts (ctrl+shift+C and ctrl+shift+S) but were placed in stack "revShortcutsLibrary". They could be added to stack "revMenuBar" too. The following changes work for Win10.
In the script of stack "revMenuBar", near line 1670: put enableMenuItem("&Card Inspector/J", tIsUserTarget) & return after tObject
In the script of stack "revMenuBar", near line 1674: put enableMenuItem("&Card Script/^@C", tIsUserTarget) & return after tObject
In the script of stack "revMenuBar", near line 1675: put enableMenuItem("&Stack Script/^@S", tIsUserTarget) & return after tObject

3) Development > Report Builder scaleFactor. I made Report Builder to fit my small 10" screen. I thought the scaleFactor of the field could be increased from .6 to .8 or 1 for most people's larger higher res screens. It's easy enough to do. In msg box: set the scaleFactor of the mouseStack to .8, position mouse in the print field, press returnKey. Close the print field and you're asked to save changes.

4) Geometry Manager. The Dictionary doesn't mention it, but in the script of stack "revGeometryLibrary" line 728, on revCacheGeometry does have a parameter "pUpdateSizes" which if true calls revCalculateGeometryDistances line 823. So Brian Milby was correct, we should use "revCacheGeometry true" to thwart the GM bug. Resizing or moving a control with GM settings is supposed to call it automatically. Maybe it isn't including "true"? Where is on resizeControl and on moveControl?

[TerryL]

5) Menu Builder. I tested Menu Builder recently in Win10 and fixed a major problem. I made 22 improvements/fixes to revMenuManager (Menu Builder) for Lite .90. It is a frustrating and difficult thing to work on. This problem escaped me but I fixed it. I have the 23 improve/fixes documented in a .txt. The script in btn "New Main Menu" called a non-existent custom command which blocked all the command lines following it from firing, rendering most of Menu Builder disabled.

I'm still testing to make sure Menu Builder is stable. What about the pull-down menus working in MacOS14? I remember Richmond writing that standalones with pull-down menus didn't work there. If you post the code you used in revMenuBar for MacOS14 compatibility, I'll try to use it in Menu Builder.

[tperry2x]

1) Object > Card Inspector Bug? In Win10, object > card inspector flashes the stack inspector before changing to the card inspector. Could this be a bug?

Yes, this is a bug relating to the way inspectors are drawn. (essentially, any inspector initially assumes it's a stack inspector until it picks up the focus of the selectedobject, and switches over to either the card inspector or the object inspector if applicable). This is hence why the brief flicker. I have reduced this in the 0.96 builds I'm working on, so that it's almost imperceptable, but I have to test on deliberately older and slower hardware to see how it performs.

2) I also noticed in the Object menu there's a keyboard shortcut for the stack inspector (ctrl+K) but not for the card inspector. I checked and nothing uses "J" so how about using ctrl+J? Also, card script and stack script have keyboard shortcuts (ctrl+shift+C and ctrl+shift+S) but were placed in stack "revShortcutsLibrary". They could be added to stack "revMenuBar" too. The following changes work for Win10.
In the script of stack "revMenuBar", near line 1670: put enableMenuItem("&Card Inspector/J", tIsUserTarget) & return after tObject
In the script of stack "revMenuBar", near line 1674: put enableMenuItem("&Card Script/^@C", tIsUserTarget) & return after tObject
In the script of stack "revMenuBar", near line 1675: put enableMenuItem("&Stack Script/^@S", tIsUserTarget) & return after tObject

Thanks for those suggestions, and the pointers on setting the shortcuts. I do have other changes to the revMenubar stack pending, so it's better I just change the affected lines as you suggest. I will check through and see if I can implement this. I'll credit you in the changelog too.

3) Development > Report Builder scaleFactor. I made Report Builder to fit my small 10" screen. I thought the scaleFactor of the field could be increased from .6 to .8 or 1 for most people's larger higher res screens. It's easy enough to do. In msg box: set the scaleFactor of the mouseStack to .8, position mouse in the print field, press returnKey. Close the print field and you're asked to save changes.

I can't say I've ever used the report builder, but I'll look into that and try your suggestion.

4) Geometry Manager... Brian Milby was correct, we should use "revCacheGeometry true" to thwart the GM bug. Resizing or moving a control with GM settings is supposed to call it automatically.

Who is Brian Milby? I have already implemented this fix (gif anim further up the page of it working). This didn't make it into 0.95, but will feature in the 0.96 version when released. I have other bits to fix beforehand though - it's not ready for primetime yet.

5) Menu Builder. I tested Menu Builder recently in Win10 and fixed a major problem. I made 22 improvements/fixes to revMenuManager (Menu Builder) for Lite .90. It is a frustrating and difficult thing to work on. This problem escaped me but I fixed it. I have the 23 improve/fixes documented in a .txt. The script in btn "New Main Menu" called a non-existent custom command which blocked all the command lines following it from firing, rendering most of Menu Builder disabled.

I'm still testing to make sure Menu Builder is stable.

Thanks for your work on Menu Builder. It very much sounds similar to the issues I'm currently experiencing editing the tiny dictionary.
When you have the Menu Builder stack ready, and at a point where you are happy, feel free to attach it and I'll ensure it makes it into the next build of Lite.

I really appreciate the additional input as there's just too many bits to try and fix, however I also wanted to ensure we aren't all duplicating our efforts and working on the same thing. That was my thinking with creating this topic "what I'm working on and what I'm planning next", so that everyone can have an idea of what I'm currently editing and we don't end up doing the same work twice. That would just be silly and not constructive.

What about the pull-down menus working in MacOS14? I remember Richmond writing that standalones with pull-down menus didn't work there. If you post the code you used in revMenuBar for MacOS14 compatibility, I'll try to use it in Menu Builder.

That was very much solved by Tom (not me, another Tom), who made a hex patch to the engine. It changed the way the menubar was drawn, but in the engine rather than in a stack file. (The fault wasn't in revMenubar as you'd logically think by the name), rather the fault was in the method in which menubars were called into existence - Sonoma didn't like it. Apple are not about to ever u-turn on their decisions, so developers are always left to pick up the pieces.

So the short answer is, I think as long as you are using the patched version (which you will be if you are running 0.95 of Lite and above), the menus should now behave under Sonoma thanks to Tom's work.

[tperry2x]

@TerryL
Thanks for that - I've implemented those shortcut changes this morning:

menuchanges.png (146.91 KiB) Viewed 1343 times

[tperry2x]

On the scale factor thing on the report builder, I was wondering perhaps making this a scaling preference?

Perhaps in Preferences > Extras > Report Builder > "scale for higher resolution screens"

[richmond62]

Who is Brian Milby?

Is that:

1. A real question?
2. A rhetorical question?
3. A rude statement?

Brian Milby is a person who works with LiveCode and contributed a fair bit when LC Open Source was a 'living thing', and his efforts should not be denigrated.

I have just sent him a private message on 'another forum' inviting him to join us over here.
-

Screenshot 2023-12-10 at 11.18.58.png (164.83 KiB) Viewed 1341 times

[tperry2x]

Who is Brian Milby?

Is that:

1. A real question?
2. A rhetorical question?
3. A rude statement?

Brian Milby is a person who works with LiveCode and contributed a fair bit when LC Open Source was a 'living thing', and his efforts should not be denigrated.

um..... okay, not sure if I rattled your cage there, for whatever reason .

Option 1.
A real question.
Not a rude question, I'd never heard of him - and I'm sure he'd never heard of me either.

I wasn't aware of his work, and if he's not posted on this forum, then I probably would not be have read any posts from him either. I don't get involved with anything on the LC forums, so not meant as a rude comment or a rhetorical question - all my questions are 'real questions'

[richmond62]

Tweaked the geometry settings this morning:
Instead of them using these out of date graphics:

I am afraid you are doing a lot of what we might call 'house keeping' if we want to be polite, or 'tidying up the filthy corners', if one wanted to be a bit ruder.

I made myself fairly unpopular (I am quite good at that) 'over there' by pointing out that in LC's "hell for leather" urge to continually chase the next thing they were neglecting lots and lots of longstanding bugs, anachronisms, redundancies, and so forth.

https://livecode.com/livecode-10-things ... nkful-for/

"The underlying engine that LiveCode runs on was built approximately 35 years ago prior to our stewardship of the engine."

"The last time we had a major refactor was for LiveCode 7 and we learned a great many lessons from that experience. If you were along for the ride on that one you may recall it took some time and when it did ship it had a number of – ahem – challenges as a version, which were not satisfactorily resolved until LiveCode 8."

This is symptomatic of LC's attitude and reminds me of what my history teacher told us in 1977 about why, after the second world war, West Germany managed to get its manufacturing up, running, and far, far more efficient that anything in Britain (remembering that Germany's manufacturing sector was almost completely destroyed in the war). This was because of the German mentality versus the British mentality (at the risk of offending just about every Scot in Britain): the British would keep mending things with bits of wire (work arounds), while the Germans would completely retool every 5 or so years. So, the British moan that the West Germans were so much further ahead than the British in 1977 due to the United States pumping money into West Germany was just a feeble excuse for the British, who as we all know, delight in mediocrity and squishing anyone who comes up with a bright idea.

"This particular refactor is going to form a foundation for great things to come, for many years."

If that is the case, they are going to get bogged down again . . . my Devawriter (home grown gubbins for Sanskrit) has been through 3 refactors only because I keep realising how fekking clunky and inefficient the thing is, and, every time I have some time trying to type a spot of the Kumara Sambhava in it [choice of text determined by what happens to have been sitting on my desk for years] and working out ways to speed things up.

"great things to come, for many years."

This is nothing short of wishful thinking, and it should fool on-one, except, of course, those who sing in the Choir of the Uncritical Church of LiveCode.

[richmond62]

not sure if I rattled your cage there

1. No you didn't.
2. It's a strait-jacket, not a cage.

Just thought it was important to point out who Brian Milby is, and if possible, get him on board:
-

Screenshot 2023-12-10 at 11.48.11.png (45.19 KiB) Viewed 1337 times

-

I don't get involved with anything on the LC forums

You don't have to: but being a passive observer can also be quite informative.

[TerryL]

@ tperry. Attached is the updated revmenumanager. I probably misunderstood, that standalones with menus will now work fine with macos14 and the menu builder doesn't need further modification. Good.

The easiest way to apply the fix is to replace the old revMenuManager with this updated revMenuManager in Toolset > Palettes.

#23 Script of btn "New Main Menu", commented out line 168. There is no revSetEdited custom cmd, and calling it completely blocked all command lines following it. This did not affect 6x, but did affect 9x revMenuManager. (no revSetEdited in btn script, its group script, cd script, or stack script)
Line 168: --revSetEdited tDefaultStack --TL 12/23, there is no revSetEdited custom cmd, blocks line 169-179.

Please test with Mac/Linux. In a new stack, Tools > Menu Builder, click "New...", click "OK" to dialog for File/Edit/Help menus. The Menu Builder Menus and MenuItems should now be enabled and editable.

Thanks for all your work on OXT Lite. Terry
----