Re: gtkmm custom widget problem
- From: Daniel Elstner <daniel kitta googlemail com>
- To: Trigve Siver <trigves yahoo com>
- Cc: gtkmm-list gnome org
- Subject: Re: gtkmm custom widget problem
- Date: Sat, 20 Jan 2007 03:09:24 +0100
Am Freitag, den 19.01.2007, 15:54 -0800 schrieb Trigve Siver:
> Hi,
>
> I have made custom gtkmm widget with embeded Ogre render
> window...everything is looking good except that I have some problem
> with motion event...I only get GdkEventMotion when I move my mouse
> pointer from OUTSIDE the GtkOgre widget TO GtkOgre widget and when I'm
> moving inside the widget I don't receive any motion event...BUT when
> I'm pressing the mouse button and moving with mouse inside GtkOgre
> widget I receive motion events...
>
> Anybody could help somehow?
Use
add_events(Gdk::POINTER_MOTION_MASK)
or
add_events(Gdk::POINTER_MOTION_MASK | Gdk::POINTER_MOTION_HINT_MASK)
in order to receive pointer motion events. If HINT_MASK is used, the
motion events are only hints, and Gdk::Window::get_pointer() has to be
called to receive further events. This has the advantage of avoiding
congestion if you can't handle the motion events fast enough. On the
other hand it involves a round-trip to the X server and thus adds
latency. You'll have to decide what's best for your application.
Preferably, the motion event handler should be able to deal with both
models. Here's a bit of sample code ripped from one of my projects:
bool CubeScene::on_motion_notify_event(GdkEventMotion* event)
{
reset_hide_cursor_timeout();
int x = TRACK_UNSET;
int y = TRACK_UNSET;
Gdk::ModifierType state = Gdk::ModifierType(event->state);
if (event->is_hint)
{
get_window()->get_pointer(x, y, state);
}
else
{
x = Math::clamp_to_int(event->x);
y = Math::clamp_to_int(event->y);
}
// Test both the event state and the more recent one from get_pointer(),
// so that we do not end up processing motion events before the initial
// button press event has been received.
if ((state & event->state & GDK_BUTTON1_MASK) != 0 && x != TRACK_UNSET && y != TRACK_UNSET)
{
// If the track position has been invalidated due to an allocation change,
// completely ignore any further button motion events until the next button
// press event. This avoids all sorts of problems due to the uncertainty
// of whether we will receive a button release event or not.
if (track_last_x_ != TRACK_UNSET && track_last_y_ != TRACK_UNSET)
{
process_track_motion(x, y);
track_last_x_ = x;
track_last_y_ = y;
}
}
return GL::Scene::on_motion_notify_event(event);
}
Hope this helps,
--Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]