I have the following code fragments:
win = new Gtk::Window;
m_canvas = new Goocanvas::Canvas;
sigc::connection conn_t1 = m_canvas->signal_event().connect( sigc::ptr_fun( &AnyEvent));
sigc::connection conn_t2 = win->signal_event().connect( sigc::ptr_fun( &WinHandler));
Now I also register an IdleHandler which generates signals:
Glib::signal_idle().connect( sigc::mem_fun( *this, &IdleSendEvent::Do));
What I want to achieve:
The handler of the canvas should receive an event and should generate a new one and this one should send to the object, so that it will call again the handler of the m_canvas->signal_event().
In other words: Indirectly via the Idle Handler the signal should be send to the sending object itself.
But if I fire to
g_signal_emit_by_name (m_canvas->gobj(), "button-press-event", event, &return_val);
the signal is not received in the canvas itself, but in some child objects there.
Q: How to emmit again to the canvas? Is there something like "get_the_parent_signal_object_handler_father_receiver" or something strange?
I did a lot of gtk_widget_get_parent_window() but all results in runtime errors like:
(go:15430): GLib-GObject-WARNING **: gsignal.c:3484: signal name 'button-press-event' is invalid for instance '0x9afbc48' of type 'GdkX11Window'
I simply have no idea where to find the correct instance which I have to emmit a signal which is then received for the canvas. It looks that the instance for g_signal_emit_by_name fires not to the object itself but all child instances. I can not find a documentation how the signals are processed and how the hierarchy can be walked through. One of the problems is that gtk+ and gtkmm are related but the documentation totally unclear and scattered.
You can't emit a signal to a particular object. You can only emit a signal from an object, that will be received by any signal handlers that are connected to that signal of the emitting object. Objects don't receive signals, only signal handlers do. (Although the signal handler may be, for example, a method of an object.)
The first argument of g_signal_emit_by_name() must be the emitting object.
To make a signal handler receive a signal, use g_signal_connect(emitter, signal_name, handler, user_data) or its C++ equivalent, sigc::signal::connect() as you have done in the example code above.
Related
I don't know what are Differences between connect() and connect_after() in pygtk. can someone explain this with an example code.
Thanks.
First, here is the definition for g_signal_connect_after:
Connects a GCallback function to a signal for a particular object.The
handler will be called after the default handler of the signal.
But what is the default handler you may ask, well, the GSignal description it's very descritive:
The basic concept of the signal system is that of the emission of a
signal. Signals are introduced per-type and are identified through
strings. Signals introduced for a parent type are available in derived
types as well, so basically they are a per-type facility that is
inherited.
A signal emission mainly involves invocation of a certain set of
callbacks in precisely defined manner. There are two main categories
of such callbacks, per-object ones and user provided ones. (Although
signals can deal with any kind of instantiatable type, I'm referring
to those types as "object types" in the following, simply because that
is the context most users will encounter signals in.) The per-object
callbacks are most often referred to as "object method handler" or
"default (signal) handler", while user provided callbacks are usually
just called "signal handler".
The object method handler is provided at signal creation time (this
most frequently happens at the end of an object class' creation),
while user provided handlers are frequently connected and disconnected
to/from a certain signal on certain object instances.
A signal emission consists of five stages, unless prematurely stopped:
Invocation of the object method handler for G_SIGNAL_RUN_FIRST signals
Invocation of normal user-provided signal handlers (where the after flag is not set)
Invocation of the object method handler for G_SIGNAL_RUN_LAST signals
Invocation of user provided signal handlers (where the after flag is set)
Invocation of the object method handler for G_SIGNAL_RUN_CLEANUP signals
The user-provided signal handlers are called in the order they were connected in.
Now that you know the signal sequence, what follows is the answer to a similar question but on the Gtk mailing list:
g_signal_connect_after will let you run your user handler after the
class's default handler; why is this usefull ?
Say I have an object that emits an "initialize" signal in which its
class handler does the work, you probably want your handler to run
after the class handler so that you can use the already initialized
object in your function.
I think normally you dont have to use this method because signals of
that nature are usually installed with G_SIGNAL_RUN_FIRST which; if
I'm not mistaken means that it's default handler will be called before
user handlers anyway.
Using it on higher level languages may not have an obvious need but, eg., lets say that you want to guarantee that a callback will be the last user callback to run, then you can use this method. (Note pygtk is deprecated, use pygobject).
A simple example where we connect two methods, on_click2 and on_click1 (by this order), by using connect_after for on_click2 we make sure that it will run last (user callbacks):
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
class Button(Gtk.Box):
def __init__(self, message):
Gtk.Box.__init__(self, spacing=6)
self.set_border_width(10)
button = Gtk.Button.new_with_label(message)
self.pack_start(button, True, True, 0)
button.connect_after("clicked", self.on_click2)
button.connect("clicked", self.on_click1)
def on_click1(self, widget):
print ("Click1 signal. connect normal");
def on_click2(self, widget):
print ("Click2 signal. connect after");
win = Gtk.Window()
button = Button("Test")
win.add (button)
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()
And the result is that on_click2 is the last to be called despite the fact it was the first connected:
$ python <filename.py>
... (Click test button)...
Click1 signal. connect normal
Click2 signal. connect after
If i have two SignalProducers (really they are API service requests so they only send 'next' once), and combine them with combineLatest (as i want to dismiss a loading spinner once both finish), what happens if one of them fails? Or both fail?
Does 'failed' get called (once or twice?) on the combined signal?
If one fails and the other succeeds, will 'next' be called on the combined signal?
Failure of any signal will cause the entire combined signal to error and stop subscription.
If one signal sends its first next and the other signal sends an error as its first value then the next will be lost, combineLatest: is only called once all signals send their first next value.
subscribeError: is only called once. Errors work in a monadic way where they bubble up the chain and stop the whole signal.
If you want to subvert this then you can use the catch:, catchTo:, or retry methods to handle errors.
(Sorry for talking about the Objective-C methods, I don't know the Swift syntax).
I am reading libpq reference. It has both of sync and async methods. Bu I discovered something strange.
When I see PQsendQuery function, it seems to send a query and return immediately. And I expected a callback function to get notified, but there was no such thing and the manual says to poll for data availability.
I don't understand why async method is written in polling way. Anyway, as libp is the official client implementation, I believe there should be a good reason for this design. What is that? Or am I missing correct callback stuffs mentioned somewhere else?
In the execution model of a mono-threaded program, the execution flow can't be interrupted by data coming back from an asynchronous query, or more generally a network socket. Only signals (SIGTERM and friends) may interrupt the flow, but signals can't be hooked to data coming in.
That's why having a callback to get notified of incoming data is not possible. The piece of code in libpq that would be necessary to emit the callback would never run if your code doesn't call it. And if you have to call it, that defeats the whole point of a callback.
There are libraries like Qt that provide callbacks, but they're architectured from the ground up with a main loop that acts as an event processor. The user code is organized in callbacks and event-based processing of incoming data is possible. But in this case the library takes ownership of the execution flow, meaning its mainloop polls the data sources. That just shifts the responsibility to another piece of code outside of libpq.
This page is describing how I can get be notified for async result fetch.
http://www.postgresql.org/docs/9.3/static/libpq-events.html#LIBPQ-EVENTS-PROC
PGEVT_RESULTCREATE
The result creation event is fired in response to any query execution
function that generates a result, including PQgetResult. This event
will only be fired after the result has been created successfully.
typedef struct {
PGconn *conn;
PGresult *result; } PGEventResultCreate; When a PGEVT_RESULTCREATE event is received, the evtInfo pointer should be cast to a
PGEventResultCreate *. The conn is the connection used to generate the
result. This is the ideal place to initialize any instanceData that
needs to be associated with the result. If the event procedure fails,
the result will be cleared and the failure will be propagated. The
event procedure must not try to PQclear the result object for itself.
When returning a failure code, all cleanup must be performed as no
PGEVT_RESULTDESTROY event will be sent.
Is there any way to monitor all signals emitted from a widget with GTK3? I know that the event signal is emitted before an event, but I'm not sure of the distinction between "event" and "signal" in GTK terminology - as this does not seem to capture all signals.
I know GDK has a function gdk_set_show_events but this mostly shows events which are sent to the window from the operating system. Is there a GTK3 equivalent?
There is not built in function AFAIK, but I'm sure you can hack something together yourself:
Use g_signal_lookup to get all signal ids for a gtype. Then use g_signal_add_emission_hook on each signal of your instance to register a hook to be called whenever that particular signal is emitted. Inside the hook function, you're provided with the signal id via *ihint, from which g_signal_query should provide you with all the information you need to print debug messages. (I didn't test it, but it should work)
Note that this will unfortunately not work for signals defined with G_SIGNAL_NO_HOOKS.
Use g_signal_lookup to get all signal ids
It's a little more complicated than described. In order to use g_signal_lookup, you first need a signal-name. If you want to monitor every signal independent of the object-type, you first need to list all signals of the specific instance-type. This can be arranged by g_signal_list_ids for exactly one single GType. To get really ALL signals emitted on the instance, you need to iterate over all parent-types of this instance. You can do this by using g_type_parent.
I have build some utility-functions by myself, that provide this functionality for the same debugging purpose the question was intended. You can connect an Emission-Hook for all signals of a GObject-instance with gemu_glib_util_connect_to_all_signals or connect an emission-Hook to a GtkWidget-instance and all its children with gemu_gtk_util_signal_connect_to_widget_children.
Will signals automatically disconnect, when target object is destroyed? Without recording the signal id from g_signal_connect(), can I remove that signal?
If you didn't save the signal handler ID, you can search for it using g_signal_handler_find() and disconnect it the usual way, or disconnect any signals that match certain criteria with g_signal_handlers_disconnect_matched() or g_signal_handlers_disconnect_by_func().
Of course when the target object is destroyed, the signals connected to it are removed (otherwise there would be a massive memory leak, but read the warning on g_signal_connect_object). However, to call g_signal_handler_disconnect you need the handler id given by g_signal_connect and friends.
You can use the *handler_block_by_func* and *handler_unblock_by_func* methods.
Example (PyGTK):
def on_treeview_fixedexpenses_cursor_changed(self, widget):
self.checkbutton_fixedexpensetax.handler_block_by_func(self.on_checkbutton_fixedexpensetax_toggled)
self.updateCurrentFixedExpense()
self.checkbutton_fixedexpensetax.handler_unblock_by_func(self.on_checkbutton_fixedexpensetax_toggled)
Source: http://www.pygtk.org/docs/pygobject/class-gobject.html