typing into height/width fields may call zoom shortcuts

[Donovaly]

To reproduce:

- open the attached SVG-file
- choose the blue rectangle that has a width of 220 and
  a height of 120
- set the cursor behind the "120,000" in the heigth
adjustment and mark the whole value "120,000"; but
assure that you don't click into the box before you
mark the value - mark the value directly when the
cursor is not already inside the box
- now change the value to e.g."2"
- do now the same for the width (mark the value in one
step from the back to the front and set the value to "2"

As result the zoom changes but the width is not
changed. If you now unchose the rectangle, the values
in the adjustments boxes will be correctly shown greyed
out, except of the width box whose value is still
displayed in black.

[Donovaly (donovaly)]

Other attachments

[Chris Mohler (cr33dog)]

This is still around in 0.47, and happens to me whenever I:

enter a width (say 200)
press [tab]
press a number (say 2)

[ScislaC (scislac)]

Reproduced with r11545 on Ubuntu Quantal using the test file

[su_v (suv-lp)]

> Chris Mohler wrote on 2010-05-27:
> This is still around in 0.47, and happens to me whenever I:
> enter a width (say 200)
> press [tab]
> press a number (say 2)

AFAICT bug #363000 is probably a duplicate of this one (see steps to reproduce in comment #4 there and below).

[John Smith (john-smithi)]

Fix committed to trunk as r11550.

[su_v (suv-lp)]

Looks like this could be backported to 0.48.x (needs testing).

[su_v (suv-lp)]

Testing r11550 (OS X 10.7.4, X11 backend):
with default gtk settings, it works as expected now.

However, with this gtk setting (via ~/.gtkrc-2.0):
  gtk-entry-select-on-focus = 0
pressing <TAB> after having typed a new width does not move the focus to the height entry, instead, focus is returned to the canvas (and typing a number may trigger a zoom shortcut). With that same gtk setting, tabbing (after 'Ctrl+A' and typing a new value) from X to Y, and from Y to W is ok, only the transition from W to H doesn't work as expected.

(Note: I'm aware that not selecting the content of the entry box when entering it is not a default setting - I only use it to prevent a crash when adding new layers (an unrelated bug limited to Inkscape using the Quartz backend of GTK+, probably upstream)).

[su_v (suv-lp)]

<off-topic>
> However, with this gtk setting (via ~/.gtkrc-2.0):
> gtk-entry-select-on-focus = 0
(…)
> I only use it to prevent a crash when adding new layers (an unrelated
> bug limited to Inkscape using the Quartz backend of GTK+, probably
> upstream))

Backtraces with trunk (Gtk2/Gtk3) in bug #528632.
</off-topic>

[su_v (suv-lp)]

John Smith wrote on 2012-07-15:
> Fix committed to trunk as r11550.

With r11550 and later revisions, dragging a slider on a tool controls bar produces these warnings (reproduced on OS X 10.7.4 and Windows (JazzyNico):

(inkscape-11550:52378): GLib-GObject-WARNING **: invalid cast from `GtkHScale' to `GtkEditable'

(inkscape-11550:52378): Gtk-CRITICAL **: gboolean gtk_editable_get_selection_bounds(GtkEditable *, gint *, gint *): assertion `GTK_IS_EDITABLE (editable)' failed

(backtrace with debug build (r11583) on OS X 10.7.4 using G_DEBUG=fatal_warnings attached)

[John Smith (john-smithi)]

Apologies for this regression warning.
Should be fixed in r11584.

[jazzynico (jazzynico)]

Fix confirmed on Windows XP, Inkscape revision 11600.

[Kris (kris-degussem)]

Backport was in revision 9910