GtkWidget::scroll-event, though, is a RUN_LAST signal; it means that
the handlers connected using g_signal_connect() will run before the
class handler. on top of that, neither GtkWidget nor GtkEventBox have
a default class handler, so connecting to the signal is identical to
getting your callback c
On Thu, Jun 5, 2014 at 4:12 PM, Robert Schroll wrote:
>
> def eb_scroll(widget, event):
>print "Event Box scroll event"
>return True
> eb.connect('scroll-event', eb_scroll)
>
this connects after the default handler, not before it.
i don't know pygtk all that well; in gtkmm (the C++ bind
On Thu, Jun 5, 2014 at 2:34 PM, Paul Davis
wrote:
On Thu, Jun 5, 2014 at 2:11 PM, Robert Schroll
wrote:
So I guess my question becomes, how can a parent (the EventBox)
prevent a certain type of event (scrolling) from being delivered to
its children.
standard solution to such a question is
On Thu, Jun 5, 2014 at 2:11 PM, Robert Schroll wrote:
> So I guess my question becomes, how can a parent (the EventBox) prevent a
> certain type of event (scrolling) from being delivered to its children.
>
standard solution to such a question is "return true from its own
handler".
__
On Thu, Jun 5, 2014 at 1:19 PM, richard boaz
wrote:
instead of using GTK to route the events correctly, is it not
possible (possibly preferable) to route all events to your own
handler which you yourself can further negotiate and forward to the
necessary widget?
I hadn't considered that solu
On Thu, Jun 5, 2014 at 11:48 AM, Robert Schroll wrote:
> Consider a composite widget, say an EventBox with a whole hierarchy of
> children. Is there some way to make one type of event go directly to the
> EventBox, while others go through to the children? I'd hoped I could do
> this with set_
for what it's worth (i.e., without necessarily delving into all the
possible finer points):
instead of using GTK to route the events correctly, is it not possible
(possibly preferable) to route all events to your own handler which you
yourself can further negotiate and forward to the necessary wid
On Wed, Jun 4, 2014 at 11:19 PM, Paul Davis
wrote:
You should know that GTK's design more or less does not cater to
overlapping GtkWidgets. It is not completely clear if you are
actually doing this, but it certainly sounds as if you are. The API
allows you to create overlapping widgets, but no
On Wed, Jun 4, 2014 at 10:53 PM, Robert Schroll wrote:
> Hi all,
>
> I'm working on a Gtk project (3.10, Python 2 for the prototype, if that
> matters) using a Gtk.Overlay [1].
You should know that GTK's design more or less does not cater to
overlapping GtkWidgets. It is not completely clear if
Hi all,
I'm working on a Gtk project (3.10, Python 2 for the prototype, if that
matters) using a Gtk.Overlay [1]. The main child of the overlay is a
WebKit.WebView. The overlaid widget is a Gtk.EventBox that contains a
number of children, grand-children, etc. Right now, scroll events
outsi
10 matches
Mail list logo
