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
