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 <voidtra...@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 <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
>>>
>> _______________________________________________
>> 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
