Gtk+ FontSelection progress

I blogged before about my intention to rework the current font dialog. Máirín Duffy provided the initial designs, and I implemented a python prototype to toy with the design.

After a long while of stalled progress, I took my prototype, uploaded it to github, and started to iterate the design with the GNOME Design guys, (aday, lapo, jimmac, hbos…). After a few iterations we came up with something we all were happy with and I moved ahead to create a gtk+ branch. Here is the result so far:

Screenshot-Font Selection

Since I was using Gtk+ 2 for the original preview, I need to figure out how to get things right for 3.0 in terms of layout. However the functionality is pretty much there. I want to discuss a few API problems in the next Gtk+ meeting.

Here's a video of the current behaviour:



19 thoughts on “Gtk+ FontSelection progress

  1. Hi:
    (I admit I didn’t look the design from Marin)
    I have few points to raise:
    – I think the shape of the window should be reversed as it matches better the shape of the screen (That would permit to see more text in the preview)
    – The search field expect you know the font name; it should also match font properties.
    – Filtering should be possible (Sherif, …)
    Best Regards


  2. It would be useful if the font preview displayed the same “quick brown fox” text while making it editable by clicking the bottom preview and letting the application provide the default (for example the currently selected text or text in the target language).


  3. Hi.
    Please don’t forget about performance for users who have a lot of fonts! GIMP’s font tool also tries to render a preview of every variant of every font in a list view, and the result is nearly unusable even on fairly high end machines that have several hundred fonts (each with multiple variants) installed; trying to scroll through the list results in multi-second lag.
    At the very minimum, you need to have a separate thread for rendering the list view. (At the minimum because it wouldn’t help the users with single-core netbooks.)


  4. Editing the text used in the preview is a must-have, sometimes you want to choose fonts based on how it renders non-ascii characters like latin-1 or japanese.


  5. It could also be nice to be able to show only those fonts that are able to render all glyphs in the preview. For example, if type “日本語はすごい!”, I don’t want to see every font that displays a bunch of rectangles, or fallback to another font. Then a message would appear “You are seeing only the fonts that correctly display the preview text you typed.”


  6. There is a *really* thought through emacs functionality called I Do Things Interactively that handles completion very nice:
    So that if you have some really long names, which are common in fonts, and many similar ones, which is common in fonts, you simply can type some letters that appear anywhere in the thought of match, and it matches it up.. so say you have 1000 fonts starting with “bit”, 900 starting with “bitstream”, 800 variants of bitstream, and heck.. smack on a font size there too…
    b re serif 12
    Which would select the font that matches best, and set the font to size 12.. and bang, you would eliminate the need for a mouse completely, just type and bang that return key and you’re good to go.
    ouch.. Apple+W is not the way to cut text 🙂 chrome restore tab + keep last form edits ❤


  7. I know the original design means to simplify things, but I think in this case while it undeniably simplifies the GUI it also complicates the font selection process itself.
    Namely, the “one big list” approach is, more often than not, very tiring to the user. What really helps me when browsing through a large collection is when I am able to choose among simple categories that refine my search.
    While the search box is a good start for this, it is not sufficient. Rather, there should be some way to easily filter:
    1) serif/sans/handwritten/symbols(including math fonts)/etc – for when I’m looking for that serif that is “just right”. It would be nice if we could filter the results with a single click and see all serifs side-by-side.
    2) bold, italic, light, etc – to unpopulate the list a bit, making it easier to browse, it makes sense to separate the font family display from the style display. Of course, this is also useful when you’re looking for a good “ultralight” font, for instance, since ultralights are so sparse in the normal font set.
    What do you say?


  8. Congrats to keep this dialog up. It really needs love!
    What are the tiny marks below the size scale?
    Something that catch my eyes is the preview that seems very tight.
    Here are a few use cases I meet regularly:
    1) There are a few fonts I use regularly. I know how they look like I just want to select them quick. I remember the name approximately. I need no preview no long list. It is a very frequent use case, should be achievable trivially: click click done.
    2) I am using two fonts for this document. I frequently switch between them. Unfortunately their name are very distant alphabetically. I do not want to scroll back and forth the font list. With the current dialog, I end up copy/pasting pieces of text to reuse the formatting… :/
    3) There are (a lot of) fonts on my system I never use/select. Maybe web sites use them to display specific scripts. Or I just don’t like them. They just clutter the selection dialog. I don’t want to see them.
    4) I am doing a graphical work. I want to set the font for a title/headline/small text/etc. I need to try within various fonts. The preview is very important, especially for the specific text.
    5) I am writing a text using a specific script not very common, or set of characters. Which fonts include them?
    6) I want a font that includes bold, italic and bold/italic variants. I use it commonly for my text formatting.
    How a new design fulfill this use cases?


  9. Does it really have to be a dialog? Would making it an instant-apply window instead require an API change?
    (And +1 to everything luc said.)


  10. I complained about that on IRC, but you didn’t reply, so I’m going to repeat myself here.
    This is wrong and I can prove it: Just look at the search entry in your mockup. 🙂
    I think there’s two fundamental ways to interact with font selection:
    1) looking for a nice font to use
    2) changing the font to a specific one you have in mind.
    Your dialog spends 90% of its space on case (1).
    And I can understand how you ended with that design, because designers probably spend 90% of their font selection time looking for a great font. But I spend 90% of my time on the other use case: Selecting a specific font with a specific size. But then, I’m a programmer and I’m working on specific bugs. So both me and your designers will probably be heavily biased. You should find some real people and see how they select fonts. 🙂
    Then I do think you should find a way to group fonts, so that you can use the power of tree views to the full extent. Not sure how that would look, but lists of thousands of entries aren’t very navigatable for either of those two use cases…
    Last note: I often use the mouse only to select the specific font. The current font selector is way better at this then your design, if only for the fact that it has a list to select the font size from and does not use a spinbutton. (spinbuttons should die anyway)


  11. Most important omissions IMO:
    1) Editable text: “abcdefg…” doesn’t help at all when searching for a non-english font.
    2) Recently used fonts with remove option (like Nautilus’ bookmarks).
    3) Filter Bold, Oblique variants.
    And consider getting rid of the (vertical) scrollbar on the preview panel.


  12. I do agree with benjamin here. This font selection is simply unusable for test case 2 that appear’s to be my main font selection mecanism.
    This is not a good design. It just make font selection a pain in the *#*! Indeed, making font family mixed with font style makes the list so so big and messy. On the other hand, the font Size utility is a good job though.
    Font preview should’nt be axed on ascii. Today, if you are redesigning this kind of utility, you have to take foreign langages into account. So the text to be displayed should be easily customisable by allowing anyone to edit the text to be previewed.
    And remember, today, display’s are wider than in the past. It’s usual to have a 16/9 screen. Designing a font selection utility should’nt be oriented to use to much height.


  13. Looks like it still lacks the two best features from the OS X Font Selection dialog — the ability to create groups of fonts, and the ability to proportionally resize all fonts in the current selection (even if there are multiple sizes in the selection).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s