Improve app menu on macOS

[smarsching]

This PR fixes a problem with app menu on macOS. The app menu is the leftmost menu with a bold label in the macOS menu bar.

In particular, it resolves a problem where the “Hide CS-Studio” menu item (shortcut ⌘H) does not hide the application and instead shows a standard about dialog (not even the “real” about dialog for Phoebus).

This change does not affect other platforms. I considered moving this logic into a separate module and only including this module when building for macOS. However, doing though would mean that an extension point would have to be added to the core-ui module, so that new module can add this functionality.

This would make the code much more complicated and when considering that the external library that adds the necessary function only adds about 130 KB to the total distribution size, I think that carrying this library around on other platforms even though it does not do anything on them, is acceptable.

[shroffk]

argh!!!
Is there a possibility that we could address this with an update to javaFX.
Should we open a ticket with javaFX

[smarsching]

@shroffk Yeah, I know, it’s really annoying.

While looking for a solution, I found a discussion from nine years ago, that linked to two related issues:

• https://bugs.openjdk.org/browse/JDK-8091517
• https://bugs.openjdk.org/browse/JDK-8088585

Considering that both this issues have not been addressed in about 10 years, does not make me very optimistic that proper support for the macOS menu bar has a very high priority for the JavaFX project and is going to be addressed any time soon…

[kasemir]

While the macOS apple menu behavior isn't perfect, the lack of movement on the JDK tickets shows that most other mortals don't seem to care.

My view is that there's value is keeping the dependencies and build system simple. CSS-on-eclipse became problematic when the build took more than 30 minutes and nobody could manually untangle the dependencies. When we presented CSS-on-phoebus at the 2018 EPICS meeting, the build completed in 20 seconds! The product included the key tools like display, data browser, and shortly after the meeting also alarms. Back then I could explain the dependencies: JavaFX, JCA, PVA, mail, jython, mysql/postgres, Kafka, .. Now we have about 100 dependencies listed in the pom.xml, which then expand to about 240 jar files... We're on a fast track to re-create the eclipse-based bloat. With that in mind, I'd simply accept this as a JavaFX shortcoming.

[smarsching]

@kasemir If this was just about cosmetics, I would agree. However, not being able to hide the application is a major issue. I think that the impact of this is comparable to not being able to minimize the application window on Windows.

I see your point about reducing dependencies, though, so how about making this a macOS-only dependency. I could use reflection, so that the code will compile and run fine without the library being present. People for whom this behavior is an issue, could then simply place the library on the classpath (either when building their Phoebus product or even at runtime).

[shroffk]

However, not being able to hide the application is a major issue. I think that the impact of this is comparable to not being able to minimize the application window on Windows.

I think I begrudgingly agree that this might be a valid reason to address this.

I would vote for keeping the PR as it is, personally I feel like the complexity of managing many OS specific dependencies is not worth it.

[georgweiss]

In my experience almost every single Mac OS update brings ever so small changes to application behavior. For instance, just discovered that after update to Mac OS 14.1.1 the Phoebus splash screen does not work, with the (probable) side effect that main Phoebus window is not put to front if user launches from Finder.

My point is that third-party libs to overcome Mac OS quirks might break on next Mac OS update.

[smarsching]

In my experience almost every single Mac OS update brings ever so small changes to application behavior. For instance, just discovered that after update to Mac OS 14.1.1 the Phoebus splash screen does not work, with the (probable) side effect that main Phoebus window is not put to front if user launches from Finder.

@georgweiss The splash screen is working for me on macOS 14.4.1, but you are right that the Phoebus app is not automatically brought into the foreground any longer, so I think that the two issues are unrelated.

Regarding the splash screen, it did not appear on a different system running macOS 13.6.6, but I could fix that after running Phoebus one with the -splash parameter. After that, the splash screen was also shown again when starting Phoebus without any parameters (e.g. from the Finder). So, the issue with the splash screen rather looks like an issue with Phoebus’s preference system than a macOS-related bug.

My point is that third-party libs to overcome Mac OS quirks might break on next Mac OS update.

Yes, making sure that there is a good user experience across different platforms is a process that never ends. I do not know any widget toolkit that succeeds in “hiding” away all the differences between platforms. This is why virtually all Java applications that provide a good UX across platforms have some platform-specific code. This is true for stuff like IntelliJ IDEA (using Swing), Eclipse (using SWT), NetBeans, etc.

So, for me the question is not whether we need platform-specific code but rather how such code can be implemented in the cleanest way possible. I see two possible paths:

1. If the Phoebus core application is supposed to properly support all three major platforms (Linux, macOS, Windows), we maintain the necessary platform-specific code in the Phoebus source tree.
2. If the Phoebus core application is supposed to only provide the minimal core functionality that is needed by everyone, ensuring a good UX is the job of the respective maintainers of the Phoebus products. In that case, the Phoebus core should provide proper extension points to enable product maintainers to add the code that is relevant to the platforms that they want to support.

The point about build time and number of dependencies that @kasemir made is relevant in this context.

