Re: Emitting signals from threads

[Mitko Haralanov <voidtrance gmail com>]

Anyone have any ideas? I still can't figure out why the column sizes go to 0.

Thank you.

On Tue, Dec 18, 2018, 13:40 Mitko Haralanov <voidtrance gmail com wrote:

This is Gtk3:

gtk3-3.22.26-2.fc27.x86_64

On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <gtk-list gnome org> wrote:

Is it Gtk2 or Gtk3, which version exactly?

Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-list <gtk-list gnome org> ha scritto:

I mistakenly replied only to Luca!! Forwarding to the list.

(Sorry, Luca, my bad)

- Mitko

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

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 gmail com> 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 gmail com> 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 gnome org> 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 gnome org
https://mail.gnome.org/mailman/listinfo/gtk-list

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

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