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

[richmond62]

Coo, talk about 'hot under the collar'.

I do tend to agree that anyone making anything they want to look the same regardless of where it is deployed better realise that:

1. Cross-platform consistency is just not going to happen if you rely on the objects provided by the IDE, or fonts that and end-user might just happen to have installed in their system.

2. Frankly expecting the IDE to preserve any theming in anyone's stack that relies on code rather than images is expecting too much.

3. Currently implementing a new interface inwith my Devawriter: half the time is being spent on graphics!

[tperry2x]

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

Are we? I thought we were having a discussion?
You only would get the IDE messing around with your stack colours if it was open at the same time the rest of the IDE is loading. If it thinks it's part of the IDE.
Do you use 'rev' in the name?
Are your stacks integrated into plugins folders, or within the IDE program folder itself - thereby becoming part of the IDE? - If so, then it should follow they follow the rest of the IDE. Third-party or not.

That's not 'dictatorial', or whatever you want to call it. It's reasonable to expect that the IDE looks at least uniform instead of a mess of different colours here, there and everywhere.

It would be different if upon choosing File > Open stack - if it then messed around with user's colours in their stacks, then yes - granted, that would be a little off. But by intertwining it inside the IDE, I'd at least expect it to look part and parcel of the rest of the IDE - like it belongs there.

[mwieder]

You only would get the IDE messing around with your stack colours if it was open at the same time the rest of the IDE is loading. If it thinks it's part of the IDE.
Do you use 'rev' in the name?
Are your stacks integrated into plugins folders, or within the IDE program folder itself - thereby becoming part of the IDE? - If so, then it should follow they follow the rest of the IDE. Third-party or not.

The glx2 script editor does not use "rev" in its name. It is *only* in the user Plugins folder.
4WDevolution does not use "rev" and is only in the user area.

Don't mess with them. You explicitly go through every open stack and strip the coloring from stacks, cards, and objects.

Also... the glx2 script editor has a specific set of syntax highlighting colors depending on which visual mode its in. This color set is different if the background is dark or light. Simply changing the background/foreground colors in binary fashion is going to make the colored text unreadable.

[tperry2x]

...Don't mess with them. You explicitly go through every open stack and strip the coloring from stacks, cards, and objects.

You've missed my point, but "SIR. YES SIR"

[mwieder]

LOL. I *did* get your point, and for the most part I agree.
I just think the implementation is wrong.

[richmond62]

Every picture is worth a thousand words . . .
-

Screenshot 2024-07-13 at 20.29.54.png (48.46 KiB) Viewed 4750 times

-
The 'thing' on the left is an image.

The 'thing' on the right is a field on top of a rectangular group.

The field uses the Charcoal font (my personal obsession) from MacOS 9 (which you PROBABLY do not have on your system).

So give the stack a whirl and see what I mean.

Oh, and by-ther-way: this is NOT me being 'dictatorial': this is just the Richmond suggestion service.

[tperry2x]

Well, nearly there with it - but you'll note there's a new preference.
"Don't allow themes to touch third party stacks at all".
To test this, note my new lime green stack - changing the theme does not do anything if that option is on.
(That option defaults to on unless turned off).
That should keep everyone happy.

Just want to test it more on the mac, but it works on Windows and Linux already.

Untitled.gif (322.6 KiB) Viewed 4740 times

[mwieder]

I like it (both the action and the default setting) and admittedly it takes care of most of my concerns.
The only feature I would add would be in the default On mode instead issue at statement to the third party stacks to allow them to do dark/light mode styling if they wish.

dispatch darkMode to stack xyzzy with true|false

[tperry2x]

dispatch darkMode to stack xyzzy with true|false

Now does this too, (you can see I intercept that message in the topstack as a test here):

switching-test-mw.gif (222.38 KiB) Viewed 4717 times

The field colour changes because of inheritance, not because I'm specifying anything.
So this is what I'm on about. You can't guarantee the appearance of objects because of inherited colours, unless of course you specifically set the colours in script. So all I was going on about is that the 4W stacks and such need adjusting to take dark/light (dark true | false) into consideration, so modification of those is still required.

Same is true of course for any third-party user stacks - they will now all need an option built in to support dark mode too, using the method in this screenshot.

Perhaps that was misconstrued yesterday. Believe it or not, it's not my intention to cause a ruckus on here.
At any rate, I've made it a preference because I'm of the opinion that it should be handled at IDE level, not at stack level - so with it being a preference, should keep everyone satisfied.

I'm hoping that does please everyone.
Now, are we done here?

[mwieder]

