font-manager
font-manager copied to clipboard
FontManager
[Feature suggestion] Filter fonts (beyond filtering typefaces)
The filtering could be extended to finer granularity and work on individual fonts, beyond filtering typefaces (font families). See below; it shows a test collection with the DejaVu families.
wip-gtk4 contains some changes related to this.
I'll see if backporting is a possibility otherwise this will get punted to 0.9 milestone.
Unfortunately it looks like backporting is not going to be quick and easy.
The GTK 4 port is not perfect either but it does seem to already work better in this regard.
Sorry, but it'll probably be a while on this. Aside from serious bugs or quick and easy fixes the focus of development is now squarely on the GTK 4 port, so I'm punting this till that releases.
We can keep this open as a motivator.
Great! I'm looking forward to the GTK 4 release!
The following is not worth an issue of itself, imo:
The search field could be auto expanding with pane width to be very broad, or at least have a much larger fixed width. You'd get a fair gain in functionality for a small aesthetic cost.
To demonstrate with an example, users might want to see at a glance whether they are searching for
DejaVuSansMono Nerd Font Mono Bold, or for
DejaVuSansMono Nerd Font Mono Bold Oblique,
but now see only truncated bits from DejaVuSansM to old Oblique. And there may exist even longer font [family] names or character widths.
The search field could be auto expanding with pane width to be very broad, or at least have a much larger fixed width. You'd get a fair gain in functionality for a small aesthetic cost.
Well, aesthetics are important, not as important as function of course but still an important consideration.
To demonstrate with an example, users might want to see at a glance whether they are searching for DejaVuSansMono Nerd Font Mono Bold, or for DejaVuSansMono Nerd Font Mono Bold Oblique, but now see only truncated bits from DejaVuSansM to old Oblique. And there may exist even longer font [family] names or character widths.
I'm not sure searching for that long and detailed of a string is a very common scenario. At least not common enough to justify making the search entry larger.
In any case, the GTK 4 port will allow for matching chunks so that should prevent such overflow without making the search field huge at all times and still allow you to drill down pretty far. ;-)
Well, aesthetics are important, not as important as function of course but still an important consideration.
Not arguing with that. Decades with macs as main production machines (I'm migrating right now) made me appreciate a well thought out design and user experience very much. But also, that sometimes ease of function > good looks. I'm very happy to see both in the upcoming versions.
I'm not sure searching for that long and detailed of a string is a very common scenario. At least not common enough to justify making the search entry larger.
In any case, the GTK 4 port will allow for matching chunks so that should prevent such overflow without making the search field huge at all times and still allow you to drill down pretty far. ;-)
The best of both worlds. Thanks for the time you took to explain!
I'm closing this out now as it's been completed in the WIP branch for a while now and will be part of the next release.
Thanks again.