Open LinuxOnTheDesktop opened 5 years ago
That's hard to do cross-platform. On Windows we already prefer Consolas, but on other platforms the Monospace font could be anything and no specific font is guaranteed to exist.
What OS / Desktop Env are you using? We already implement "Monospace" font family in the password field. There is a known bug on LXDE regarding fonts and Qt. https://github.com/keepassxreboot/keepassxc/issues/1771#issuecomment-375773730
https://github.com/keepassxreboot/keepassxc/blob/develop/src/gui/PasswordEdit.cpp#L34-L37
What OS / Desktop Env are you using?
I should have said: Linux Mint Cinnamon; and Cinnamon uses GTK for preference. I can provide some screenshots of 0s and Os if you like.
I just tried keepassxc today as a possible replacement for keepassx-0.4 and this was the first thing that struck me as "Unusable". openSUSE Tumbleweed and openSUSE Leap 15.0 This tool definitely needs a setting for a selectable font I compiled from git and added
<property name="font">
<font>
<family>Monospace</family>
</font>
</property>
to <widget class="QWidget" name="entryNotesTab">
in ../src/gui/EntryPreviewWidget.ui
Now keepassxc is much better usable for me
"Monospace" is not a font, it's a fallback name that could be anything. This points to a broken font config on your system and you should configure a different font as your default Monospace font.
KeePassXC respects that setting as long as Qt is made aware of what your Monospace font is:
I did, but I did not want to force my preferences onto the rest. My prefered fixed-width font = DejaVu Sans Mono
I'm using KUbuntu 19.04 and that has the default mono space font of 'Hack' this works fine in the Kate text editor but KeepassXC doesn't pick it up I'm not sure what font it's using see screenshot
It makes it difficult to tell the difference between I and l and O and 0
This is what Kate displays
P.S. I have version 2.4.3 using the AppImage
Kate's rendering of the zero seems somewhat strange and ugly but the rendering does satisfy the desideratum here. To wit: enable the user to distinguish the number zero from the letters 'o' and 'O'. Surely enabling the user to make that distinction is a basic prerequisite for a password manager.
Are you using the qt5ct "theme"?
I assume you mean the plasma theme? It's 'Breeze Dark'
This is probably a theme issue not passing the monospace font to Qt correctly. We request a monospace font in the password field.
I've tried this with a few different themes, KeepassXC gets the same font with all of them. Since it works with Kate and Konsole I'd assume the theme is doing it's thing correctly.
Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.
Any idea on how to debug further? It wouldn't be a terrible idea if keepassxc had an option to set a specific font.
On Fri, 11 Oct 2019, at 22:26, Jonathan White wrote:
Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/2741?email_source=notifications&email_token=AABFBI4KK5KM5YSKSCTLCLTQODVSBA5CNFSM4G2ECGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBIF5Y#issuecomment-541229815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFBI67H5PQ4T7Q7GHULETQODVSBANCNFSM4G2ECGLQ.
-- Regards
Rowan Wookey BSc (Hons) Comp, CISMP, MBCS Server Administrator & Programmer
Please add admin@rwky.net to your contacts/email whitelist.
Which release are you using? AppImage? Snap? PPA? Distribution-native packages (if so, what distribution)?
P.S. I have version 2.4.3 using the AppImage
The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.
The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.
For my part I don't think I was using the AppImage. I should have recorded whether or not I was in my original report. I cannot easily check now because, whilst keepassxc has its shutdown problem, I'm using KeePass under Wine.
I've tested on another machine and the app image is working fine, oddly enough the snap doesn't pick up the dark theme so doesn't look right but that's a separate issue.
Considering it works fine on one system I'd assume it's some weird problem local to the one machine and not a keepassxc problem.
That's what I've been saying :smirk:
👋 I'm here because today I mistook an S
for a 5
in a password.
(Screenshot is from v2.5.1, via Snap, Kubuntu 18.04, but I think the 5
vs. S
issue was worse on my Mac...)
One idea we might borrow from 1Password that I like is using a slightly different color for numbers -- maybe a green, to match the KeePassXC logo? This would help mitigate/bypass the font availability problem discussed above. Just an idea.
Edit: My particular use-case was reading a password from my laptop to input on a mobile device, something that I admittedly do infrequently.
KeePassXC - Version 2.5.1 Revision: 0fd8836 Distribution: Snap
Qt 5.9.5 Debugging mode is disabled.
Operating system: Ubuntu Core 18 CPU architecture: x86_64 Kernel: linux 5.3.0-23-generic
Enabled extensions:
Cryptographic libraries: libgcrypt 1.8.1
Using color alone isn't a wonderful differentiator, for accessibility reasons.
Perhaps every glyph/character should have an indicator or some sort, identifying its type (upper/lower case, number, non-"ascii") ... not necessarily all the time, but only when displayed in a context that means its likely the user will be manually retyping the phrase.
Here's an example, with the passphrase on one line and the glyph indicators on a second line, in the limited medium of text in markdown :-) so I get to avoid issues with variable-width glyphs and actual useable UI design ...
1lo0O⚬
NLLNU!
Number one, lower letter L, lower letter L, lower letter O, number zero, upper letter O, pictograph "o"
Using color alone isn't a wonderful differentiator, for accessibility reasons.
Ugh, sorry, I feel bad for not thinking about this. Thanks for your note.
Absolutely not my intention to make you feel bad - color isn't a bad indicator! Just not on its own, without other elements :-) You could argue in this case that as the color would only be providing a hint, and that we already had the actual content on display, it wouldn't be inappropriate.
Let me add a few observation, simply because I think there is a problem - and it hasn't been fully addressed !
[remark: the "monospace" setting in general settings changes sth, but it doesn't solve the problem]
For any user who cannot use autotyping or who's got to enter some passwords manually into his DB which where generated by another system (e.g. Apple's Timemachine) this is quite unsatisfactory. Best Regards
While trying out KeePassXC I missed the option to customize the font used for displaying the password(s). It's a feature I know from KeePass 2 (see screenshot below). Tools => Options => Interface (2)
Source Code Pro helps me to distinguish look-alike characters in passwords. In other situations/environments I prefer different (mono space) fonts.
Setup: KeePassXC 2.7.4 and KeePass 2.52 on Windows 10 22H2
You can change the default monospace font on windows in the registry: https://superuser.com/a/1567627 The font selection is a feature we are interested in adding though
The font selection is a feature we are interested in adding though
👍
I didn't find such a clear statement in the existing issues (so far it was rather about mono space in general or font size). Looking forward to see this in one of the future releases.
Source Code Pro helps me to distinguish look-alike characters in passwords.
You can use colored passwords for that since 2.7.2.
I'm seconding (tenthing?) this request. I understand that there are bugs that can prevent KXC from picking up the system's monospace font. But why use the system font to begin with? There's no guarantee that it has distinguishable characters.
IMO it's in a password manager's interest to either provide a good font, and/or allow the user to override it. It shouldn't depend on the system to provide it with a suitable font.
Thanks!
Just to add to this as I don't think my issue is a full "new" issue. the upper case i and lower case L look exactly the same in windows when you click to reveal the password on the entry edit screen. the font is good from the normal view, just not the edit view.
I don't care about picking my own monospace font, just for consistency in the editing view password field too. Like mentioned above, on Windows it's not monospace. Is there a separate issue for that?
Is this it? https://github.com/keepassxreboot/keepassxc/issues/7337 There looks to be a lot of confusion in both issue discussions.
For me, the issue is similar but different (#10277).
On my system, KeePassXC chooses a particularly badly readable font for monospace, with apparently no current workaround either for font type or size. OK possibly I could track down that offensive font and uninstall it or something.
On that note, it seems that KeePassXC, on my system, simply picks the first mono font from an alphabetic list of system font types. ...
That would be a Qt problem in your case since we simply ask Qt for the preferred monospace font.
That would be a Qt problem in your case since we simply ask Qt for the preferred monospace font.
Your comment got me thinking, and I dug into this.
It turns out that KeePassXC overrides the size of the monospace font requested from Qt with the size of the (non-monospace) system default font:
At least in my case, that leads to a monospace font rendering noticably smaller, and apparently with somewhat bad scaling artifacts on top.
In the specific case of Windows with Consolas, a similar issue is already being compensated:
(At least) on platforms where UI fonts can be completely arbitrarily chosen (e.g. Linux/KDE), such fudging/compensation attempts make no sense to me at all. Rather, it leads to much less 'surprise' to use the configured fonts as-is, which conveniently also enables existing mechanisms to override/configure those for specific, individual applications (which was my issue in #10277), e.g. via ~/.config/keepassxcrc
:
[General]
fixed=Droid Sans Mono Dotted,11,-1,5,50,0,0,0,0,0,Regular
I've drawn up the appropriate (trivial) patch, see the PR above.
I'm glad to see that there is interest in adding a configurable option for monospaced fonts. I recently switched from the original Keepass to KeepassXC to get around a growing number of UI issues with mono. XC Has been great so far, with usage of an inappropriate font for passwords being the only blemish.
I can confirm, as have others here, that the system monospace font is not used under KDE. Instead some other, unknown monospaced font is used in place of the default mono font. (KDE 6.1.5, KDE Framework 6.5.0, QT 6.7.2)
Summary
It seem to me that, unless I force an override via a global (DE) font setting, KeePass will use fonts that do not clearly distinguish the zero character from the capital 'o' character.
Desired Behavior
'0' and 'O' would be clearly distinguished, ideally via a font that puts a strike through the number.
Possible Solution
The app would have a setting for changing its font and, ideally, to a font that clearly distinguishes 'O' and '0' - and the app would advertise the point of this (that point being, that it is important for a password program so to do - for, sometimes, one will transcribe what one sees in the app - onto, for instance, a different device).
Context
Sometimes I transcribe from one device to another, i.e. from what I see in KeePassXC to e.g. my phone.