Just to inform, the manager still kill the running client (manually -./boinc- opened on another terminal) when you close with the red X (on Linux at least).

That not happening when you close using the file tab.

Just to inform, the manager still kill the running client (manually -./boinc- opened on another terminal) when you close with the red X (on Linux at least).

That not happening when you close using the file tab.

If you enable the exit dialogue under options>other, then exit using File>Exit and ensure the stop running tasks isn't ticked, the next time you exit using the red X the client is not killed. (Ubuntu 19.04) at least on my system.

Just to inform, the manager still kill the running client (manually -./boinc- opened on another terminal) when you close with the red X (on Linux at least).

That not happening when you close using the file tab.

If you enable the exit dialogue under options>other, then exit using File>Exit and ensure the stop running tasks isn't ticked, the next time you exit using the red X the client is not killed. (Ubuntu 19.04) at least on my system.

I made that (several times, now & before) and no joy. When you hit the red X the manager stop but it stop the client (who runs in another terminal). I use Ubuntu 18.04

If i exit by File > Exit that's works fine (provided the stop running task is not checked of course).

My point is simply and since that works on the old client, something was changed who make that stop working. Closing the manager with the red X on one terminal must not kill the client on the other one unless you specifically choose to do that.

<edit>I see that you talk about, i will call it an "exit and restarting path" and works as a workaround of the problem (thanks for point me that) but the question remains: why we need to do that? Why that not working in the first try as worked for years on the old managers?

... something was changed who make that stop working.

Previously, clicking the X caused 'minimise to system tray'. Now that the system tray icon has been abolished on Linux builds, my guess is that the replacement pathway doesn't handle all scenarios cleanly. I'll try to take a look this afternoon.