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.
Related
OK, I've been struggling with this for a while. What is the best way to accomplish the following:
where Reaction Wheel 1-4 are links to the same block in a library. When the Speed Counter, Speed Direction and Current signals are added to the final bus output as shown, MATLAB (rightfully) complains:
Warning: Signals 9, 10, 11, 12 entering Bus Creator
'myAwesomeModel' have duplicated names 'Current'. These are being made unique
by appending "(signal #)" to the signals within the resulting bus. Please
update the labels of the signals such that they are all unique.
Until now I've been using a "solution" like this:
that is, place a size-1-mux/gain-of-1/other-dummy block in the middle, so the signals can be renamed into something unique. However, I really like to believe that The MathWorks has thought of a better way to do this...
What is the "proper" way to construct bus signals like this? It feels rather like I'm being pushed to adopt a particular design/architecture, but what that is precisely, eludes me for the moment...
It was quite a challenge for me but looks like I kinda sorted it out. Matlab R2007a here. I'll do the example with an already done subsystem, with its inputs, outputs, ...
1- In Block Properties, add a tag to the block. This will be done to identify the block and its "siblings" among the system. MY_SUBSYSTEM for this example.
2- Block Properties again. Add the following snippet in CopyFcn callback:
%Find total amount of copies of the block in system
len = length(find_system(gcs,'Tag','MY_SUBSYSTEM'));
%Get handle of the block copied/added and name the desired signal accordingly
v = get_param(gcb,'PortHandles');
set(v.Outport(_INDEX_OF_PORT_TO_BE_RENAMED_),'SignalNameFromLabel',['BASENAME_HERE' num2str(len)]);
3- In _INDEX_OF_PORT_TO_BE_RENAMED_ you should put the port signal index (starting from 1) that you want to have renamed for each copy of the block. For a single output block this should be 1. BASENAME_HERE should be the port basename, in this case "Current" for you.
4- Add the block to the desired library, and delete the instance you used to create this example. From there on, as you add from the library or copy an existing block, the outport should name Current1, Current2, Current3, and so on. Notice that you could apply any convention or formatting.
Hope this helps. It worked for me, don't hesitate to ask/criticize!
Note: Obviously, as the model grows, this method may be computer-demanding as find_system will have to loop through the entire model, however looks like a good workaround for me in small-medium sized systems.
Connect a Bus Selector to each Data Output. Select the signals you want and set "Output as bus". Then connect all Bus Selectors to a Bus Creator.
simulink model
In the past, I have used libraries that would allow me to register a callback so that the library can call my method when some event happens (e.g. it is common to see in code that use GUI libraries to look like button.onClick(clickHandler)).
Naively, I suppose the library's handling mechanism could be implemented like:
while(1){
if (event1) { event1Handler(); }
if (event2) { event2Handler(); }
...
}
but that would be really wasteful right? Or is that really how it is done (for instance do well known GUI libraries like java swing, or GTK+ do it this way)?
background:
This question hadn't really occured to me until I encountered curses. I thought about implementing my own callback system, until I realized I didn't know how.
The while loop will typically wait for an interrupt from the user (GetMessage in Windows). When an interrupt arrives GetMessage returns and then it ends up in the callback function. The if statements are typically implemented as a switch-case. See Windows Message Loop on Wikipedia.
In more detail, what happens is the following:
The user application calls GetMessage, which forces the process to sleep until an input message for that application arrives from the systems queue. When a message arrives, the user app calls DispatchMessage, which calls the callback function associated with the window that the message was aimed at.
Windows API uses one callback which handles all events in a switch case. Other libraries use one callback per event class instead.
The function pointers themselves are stored together with other window data in a struct.
Callback system implementation probably has different implementation in different technologies, however, I suppose they should be working this way:
A data structure stores the callback IDs and pointers to the handlers.
A callback handler has a validator
Event handlers have callback callers, which know what are the possible callbacks and check their validity this way:
for each callback in event.callbacks
if (callback.isValid())
call callback()
end if
end for
When you add a handler to a function the system will automatically know where the callback is valid and will add the callback to the datastructure described in 1.
Correct me if I'm wrong, this description is just a guess.
Simple question:
I've added some scales (sliders) to my window, and I want to call a method when you move the scale.
What is the signal name that I use for gtk_signal_connect?
ie I should be able to write something like:
gtk_signal_connect(GTK_OBJECT(my_scale), "scale_moved", (GtkSignalFunc)my_event, data);
or am I missing something here?
And more importantly - how do I find out in the future what the signal names are? for example - I googled 'gtk_signal_connect' but I didn't find a big list of different signals.
Similarly, I didn't find details about related signals in the GtkScale documentation. (Well, in this page, there is a single signal detail, but it relates to changing the displayed value format).
GtkScale inherits from GtkRange, and signals are inherited in GTK+. Therefore, you can connect to the value-changed signal exposed by GtkRange.
You're on the right track to find the signals exposed by a given GTK+ widget: besides the source code itself, the documentation is indeed the canonical resource, but you should also take the base classes into account in your search.
I want to write GUI code that is orthogonal. Lets say I have a circle class and a square class and they need to interact. Right now, to get the circle and square talking to each other - say the circle object sends a message to the square object, I would use something like square_obj.listen_for_circle(circle_obj) where listen_for_circle is a method that implements an addlistener.
This is a problem for me since now the two objects are linked - and removing one object from my code would break it. What I am looking to do is for the circle_obj to be able to broadcast a global message say 'CIRCLE_EVENT'. Additionally square_obj would be listening for global message broadcasts of type 'CIRCLE_EVENT', and upon hearing the event - does some action.(Ahhh, now the objects have no links to each other in the code base!)
Is this possible or even reasonable in MATLAB? (or maybe i'm just going crazy).
As always, advice much appreciated.
I'm not really sure why addlistener is problematic for you. It basically just adds an event listener that doesn't do anything if the event-origin object (the circle) is deleted.
Alternately you can use event.listener or handle.listener. They are undocumented but work well, and are widely used within the Matlab codebase (m-files). See explanation here: http://UndocumentedMatlab.com/blog/continuous-slider-callback/#Event_Listener
I am using Simulink to communicate with a serial device. I am trying to use the Serial Send block to send a value to the device. If I try to use a 'traditional' source (such as the Constant block) to send data, I get the following error.
The block 'Serial Send' cannot be assigned a continuous sample time.
How can I send a non-continuous signal?
You have to convert signal to discreate. First put your data to Quantizer than output from Quantizer connect "Zero-Order hold " now you send data to serial send
Per a discussion on the MATLAB mailing list (source):
You can set a sample time on the
Constant block. If you double click on
it you will see the sample time is set
to -1. You can also drag in a sample
and hold block. You may want to turn
on sample time colours to make
debugging easier.
Update:
Also, you may want to try using the To Instrument block instead of the Serial Send block. I've never used either, but the main difference I see is that the To Instrument block is designed for sending "simulation data", which might be more compatible with the Constant block. Maybe there's a reason that you can't use the To Instrument block, though.