Re: Latest prerelease - <Control>1 crash
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Tue, 7 Oct 2008 21:55:27 +1100
On Mon, 06 Oct 2008 17:46:13 -0500
Adam Krolnik <adam.krolnik@xxxxxxxxxxxxxxx> wrote:
>
> Here's with 1314.
> This only occurrs when having <Control>1 be double click.
>
> [DEBUG ] button binding cb begins: event-type: 4
> [DEBUG ] button binding cb ends
> [DEBUG ] _stroke_watcher_button_event_cb begins: event-type: 4
> [DEBUG ] _stroke_watcher_button_event_cb, UNWATCHED PRESS
> [DEBUG ] output button press cb
> [DEBUG ] _stroke_watcher_button_event_cb begins: event-type: 7
> [DEBUG ] current watch on widget
> [DEBUG ] _stroke_watcher_button_event_cb, nothing to do
> [DEBUG ] clear all gesture_watch's for a widget
> [DEBUG ] button binding cb begins: event-type: 4
> [DEBUG ] button binding cb ends
> [DEBUG ] _stroke_watcher_button_event_cb begins: event-type: 4
> [DEBUG ] _stroke_watcher_button_event_cb, UNWATCHED PRESS
> [DEBUG ] output button press cb
>
> Gtk-ERROR **: file gtktextview.c: line 5720
> (gtk_text_view_start_selection_drag): assertion failed:
> (text_view->selection_drag_handler == 0)
> aborting...
That 'assert' is the symptom of a problem. I looked into gtk 2.6.9, in
gtk_text_view_start_selection_drag() it has:
g_return_if_fail (text_view->selection_drag_handler == 0);
In gtk 2.10.14 and 2.14.3 (sources of which I happen to have here) and
presumably all between these and maybe some before, there is only this:
if (text_view->selection_drag_handler != 0)
return;
Of course this begs the question - why the bad interactions with normal
'drag-selection' process for GtkTextView. I've changed a couple of things in
svn, maybe it will be better now.
Regards
Tom
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
