Comments on OXT Lite 1.0.7
- tperry2x
- Posts: 2306
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: Comments on OXT Lite 1.0.7
Oh, by the way - do you have a screenshot of that scary dialog avaliable?
- OpenXTalkPaul
- Posts: 2141
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: Comments on OXT Lite 1.0.7
Yes, in revMenuBar the 'toolbar' group (to differentiate it from the actual menubar group), having no colors set on it by default, will inherit any card or stack colors. That group is set to non-opaque so setting the backColor doesn't work, you'd have to either make it opaque or set it on the card or the stack level for that.tperry2x wrote: ↑Sat Aug 31, 2024 11:04 amThat's cool. I didn't know they were customisable at all. I'll have to read up a bit more on that.OpenXTalkPaul wrote: ↑Fri Aug 30, 2024 8:57 pm It is possible to set the bottomcolor of the revmenubar or menubar-group to set the color of disabled menu item labels in the menu
Here's a 'before' and 'after' of me testing it out:
I didn't realise that this also affects any disabled buttons in the 'revmenubar' as well. Makes sense I suppose as the 'menu' (if you can call it that) is actually drawn as a group of buttons, so I suppose it doesn't differentiate between them?
NOTE: that setting colors on the menubar has no effect at all on macOS where the menuBar actually gets turned into NSMenu object (standard Apple API). I believe the inheritance does behave same way as Linux when on Windows so it should probably be OK to set it regardless of the platform, it just won't have any effect on menubar on Mac.
Setting the card's colors does effect the 'Toolbar' (but not the menubar) on macOS, so you can for example:
Code: Select all
set the backGroundColor of card 1 of stack revMenuBar to purple
- OpenXTalkPaul
- Posts: 2141
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: Comments on OXT Lite 1.0.7
I thought I posted that, but maybe in my haste I over wrote it with my menubar
comment... here is what popped up, I think it was during initial install: My guess is the .desktop launcher file needs to be set to executable too?
I'm leaning towards standard packaging like .deb or snap or whatever, might need several formats for Linux.
Also .pkg for macOS (only problem with that is Apple doesn't include separate tools too build those anymore, you can still build them in X-Code still I believe.
And Whatever the standard package format is for Windows (probably NOT .cab anymore?)
That way the system's installer can install files into the systems folders, like any dependencies that are required, install receipts, license, and maybe pre-made prefs and user folders.
I think having custom installer is just asking for trouble,
- tperry2x
- Posts: 2306
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: Comments on OXT Lite 1.0.7
Oh, that dialog. Yes, you are right: that's just a chmod +x that's needed.
Or just click the "mark executable" button, which does exactly that, then opens the application. Nothing to do with code signing (thankfully).
Or just click the "mark executable" button, which does exactly that, then opens the application. Nothing to do with code signing (thankfully).
- OpenXTalkPaul
- Posts: 2141
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: Comments on OXT Lite 1.0.7
No it's just a 'hardening' of security that I haven't noticed before on Linux (didn't mean to make it sound like more of a problem than it is).
Who is online
Users browsing this forum: No registered users and 4 guests