Having spent the last two weeks working on my first app, the one\nthing that seems to have caused more than half my troubles is\nexitOnClose. Not sure what can be done about it, but some things\nthat I've noticed:
\n
\n- exitOnClose doesn't exit the app on close, it just destroys all\nthe event handlers, cancels all in-progress XHRs, and makes the app\nstop responding. It only exits if the closing window is\nthe last window in the app. It's because of the\nnot-actually-exiting behaviour that I spent so long being confused,\nnot realising that exitOnClose was the source of my problems.
\n- tabGroups have exitOnClose=true by default. Not only is this\nconfusing on its own (no other widget has it set), it also means\nthat when combined with the above, having a login screen followed\nby a tabgroup, if you hit \"back\" to get back to the login screen,\neverything dies because the tabgroup tried to \"exit\". Again, this\ntook a couple of days of banging my head on the desk before\nrealising that a seemingly innocent operation (closing a tabgroup)\nwas doing something I didn't ask for (\"exiting\" the app), and\nbreaking everything in a way that made no sense (leaving the GUI\nfunctioning but with no events firing)
\n- close as in \"user is on the login screen and hits the back\nbutton\" and close as in \"user logs in, moves to the main screen,\nthe login screen is no longer needed and can be close()d\" both\ntrigger the behaviour. This makes it impractical to have a login\nscreen which exits the app if closed with the back button, and does\nnot exit the app when closed via close()
\n- during some experiments with modal windows, I somehow even\nmanaged to close an exitOnClose window, and my app closed but the\nwidgets were still there, floating above my android desktop, god\nknows what happened there...
\n
\n
So in summary, please please please make exitOnClose exit the\napp when the window is closed, now matter how unclean the shutdown\nprocess. Having it half-exit, half-break the app in weird ways\ncauses lots of pain when debugging seemingly unrelated\nfunctions.
But it's set to true by default for tabGroups, so if you have a\ngroup that doesn't exit back to the splash screen (ie,\nthere's a log-in screen in between), closing it triggers an\nunexpected undocumented \"exit\", and because it doesn't\nactually exit, the app ends up in a confusing zombie\nstate.
\n
For going back to the splash, it doesn't matter whether the app\nexits or zombifies. For going back to a login screen, zombifying is\nbad, exiting fully is good. Thus, if we want to support both cases,\nexiting fully is better. If we don't want to support the latter\ncase, then it shouldn't be the default (It isn't even documented\nthat it's true by default, so even after reading the manual, the\nbehaviour is still unexpected).
\n
My personal preference would be to make it work in both cases,\nand I don't see any downside to it working in both -- but if you\nreally want it to only work in one case, please at least\ndocument the behaviour so developers know how to avoid it in the\nother.