https://bugs.kde.org/show_bug.cgi?id=492187
Bug ID: 492187
Summary: LSP popup box has very poor contrast with surrounding
code and general styling issues
Classification: Applications
Product: kate
Version: Git
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: adam.m.fontenot+...@gmail.com
Target Milestone: ---
Created attachment 172953
--> https://bugs.kde.org/attachment.cgi?id=172953&action=edit
screenshot of various issues with popup window appearance
SUMMARY
There are some overlapping issues with the style of the LSP popup box. Style is
subject to opinion, of course, but I'm going to try to highlight some objective
issues.
I'm happy to split these issues into additional reports as necessary / as
requested, but I think the most likely resolution is going to happen in a
single merge request where someone takes the time to improve the widget
styling.
1. It's difficult to visually distinguish the popup box from the surrounding
code editor widget. This seems true regardless of what color scheme you're
using in Kate.
2. Some of the text in the box is very large, drawing attention where it
doesn't seem to be warranted. See attached screenshot for example.
3. Popup boxes that contain a lot of information are a bit difficult to read
and "cramped" feeling.
4. It's difficult to visually tell what is a link and what isn't. It's
impossible to distinguish some code elements unless they are syntax
highlighted.
POSSIBLE RESOLUTIONS
1. Instead of using the editor background color from the user's theme as the
background color for the popup, use a different color from the same theme (if
it's possible to choose one appropriate for popups - this isn't clear to me).
Alternatively, create contrast with the editor background by brightening the
theme background color if it's below a certain value, and darkening it if it's
above that value.
Also, increasing the padding on the internal document slightly would help
create more separation.
2. I think the text styling issues come primarily from naively asking Qt to
render Markdown - in the screenshot, Qt seems to be rendering a `#` header in
the Markdown source text the way it would render an `h1` HTML element - that
is, with really large text. But this rendering doesn't accurately convey the
semantic meaning of a header in documentation. It's not usually used to outline
a huge document with a hierarchy, e.g. h1, h2, h3. It's more often used to
break documentation into a few sections by category (with no hierarchy). For
this reason, smaller text - perhaps bold, perhaps underlined - would be more
appropriate and not feel as "shouty".
In addition, the huge heading shown in the screenshot seems to justify
additional padding following the heading, but it's uncomfortably close to the
succeeding line of text.
3. Increasing the document padding (as in 1, above) would help here. A bit more
space between paragraph elements would be useful. There's also a feeling of
cramping caused when the box is too small a proportion of the window to show
all the contents without horizontal scrolling, as in Bug 492090. I'd suggest
setting the maximum size to 50% of the text area width.
The popup box doesn't appear to respect the editor-wide "line height
multiplier" setting.
Additionally, I think it would be great to at least have the *option* to use a
different text size for popup boxes. Since these are more ephemeral, I think a
good default would be to use a size 1 pt smaller than is used for document body
text. But giving users more options on this would be good. Perhaps it would be
possible to even allow setting a CSS file, similar to how the LSP plugin window
accepts (and validates) JSON settings for the language servers. I'm not sure
how plausible implementing that is.
4. Primarily this concerns code objects that appear in body text, with
`backticks` in the Markdown source. Because all text rendered in the LSP plugin
popup uses the user's default font (presumably monospace), code presented in
backticks has no visual distinction. Perhaps setting a background color for any
code element in the popup would help distinguish these from the surrounding
text. If this were done, it would be more clear that bits of code with color
are intended to be clickable (*is* that the intent? I'm genuinely not sure).
Alternatively, a sans-serif font could be used for non-code in the popup?
Alternatively, anything clickable could be underlined. As things stand now,
clickable links aren't even underlined on hover.
SYSTEM INFORMATION
Operating System: Arch Linux
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.5-arch1-1 (64-bit)
Graphics Platform: Wayland
--
You are receiving this mail because:
You are watching all bug changes.
