Right now we queue populating the user list in the middle of setting
up the dialog actors. Of course, the actual population happens some time
later after going back to the main loop.
It's more logical to structure the code so the the actors are
instantiated first in one block and then other things after that.
This commit moves the user list population enqueuing operation to the
bottom of the constuctor.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
In some cases we load the user list after going back
to main loop and in other cases we load the user list
right away (depending on if accounts service is ready).
In the case we load the user list right away we cause a
traceback because loading the user list forces a reset,
which then tries to reset actors which aren't instantiated
yet.
This commit ensures the user list is loaded after the constructor
finishes and the event loop runs irregardless of the accountsservice
state.
https://bugzilla.gnome.org/show_bug.cgi?id=721868
One of the most frequent complaints about our launching behaviour is
how we handle terminals. Among all MDI applications, the terminal is
the one that is most likely to have lots of semi-independent windows
opened at the same time, and spawning new windows is much more common.
More so, if it does not support tabs.
Therefore, we special case terminal launchers to always create a new
window. It is an application that most non-technical users will not
use, so chances of them being confused by any special behaviour is
expected to be low.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Specifying the session mode on the command-line doesn't play
well with session management (since the saved session desktop
file well either drop the specified session mode, or force it
always, even if the user picked a different mode at the login
screen)
This commit adds support for specifying the session mode via an
enviroment variable. For now, keep the old command line interface
for backward compatibility
https://bugzilla.gnome.org/show_bug.cgi?id=720894
All get_app_from_*() helpers are transfer full, but
get_app_from_gapplication_id() was directly returning the result
of lookup_app(), which is transfer none.
https://bugzilla.gnome.org/show_bug.cgi?id=721439
Workspaces can removed from any index, and in particular they
will be removed by the WorkspaceTracker if they stop containing
windows at some point. Make sure WorkspacesView is not confused
and destroyes the right Workspace objects.
https://bugzilla.gnome.org/show_bug.cgi?id=721417
The hash table must keep a copy of the IDs, because the GAppInfos
are unreferenced (and thus freed) at the end of the function.
This was possibly not a problem if the GAppInfos were referencing
the memory-mapped cache, but it becomes one for regularly parsed
desktop files in ~/.local.
https://bugzilla.gnome.org/show_bug.cgi?id=721039