Tom- I think I'm gonna be quite happy with this. Looking forward to kicking the tires.

So all I was going on about is that the 4W stacks and such need adjusting to take dark/light (dark true | false) into consideration, so modification of those is still required.

Only if they specifically want to support dark mode appearance changes. Stacks like devolution already support a unified appearance which I think looks good in both modes. The glx2 script editor has a user-defined visual approach which would probably be annoying if it changed with the mode. And I've already implemented dark mode switching in PowerTools, as per the switching path we've set up.

So now there are two paths forward for third-party stack developers to support dark mode: use inheritance by removing any specific foreground / background coloring; or implement a darkMode handler to achieve the desired visual aspect.

[tperry2x]

Tom- I think I'm gonna be quite happy with this. Looking forward to kicking the tires.

Cool. I'm glad we found a solution that works, and being a preference, it can be toggled to however someone wants to implement it.

So now there are two paths forward for third-party stack developers to support dark mode: use inheritance by removing any specific foreground / background coloring; or implement a darkMode handler to achieve the desired visual aspect.

I suppose we actually have three methods.

• Use inheritance by removing any colouring

• Implement a darkMode handler to achieve a desired appearance (stack specific on a case-by-case basis)

• Set a stack custom property via the appearance menu > ignore default IDE theme... (don't theme, but only for this stack)

Hopefully every possibility covered.

[richmond62]

Well we all know what happens to those who try to keep everybody happy.

[mwieder]

If you want to try out the latest PowerTools plugin with darkmode switching it's at

https://github.com/mwieder/PowerTools

[tperry2x]

Thank you.
I'm happy to report it works well in OXT Lite:

powertools.png (150.82 KiB) Viewed 4613 times

If I was going to be super-critical, the only bug is the one we found regarding the paint tools. It suffers from the same thing. If you paint with the spray can for example.
Save the stack.
Close and remove from memory.
Re-open the stack. No paint image, which I had to re-jig the revTools palette quite a bit to fix.

Everything else I placed in from the powertools stack seemed to work well though.
I like that there are preset progress bar styles for example, and being able to drag and drop a menu in is probably my favourite. I was thinking of re-jigging the revMenubuilder anyway to fix a few bugs and make it more compatible - plus perhaps add a non-crashy workaround for MacOS 11+ too, so this is a good feature. - Can I blatantly copy (rip-off) the preset menu control in OXT lite?

[mwieder]

Feel free to cannibalize anything you want.
Not sure about that spraycan thing - I'll have a look a bit later on.

[tperry2x]

In fact, I should elaborate - that bug occurs with any paint tool. Something in the IDE does not like the way the initial paint image is created. The bug exists in LCC too, as far back as 8.2.0 - but isn't a problem in the version 6.x engine/IDE.
If you manually make a paint image first, then draw into it, then it's fine - so that's what my script does. (plus it sends the paintimage to the back layer) so you don't paint over a button or make a button non-clickable.

There's a whole thread on it here, although it might be a bit TL:DR.

[mwieder]

...interesting...

yeah, the initial image does actually get created, but the system doesn't recognize that something new has been added. So saving the stack doesn't do anything because there's no need. If you, for instance, edit a script then the new-thing property gets set and saving the stack does work, including the spray can image.

I'm sure there's a property that can be set after placing a new image... bears further insight.

[tperry2x]

The short version of that mega-thread is that I fixed it here
viewtopic.php?p=8344#p8344

There were other fixes too:
viewtopic.php?p=8396#p8396

Likewise, feel free to extract any part of my amended tools stack and dissect for your own use. If there's anything helpful you can use, then no point us all reinventing the wheel.

(big list of bugs to fix, and ones that have been fixed here)

[mwieder]

If you're fixing things in the "standard" tools palette, you might want to look at new object naming. There's some code that assigns a unique name to new objects ("button 1", "button 2", etc) but then for no apparent reason that gets overwritten later by "button". I ended up writing my own code for new object creation, so I forget where the original is in that stack's code.

[mwieder]

OK - that's brilliant.
I just implemented a modified version here and it's working well.
The only drawback I see is that the background image gets put on the topstack when the paint tool is clicked. Ideally this should be instead when drawing gets started, but I don't see a way to do that short of hacking into the engine code.

Update: note that I made a couple of changes to the way you've implemented this.
I added a line to tell the system that the stack has changes that might need saving:

Code: Select all

revIDESetEdited the short name of the topstack

and I inset the rect of the background image by 2 pixels because otherwise I got a hard crash doing

create a new stack
select the bucket tool
click on the new stack

apparently trying to color all the way to the stack/card edge is a Bad Thing.