UI: Compact layout for Document Properties (0.92)

Bug #1510831 reported by su_v on 2015-10-28
This bug affects 10 people
Affects Status Importance Assigned to Milestone
inkscape (Debian)
Fix Released

Bug Description

The minimal size (width, height) of the Document Properties dialog has grown with each of the past releases, and current trunk features a rather huge dialog window, which - for the 'Page' options - expands beyond screen height e.g. on a 13-inch laptop monitor, even with a moderately small font size for Gtk+.

Attached are screenshots of the dialog in
- Inkscape 0.47 (Clearlooks-based theme),
- Inkscape 0.48 (Adwaita GTK2),
- Inkscape 0.91 (Adwaita GTK2) and
- current trunk (0.91+devel, Adwaita GTK2)
for comparison.

The minimal width seems to have increased due to
1) additional tabs (metadata, license)
2) new options for the viewBox scale
   (the text at the end: "User units per $(display_units)")

The minimal height is increased due to
1) additional viewBox options
2) viewBox scale help text displayed in-line
   (as opposed to a tooltip)

Unused empty space in the other tabs has increased a lot.

Compacter layout so that all options are accessible even on smaller screens, and unused empty space in all pages is minimized.

Help for translators to keep the dialog at a moderate size: A dialog designed with a portrait proportion in mind should not be wider than half the screen width, nor expand beyond the screen height. If this can't be guaranteed, maybe the dialog needs to be reorganized with a landscape orientation (with tabs on the left, using constraints for the length of the labels).

Note: For a future GTK3-based release, the dialog will likely require a different redesign due to the large padding of the tab labels enforced with the built-in default theme of GTK3 (Adwaita) - this increases the dialog's minimal width even further, along with rather disproportional spacing and/or expanding of the widgets within the individual pages of the notebook.

There are later reports filed about the same issue, which possibly will lead to workarounds being committed to the current stable release branch lp:inkscape/0.92.x. Current proposals in other reports are
a) making the (by default undocked) dialog in itself scroll-able:
Bug #1655321 “undocked Document Properties dialog too tall, not resizable”
b) reducing minimal height by moving explanatory text to a tooltip:
Bug #1666098 “Document Properties dialogue is too large to use - buttons off-screen”

Tags: ui Edit Tag help
su_v (suv-lp) wrote :
su_v (suv-lp) wrote :
su_v (suv-lp) wrote :
su_v (suv-lp) wrote :
ScislaC (scislac) on 2015-10-28
summary: - UI: Compacter layout for Document Properties (0.92)
+ UI: Compact layout for Document Properties (0.92)
Alvin Penner (apenner) wrote :

confirmed on Windows XP, Inkscape rev 14391

a major contributor to the excess width is the side by side presence of Scale X and Scale Y. Given the fact that Scale Y has been disabled, it should be removed entirely. There is no point in having a setting available, when there is no intention of ever using it.

Changed in inkscape:
status: New → Confirmed
jazzynico (jazzynico) wrote :

Note that the French translation is not finished yet, and that things are going to be worse when it's done...

Changed in inkscape:
status: Confirmed → Triaged
jazzynico (jazzynico) wrote :

The "Scale Y" entry or the "User units per mm." text could also be moved to a different line.

jazzynico (jazzynico) wrote :

Attaching a patch to hide (but not remove from the code) the Scale Y option.
Please test and comment.

jazzynico (jazzynico) on 2016-05-23
Changed in inkscape:
assignee: nobody → jazzynico (jazzynico)
status: Triaged → In Progress
Alvin Penner (apenner) wrote :

patch tested successfully on rev 14907. I would suggest applying it to trunk.
attached is a screenshot comparing the before and after dialogs.

On 2016-05-23 22:55 (+0200), Alvin Penner wrote:
> I would suggest applying it to trunk.

As long as the report is not closed as "fixed" [1], why not ... OTOH I
do wonder though whether this is a meaningful reduction of GUI options
just for the sake of reducing the minimal width of the dialog: if
explicitly chosen by the user via custom values for the viewBox, the
intentional removal of the potientially different y scale factor from
being displayed in the GUI could be quite misleading (doesn't allow to
verify the effect of the custom viweBox values). If this entry (y scale)
is removed from the GUI, should the user still be allowed to introduce
non-uniform scaling via custom viewBox values at all via GUI, or be
forced to apply such a change only via XML Editor? ... Or should the
y-scale information be moved into the expandable section with the
viewBox values? Also, what about the 'preserveAspectRatio' attribute for
the top-level SVG element? Currently, there is no GUI for this attribute
of the top-level SVG element; AFAIU its presence (and its 'align' value)
in the end define whether the content is scaled uniformly or not.

[1] The proposed patch AFAICT won't help with the dialog height: it
still does not fit on small screens, while the other tabs have lots of
empty (vertical) white space. In order to not stall a soonish release of
0.92, converting the comment explaining the details for the scaling via
viewBox values to a tooltip might be applied as a companion workaround
(just that - it does not replace an overall redesign of the dialog
IMvHO); this could at least somewhat ameliorate the issues with the
overly large minimal height of the dialog (the absolute minimal height
of course depends on the GTK2 theme (latest Adwaita GTK2 from 3.20 has
yet again increased the minimal size of a lot of widgets to reduce the
visual differences to GTK3's default built-in Adwaita theme) and the
default font size for the desktop (or just the GTK+ apps). Note that
increasing the height of the expandable 'ViewBox' section (e.g. for the
y-scale, or the text explaining the options for document scale factors)
does not help long-term because the dialog's height does not shrink back
after collapsing those sections again (potientially leaving portions of
the dialog (at the bottom) off-screen and inaccessible on small monitors).

Alvin Penner (apenner) wrote :

warning, rant coming.

the problem that I have with the 'scale Y' display field in the Document Properties Dialog is that the information that is presented in this field is either wrong or misleading or both. Therefore it should not be there at all. This can be seen as follows:
attached is a drawing with a rectangle 200x200 mm. The viewbox is the default A4 viewbox (210x297) and the document properties shows the X scale and Y scale = 100% as expected.

Alvin Penner (apenner) wrote :

now we go through a uniform scale in this drawing by changing the view box to be 420x594. The document properties shows the X scale and Y scale are both 200% as expected. And the rectangle is half the previous size as expected.

Alvin Penner (apenner) wrote :

now we go through a non-uniform scaling by using a viewbox of 420x297. The document properties shows the X scale is 200% as expected and the Y scale is 100% as expected. However the actual rectangle that is shown on the screen is still 100mmx100mm, the same as it was in the previous uniform scaling case.

This suggests that the code for performing non-uniform scaling does not even exist, or that it has been deliberately disabled. If the code does not exist then we should not present a user-interface that suggests that it does exist. This is, at best, misleading, and at worst simply wrong.

jazzynico (jazzynico) wrote :

Well, the goal of the patch was not to close the report, but act as a temporary workaround until the whole dialog is correctly redesigned. I first supposed that the Y scale was completely unnecessary because it's always disabled (or at least I never saw it enabled), but apparently it's not that easy.

If no consensus can be reached about it, I suggest we just forget the patch and focus on the original report instead.

Changed in inkscape:
assignee: jazzynico (jazzynico) → nobody
assignee: nobody → jazzynico (jazzynico)
status: In Progress → Triaged
Alvin Penner (apenner) wrote :

sorry, perhaps I spoke too vociferously...
I still think that this patch should be applied, just as a temporary measure, since it would be very helpful to have this in place for 0.92.

The underlying issue, namely, non-uniform scaling, is an extremely serious issue which is not going to be resolved any time soon, if ever, and we should not wait for it to get resolved. (For example, the rendering produced by IE11 is identical to Inkscape rendering, meaning the 'deficiency' is not just in Inkscape itself, meaning we could be waiting years for this to get resolved.)

su_v (suv-lp) wrote :

@Alvin - you need to set 'preserveAspectRatio' to 'none' explicitly to enforce non-uniform scaling (as mentioned, Inkscape has no GUI for it, but if the attribute is set accordingly, Inkscape does respect it for rendering).

For details, see SVG 1.1. spec.

Alvin Penner (apenner) wrote :

okay, I'll give that a try sometime soon.

In the meantime the question still remains: what is the probability that these UI issues are going to be satisfactorily resolved within the near future, in time for the release of 0.92? In my opinion the probability is near zero (given the fact that the original commit, 14022, was made more than a year ago). So I think we should go ahead with a temporary patch as above, rather than waiting for the various associated issues to get resolved.

jazzynico (jazzynico) on 2016-05-30
Changed in inkscape:
assignee: jazzynico (jazzynico) → nobody
jazzynico (jazzynico) on 2016-08-29
Changed in inkscape:
milestone: 0.92 → 0.93
Jabiertxof (jabiertxof) on 2017-01-25
Changed in inkscape:
assignee: nobody → Jabiertxof (jabiertxof)

The easiest way to use available screen space is to use a two-colum layout when is viable, as you can see in this mockup I made combining the page background color settings and the page border settings in a signle row (UI text is in spanish).

Also, a way to collapse/hide the clarification text about the new measurement details regarding CSS rules in ver.0.92 would allow the user to scale down the window even more.

Jabiertxof (jabiertxof) wrote :

Gracias Rolando. Buena idea!

su_v (suv-lp) on 2017-02-27
description: updated
Jabiertxof (jabiertxof) wrote :

Here is a patch with the Rolando idea.

Jabiertxof (jabiertxof) wrote :

the patch is for 0.92.x, needs to make another for 0.93. Here is a pic working. Not tested on 0.92.x GTK3

jazzynico (jazzynico) on 2017-04-02
Changed in inkscape:
status: Triaged → In Progress
Changed in inkscape (Debian):
status: Unknown → Confirmed
Phil Wyett (kathenas) wrote :

I can confirm the patch in #21 fixes the issue in inkscape 0.92.1-1 on debian stretch (9).

Jabiertxof (jabiertxof) wrote :

Merged on 0.93 on r.3de5a80d68..c1b8f8c0e6

Jabiertxof (jabiertxof) wrote :

Git patch for 0.92.x

Phil Wyett (kathenas) wrote :

Though the patch does work. If you expand other elements within the properties page, the page will extend beyond bounds and when you collapse the element expanded, it will not return to normal.

See attached video.

Jabiertxof (jabiertxof) wrote :

@kathenas: The only way to avoid this is make this dialog non resizeable. Is the same problem on the DPI change dialog. And I can be sure of it so:
Is ok make this dialog non resizeable?

Thanks in advance for the feedback.

Changed in inkscape:
status: In Progress → Fix Committed
Phil Wyett (kathenas) wrote :

@jabiertxof I do not mind it being non re-sizeable. If you put forward a patch that makes it this way, then people can test and give feedback.

Jabiertxof (jabiertxof) wrote :

I just commit a non resizeable dialog to master on r.a7754fdc. I hope I can commit soon to 0.92.x

Jabiertxof (jabiertxof) wrote :

Fix Commited in r.6f979756a7 of 0.92.x

Phil Wyett (kathenas) wrote :

Applied the series of two patches and the situation is much better when expanding sections and then collapsing them. See attached video to see in action.

Patrick Storz (ede123) wrote :

Three more mostly redundant bugs asking for a resizable dialog: bug #1713946

@Jabier (and everbody else):
With the 0.92.3 release coming up - do you think the changes in 0.92.x are sufficient at this point or is the dialog still problematic?

Mc (mc...) on 2018-03-05
Changed in inkscape:
milestone: 0.93 → 0.92.3
Changed in inkscape (Debian):
status: Confirmed → Fix Released
Bryce Harrington (bryce) on 2018-05-12
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.