Re: file selection interacting with drawing area

["Amadeus W. M." <amadeus84 cablespeed com>]

On Sun, 14 May 2006 15:42:22 -0500, Paul Davis wrote:

> 
> 
> Amadeus W. M. wrote:
> 
>>On Sun, 14 May 2006 11:25:13 -0600, Timothy M. Shead wrote:
>>
>>  
>>
>>>On Sun, 2006-05-14 at 12:42 -0400, Amadeus W. M. wrote:
>>>    
>>>
>>>>I have an unusual problem. I have a window (MainWindow) which contains a
>>>>drawing area (Darea) and some buttons. The user can draw various things
>>>>with the mouse. E.g. a segment is being drawn/updated continuously when
>>>>the user moves the mouse with button 1 pressed. The final position of the
>>>>segment is recorded when button 1 is released, so there is an
>>>>on_Darea_button_release() callback, which also draws the segment.
>>>>
>>>>Enter the file selection dialog. When the user selects a file by
>>>>double-clicking, the dialog terminates upon the second button PRESS. The
>>>>event immediately following the second button press is a button RELEASE,
>>>>but that's now caught by the Darea, because the file selector is gone.
>>>>Bad things happen: the Darea, of course, tries to store and draw a segment,
>>>>because on_Darea_button_release() has been called.
>>>>
>>>>What do I do?
>>>>
>>>>I'm thinking about introducing a
>>>>
>>>>bool loading_file;
>>>>
>>>>which is set to 1 when the file chooser is being popped up,
>>>>and inspected within on_Darea_button_release(): only draw/store the
>>>>segment if and only if loading_file=0; if loading_file happens to be 1,
>>>>set it to 0. Something like this:
>>>>
>>>>bool on_Darea_button_release(GdkEventButton * ev)
>>>>{
>>>>
>>>>    if(loading_file){
>>>>       loading_file=0;
>>>>       return 0;
>>>>    }
>>>>
>>>>    // if we've survived...
>>>>
>>>>    // set the segment from ev->x, ev->y.
>>>>    Darea.queue_draw(); 
>>>>    return 0;
>>>>}
>>>>
>>>>This seems awkward and prone to error though. Is there a more natural/Gtk
>>>>way?
>>>>      
>>>>
>>>I wouldn't make this conditional on the file dialog, since other
>>>dialog(s) added later may cause the same problem.  
>>>    
>>>
>>
>>That's exactly why I didn't like it.
>>
>>You just need to keep
>>  
>>
>>>track of whether you caught a button press event, and ignore the button
>>>release if you didn't - add an on_Darea_button_press() handler and set a
>>>flag there - then test it in on_Darea_button_release().
>>>
>>>    
>>>
>>
>>Yes, it's more robust to set the bool flag to 1 in
>>on_Darea_button_press_event(), rather than make it contingent upon the
>>file selection dialog. Then, in on_Darea_button_release_event(), just
>>return if the flag is not 1. But I can't avoid the flag thing, can I?
>>
>>  
>>
> You could set the sensitivity of your widget to button_press events in 
> your load file method.
> 
> But the more I think about this, the more I'm unsure if it'd work.
> 
> I'd go with the flag.
> 

He, he, that's the first thing I tried, as I thought it to be more
GTK-like. But if I restore the sensitivity of the Darea at the end of the
callback that pops the file selector, then the Darea IS sensitive upon the
second button release in the file selector. These are the events:

Darea->set_sensitive(0);

1st button press in file selector
1st button release in file selector
2nd button press in file selector - closes file selector

Darea->set_sensitive(1);  // at the end of the callback that popped the
file selector.

2nd button release - necessarily on Darea, as the file selector has just
vanished.

All this could be fixed if the file selection widget terminated upon
double button release, rather than on double button press.