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

[richmond62]

Hmm: rather feeble sarcasm . . .

OMG

I have enough people worshipping my lotus feet without having to be your God . . .

If you are a "lucky" chap I'll try to update copies and see what gives tomorrow.

Please read my postings about tiny icons and an ARM engine.

[mwieder]

I patched the startup handler in the home stack to allow me to continue updating. All went well until the final two updates. The penultimate one had changes to the home stack, so I had to reinstall my patch. That went fine, but after the final update (202407121402) I can no longer launch. Launching from the commandline gives me the normal library loading results ending with

[202088] MCU_library_load libpango-1.0.so.0 -> libpango-1.0.so.0
[202088] MCU_library_load libpangocairo-1.0.so.0 -> libpangocairo-1.0.so.0
[202088] MCU_library_load libpangoft2-1.0.so.0 -> libpangoft2-1.0.so.0

at which point it hangs, leaving an open process that has to be kill-9ed.

[tperry2x]

I patched the startup handler in the home stack to allow me to continue updating.

I'm afraid you've lost me, as I'm not using any startup handler in the home stack to do any updating.
Don't worry, I'll put a 1.06 version together.

In fact, the Linux and Windows versions are there already. Mac version to follow tomorrow at some point.

[tperry2x]

Hmm: rather feeble sarcasm . . .

OMG

I meant OMG, as in computers are a pain in the backside sometimes. Not directed at any person.

If you are a "lucky" chap I'll try to update copies and see what gives tomorrow.

Or is ^ that the feeble sarcasm? Emphasis, mine. I don't know how this makes me feel 'lucky'.

Please read my postings about tiny icons and an ARM engine.

I did, and I think you are hugely underestimating the cost due to the amount of effort and hours involved pouring over legacy stale code, before you even begin to battle with Apple's API changes. (added links so people could find the posts).

[mwieder]

I'm afraid you've lost me, as I'm not using any startup handler in the home stack to do any updating.

No, you're not. What's messing me up is the end of the startup handler

Code: Select all

   -- revised the layoutguides (22-11-2023), made this an option in prefs
   if the cLayoutGuides of stack "revPreferences" is true then
      -- guides are on
   else
      -- guides are off, unload
      put "community.ferruslogic.plugin.devguides" into tCloseFerrus
      send "extensionFinalize" to stack tCloseFerrus
      set the destroyStack of stack tCloseFerrus to true
      close stack tCloseFerrus
   end if
   revInternal__Log "Leave", "Startup"
   
   return tError
end startup

I had to change this to

Code: Select all

   -- revised the layoutguides (22-11-2023), made this an option in prefs
   if the cLayoutGuides of stack "revPreferences" is true then
      -- guides are on
   else
      -- guides are off, unload
      put "community.ferruslogic.plugin.devguides" into tCloseFerrus
try
      send "extensionFinalize" to stack tCloseFerrus
      set the destroyStack of stack tCloseFerrus to true
      close stack tCloseFerrus
   end if
catch e
end try
   revInternal__Log "Leave", "Startup"
   
   return tError
end startup

Otherwise the IDE hangs and I have to kill the process.

[tperry2x]

...Otherwise the IDE hangs and I have to kill the process.

Just so I can try and replicate your error, which platform/OS are you using?
I thought it might have been the "strict compilation mode" thing, but I can't replicate the startup error you are seeing at the moment, even by turning that on. Please can you also confirm what version of OXT lite you are using.

