search

eclipse-jdt / eclipse.jdt.ui

Eclipse Public License 2.0
35 stars 86 forks source link

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

Closed laeubi closed 1 month ago

laeubi commented 2 months ago

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 commented 2 months ago

@RedeemerSK is that something you may work on?

iloveeclipse commented 2 months ago

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

laeubi commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

humphreygao commented 2 months ago

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

laeubi commented 2 months ago

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

The problem is not the method parameters!

iloveeclipse commented 2 months ago

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

Have you noticed that: image

laeubi commented 2 months ago

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

https://github.com/eclipse-jdt/eclipse.jdt.ui/assets/1331477/782bd4d7-64b9-4670-8615-2df8c5aa3363

RedeemerSK commented 2 months ago

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 commented 2 months ago

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

laeubi commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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.