On Wed, 2004-05-05 at 21:49, ext Soeren Sandmann wrote:
Tommi Komulainen <tommi komulainen nokia com> writes:Now, in practice I'm getting in trouble very quickly. 1. With the above naive implementation the context menu is popped up and it grabs the focus before the button-release-event is emitted. This apparently makes the widget miss the event and is left in somewhat inconsistent state. The effects are visible after dismissing the popup menu (releasing the grab.) With GtkButton this means that it's drawn in depressed state the next time the cursor hovers over the button. With GtkEntry it starts a drag. 2. If instead I fake a button-release-event before showing the popup menu GtkButton emits an extra 'clicked' signal, and the GtkEntry still starts a drag. Any hints, what am I doing wrong?Just a guess, but are you sure you are passing in the correct "button" and "time" parameters? I don't really see any other reason this should be different from the usual "pop up immediately when you press the button".
Yes, the button is the same as received in the 'button-press-event' event handler and time is GDK_CURRENT_TIME. I'm attaching my test program, I've managed to get it slightly more close to working. There is a small difference. When the menu is shown immediately, it is not so necessary to show the depressed effect - in the cases I've seen the 'button-press-event' handler stops the event and shows the context menu instead. However in this delayed case it would look awkward if the mouse button were depressed, but the GtkButton weren't, so I'm letting the event pass. After playing around a little more I noticed that if I generate the 'button-release-event' *after* the context menu is deactivated, I get rid of the false depressed state without the extra 'clicked' event. I'm still getting an extra drag from a GtkEntry, though. -- Tommi Komulainen <tommi komulainen nokia com>
Attachment:
popuptest.c
Description: Text Data