Drawing custom menu items for Menu Bar **Dark Theme Only**

[ShahzaibIbrahim]

Using gc to draw menu item, moving the responsibility from OS due to wrong scaling of menu bar horizontally in Dark Theme. Snippet 373 can be used to test menuItems with images.

Additional points covered in this PR:

• Changing the text color from a grayish tone to white.
• When ALT key is pressed mnemonics are underlined and work as a toggle, the behavior which was missing from dark theme previously.

Screenshot of the fix:

HOW TO TEST

• Run the RunTimeWorkspace with the following VM Arguments

-Dswt.autoScale=quarter
-Dswt.autoScale.updateOnRuntime=true

• Go to "Windows" -> "Preferences" -> "General" -> "Appearance"
• Change theme to "Dark"
• Click "Apply and Close"
• Move the window from 100 -> 175 (or anything 100+) zoom level
• See if menu bar is properly aligned.

SCENARIOS TESTED

autoscale.updateOnRuntime = false && autoscale=int200 (Prevent regressions)
100% (Primary), 175% (Second)
150% (Primary), 200% (Second)
175% (Primary), 125% (Second)
200% (Primary), 100% (Second)
200% (Primary), 150% (Second)
autoscale.updateOnRuntime = false && autoscale=quarter (Prevent regressions)
150% (Primary), 200% (Second)
175% (Primary), 125% (Second)
autoscale.updateOnRuntime = true && autoscale=int200
100% (Primary), 175% (Second)
150% (Primary), 200% (Second)
175% (Primary), 125% (Second)
200% (Primary), 100% (Second)
autoscale.updateOnRuntime = true && autoscale=quarter
150% (Primary), 200% (Second)
175% (Primary), 125% (Second)

EXPECTED BEHAVIOUR

The menu bar should be scaled properly.

contributes to #62 and #127

[github-actions]

Test Results

   486 files  ±0     486 suites  ±0   8m 30s ⏱️ +53s
 4 154 tests ±0   4 146 ✅ ±0   8 💤 ±0  0 ❌ ±0 
16 370 runs  ±0  16 278 ✅ ±0  92 💤 ±0  0 ❌ ±0 

Results for commit bd3cf3a. ± Comparison against base commit 4d61d1d.

♻️ This comment has been updated with latest results.

[HeikoKlare]

I tested the changes with different scale factors and auto-scale settings (quarter/integer200). The scaling results look fine, in constrast to the existing scaling behavior that was broken.

I have some detailed comments and a general question: are there snippets to test the behavior also in combination with images? Our default applications only have menus with text but it would also be interested to test the changes with images, so we should either have or provide a snippet with images for validation.

Please also improve the commit message according to the recommendations, such that it explains the existing issue and more precisely describes the fix. E.g., it currently sounds as if the menu is always draw in a custom way by this change, but it only affects the behavior when using dark theme.

[HeikoKlare]

Thank you for the recent improvements. There are several improvements in the new version, that's great. In particular, this change also improves the visualization of menus with images. This is how it looked before:

And this is how it looks now:

Only problem is that the left margin is always applied to the text, even if an image is present. But in that case, the margin should be applied to the image (and maybe some additional small margin needs to be placed beetween image and text). This is, e.g., how it looks for the light theme:

One additional issue I found concerns the handling of mnemonics, i.e., when pressing Alt+$ for accesing menu item with menmonic $.

1. The visualization is broken: the background color of the menu items does not fit when pressing the "Alt" button (it is black while the rest of the menu is grayish). See the screenshot below.
2. Mnemonics are always displayed (underlined) and not only when Alt is pressed. This is, actually, existing behvior, but differs from default behavior, such as in light theme, where the mnemonics are only underlined when Alt is pressed. Maybe we could address this as a follow up, as no regression is introduced. On the contrary, in the current behavior, pressing Alt hides the mnemonics, so badly inverts the intended behavior.
3. Most severe issue: there is no reaction to key bindings for mnemonics. E.g., pressing Alt+F should open the "File" menu, but does nothing.

[HeikoKlare]

Something seems to be wrong with the PR now. No matter whether I rebase on #1349, I see two issues:

1. The left margin of each menu item is quite large
   
2. There are unexpected menu items, like another "File" entry with only a single entry in the menu that opens up from it
   

Can you please check that, @ShahzaibIbrahim?

[HeikoKlare]

I retested and found that the faulty second "File" entry is because of a broken workbench.xmi on my side. Still, it shows some placement issue, as the text is cut off (hapenning for a "File" entry without a mnemonic, while the original "File" entry with mnemonic is not cut off). That may be investigated. You can easily reproduce by manually adding two menus (with at least one dummy menu item in each of them to have the menu shown) through the Model Spy:

[HeikoKlare]

