Lost input in quickfill cells due to race

[Herbert Thoma]

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?
>
> Regards,
>
> Christian
>
>
> 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
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>

-- 
Herbert Thoma
Dipl.-Ing., MBA
Head of Video Group
Multimedia Realtime Systems Department
Fraunhofer IIS
Am Wolfsmantel 33, 91058 Erlangen, Germany
Phone: +49-9131-776-6130
Fax:   +49-9131-776-6099
email: tma at iis.fhg.de
www: http://www.iis.fhg.de/