Learning/Problems from across the way #2

[richmond62]

Someone is in the process of developing a new combo-box thing which is well worth having a look at.

https://forums.livecode.com/viewtopic.php?f=9&t=39005

[tperry2x]

Unfortunately this doesn't rewrite the combobox classic control, merely is another implementation of it.
It does not solve the incorrect combobox UI element being drawn on MacOS Sonoma + which is a pity. I thought the OP had re-coded the classic control, but that's not the case.

Not that it's not clever - it is, I'd just got my hopes up that the control was re-written.

[richmond62]

What exactly is wrong with the 'classic' combobox thing?
-

Screenshot 2024-04-02 at 17.59.56.png (35.24 KiB) Viewed 2376 times

-
Admittedly that's on MacOS 12.

I can see nothing objectionable, and the OP [on the other forum] does not make things clear in a way that I can understand.
-

Screenshot 2024-04-02 at 18.07.42.png (36.44 KiB) Viewed 2376 times

-
I think I prefer the 'classic' thing as it is easier to set properties as it is NOT a group.

[tperry2x]

What exactly is wrong with the 'classic' combobox thing?

If you look at it in dark mode (yeah, I know you don't care about dark mode), but in the interests of LCC/OXT devs that do and are trying to support light/dark modes - this is also why your inspector palettes look terrible in dark mode on MacOS 11+

I did mention this before, hang on.... will try and find original post and link it here.
Here you go:
https://www.openxtalk.org/forum/viewtop ... 4247#p4247

With the LCC / OXT representation of the popup menus on the left, and how they are supposed to appear when drawn by all other apps on the right.

The disparity between how LCC/OXT draws these, (and how they are supposed to be drawn) only grows greater, as the system versions of MacOS increase. If you look at Sonoma in dark mode, they are well out. (not that I get to do that except when I can borrow the use of a colleague's mac at work - which won't be for a couple of weeks now).

I mean, it's not exactly a 'deal breaker', but gets increasingly hard to read the content of popup menus and comboboxes on Big Sur +

[richmond62]

Maybe I should point out that "across the pond" LiveCode has no option for dark mode, so there must be other reasons.

[tperry2x]

LiveCode has no option for dark mode, so there must be other reasons.

I don't quite follow you. I wanted to support light and dark mode, (it was on my 'road map') as in this day and age - I think it's good to offer both.

I know exactly why the classic controls are bound to the same appearance of MacOS 10.15 and 'degrade gracefully' (I think the popular parlance is). It's because the mac interface controls are compiled with a certain (now old) version of xCode, which did not support the updated UI interface elements of Big Sur+. (because it wasn't aware of it).

[richmond62]

What I mean is that this subject is being dealt with vis-a-vis LiveCode, and not OXT Lite: and as LiveCode does not have a dark mode option the reasons for an attempt to make another combo box thing must lie elsewhere than dark mode.

This is something quite different to your concerns re combo boxes in OXT Lite.

[richmond62]

This is something you CANNOT do:
-

darkMode.jpg (107.88 KiB) Viewed 2354 times

[tperry2x]

Yes. Inverted mode. You can with the accessibility library. Now try adding an image to the card and see how the colours are inverted too. But that's not showing support by the ide in any way. It's simply faking it. (Nice white drop shadows!)

That is childsplay in linux.

Screenshot_2024-04-02_22-05-07.gif (92.61 KiB) Viewed 2338 times

command is:

Code: Select all

xcalib -invert -alter

Which of course you can bind to any shortcut combination (which of course you cannot do in MacOS with a single keypress). I can bind this to a single press of the f9 key if I want.

But that's by-the-by and largely irrelevant - yes, perhaps there were other reasons for wanting to recreate the combobox control by the OP, but as I said above, I'd hoped it was to solve the appearance issue of the classic control. It seems it wasn't though.

[richmond62]

Of course my screenshot of LC 963 has been inverted; just to point out that LC 963 cannot, obviously at least, present itself in dark mode.