Does the same thing happen on a fresh copy of OXT lite?
Does the same thing happen on a fresh machine / blank VM? (wondering if it's a setting / config it's picking up that it doesn't like).

[mwieder]

Well, since it's now nonfunctional it's a little hard to give you more feedback.
I *am* running it in local mode instead of /opt, but that hasn't been a problem before trying to update.
And I tried with no third-party plugins, but that didn't help.

[tperry2x]

Well, since it's now nonfunctional it's a little hard to give you more feedback.
I *am* running it in local mode instead of /opt, but that hasn't been a problem before trying to update.
And I tried with no third-party plugins, but that didn't help.

Ah, since you moved it out of /opt/ I wonder if it's a permissions problem.
Did you subsequently grant yourself permissions using:

Code: Select all

sudo chown -R $USER ~/path-to-openxtalk-lite-folder/

That would make sense if it's trying to load something, and failing because it doesn't have read access - so putting your catch e will hide the error, but not fix it.

Between your:

Code: Select all

catch e
end try

can you try:

Code: Select all

catch e
   answer QUOTE & e & QUOTE
end try

That should at least show a dialog with what the error is.

[richmond62]

Right, let's try and run a copy of OXT Lite 1.05 on MacOS 12 through the latest updates:
-

Screenshot 2024-07-13 at 11.56.24.png (146.73 KiB) Viewed 2419 times

-

Screenshot 2024-07-13 at 12.05.18.png (468.34 KiB) Viewed 2418 times

-

Screenshot 2024-07-13 at 12.07.07.png (50.54 KiB) Viewed 2417 times

-
Nothing obvious to complain about.

the final update (202407121402)

And our numbers coincide!

[tperry2x]

And our numbers coincide!

That's brilliant. I'm now just perplexed as to why Mark has the error he's got, but if you change the version string in /path-to-openxtalklite/contents/Tools/Toolset/.version
(just change 1.05 to 1.06) - and you have the v1.06 build - saves you having to download 700MB+ again.

(download link, as it tends to get buried)
https://openxtalk.org/forum/viewtopic.php?p=8806

Alternative download page, (if this site goes down again)
https://www.oxt.tsites.co.uk/viewtopic.php?p=4#p4

[richmond62]

Absolutely no problems on MacOS 15 beta either.

[mwieder]

It's working now, sort of. I changed the startup handler to read

Code: Select all

if there is a stack tCloseFerrus then
      send "extensionFinalize" to stack tCloseFerrus
      set the destroyStack of stack tCloseFerrus to true
      close stack tCloseFerrus
end if

[mwieder]

But here's why I'm pushing back against your dictatorial dark mode stripping of coloring.
Here are screenshots of part of my development environment using LC:

devoLC.png (18.33 KiB) Viewed 2361 times

and the same plugin using OXTLite

devo105.png (15.09 KiB) Viewed 2361 times

[tperry2x]

I wouldn't call it "dictatorial dark mode stripping"
All you need do is set a custom property on your stack:

Code: Select all

set the ignoreIDETheme of this stack to true

I could equally counter, why would I need to change the entire IDE to compensate for your stack, when setting this one custom property on your stack would fix it?

Is it not "dictatorial" to assume the entire IDE should be changed for the benefit of one stack with a custom appearance? That would be my pushback on it.

[mwieder]

So A: it's not "my" stack. Why should I have to tell Mr. Gaskin to rework his stack so that my development environment works in OXTLite the way it does in LC? What are my chances of that happening? And this goes for any other third-party plugins I've added to my environment. If third-parties are moving over to OXT for future work maybe this would happen. If they're continuing on with LC and don't know they need to rework things and/or don't care to put in the work, what then?

The glx2 script editor another. At least this is in my control, so I *could* change it, but there's a lot of work that went into not just the chalkboard motif but allowing for a custom set of coloring. I'm not about to "fix" that.

What I'm suggesting instead is just let the stack itself do the work:

Code: Select all

dispatch "darkMode" to stack xyzzy with true

Then if the stack supports specific colorizing changes it will switch modes. If not (assuming the IDE stacks have their colorization stripped already) then all is well and they will already inherit changes. Note that this applies only to the IDE stacks that have a visual aspect - most stacks wouldn't need any changes.

[tperry2x]

dispatching

Code: Select all

dispatch "darkMode" to stack xyzzy with true

...
So, you'd want the IDE to send this "darkMode" handler to each stack that gets opened, on the off chance that there's a corresponding handler? (Which will exist for the case of 1 stack so far). Surely that's more incompatible?
All I'm saying is that if you are going to design a stack with a custom interface, which goes against the rest of what the system and IDE is following, then why not just design it with that in mind?

For example, I might have a stack that has a blue background. If I choose View > Appearance submenu > "Ignore default IDE theme...", then whatever the IDE does (whether it's dark, light, orange, polka-dot or checkerboard) it won't matter. It won't mess with the stack. It's a one time set-and-forget option. It'll always look the same.

I wanted the IDE to match what the system is doing, or at least give it a chance. I didn't want someone to open a stack with the IDE in dark mode - with the tools in dark mode, the menubar, all other windows such as the 'Application browser' etc etc... and the stack they are working on not follow the rest of the IDE - a glaring white page, when they've specifically chosen dark mode for the OS.

Why it's stripping out the dark mode on that stack is the exact reverse. You have it set to light mode or 'default' (because the 'default' in LCC is to not be aware of any system theme - unless you are on Linux. Again, choosing that menu option will eliminate the issue.

Richard Gaskin may not want to re-tool any stack to suit, and that's entirely his choice.
Some modification of that stack is probably necessary anyway, as doesn't it have problems with the revTools stack as well? Or would you have us redesign other parts of the revTools stack or the rest of the IDE to compensate?

Stacks might work in LCC 9.x, but that is very much now a static piece of history. It's not moving forward. Yes, myself and Paul are both trying different things in our OXT builds - and some of that is likely to reduce compatibility along the way for some things. Sometimes, adding more things that people have requested naturally breaks other things - especially when it's so interwoven like the IDE is.

A third point: why not have it apply whatever colour you want the stack to be via script anyway, or make the stack theme-aware (so it actually looks good in light mode)?

[mwieder]

doesn't it have problems with the revTools stack as well?

I've already coded that into PowerTools. Dark mode switching works as advertised.

Here's another: the glx2 script editor in LC and OXTLite

LCglx2.png (16.81 KiB) Viewed 2333 times

105glx2.png (14.25 KiB) Viewed 2333 times

So... if you want the IDE stacks not to have specific foreground/background colors but just inherit them (and I do support that idea) then they should either be set up that way from the start or you should do what you're doing in stripping the colorizing. But stop short of doing that for user stacks. If the users want to support that then that's up to them and dispatch a message to tell them to switch modes will do the trick.

[tperry2x]

So what happens in the top example, the LCC one, if I have the script 'colorization' mode set to light?
This is where that approach won't work.

With my approach, if I set the script colour theme to a dark theme, then the background is dark & text is light. If I set the script colour theme to a light theme (or default), the background is light & text is dark. But, again - does your script editor assume that everyone wants a dark background?

Plus, my approach factors in multi-platform issues.
What I mean by that, linux is the only version of the IDE that will pick up on the system theme out-of-the-box. If you have an orange GTK theme for example, then no surprise - your stack will be orange. So will the rest of the IDE.
Overriding the colours and specifically specifying what you want is the only sure-fire way to be 100% certain it'll look the same across all platforms, on all IDEs.
Additionally, if I wanted my stack to be lime green - I'd set it via my appearance menu so it shouldn't be overridden by the IDE - as the stack author intended it to look that way. If not, then nobody else would want the lime green if it's not intentional. Which is where we are with both of those stacks - they don't factor in user IDE appearance choice if they are presently assuming that dark mode is the only option.

This is what I mean, using Libreoffice as an example:

dark-mode-isnt.png (50.36 KiB) Viewed 2317 times

dark-as-dark.png (88.6 KiB) Viewed 2317 times

The program follows the system theme for all the buttons, but as 'default' the page is glaringly white - this is always very jarring when you have been working in dark mode for a long time, only to open this and have your eyeballs obliterated by a searing white page.

Choosing their dark mode override, sets the page as you'd expect - and ignores the rest of whatever the system theme might be doing. So if a user chooses to have a dark page (a custom coloured stack to continue that analogy), they have to choose so from a menu. Same approach with OXT lite, except without the eyeball-searing.

[tperry2x]

Or, as I mentioned - just set your buttons to be button images (like other stack authors have done) - as does Richmond on his Devawriter stack, and many others - you know they aren't going to change then.

Use a background graphic (vector if you'd like), and set the colour. Done.
You know the only way that's going to change is if someone intentionally changes it with the properties inspector or via scripting.

But, all stacks should be responsive to what is selected in the IDE. The IDE should be the master-control element here, the document / stack has to specifically be set to override this. Not the other way around.
Suggesting that the IDE make changes to accomodate a stack would be like a libreoffice document being able to change the rest of the program when it was opened. It should follow that it's the other way around.

Or, just set everything to a neutral grey of 127,127,127

[mwieder]

But, all stacks should be

That's what I mean by dictatorial.

All I'm saying is don't mess with third-party stacks.
We're done here.