Closed laeubi closed 1 month ago
@RedeemerSK is that something you may work on?
May be using bold font style will be the solution here?
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.
But it is much better compared to the non-bold R:
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...
I would be even happy with (maybe a preference) to disable the colors like it was before ;-)
It format the method parameter(one parameter per line) to improve readability, so I like it.
It format the method parameter(one parameter per line) to improve readability, so I like it.
The problem is not the method parameters!
I would be even happy with (maybe a preference) to disable the colors like it was before ;-)
Have you noticed that:
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
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:
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.
Current:
New (same font-weight as rest):
@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"...
@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.
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
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.
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: