display is wrong when transforming by mouse

[Buliabyak-users]

In the "show object" (default) mode in selector, when
you transform an object by mousedrag, it is simply
scaled in its entirety. Thus the following modes are
not honored (the display is only restored when you
release mouse):

- not-scaling stroke width

- not-transforming pattern fills

- not-transforming gradient fills

- not-scaling rounded corners in rects

All of these except the last one can be fixed after we
decouple SPStyle from the renderer and add
compensations to the function that copies style
information to the renderer. The last one which is
basically the same as bug #165363 (sf848692) is probably not fixable.

[Buliabyak-users (buliabyak-users)]

Workaround: set selector to "show box outline". Make this
the default?

[Buliabyak-users (buliabyak-users)]

One more aspect of this bug is trasforming by mouse of a
selection containing both an original and dependent object:

Kees: bbyak: Create text at top of page (blow up to about 40
size). Draw circle in center of page (diameter = half page
width), move text off page to the left of the circle,
shift-select the path (to have both selected), text/put on
path, click again to get rotation handles, rotate 90
degrees, see 45.
(06:16:00) bbyak: it's a curious bug actually
(06:16:40) bbyak: one more aspect of the endless bug 969406
(06:17:19) bbyak: which is probably best fixed by removing
"show while transform" mode :)
(06:17:47) bbyak: or just leaving it as is, since it's
purely a display thing, no wrong data created
(06:18:15) bbyak: Kees: you may be surprised to know that
you actually rotated it by 45, not by 90 :)
(06:18:29) bbyak: so the end result after you release mouse
is correct
(06:18:48) bbyak: but the display _while_ you are dragging
is wrong, it doubles the angle
(06:19:48) bbyak: because text receives the rotation twice:
once by itself and once from its source path which is also
rotated
(06:20:01) bbyak: so it's shown as rotating with double speed
(06:20:34) bbyak: however when you release mouse, a special
check is made if you are transforming a textpath together
with its path
(06:20:42) bbyak: and if so, textpath is not transformed
(06:21:26) bbyak: so textpath becomes correctly rotated only
by 45, which is the real angle by which you rotated the circle

[Peter Moulder (pjrm)]

[Comment copied from dup bug 1095663]

Currently the compensation of stroke-width etc. is in
sp_item_write_transform, which is called only when writing
to the repr. (The functions that sp_item_write_transform
calls tend to call item->updateRepr().)
To provide the desired accurate previewing of stroke width,
I think we'd have a function like the current
sp_item_write_transform except without updating the repr(s).

There are a few areas where inkscape delays updating the
display until either an idle event or the mouse is released.
 Typically these are to improve responsiveness with large
drawings. I don't know offhand whether this is such a case.
 Eventually inkscape may become smarter at handling such
cases, though I'd guess people won't look at that for a while.

[Buliabyak-users (buliabyak-users)]

One more aspect of this bug: dragging text-on-path or linked
offset together with original moves the linked objects by
twice the distance while you drag (dup 1114747), though they
are repositioned correctly once you release the mouse.

[Ambrose Li (ambrose-li-cccgt)]

Package: inkscape
Version: 0.43-2
Severity: normal

When the "Scale stroke width" preference is disabled, the thickness of the line
segment *will* still vary when it is being scaled. When the user releases the
mouse, the line segment will suddenly return to the original thickness.

This is misleading (wrong) visual feedback for the user.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.28-ow1
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (charmap=BIG5)

Versions of packages inkscape depends on:
ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit
ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library
ii libc6 2.3.5-9 GNU C Library: Shared libraries an
ii libfontconfig1 2.3.2-1.1 generic font configuration library
ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib
ii libgc1c2 1:6.6-2 conservative garbage collector for
ii libgcc1 1:4.0.2-5 GCC support library
ii libgconf2-4 2.10.1-2 GNOME configuration database syste
ii libglib2.0-0 2.8.4-2 The GLib library of C routines
ii libglibmm-2.4-1c2a 2.8.2-2 C++ wrapper for the GLib toolkit (
ii libgnomevfs2-0 2.10.1-5 The GNOME virtual file-system libr
ii libgtk2.0-0 2.8.9-2 The GTK+ graphical user interface
ii libgtkmm-2.4-1c2a 1:2.6.5-1 C++ wrappers for GTK+ 2.4 (shared
ii liborbit2 1:2.12.4-1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.10.1-2 Layout and rendering of internatio
ii libperl5.8 5.8.7-10 Shared Perl library
ii libpng12-0 1.2.8rel-5 PNG library - runtime
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii libsigc++-2.0-0c2a 2.0.16-2 type-safe Signal Framework for C++
ii libstdc++6 4.0.2-5 The GNU Standard C++ Library v3
ii libx11-6 6.8.2.dfsg.1-11 X Window System protocol client li
ii libxft2 2.1.7-1 FreeType-based font drawing librar
ii libxml2 2.6.22-2 GNOME XML library
ii libxrender1 1:0.9.0.2-1 X Rendering Extension client libra
ii libxslt1.1 1.1.15-2 XSLT processing library - runtime
ii zlib1g 1:1.2.3-9 compression library - runtime

Versions of packages inkscape recommends:
ii dia 0.94.0-12 Diagram editor
ii imagemagick 6:6.2.3.6-3 Image manipulation programs
ii libwmf-bin 0.2.8.3-3 Windows metafile conversion tools
ii perlmagick 6:6.2.3.6-3 A perl interface to the libMagick
ii pstoedit 3.33-15 PostScript and PDF files to editab
pn sketch <none> (no description available)

-- no debconf information

[Wolfram Quester (wolfi)]

# Automatically generated email from bts, devscripts version 2.9.9
forwarded 345838 http://sourceforge.net/tracker/index.php?func=detail&aid=1399257&group_id=93438&atid=604306

[Ajashton (ajashton)]

With the not-scaling stroke width, this is not merely a case
of the display being wrong & the end result being fine. For
example:

- Create a small box (with some kind of stroke value).
- Add a guide & set snap to bounding box
- Scale the box, snapping it to the guide

Depending on your zoom level it may or may not be obvious,
but the end result it _not_ snapped to the guide (as would
be expected). Getting a stroked object to truly snap to a
grid or guide when scaling takes 2 or 3 transformations.

Setting the selector to show box outline does not solve this
problem.

It looks like you have an idea of what is causing this
problem - is the solution dependant on a future change (eg
Cairoification) or can a fix be found sooner?

[Buliabyak-users (buliabyak-users)]

ajashton: unsnapping and other distortions when scaling with
stroke were fixed a couple months ago in svn. That problem
had nothing to do with this bug.

[Tom Davidson (tjd-mit)]

ajashton and buliabyak: see bug 174046 for more on this tricky issue...

[Diederik van Lierop (mail-diedenrezi)]

Hi Tom,

It sure is similar in its symptoms, but this one is about the drawing of objects while transforming, whereas bug 174046 is about where the object ends up after snapping. I will solve the latter, but probably not this one.

[Alex Valavanis (valavanisalex)]

forwarded 345838 https://bugs.launchpad.net/inkscape/+bug/sf969406
thanks

[Beluga (buovjaga)]

Still repro.

Win 7 64-bit
Inkscape 0.91 r13725

[Adam Belis (adambelis)]

this is fixed in 1.1-dev (0b4651b, 2020-02-09

Closed by: https://gitlab.com/adambelis

[Diederik van Lierop (mail-diedenrezi)]

Are you sure Adam? This commit seems unrelated to this bug?

https://gitlab.com/inkscape/inkscape/commit/0b4651b