Menu conjecture

[tperry2x]

Something I just found (link)
It seems in LC Create, if you click a menu - it stays open. - So in other words, to dismiss the menu, you always have to choose something from it.

I mention this, as this isn't the case in LC/OXT currently. You can click a menu to activate it. Then with it open, you can click your stack and it hides.

This makes me think they have changed (and quite drastically changed) the way menus are drawn. I kind of want to do the same too. I've saved the image in case it 'goes away'.
I find it interesting, because it seems like that user "spoadr" is on MacOS, yet the menubar looks very un-mac like. This makes me wonder if in LC Create, it has a completely bespoke way of drawing menus.

If that's the case, I'm wondering about approaches of redrawing in-stack and in-standalone menus a bit differently. (Not using what is essentially a group of buttons embedded in the menubar).

Why? because this would solve a few issues we are having with menus in Sonoma+, and a few sporadic pauses / long delays with menus in Linux (which is a randomly occuring issue, which I suspect is a memory leak of some kind).

Image in post from discord:

e7c79415338f202e2b1a638b5cc54be55a743901_2_268x500.png (37.78 KiB) Viewed 3739 times

As an aside, one thing led to another and I found myself staring at a page for appli.io
Does the IDE here look very familiar to anyone?

I mention this image, because you'll note on there, the MacOS menubar only contains the application name. Nothing more. I'm just thinking I could do the same on MacOS and have a unique non-mac menu for the IDE. This lends itself to me redesigning the menus for the IDEs - and since I want to redo the menu builder stack, this ties in nicely.

Thoughts?

[richmond62]

As far as I am given to understand (special, pompous way of ducking responsibility) Create is 'done' via a browser; so I assume the whole thing is inside a browser window. So those menus are Create's menus that a "programmer" will see inside his/her browser of choice regardless of what operating system they are running on their computer.

[tperry2x]

Well, that's kind of what I originally thought, however with the rounded mac-esque window style and the mountainous background - I kind of wondered if it's more like a PWA (web app) which loads web content inside a desktop UI wrapper. A bit like electron wrappers can.

This was my idea anyway, which I had thought about entirely also replacing the IDE horizontal 'toolbar' at the same time, as well as changing the way menus are drawn.

alt-menus.png (247.11 KiB) Viewed 3728 times

[richmond62]

Well, at the risk of sounding extremely banal, I do NOT want a 'desktop' picture imposed on me. I prefer to work with a fairly 'boring' dark, neutral texture that does not detract from the work I am concentrating on.

[tperry2x]

This is not simply a desktop picture. That's not what I mean at all.
This is a floating rectangular window containing an entirely alternative way of drawing menus.

Or put another way, this would be making the menubar on MacOS function the way it does already on Windows and Linux. I know this is entirely non-mac-like, but I'm trying to avoid the LC method of menu generation - which is stuffing a group, made up of buttons, into the menubar. This is what newer MacOS versions do not like.

Hence my screenshot of appli.io on the Mac. They do the same. The menubar only shows the application name. The rest is fully button driven in their case. I don't want that, so my alternative is to have my menus underneath, then the buttons. Hopefully this is clearer as to what I'm proposing. This is a drastic change to the way menus are drawn under the MacOS version of the IDE (windows and linux users will be used to this concept).

menu-mockup-2.png (309.08 KiB) Viewed 3691 times

With "Toolbar Text" turned on:

menu-mockup-3.png (335.69 KiB) Viewed 3685 times

[richmond62]

I think that looks good and clever, AND if it will avoid a lot of the Mac-specific problems I would stop worrying about Apple's dictatorial HIG.

[tperry2x]