What is a real !@#$%^&*()) about MacOS as well, is that if you take a screenshot while in inverted mode the screenshot comes out "non-inverted", so for that silly picture I had to invert the thing in GIMP before posting it.

[richmond62]

AND

Code: Select all

xcalib -invert -alter

being "all jolly hockey-sticks" if you wish to invert your screen, no more results in a dark mode for LC 963 than mine does.

[tperry2x]

being "all jolly hockey-sticks" if you wish to invert your screen, no more results in a dark mode for LC 963 than mine does.

Yes, as I mention above "It's simply faking it". Not actually inverting colours (to do so would be quite demanding), so it does this by using the invert mode on the graphics card (frame buffer). Doesn't actually change any real pixels, just what is sent to the monitor.

[OpenXTalkPaul]

You can bind all sorts of keys with the keyboard control panel on macOS and override defaults combos for most apps.
But that is off topic here.

Are you sure 9.7 source changes weren't ultimately included in the 9.6.3 build? I was thinking those might have been included because I beleive those changes were pushed before July 29th 2021 (when 9.6.3 was released).

As far as the classic controls not looking correct in dark mode, as a stop-gap measure at one point I edited the default properties of some of the classic controls so that, for one example the text of 'standard' button would be black so that it would at least be readable in dark mode.

I also built a collection of Widgets intended to (eventually) be replacements for most of the classic controls (check boxes, radio buttons, sliders, etc.). These widgets would all support dark mode, and perhaps could also be merge with the Mac 'native' (the actual Cocoa) FFI widget objects as an option along with the custom drawn widget control.
Obviously it would be best to update those classic controls in the engine too.

That's what I really want for buttons. One button to rule them all, with ability have native look on a variety of operating systems AND various OS versions, and also be able to switch to a generic more customizable button appearance. An all-in-one object.

[tperry2x]

Are you sure 9.7 source changes weren't ultimately included in the 9.6.3 build? I was thinking those might have been included because I beleive those changes were pushed before July 29th 2021 (when 9.6.3 was released).

I believe they are included. Obviously I can't test all of them conclusively, not having a working mac recompile of the engine, however - I can confirm that I've noticed the following changes in my 9.7 recompiled versions for Windows and Linux:

• If lots of fonts are loaded into memory, the time to quit the IDE has been improved.

• If an engine runtime error occurs, an error dialog will be displayed rather than failing silently.

• While typing in the script editor, performance has been improved. (most noticeable for windows)

• If you open and close the message box, the IDE used to get slower. Fixed.

There were lots of fixes for MacOS, which is why I'm keen to get the 9.7 engine compiled with my 1 change.
These were:

• X and Y Co-ordinates now should be correct for multi-screen macOS systems.

• Placing buttons and progress bars on a card will no longer cause slowdowns on macOS 10.10 or later.

• When opening the IDE menus on macOS, there should no longer be a delay.

• The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X.

• Scripts which run without locking the screen are a lot faster (macOS Big Sur and later)

• MacOS date and time formats now return correctly on Sonoma

• The engine will now return the correct value for the systemVersion on all macOS versions. Previously, when running on macOS 11.0 and above, the system version would be reported as 10.16.0

As I say, can't test those at the moment until we have a working mac recompile - so currently the mac engine version is trailing behind Windows and Linux. (which was why I was fooling about thinking of other ways to run this on MacOS using a windows build or even a BSD unix one through the darwin layer if that was possible).

[OpenXTalkPaul]

• The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X.

• Scripts which run without locking the screen are a lot faster (macOS Big Sur and later)

• MacOS date and time formats now return correctly on Sonoma

• The engine will now return the correct value for the systemVersion on all macOS versions. Previously, when running on macOS 11.0 and above, the system version would be reported as 10.16.0

OK 9.6.3 definitely doesn't include the OS version number fix so the rest of the list probably wasn't compiled in, although we do have already some work-arounds, like with macOSversion().

