It is possible that I haven't read this thread carefully enough.
You cannot update a GtkTreeModel or any other similar data structure that is currently being used as "the model" by a GtkTreeView or other similar widget, from a worker thread.
The model will emit signals reflecting what you've done to it, and the widget will do "GTK stuff" in its handlers for those signals, which will execute inside the worker thread.
You *can* update a GtkTreeModel (or similar) from a worker thread if you ensure that it is detached from any view widget during your updates.
On Wed, Feb 27, 2019 at 3:45 PM Mitko Haralanov via gtk-list <gtk-list@xxxxxxxxx> wrote:
I could start a new thread but will be confusing for anyone who may be
reading this thread a year from now researching a similar problem.
So, with that said, let me try to clarify:
The application has a GtkTreeView being populated by a GtkTreeModel.
The TreeView has 3 columns, the last one having a GtkCellRenderPixbuf
displaying a "gtk-edit" icon. The TreeView also has a
button-presse-event callback connected, which checks where in the
TreeView the mouse button has clicked and if it happens to be on the
last column/renderer, opens an "Edit" dialog box. One of the other
columns of the TreeView has a GtkCellRendererSpinner attached to it.
This cell render has a cell data function that will "spin" the spinner
when the model gets updated. The GtkTreeModel backing the TreeView
contains a column that is of type guint64. This is the value that
causes the GtkCellRendererSpinner to "spin" when it gets updated.
The actual event which causes the model to get updated is the
application finding a file on the filesystem matching a certain
pattern. This discovery process is happening in a worker thread as to
not block the main UI. In that worker thread, the filesystem is
scanned recursively looking at all files in a directory tree. When a
file matching the pattern is found, a function is scheduled using
g_idle_add()/g_main_context_invoke_full(). This callback is what
actually emits a signal whose handler updates the model.
So, the worker thread is not doing the *real* signal emission. It's
just scheduling a function to run in the main context thread, which
does the *real* signal emission.
As I mentioned in a previous email, I haven't had a lot of time to
create a separate application to show this. I can try to do that if
things are still not clear but I was hoping that the additional
information, which I posted earlier might be useful.
Thank you,
- Mitko
On Wed, Feb 27, 2019 at 2:18 PM Fontana Nicola <ntd@xxxxxxxxx> wrote:
>
> Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list ha
> scritto:
> > Thanks for the reply.
> > ...
>
> Hi,
>
> I find this mail thread really confusing and with a lot of misleading
> guesses. As already stated elsewhere, a minimal working example would
> likely be a *much* quicker way to solve your problem. I'd also suggest
> to start a new clean mail thread.
>
> > One of the main reasons why I am not using g_idle_add() is the timing
> > of the callback. I don't want to defer the processing of the callback
> > to the "idle" time since this is signal handling related.
>
> g_main_context_invoke is just a wrapper around an idle GSource:
>
> https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854
>
> There no magic speed gain in using it instead of g_idle_add: it just
> happens to be more convenient.
>
> > Another advantage of g_main_context_invoke[_full]() is that it will
> > check the "context" of the caller and, if possible, will call the
> > callback directly:
>
> Here rings an alarm bell: you are in a worker thread and you want to
> execute some code in the GTK thread; how can you expect that code to be
> called directly?
>
> In another email you said:
>
> > The only thing that the threaded signal callback is doing is changing
> > the *model*, which should be allowed.
>
> I don't know what a "threaded signal callback" is, but if with that you
> meant code executed in the worker thread, can you please point me where
> you got the idea that the model could be changed from outside the GTK
> thread? I always thought this was *not* allowed.
>
> Apart from that I still did not understand if you have problems with
> threads, with timing, with user interface not updating properly or
> other.
>
> Ciao.
> --
> Nicola
>
>
_______________________________________________
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
