Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

ShahzaibIbrahim
Copy link
Contributor

@ShahzaibIbrahim ShahzaibIbrahim commented Aug 14, 2024

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:

image

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.

EXPECTED BEHAVIOUR

The menu bar should be scaled properly.

contributes to #62 and #127

Copy link
Contributor

github-actions bot commented Aug 14, 2024

Test Results

  284 files   -   201    284 suites   - 201   5m 22s ⏱️ - 3m 29s
4 158 tests ±    0  4 150 ✅ +    1   8 💤 ± 0  0 ❌  - 1 
8 246 runs   - 8 140  8 188 ✅  - 8 105  58 💤  - 34  0 ❌  - 1 

Results for commit 3cf5e46. ± Comparison against base commit 02e20d6.

♻️ This comment has been updated with latest results.

Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@ShahzaibIbrahim ShahzaibIbrahim force-pushed the use-dpi-dependent-win32-api-calls branch from 2d1a006 to a9d2293 Compare August 20, 2024 13:22
@ShahzaibIbrahim ShahzaibIbrahim changed the title Drawing custom menu items for Menu Bar Drawing custom menu items for Menu Bar **Dark Theme Only** Aug 20, 2024
@ShahzaibIbrahim ShahzaibIbrahim force-pushed the use-dpi-dependent-win32-api-calls branch 2 times, most recently from e7017c6 to e10a814 Compare August 21, 2024 11:21
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
image
And this is how it looks now:
image
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:
image

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.

image

@HeikoKlare
Copy link
Contributor

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
    image
  2. There are unexpected menu items, like another "File" entry with only a single entry in the menu that opens up from it
    image

Can you please check that, @ShahzaibIbrahim?

@HeikoKlare
Copy link
Contributor

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:
image

@ShahzaibIbrahim ShahzaibIbrahim force-pushed the use-dpi-dependent-win32-api-calls branch 2 times, most recently from 674c379 to 3c16e7e Compare September 5, 2024 12:10
@HeikoKlare
Copy link
Contributor

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:
image

@ShahzaibIbrahim ShahzaibIbrahim force-pushed the use-dpi-dependent-win32-api-calls branch 2 times, most recently from 5ee53ab to e0d0e5b Compare September 6, 2024 08:56
@ShahzaibIbrahim
Copy link
Contributor Author

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: image

Yes sorry, that was a leftover.

@HeikoKlare
Copy link
Contributor

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?
image

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?
image

@ShahzaibIbrahim ShahzaibIbrahim force-pushed the use-dpi-dependent-win32-api-calls branch 5 times, most recently from db0f7f1 to 14830a6 Compare September 13, 2024 15:15
When switched to Dark Theme, using gc to draw menu item, moving the
responsibility from OS due to wrong scaling of menu bar vertically.

Also changing the text color from a grayish tone to white.
Also when ALT key is pressed mnemonics are underlined and work as a toggle, the behavior which was missing from dark theme previously.
Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposed change works really great now! It fixes the existing issues with scaling the menu bar in dark theme and it also improves the appearance of the menu bar in dark theme overall.

I only have one behavioral concern left, which is about the statically defined margins that (1) seem to be inappropriate and (2) are scaled incorrectly. The other comments are regarding code style / design and rather nitpicky.

Comment on lines 1154 to 1163
/*
* Weirdness in Windows. Setting `HBMMENU_CALLBACK` causes
* item sizes to mean something else. It seems that it is
* the size of left margin before the text. At the same time,
* if menu item has a mnemonic, it's always drawn at a fixed
* position. I have tested on Win7, Win8.1, Win10 and found
* that value of 5 works well in matching text to mnemonic.
* NOTE: autoScaleUpUsingNativeDPI() is used to avoid problems
* with applications that disable automatic scaling.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this relevant anymore, so that the width can be set to a different value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This information still seems relevant on explaining the difference between left margin and item size. Also we are back to using value of 5 again to match the margins between items in menu bar. I would suggest to keep this comment as is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, then please re-add it, because currently this PR will remove it. Only the information on autoScaleUpUsingNativeDPI should be revised, as that method is not used anymore.

Comment on lines 50 to 51
final static int LEFT_TEXT_MARGIN = 15;
final static int ADDED_ITEM_WIDTH = 15;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How are these values derived? The margins look rather different to the existing implementation and to the light theme. In the existing implementation, a value of "5" was hardcoded for the left margin at some point, maybe that would fit as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going back to the value 5 for item width as before (because of larger gap) and left margin value was derived as a result of testing against different values and finding out the closest to the light theme.

Copy link
Contributor

@HeikoKlare HeikoKlare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code quality improvements are overall fine. The behavioral concerns in the last review have not been addressed yet. Please check them again.

In addition, testing Snippet 373 shows a misplacement of the image:
image
image

One minor finding that may be addressed independently as it is not part of this PR:
the image is not scaled correctly when using rescaleOnRuntime:
image

Comment on lines 1154 to 1163
/*
* Weirdness in Windows. Setting `HBMMENU_CALLBACK` causes
* item sizes to mean something else. It seems that it is
* the size of left margin before the text. At the same time,
* if menu item has a mnemonic, it's always drawn at a fixed
* position. I have tested on Win7, Win8.1, Win10 and found
* that value of 5 works well in matching text to mnemonic.
* NOTE: autoScaleUpUsingNativeDPI() is used to avoid problems
* with applications that disable automatic scaling.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, then please re-add it, because currently this PR will remove it. Only the information on autoScaleUpUsingNativeDPI should be revised, as that method is not used anymore.

gc.setBackground(isSelected? display.getSystemColor(SWT.COLOR_DARK_GRAY) : parent.getBackground());
gc.fillRectangle(menuItemArea);

int xPoisitonText = DPIUtil.scaleDown(x + LEFT_TEXT_MARGIN, zoom) + (this.image != null ? this.image.getBounds().width : 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Positioning is still wrong and inconsistent across different zoom level. Please correct the scaleDown calls as described before to solve this and adapt the LEFT_TEXT_MARGIN accordingly.

This is 100%:
image

This is 150%:
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also fix the typo in the variable name xPoisitionText

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants