On Mon, 04 Sep 2017 09:17:10 +0200 Stefan Salewski <mail@xxxxxxxxxxxx> wrote: > On Sun, 2017-09-03 at 16:54 +0100, Emmanuele Bassi wrote: > > You're blocking the toolkit's main loop, here. If your application > > does this, it's broken and needs to be fixed - regardless of what > > the cursor looks like. > > > > The cursor is rendered by the Wayland compositor, but the animation > > is > > performed by the toolkit, i.e. it's the toolkit that uploads the > > cursor's data to the compositor. > > Of course you are right that using g_idle_add() is still blocking the > GUI. But I think that having an animated Busy cursor makes only sense > at all when it is animated while a program is doing some heavy > calculation. So the animated cursor is indeed an indication for a > short blocked period. My chess engine takes only a few seconds to > calculate the next move, so creating an own thread is some overkill. > What I need: User has done his move, so update display, indicate that > computer is "thinking" for a few seconds, and then update display > again. I think that should be possible with g_idle_add(). Instead of > the busy pointer I may set a message to the window title. > > Later I may consider indeed using a separate thread -- I did that > already one year ago for my Ned Nim editor for communicating with the > nimsuggest process, but I can not remember details currently. Doing it > really properly may be not easy for a chess engine, as the human > player should be able to interrupt the computer thinking at arbitrary > times. Unfortunately there exist very few examples, and some are more > Python related like I think you are partly thinking out loud, because you began with "of course you are right that using g_idle_add() is still blocking the GUI", but in so far as you were wanting an answer the point is that any GTK+ program runs a glib event loop in its main (starting) thread. That event loop must not be blocked by your "some heavy calculation", whether in an idle callback or in some GTK+ signal callback or in whatever other way you may be thinking of doing it in that thread. The conventional way of dealing with this is for the blocking "heavy calculation" to be run in a separate worker thread or in a thread pool, and for that worker thread to post its result back to GTK+ using g_idle_add(). g_idle_add() is thread safe. You might also want to look at GTask (and g_task_run_in_thread()), which follows this approach but with some additional syntactic sugar. As to your test case, that works fine in GTK+-3.22 with the X11 backend and the Adwaita theme. I do not have wayland installed. Possibly you have found a bug in the wayland backend, depending on whether anyone else can reproduce your issue. Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