Please check your latest commit. Only considering the diff, it does not seem to be in the intended/final state. There is a System.out.println() statement and some some added magic number in addition to the essential change:

[ShahzaibIbrahim]

Please check your latest commit. Only considering the diff, it does not seem to be in the intended/final state. There is a System.out.println() statement and some some added magic number in addition to the essential change:

Yes sorry, that was a leftover.

[HeikoKlare]

I've quickly retested again, but still see the large left margin for every menu I have mentioned before. Is that intended and is it reproducible for you?

In addition, I see that when activating mnemonics mode (pressing Alt) only the texts but not the complete menus are highlighted. That's different to existing behavior and to behavior of the light theme. Anyway: is the behavior intended or is that by accident?

[HeikoKlare]

Unfortunately, when doing another final testing after rebasing, I found a further issue. To reproduce, do the following:

• Have a primary monitor with >100% scaling (e.g., 125%), have a secondary monitor with 100% scaling
• Start an application with PerMonitorV2 DPI awareness in dark mode
• Move the application from 125% monitor (on which it looks fine) to 100% monitor.

The sizes seem to be calculated properly, but the font is too small (probably 100% instead of 125%):

@akoch-yatta @ShahzaibIbrahim can you please have a look? Maybe this is easy to resolve by using proper scale values at some place.

[HeikoKlare]

Unfortunately, it looks still almost the same. On 125% it became better/good, but with the primary monitor on 150% or above, I still see the issue. E.g., this is with primary monitor 175% on secondary monitor with 100%:

[akoch-yatta]

Unfortunately, it looks still almost the same. On 125% it became better/good, but with the primary monitor on 150% or above, I still see the issue. E.g., this is with primary monitor 175% on secondary monitor with 100%:

@HeikoKlare Sorry for all that back and forth, we need to improve the test protocol on our side, so you don't have that much work retesting changes. It is not yet properly working on all scenarios, as you mentioned. We'll have a look on that tomorrow.

[HeikoKlare]

This is how it looks when I start on 125%:

This is on 150%:

[akoch-yatta]

In each of the following screenshot there is an adapted version of Snippet373 started with commit 2fe01bf, 4 times each. The title gives the info of the configuration:

1. autoscaleOnRuntime active or not
2. autoscale mode: int200 or quarter

---

Setup: Primary 125%, secondary 175%
Primary:

Secondary:

---

Setup: Primary 175%, secondary 125%
Primary:

Secondary:

---

Setup: Primary 150%, secondary 200%
Primary:

Secondary:

---

Setup: Primary 200%, secondary 100%
Primary:

Secondary:

[HeikoKlare]

Is this supposed to be ready for another review? I have only taken a quick look into an SDK application, but horizontal spacing is still off. See this screenshot at 150% (top one is with current implementation, bottom one with this PR):

And at 175%/200%, vertical spacing also seems broken (scaling mode "integer200"):

[akoch-yatta]

Hmm, I cannot reproduce any vertical spacing issue, neither with quarter nor with int200.
100%

150%

175%

200%

Regarding the horizontal indentation: I agree, that int direct comparision positioning could be improved. I tweaked some statics in cd3bb9b to achieve the following result
100%

150%

200%

[fedejeanne]

The changes look fine to me and I didn't find any regressions/bugs while testing.

I only have 2 nit-picky comments regarding readability but aside from that, this PR is good to go on my account.

[fedejeanne]

@ShahzaibIbrahim please squash your commits and this one is good to go on my account. @HeikoKlare should I merge or do you want to take another look?

[HeikoKlare]

I've retested this and did not find any issues anymore. In particular with existing HiDPI support (i.e., without per-monitor rescaling at runtime) and all combinations of settings (integer200 or quarter scaling, DPI awareness set to PerMonitorV2 or System, two monitors with different scalings between 100% and 200%).

The general appearance is also better than with the existing implementation (placement/spacing and highlight color). There is still some room for slight improvements on vertical alignment (with 100% is slightly off to the top while at 175% it is slightly off to the bottom), but that's rather nitpicky and, as said, the proposed state is still far better than the existing one.

@ShahzaibIbrahim can you please check the code formatting again (see, e.g., the comments I made) and squash the commits, so that we can merge this for M2?

[fedejeanne]

I would like to merge this PR but I'm not sure that every check ran. I only see 7 on the Checks tab.

Other PRs have also checks from Jenkins

I also noticed that https://ci.eclipse.org/releng is currently offline

Is there a shortage outage? @merks / @laeubi / @akurtakov ?

[HeikoKlare]

Is there a shortage?

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5131

[BeckerWdf]

Is there a shortage?

you mean "outage"?

[HeikoKlare]

Jenkins is still unavailable, but (Jenkins) builds before latest update were successful and without new issues. Since only formatting changes have been performed since then, this is still safe to merge.