Bug 4013 - "Menu path" font size in Hotkeys tab is too small
Summary: "Menu path" font size in Hotkeys tab is too small
Status: RESOLVED FIXED
Alias: None
Product: clawsker
Classification: Unclassified
Component: default (show other bugs)
Version: 1.0.1
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-04-20 10:52 UTC by George
Modified: 2018-07-15 20:38 UTC (History)
0 users

See Also:


Attachments
screenshot (116.95 KB, image/png)
2018-04-20 10:52 UTC, George
Details
Font change (152.52 KB, image/png)
2018-07-15 19:00 UTC, Ricardo Mones
Details
My screenshot (251.97 KB, image/png)
2018-07-15 20:38 UTC, George
Details

Description George 2018-04-20 10:52:17 UTC
Created attachment 1866 [details]
screenshot

The font size of the contents of "Menu path" column in Hotkeys is too small. The Hotkey column shows correct size (as per KDE's default font).
Comment 1 Michael Schwendt 2018-04-20 11:48:22 UTC
What is your screenshot supposed to demonstrate?
Comment 2 George 2018-04-20 11:57:09 UTC
That the font size in the left column is smaller than everything else in the UI.
Comment 3 Michael Schwendt 2018-04-20 12:05:11 UTC
Your ticket title claims it would be "too small". The screenshot doesn't confirm that. That it is smaller is intentional. In your screenshot it is much bigger than with default GNOME Shell, for example.
Comment 4 Paul 2018-04-20 12:07:04 UTC
It's intentional.
Comment 5 George 2018-04-20 15:22:08 UTC
I understand this may be subjective but on a 108dpi screen it is too small. The "normal" font is Noto Sans 10. I don't know why it is intentional but keeping something deliberately hard to read is not good, especially considering the available (now wasted) space on the right side.
Comment 6 wwp 2018-04-20 16:10:18 UTC
It's maybe intentional, but it only shows lazy programming here. We should either use the same size and allow resizing or column (or resize automatically or use a scrollbar), or make the font size proportional to the DPI, instead of hardcoding it. Here on a 1920x1080 screen 96DPI, the font size is OK but because I'm an eagle-eye one, increase the DPI or use poorer eyes and it's not OK at all. Or close as WONTFIX if you don't want to fix.
Comment 7 Ricardo Mones 2018-04-23 09:31:18 UTC
(In reply to comment #6)
> It's maybe intentional, but it only shows lazy programming here.

Won't say the opposite... :-)

> We should either use the same size and allow resizing or column (or resize
> automatically or use a scrollbar)

It already resizes automatically. The intention was to distinguish somehow labels from hotkeys, which can't be done using same size (and bold and italic did't look very well to my eyes).

>, or make the font size proportional to the DPI, instead of hardcoding it.

That can be done using Pango markup, which is my preferred option so far, though still have to test it on a high-DPI display.

> Here on a 1920x1080 screen 96DPI, the font size is OK but because I'm an
> eagle-eye one, increase the DPI or use poorer eyes and it's not OK at all.

Crazy-horse agrees with Eagle-eye: fixed size not OK for white man :-)

> Or close as WONTFIX if you don't want to fix.

I'd keep that card for future fixes harder than this one ;-)
Comment 8 George 2018-04-23 10:09:54 UTC
> The intention was to distinguish somehow labels from hotkeys

They are already distinguished by the left alignment of both columns.

If I may suggest:

- Make the font the same size
- Bold the lines with assigned hotkey
- Replace "Disabled" with empty to make it easier for the eye to see the actual shortcuts
- Make columns sortable, e.g. clicking on "Hotkey" to sort the hotkeys
- Currently it is possible to assign the same hotkey to different actions. Create a warning when duplicate hotkeys are assigned suggesting to either swap the assignment or cancel it.

Do any of these need a separate bug/enhancement report?
Comment 10 Ricardo Mones 2018-07-14 15:26:37 UTC
(In reply to comment #8)
[…]
> - Replace "Disabled" with empty to make it easier for the eye to see the
> actual shortcuts

That string comes from GTK+ itself, is not set by clawsker. If you have pointers on how to change it I'll be glad to read them and see if it can be done easily.

[…]
> Do any of these need a separate bug/enhancement report?

Yes, they have nothing to do with this report. Some were already planned (warning about duplicates for example), but feel free to add them here and/or provide patches for fixing them.
Comment 11 George 2018-07-15 08:18:14 UTC
I pulled git://git.claws-mail.org/clawsker.git and compiled it.

The issue remains.
Comment 12 Ricardo Mones 2018-07-15 19:00:25 UTC
Created attachment 1890 [details]
Font change
Comment 13 Ricardo Mones 2018-07-15 19:03:58 UTC
(In reply to comment #11)
> I pulled git://git.claws-mail.org/clawsker.git and compiled it.
> 
> The issue remains.

You don't need to "compile" it to test the fix, just run the updated clawsker, so not sure what are you seeing.

As you can see in attachment just uploaded the font is larger than before, and it's just the small GTK+ font.

If you can't read that font I'd suggest you to increase your desktop font size, because small font is derived from normal font by GTK+ and also used in other programs (Claws Mail itself for example).
Comment 14 George 2018-07-15 20:38:43 UTC
Created attachment 1891 [details]
My screenshot

Here is a screenshot from me too. I don't see any change in font size.

> If you can't read that font I'd suggest you to increase your desktop font size

In KDE Plasma my "General" font is Noto Sans 10. "Small" is Noto Sans 8, "Toolbar" is Noto Sans 9. I don't see such small font like in Clawsker anywhere in Claws Mail (and as a whole - in any other program). Are we talking about the same thing?

Note You need to log in before you can comment on or make changes to this bug.