Fwd: Emitting signals from threads

Mitko Haralanov via gtk-list <gtk-list@xxxxxxxxx> · Tue, 18 Dec 2018 09:46:45 -0800

I mistakenly replied only to Luca!! Forwarding to the list.
(Sorry, Luca, my bad)
- Mitko

---------- Forwarded message ---------
From: Mitko Haralanov <voidtrance@xxxxxxxxx>
Date: Tue, Dec 18, 2018 at 9:37 AM
Subject: Re: Emitting signals from threads
To: Luca Bacci <luca.bacci982@xxxxxxxxx>

I found something that is different between the two cases - button click with signals and without.
Using the code from the link that Luca posted, I decided to print the size of each column when a button press is received. As it turns out, the width of the columns is different in the two cases:

Without thread signals:
column[0](193) = 0 -> 193
	cell[0] = min->109, natural->109
column[1](66) = 193 -> 259
	cell[0] = min->20, natural->20
	cell[1] = min->16, natural->16
	cell[2] = min->35, natural->35
column[2](36) = 259 -> 295
	cell[0] = min->16, natural->16
x = 105.872116, y = 259.547516

(x and y are the coordinates of the button press event)

With thread signals:
column[0](0) = 0 -> 0
	cell[0] = min->135, natural->135
column[1](66) = 0 -> 66
	cell[0] = min->20, natural->20
	cell[1] = min->16, natural->16
	cell[2] = min->35, natural->35
column[2](36) = 66 -> 102
	cell[0] = min->16, natural->16
x = 113.528488, y = 158.563782

As you can see, the width of the first column is 0 when the signals are being emitted. As expected, if I were to click very close to the left border of the widget, the edit dialog does not get triggered as the x coordinate falls within column 1:

column[0](0) = 0 -> 0
	cell[0] = min->135, natural->135
column[1](66) = 0 -> 66
	cell[0] = min->20, natural->20
	cell[1] = min->16, natural->16
	cell[2] = min->35, natural->35
column[2](36) = 66 -> 102
	cell[0] = min->16, natural->16
x = 21.247330, y = 181.310333

I could use the cell renderer width if the column width is 0 but that seems unreliable since the cell renderer width is not the same as the column and it's also not static.

On Tue, Dec 18, 2018 at 8:23 AM Mitko Haralanov <voidtrance@xxxxxxxxx> wrote:
I am not posting the complete function because there is a lot of irrelevant code. I am also not interested in the specific cell renderer but rather the row on which the click occurred.
tatic gboolean on_button_press_event(GtkWidget *widget,
						      GdkEvent *event,
						      gpointer data)
{
	GtkTreeView *treeview = GTK_TREE_VIEW(widget);
	GdkEventButton *button = (GdkEventButton *)event;
	GtkTreeModel *model;
	GtkTreePath *path;
	GtkTreeIter iter;
	GtkTreeViewColumn *column;
	GtkScopeProjectEditDialog *dialog;
	GtkScopeProjectEditData *pdata, fill;
	GtkScopeProject *project;
	guint response, index;
	gboolean ret = FALSE;

	if (button->type != GDK_BUTTON_PRESS ||
	    !gtk_tree_view_get_path_at_pos(treeview, button->x, button->y,
					   &path, &column, NULL, NULL))
		return FALSE;

	index = GPOINTER_TO_UINT(g_object_get_data(G_OBJECT(column), "index"));
	if (index != TREEVIEW_COLUMN_EDIT)
		goto done;
	model = gtk_tree_view_get_model(treeview);
	if (!gtk_tree_model_get_iter(model, &iter, path))
		goto done;
	gtk_tree_model_get(model, &iter, PROJECT_COLUMN_OBJ, &project, -1);
        ...

The issue is that the column which is returned by gtk_tree_view_get_path_at_pos() is different depending on whether thread signals are being emitted vs not. I have verified that the button press coordinates are the same (button->x and button->y have the same values in both cases).

On Tue, Dec 18, 2018 at 5:24 AM Luca Bacci <luca.bacci982@xxxxxxxxx> wrote:
Hi Mitko! Can you post here the code for the button-press event handler?
It should more or less follow the code here: http://scentric.net/tutorial/sec-misc-get-renderer-from-click.html

Luca

Il giorno lun 17 dic 2018 alle ore 20:28 Mitko Haralanov via gtk-list <gtk-list@xxxxxxxxx> ha scritto:
Hi,
In my application, I want to be able to update a treeview from a separate thread. Each treeview row was a column that is a progress bar. The progress to be displayed is generated by a separate thread as to not block the UI.

Since GTK is not thread-safe, the way the application is written is that the thread, when it needs to emit a signal, will prepare the signal data and then call g_main_context_invoke_full(NULL, cb, data, ...) in order to be able to call g_singal_emit() in the global default context thread. The signal handler updates the tree model, which in turn updates the tree view.

For the most part this works with one big, ugly exception - the same treeview has a column, which is supposed to open the item's Edit dialog when clicked. So, naturally, I have a button-press handler connected to the treeview, which launches the Edit dialog when the button press occurs in the correct column.

However, when an update is running and the thread is continuously emitting signals, clicking on *any* column of *any* of the other items opens the Edit dialog. The treeview behaves as if the items in it have only one column.

Every example or document that I have seen in relation to signals from threads says to emit the signal from a g_idle_add() handler. However, g_main_context_invoke_full(NULL, ...) should be the same as calling g_idle_add().

Can someone shed some light into what might be happening?

Thank you.

_______________________________________________

gtk-list mailing list

gtk-list@xxxxxxxxx

https://mail.gnome.org/mailman/listinfo/gtk-list

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list