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

Javadoc Hover: Generic Types are hardly readable in light/default theme #1442

Closed
laeubi opened this issue Jun 7, 2024 · 15 comments
Closed
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@laeubi
Copy link
Contributor

laeubi commented Jun 7, 2024

grafik

the light green is hardly readable on white background (not sure why the <?> is printed differently) especially as a very thin font is used here. If more than one generic is involved it even becomes worse:

grafik
grafik

Eclipse SDK

Version: 2024-06 (4.32)
Build id: I20240529-1800
@jukzi
Copy link
Contributor

jukzi commented Jun 7, 2024

@RedeemerSK is that something you may work on?

@iloveeclipse
Copy link
Member

May be using bold font style will be the solution here?

@laeubi
Copy link
Contributor Author

laeubi commented Jun 7, 2024

It looks like the last example the List<R> ... is using bold font I still find it hard to read on light background.... the colors just seem not suitable for an almost white background.

@iloveeclipse
Copy link
Member

But it is much better compared to the non-bold R:
image
so using bold style will be an easy fix (I assume), while selecting "right" colors will most likely lead to never ending discussion, as everyone will have other preferences...

@laeubi
Copy link
Contributor Author

laeubi commented Jun 7, 2024

I would be even happy with (maybe a preference) to disable the colors like it was before ;-)

@humphreygao
Copy link

It format the method parameter(one parameter per line) to improve readability, so I like it.

@laeubi
Copy link
Contributor Author

laeubi commented Jun 7, 2024

It format the method parameter(one parameter per line) to improve readability, so I like it.

The problem is not the method parameters!

@iloveeclipse
Copy link
Member

I would be even happy with (maybe a preference) to disable the colors like it was before ;-)

Have you noticed that:
image

@laeubi
Copy link
Contributor Author

laeubi commented Jun 7, 2024

Thanks thats better now, but one need to focus (F2) the hover and at least under Linux its hard to oben the submenu as the hover closes in between and the Color preferences itself are empty

Peek.2024-06-07.14-11.mp4

@RedeemerSK
Copy link
Contributor

RedeemerSK commented Jun 7, 2024

Thanks thats better now, but one need to focus (F2) the hover and at least under Linux its hard to oben the submenu as the hover closes in between and the Color preferences itself are empty
Peek.2024-06-07.14-11.mp4

I have very limited expertise in Linux (distros) native graphics backends and thus I can only wonder why the hover viewer won't stay displayed after opening javadoc styling enhancements menu for you o.O.
EDIT: it does not close for me and it seems also for @iloveeclipse .
EDIT2: also the menu seems pretty bugged for you on that video - its content does not reflect javadoc content & current settings for styling enhancements. I already see what's causing this bug.

Btw, same menu (button) is available in Javadoc view.

But it is much better compared to the non-bold R:
image
so using bold style will be an easy fix (I assume), while selecting "right" colors will most likely lead to never ending discussion, as everyone will have other preferences...

Right now none of the type params in the content is bold. It's just that method return type section is italic which makes it to look little bit bolder.

Shortly I'll post screens how it would look with type params being same font-weight like the rest of the signature - because that's the actual difference right now ... they were made lighter than the rest with the intention to decrease their contribution to visual complexity.

@RedeemerSK
Copy link
Contributor

Current:
javadoc_styling_type_params_less_font-weight_win png
javadoc_styling_type_params_less_font-weight_ubuntu

New (same font-weight as rest):
javadoc_styling_type_params_no_font-weight_win png
javadoc_styling_type_params_no_font-weight_ubuntu

RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 8, 2024
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 8, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
@laeubi
Copy link
Contributor Author

laeubi commented Jun 8, 2024

@RedeemerSK with "normal" font weight it is better readable indeed I think one should either use colors or the lighter font weight but not both, and yes the hover/menu seems very "buggy"...

@RedeemerSK
Copy link
Contributor

RedeemerSK commented Jun 8, 2024

@laeubi please what's your platform ? (linux distro / desktop environment / anything that may have something to do with how SWT renders menus). I assume you are running it natively, not in VM or some other non-native way, right ?

EDIT: ignore, found the reason for buggy menu

Also ... until the fix that removes lighter text makes it into future builds, for those that are impatient and also willing to walk the unlawful path and do little bit of hacking that I of course won't officially suggest (*wink* *wink*), there's a way to apply the fix to any existing eclipse installation.

The fix can be manually applied to the files bundled inside org.eclipse.jdt.ui plugin JAR used by eclipse installation (present in ~/.p2/pool/plugins directory). Surprisingly for me, because since the JAR is signed, I (it seems wrongly) assumed tampering with it would render it invalid / unusable, which is not the case and eclipse has no problem starting with modified plugin JAR.

@RedeemerSK
Copy link
Contributor

RedeemerSK commented Jun 8, 2024

Thanks thats better now, but one need to focus (F2) the hover and at least under Linux its hard to oben the submenu as the hover closes in between and the Color preferences itself are empty

Just noticed that hover & menu behaves differently when activated by pressing F2 (then going to menu hides the hover) compared to being activated by "entering into it" with mouse (then going to menu keeps hover displayed) on Ubuntu I'm testing this on. Will look into that. Can others confirm same behavior, @laeubi ?

EDIT: found the cause (bug), fixed

RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 26, 2024
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 26, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 26, 2024
Also simplify populating enhancements menu & colors sub-menu by
re-creating them every time they're being requested.

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 28, 2024
Also simplify populating enhancements menu & colors sub-menu by
re-creating them every time they're being requested.

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 28, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 28, 2024
Also simplify populating enhancements menu & colors sub-menu by
re-creating them every time they're being requested.

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
Also simplify populating enhancements menu & colors sub-menu by
re-creating them every time they're being requested.

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
Re-create them every time they're being requested.

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
RedeemerSK added a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jun 29, 2024
Re-create them every time they're being requested.

Fixes eclipse-jdt#1442
@RedeemerSK
Copy link
Contributor

Fix PR: #1482. I hope it's OK I am also fixing bugged styling enhancements menu in that PR and not just the hard to read colored type parameters. If necessary, I can split into two separate PRs.

iloveeclipse pushed a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jul 9, 2024
iloveeclipse pushed a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jul 9, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes eclipse-jdt#1442
iloveeclipse pushed a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jul 9, 2024
iloveeclipse pushed a commit to RedeemerSK/eclipse.jdt.ui that referenced this issue Jul 9, 2024
Re-create them every time they're being requested.

Fixes eclipse-jdt#1442
iloveeclipse pushed a commit that referenced this issue Jul 9, 2024
- incorrect text was searched for inside HTML content to see if
enhancements are present
- menu actions for enhancements enabled state were not set / left only
when enhancements were present in content

Fixes #1442
iloveeclipse pushed a commit that referenced this issue Jul 9, 2024
iloveeclipse pushed a commit that referenced this issue Jul 9, 2024
Re-create them every time they're being requested.

Fixes #1442
@iloveeclipse iloveeclipse added the enhancement New feature or request label Jul 9, 2024
@iloveeclipse iloveeclipse added this to the 4.33 M2 milestone Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants