Comment 8 for bug 1659229

su_v (suv-lp) wrote :

Patch from comment 6 (last version, 2017-01-26 19:43:10 UTC) tested with lp:inkscape/0.92.x r15346 on Ubuntu 14.04.5 LTS (GNOME desktop) and on OS X 10.7.5 (GTK+/X11):

1) Refactored code:
* Local tests [1] confirm so far that the refactored internal feature produces the same result as unpatched r15346 (the patch combines two separate code blocks which used in part duplicated code). The correlation between the new (and nested) radio choices and the numbering of the 'result' remains odd though AFAICT (and error prone I guess when edited later by other contributors): result 3 is radio choice 1 ("recommended"), result 2, 3 are radio choice 2_1, 2_2.
The refactoring of the internal logic should be reviewed code-wise by the original author (Tav).
* FIXME: console warnings when the dialog opens:
(inkscape:11741): Gtk-CRITICAL **: gtk_box_pack: assertion 'child->parent == NULL' failed
* TODO: re-test/clarify whether legacy guides/grids/3dboxes are intended to be converted/adjusted to user units as needed (internal detail) if the document is kept as is ('Ignore' in original dialog) - I did not pay attention to this aspect while testing the patch.

2) User information:
I understand that the text provided in the dialog is now discussed with UX experts and users on the 'inkscape-devel' mailing list. I will therefore refrain from commenting on the specifics, apart from aspects which are mentioned below in the notes about usability.

3) Usability:
Initial impression: The dialog based on the proposed patch feels a bit "over-engineered" with its multiple hidden sections and nested radio choices, slightly more complicated to use and (based on my experience during testing) more prone to wrong or unintended choices than the old one (with one checkbox, and three simple buttons):
* The effect of the current active choice for physical output can't be quickly grasped because there is too much text (of similar length and wording) for each choice: The user each time has to reassure herself whether the selected option is indeed the intended method. Memorizing which one was used last time when a affected file was opened may be difficult.
* The secondary level of radio choices (for physical output) should be indented one level, in correspondence with the logic/relation of the dialog's options.
* The nested structure of radio choices requires more action (more clicks) to access e.g. the feature labeled 'Scale elements' in the old dialog.
* Keyboard navigation is more complicated with the new dialog: the user has to focus attention entirely on the dialog, and remember where to use <Tab> and where cursor keys are required, and in which sequence.
* The label 'Convert' of the only remaining button is incorrect for the recommended "default" action (digital artwork for screen display) - the file is opened as is (no conversion happens).
* There is no "default" action to quickly proceed (with <Enter>).
* There is no defined behavior for 'Cancel' (<Esc>). Maybe Inkscape should cancel opening the file altogether, or - this needs to be discussed - open the file without any conversion (and without creating a backup file, independent whether that option is checked or not).

5) 'More details' section:
- The dialog window does not shrink back if the expanded 'More details' section is collapsed again.
- It is unclear which of the two bottom paragraphs in the expanded 'More details' section refers to which of the three radio choices in the upper part.
- Actual information (how the SVG file will be modified) is not provided in 'More details' section (set/modify the viewBox of the SVG file to adjust the length of the internal SVG user units as needed, or scale every individual object as needed, or do nothing).

6) Platform-specific issues:
* With some window managers/GTK+ backends, the dialog (original version as well as the patched one) may drop below the document window if the user accidentally clicks on the canvas area. Inkscape remains 'frozen' until the user discovers that there is a dialog pending input below the (usually maximized) document window to proceed to do actual work (based on tests this affects both the X11 and Quartz backend of GTK+ on OS X, but neither Windows nor Linux builds).
  This also affects e.g. the 'New from Template' dialog, but not the 'Import Clip Art' dialog - an indication that it can be "fixed"?

[1] There is no test suite available which automates opening legacy files and comparing visual appearance as well as precise (computed) values between expected and actual results. The tests I can offer are done manually, with legacy files used earlier to test the original internal dpi-change implementation,, inx-legacytext and the internal fix-pre-092 implementation for baseline spacing in legacy files.