However, I that this argument also applies to many other aspects of Phoebus. For example, the build would be quicker and there would be fewer dependencies if support for different archive sources, PV sources, logbook systems, etc. was not part of the core repository.

So, we either want to keep one big repository for everything (the approach also used by the Linux kernel), which will invariably lead to more dependencies and longer build times as more functions are added. Or we could switch to a concept that maintains different components in separate repositories, shortening build times and reducing the number of dependencies for each component, but having other downsides.

To be clear, I am very much in favor of the current approach of maintaining everything in a single place because it is so much easier than trying to maintain a proper API for each component without breaking backwards-compatibility. I just think that this goal cannot be achieved while also minimizing build times and the number of dependencies.

In summary, I do not expect people who do not care about the UX on macOS to put work into improving it, but we have to figure out a way for those who do care to make the necessary changes, be it in Phoebus itself or in separately maintained extension modules.

[smarsching]

@georgweiss Just a quick note regarding the bug that the application window is not being brought to the foreground on startup:

This bug has been fixed in JavaFX 17 and 21. It has not been fixed in JavaFX 19, I guess because this is not an LTS release.

I just built Phoebus with JavaFX 21.0.3 and this indeed fixes the issue with the window not being brought into the foreground. In fact, it also fixes the issue with the app menu, which of course is a much better way to fix this then the changes suggested in this PR.

I am not sure why I could not find the issue for the fix of the app menu. Maybe it was fixed as a side effect of a change made for another reason. Anyway, I am just glad that it has been fixed.

So, I suggest that we switch to JavaFX 21 as soon as reasonably possible. I am happy to provide a PR for that change. Or are there any reason why we cannot upgrade yet of which I am not aware?

[georgweiss]

Thanks @smarsching for spending more time than me investigating this.

Now that we are on Java 17 I see no reason not to go for JavaFX 21.

[shroffk]

Now that we are on Java 17 I see no reason not to go for JavaFX 21.

+1 on moving to JavaFX 21

[kasemir]

Fixing a JavaFX issue by simply updating to a more recent JavaFX version is perfect, and brings this specific Mac OS issue to an ideal conclusion.

Still, some key points of the discussion need to continue, maybe you can do that at the upcoming codeathon.

EPICS has been around for 30+ years. Display tools only last ~10 years:

198x: edd/dm
199x: medm
200x: edm
2009: Eclipse-based CS-Studio w/ BOY
2016: Start of phoebus
2018: Phoebus-based CSS w/ Display builder presented at Chicago EPICS meeting
2019: Web runtime
There were other approaches based on tcl/tk, Visual Basic, Borland Delphi, .. that didn't find broad acceptance and fizzled out. There are several python/qt based approaches that have caught on.

Phoebus is in its 8th year. Will it be dead in 2 more?
Opinions will vary, but what makes a tool successful?
With EPICS base you can typically get the sources as one *.tgz or one "git clone", then "make", and you're done. The only dependency that you had to prepare was the readline library, and that's recently become optional resp. auto-detected.
edd/dm, medm, edm used to be that way, but by now their graphics libraries are no longer bundled in default linux distros. Plus even when you do get it all built, the result shows its age.
I don't need to detail our issues with the Eclipse-based CS-Studio.
Phoebus looked great back when JFX was included in Oracle JDK 9. I was worried when it got split out, but this very ticket suggests that JFX is alive and remains a good choice. We do support a basic "git clone; mvn run", but I think we reached the point where nobody understands the dependencies. We simply hope that maven somehow resolves them.

[shroffk]

Yes,
This does sound like a perfect topic for discussion at the codeathon

Just to ensure that I keep my maven fan club membership active... We have had
successful CI builds for years now and the expansion of dependencies has not broken anything. I have checked the issue tickets and my email and except for 1-2 problems, primarily related to the use to the wrong JDK, it does not seem like the broader community is struggling with builds.

We can pull out the services, core, and each app into individual repo which would make the dependency tree smaller but at the cost of having to deal with the complexity for multiple repos.

Let us have this discussion in person though (preferably with some beer) and figure out our main concerns and how to address them moving forward :)

[shroffk]

@smarsching can I close this PR and we can open a new one with javaFX 21

[smarsching]

@shroffk Yes, I just closed this PR in favor of #3007.

@kasemir You have a good point there. If I may add my two cents (I won’t be able to make it to the Codeathon), I think that your observation proves that tools that heavily rely on a GUI have a much shorter lifecycle then backend tools that run headless.

I think that this trend does not only apply to “native” GUIs but maybe even more so to web-based applications. It feels like there is new trend in web UI design about every six months.

The tools that survive long-term are the ones that constantly change. If you look at stuff like Microsoft Office, which has literally been around for decades, the early versions probably have nothing in common with the current versions.

So, when seeing Phoebus as an evolutionary step of step of CSS, the software has been around for 15 years, and I don’t see a reason why it could not be around for another 15 years or longer. In the future it might look different and not be based on JavaFX (though for the moment, I do not see a reason to switch to something else), but for me this is not death but just another step in the constant process of renewal.