Sticky remMenuBar

[dunbarx]

Not sure how long this has been the case.

The revMenubar remains visible when LC is not the frontMost app. It does no harm, but this flies in the face of every user guideline I know. Working in 8.1.8. Mac OS 10.9.

I know I can hide it, but what gives?

Craig

[FourthWorld]

Is it a palette? I had thought they changed it to modeless due to complaints of stacks submarining beneath it.

[dunbarx]

Richard.

Mode is 3. Modeless dialog.

But does that matter? All other LC gadgets, stacks (palette or not) dialog boxes, whatever, go away if I place another app in front. But not stack "revMenuBar".

Craig

[FourthWorld]

Only palettes should go away when an app switches to the background. If you find any other modes hiding when backgrounding that would be a bug that should be reported.

[bogs]

Since I had OSX open, I popped open a number of different Lc versions from 8.1.8 to 6.7.11. It seems like it is kind of random as to what stays around with say, Finder open in front.

The menu changes to Finders regardless, but as Craig notes, the menubar stays up there. In 7 the application browser stuck around, in Mc the home stack stayed.

[FourthWorld]

From time to time user feedback prompts the team to change palettes to modeless or vice versa.

But as with any Mac app, what should be consistent is that only palette mode windows hide in the background.

[dunbarx]

I see that everything, palettes included, go away when LC is not in front.

I can imagine situations where, if palettes stick regardless of whether LC is in front or not, that could either be very useful or very annoying. In any case, everything goes away for me except revMenubar.

I will open a report and see what the gods say.

Craig

[bogs]

But as with any Mac app, what should be consistent is that only palette mode windows hide in the background.

Sounds logical, but I'm curious about this statement :

Is it a palette? I had thought they changed it to modeless due to complaints of stacks submarining beneath it.

The curiosity on my part is, wasn't the menu bar always (previously) a palette? However, I've seen stacks over it in previous versions. So, the question is what changed to make that not the case after 7, so that they would need to change it to modelss dialog?

[dunbarx]

Filed #21218

We will see what comes back. i mentioned that there was discussion on what should or should not be hidden when LC goes below.

Craig

[FourthWorld]

But as with any Mac app, what should be consistent is that only palette mode windows hide in the background.

Sounds logical, but I'm curious about this statement :

Is it a palette? I had thought they changed it to modeless due to complaints of stacks submarining beneath it.

The curiosity on my part is, wasn't the menu bar always (previously) a palette?

See above where I wrote:
"I had thought they changed it to modeless due to complaints of stacks submarining beneath it."

However, I've seen stacks over it in previous versions.

If a non-palette stack can be brought in front of a palette that would be a bug.

In v9 on Linux there is an occasional window layering issue that's been reported with palettes, but I've not seen it on macOS nor in earlier versions on Linux.

[bogs]

The curiosity on my part is, wasn't the menu bar always (previously) a palette?

Apparently not.

RevMenubar mode v6.5.2

Selection_004.png (26.96 KiB) Viewed 10341 times

2: non-editable window
The stack is open and displayed in a normal window, but is not editable. A stack has this mode if its style is "topLevel" or if it was opened with the topLevel command, and the stack's cantModify property is set to true.