The getting dates/times (in all sorts of formats) from the OS seems kind of trivial like using shell(date), so not sure why that would've gotten broken in Sonoma?

I'm not sure about this one:

The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X

There's only one external included with Community that accesses the microphone. The issue with that was that was code-signing related (I strip the code signature and it started working again). Anyway, I have an AVAudio Record extension to record audio on Mac now. Unless maybe this bug was related to using web camera/mic API's via HTML5/BrowserWidget?

For fonts I'd like to have a menu/button, maybe in the in the revPrefs UI, that re-reads the Font cache/Fonts in memory list and updates Font menu. If I load a font with a Font Manager I shouldn't have to quit and relaunch the IDE to use the newly loaded font. if you load the font from the IDE's syntax it probably updates the Font menu list then, but it doesn't update the fonts menu you load a font with some external mechanism.

[tperry2x]

OK 9.6.3 definitely doesn't include the OS version number fix so the rest of the list probably wasn't compiled in

That's what I'm on about - you won't find this in 9.6.3 - you'll find it in 9.7 (it was fixed in 9.6.8)

The getting dates/times (in all sorts of formats) from the OS seems kind of trivial like using shell(date), so not sure why that would've gotten broken in Sonoma?

Because Apple

I'm not sure about this one:

The engine will no longer crash when accessing the camera or microphone on recent versions of macOS X

Again, this was fixed in 9.6.7, so you won't see the change in 9.6.3 code.

For fonts I'd like to have a menu/button, maybe in the in the revPrefs UI, that re-reads the Font cache/Fonts in memory list and updates Font menu. If I load a font with a Font Manager I shouldn't have to quit and relaunch the IDE to use the newly loaded font. if you load the font from the IDE's syntax it probably updates the Font menu list then, but it doesn't update the fonts menu you load a font with some external mechanism.

The font menu updates in realtime, at least on Linux - you can use:

Code: Select all

put fontNames()

To return a list of currenly loaded fonts.

You can also use:

Code: Select all

put fontFilesInUse

Which will return things like this, also showing extras the IDE has loaded:

ff-inuse.png (16.15 KiB) Viewed 2085 times

There's also: revFontGetSystemFont(), which is supposed to show what system font is selected.
Not that this reports it correctly.

fonts.png (33.12 KiB) Viewed 2082 times

...and this is the bit in revIDELibrary which gets the contents of the fonts folder, filters them as it's interested in truetype .ttf fonts, and activates each in turn inside the IDE:

Code: Select all

on revIDEInitialiseIDELibrary
   # Load fonts
   local tFonts
   put files(revIDESpecialFolderPath("fonts")) into tFonts
   filter lines of tFonts with "*.ttf"
   repeat for each line tFont in tFonts
      start using font file (revIDESpecialFolderPath("fonts") & slash & tFont)
   end repeat
   ...
   

So we could borrow a bit of this function to write our own if need be.

[richmond62]

No crashing on MacOS Sonoma:

Code: Select all

on mouseUp
   put fontNames() into fld "FLIST"
end mouseUp

[tperry2x]

That isn't one of the known issues on Sonoma.

[OpenXTalkPaul]

Again, this was fixed in 9.6.7, so you won't see the change in 9.6.3 code.

I meant that I've never experienced any problem with camera or record audio crashing, but I'm also not using commercial edition that has the AVMedia edit/record externals from Monte. I was thinking that this doesn't apply to Community edition.

[tperry2x]

I meant that I've never experienced any problem with camera or record audio crashing, but I'm also not using commercial edition that has the AVMedia edit/record externals from Monte. I was thinking that this doesn't apply to Community edition.

I hope that's the case, but they do specifically mention the engine crashes - (and they do only say it's a potential crash, so probably won't happen all the time). it seems the engine was essentially the same between all the editions - (the IDE did all the bits that differentiates it between commercial, community, indy etc).