Okay, but before I get into that - I first need to know if the following works.
(otherwise there's no point in taking it further for MacOS).

If you are running Sonoma (and above), here's an unpatched MacOS x64 standalone.

contents of dmg.png (209.14 KiB) Viewed 3658 times

I want to see if this even opens in Sonoma and above. If it does, then I want to see if it crashes when the mac menubar is set. I'm trying to avoid the engine creating a MacOS style menu at startup.

I'd like to find out if the menus work in-stack on Sonoma+ (are they selectable and do they behave?)
I'd also like to know if adding it 'later' - by clicking those checkboxes, causes a crash or causes it to load into the menubar properly.

[richmond62]

Sorry: nothing doing until tomorrow as my Mac Mini running MacOS 15 is at work.

Currently cranking on "Gurage alternates" (You couldn't make it up even if you wanted to) of Ethiopic.

[tperry2x]

Okay, - I'm hoping it works. Works well on Linux
(this is not a mockup) - this is a working stack
BTW: I don't use the blur function here, as it's quite slow. I instead use a trick with the resizeQuality and scaling.

Screenshot at 2024-10-13 19-22-50.png (264.43 KiB) Viewed 3612 times

The only annoyance I have with this is that it's not as 'fluid' or 'smooth' as I'd like. There's a flicker that is perceptable. Only probably about 5 milliseconds, but I can see it.
I would lock and unlock screen, but that causes another issue - you end up duplicating the stack ad-infinitum as a ghost image, so it gradually gets darker and darker and more and more blurred until it looks like nothing.

So, I'm thinking about another way to 'freeze' the display and momentarily unlock it without any visual effects. (What do I mean 'visual effects'?) - not the ones in OXT. The visual effects that might be apparent in the underlying OS when hiding and showing a window.
For example: KDE, Windows 10 & 11, MacOS (newer versions) - show an effect when you open and close any window. I would have a full-screen snapshot of the current window acting as a mask, but this is 'expensive' on CPU time (I'm trying to script with the most efficient / low-powered computer that OXT will run on in mind). - This is no good if there's some kind of visual effect, so that approach won't work...

[neville]

Hmm. Not at all sure about messing with the look and feel of a basic thing like the menubar, which is so intrinsic to the difference between Mac and other platforms. Anything that looks like port from a different os will definitely turn off general Mac users.

And even if that would be acceptable for the IDE, it would definitely *not* be acceptable on standalones.

[tperry2x]

I did want multiple points of view on this, as the last thing I wanted to do was go to the trouble of replacing stuff, only to find it's all got to be put back again.

If I was doing this IDE just for me, then yes - I'd do away with the old interface. But I'm not, and this was only all because of macOS and the menu situation.

(Which I think is fixed incidentally, already in the source... if only we could get the damn thing to compile). That might go some way to stopping these MacOS surprise crashes. I can leave OXT Lite open for days on Windows and Linux (which I have inadvertently a couple of times). Not so on MacOS 12.

Okay, will shelve this idea.
As I mentioned, many times before, I wouldn't expect the LCC9.6.3 engine to stay running on anything above MacOS 11 as it's not officially supported. What with MacOS also being such a moving target, there could be anything changed by Apple at any time which breaks the engine or makes it unstable.

mac-os-support.png (169.1 KiB) Viewed 3558 times

[richmond62]

On Opening the menutest.app on my up-to-date machine and setting the selection as shown:
-

SShot 2024-10-14 at 13.22.51.png (140.58 KiB) Viewed 3531 times

-
As soon as either:

1. Click on the app window.

2. Click on the menubar.

the thing crashes.

[tperry2x]

Okay, so that answers my question then. As soon as the menubar is called into existance, it kills everything on Sonoma+
I just wondered if loading it 'later', as in loading it not as the application starts would make any difference.
Apparently not. Oh well - so endeth the menu experiments.

[OpenXTalkPaul]

Well, that's kind of what I originally thought, however with the rounded mac-esque window style and the mountainous background - I kind of wondered if it's more like a PWA (web app) which loads web content inside a desktop UI wrapper. A bit like electron wrappers can.

This was my idea anyway, which I had thought about entirely also replacing the IDE horizontal 'toolbar' at the same time, as well as changing the way menus are drawn.


alt-menus.png

Yes that's what I think 'Create' may be too. A web app (for 'Create Cloud'). and 'Native' is the same web-app engine but in a desktop app wrapper that exposes some more of the OS (not as sandboxed as running in a browser).
This makes sense to me, and from a business standpoint for LC too. As I've mentioned in the past, a WebAssembly Engine would be able to run at nearly 'native' speeds on just about any platform that has a modern HTML5 web browser engine, and it would be much less to maintain than 5-6 platform/architecture specific engine builds. Wrappers like Electron already facilitate some of 'Native' app functionality you can interact with using JavaScript.

But yeah, I gather that LC Create is going to be all mobile/single-window-UI oriented now, 'hamburger' menus, right and left sidebars, etc., because that's the world we live in now. (sigh). I like the 'old-school' desktop UI's with windows flying around everywhere.

[OpenXTalkPaul]

I'm trying to avoid the LC method of menu generation - which is stuffing a group, made up of buttons, into the menubar. This is what newer MacOS versions do not like.

I believe the way it actually works on macOS s the engine looks at the menu-button group and then if raiseMenus is on (or is it off?) it builds an NSMenu (or a customized subclass of it) menubar based on that information. The global menubar object is a singleton object for each app (comes with NSApp / AppKit), so you can get and manipulate this object easily via xBuilder FFI. That's exactly what the 'Status Menu" library does (which came with the Community IDE, I believe originally developed by Trevor DeVore). What I think that newer macOS don't like is the 'custom subclass' bit, the IDE menubar hides some of the menu items that an app would normally get by default from the OS APIs. That is some things that became standards on macOS, such as tabbed documents windows, 'native' fullscreen, etc. were never implement (or at least not natively implemented) in the macOS version of Engine, they simply delete or hide those standard menu items but it seems that may be no longer be acceptable to the OS? At any rate it has to do with changes Apple made that conflict with the engines methods.