GTK3: text options dialog too wide

Bug #1300275 reported by Andreas E. on 2014-03-31
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

The dialog to choose text/font properties is tooo wide if a font preview is longer than expected. The dialog is not resizable beyond that width. The minimum width is set to fit all font previews in full width, and in case a font preview is too long it is neither cropped nor wrapped.

This is a typical mistake in many gtk applications that is often left open until it causes issues. Exceeding dialog widths, min-widths and max-widths should better be considered already when designing a dialog, and all existing dialogs would better be reviewed that they are properly designed.

Inkscape 0.91.x, gtk3

su_v (suv-lp) wrote :

Reproduced with Inkscape r13242 in OS X 10.7.5 with GTK3 3.10.7.

tags: added: gtk3 ui
Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
summary: - text options dialog too wide
+ GTK3: text options dialog too wide
jazzynico (jazzynico) wrote :

Also confirmed on Windows XP, Inkscape trunk revision 12828 with the experimental GTK3 devlibs.

Changed in inkscape:
status: Confirmed → Triaged
jazzynico (jazzynico) on 2014-04-01
Changed in inkscape:
assignee: nobody → jazzynico (jazzynico)
status: Triaged → In Progress
jazzynico (jazzynico) wrote :

With the attached patch, the dialog's size is no longer constrained by the font family text size.
But it's still a bit too large due to either the buttons or the tree views.

Tested on Windows XP, Inkscape trunk revision 13248 with the official and experimental GTK3 devlibs.

Still working on it...

su_v (suv-lp) wrote :

> But it's still a bit too large due to either the buttons or the tree views.

Confirmed on OS X 10.7.5 with GTK+ 3.10.7 (Quartz, X11): with a small monitor, the minimal (fixed) width is too wide for a docked dialog (it is wider than the half of of the screen e.g. on a 13" MBP), and at the same time has lots of empty space in the style list and in the text widgets for font size, line spacing, text-on-path offset, whereas the font list has the previews cut off.

Thangalin (thangalin) wrote :
Download full text (3.4 KiB)

X-Post from the mailing list.


There are a number of issues with the Text and Font (Ctrl+Shift+T)
panel, including:

* Loading. Loading all system fonts can, in some cases, significantly
reduce application launch time.
* Memory. Loading fonts eats through memory.
* Performance. It can be sluggish to scroll through hundreds of fonts.
* Panel width. Long font names can cause the Text and Font panel (when
docked) to take up half of the drawing area.

The issues include:


I'd like to propose some cosmetic changes to the Text and Font pane
that could, perhaps, resolve all of these issues.

See attached (

1. Remove the word "font" (the tab menu gives context).
2. Add horizontal scrollbars to account for long names.
3. Add a Preview list box that shows the fonts in the view port for
the Family list box. This means that fonts don't have to be loaded
until the Family list box view port displays them. Rather than load
the fonts at startup, load them at runtime as needed. It's probably
reasonable to apply a micro delay (say 50ms) so that scrolling through
the Family list box is smooth and fonts are only loaded/rendered when
the user stops scrolling for 50ms. Remove the preview from the Family
list box.
4. Allow the user to provide custom preview text. Preview list box
should present this text. Put a reasonable limit (e.g., 30 characters)
on this. Perhaps this could be a select drop-down with various phrases
that show all the letters (e.g., "Grumpy wizards...", "...lazy dog",
"Cwm fjord...", "0123456789", plus a short history past user-defined
5. Allow the user to toggle the Preview list box. This could have a
significant performance increase for people who don't need to preview
all the fonts all the time. It could also save lots of memory.
Additionally, it would free up screen real estate as the panel width
would decrease by the Preview list box width.
6. Allow user to change font size and units. The size is shown as a
drop-down in the mock-up, but the user should also be able to type in
a specific size (e.g., 9.5) as per existing functionality.
7. Maybe allow the user to disable the scroll lock between the Family
and Preview list box areas so that they can vary independently.
Activating the lock automatically updates the Preview list box to
reflect the Family list box view port.
8. Provide beefier handles to resize the pane. Resizing it should
increase the height of the Family/Style/Preview list boxes, pushing
the options (justification, size, space, etc.) down. Clicking on three
tiny dots can be a daunting task for people with shaky hands...
9. Never disable the Set as Default / Apply buttons. If pressing the
buttons won't do anything, then fail silently. Otherwise, always let
the user click them and try to perform the appropriate action.


Tavmjong Bah (tavmjong-free) wrote :

Width problem appears to be fixed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers