Re: Latest prerelease - <Control>1 crash

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: