Lost input in quickfill cells due to race
herbert.thoma at iis.fraunhofer.de
Mon Jul 18 11:08:40 EDT 2011
On 18.07.2011 16:43, Christian Stimming wrote:
> Reverting your patch from May (r20689) will make this behaviour go away again.
> This is Ubuntu 10.10 with gtk-2.20.1. I don't want to revert your patch right
> away as I'm sure you had some other bugs that went away by your patch, but
> this particular other issue was introduced by it. (Unfortunately, it also went
> into the stable 2.4.6 already, so it needs to be fixed there as well...)
I can confirm that this bug also occurs on openSUSE 11.4 with gtk-2.22.1
> Do you have any ideas here?
> Am Dienstag, 24. Mai 2011 schrieb Jim Paris:
>> I've been looking at it some more and came up with the below fix,
>> which seems to work. The keyboard input ends up in the commit_cb
>> which calls gtk_editable_insert_text then gtk_editable_set_position.
>> It's the call to _set_position that clears the selection!
>> I think this might be a bug in GTK+, because gtk_entry_real_set_position
>> does this:
>> if (position != priv->current_pos ||
>> position != priv->selection_bound)
>> _gtk_entry_reset_im_context (entry);
>> gtk_entry_set_positions (entry, position, position);
>> The test is basically always true. I don't think that || was
>> intended: priv->current_pos is the start of the selection,
>> priv->selection_bound is the end of it. If the test were&&, then
>> an attempt to position the cursor at either end of the selection
>> wouldn't have cleared it.
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
Head of Video Group
Multimedia Realtime Systems Department
Am Wolfsmantel 33, 91058 Erlangen, Germany
email: tma at iis.fhg.de
More information about the gnucash-devel