I mistakenly replied only to Luca!! Forwarding to the list.
(Sorry, Luca, my bad)
- Mitko
---------- Forwarded message ---------
From: Mitko Haralanov <voidtra...@gmail.com>
Date: Tue, Dec 18, 2018 at 9:37 AM
Subject: Re: Emitting signals from threads
To: Luca Bacci <luca.bacci...@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 <voidtra...@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.bacci...@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
