Gestion des sessions

Une session est un ensemble d'applications en cours d'exécution, chacune ayant un état particulier. La session est contrôlée par un service appelé « gestionnaire de session ». Les applications participant à la session sont appelées « clients de session ».

Le gestionnaire de session envoie des commandes à ses clients au nom de l’utilisateur. Ces commandes peuvent amener les clients à valider les modifications non enregistrées (par exemple en enregistrant les fichiers ouverts), à conserver leur état pour de futures sessions ou à se fermer correctement. L’ensemble de ces opérations est appelé « gestion de session ».

En général, une session regroupe toutes les applications qu’un utilisateur exécute simultanément sur son bureau. Sous Unix/Linux, cependant, une session peut inclure des applications s’exécutant sur différents ordinateurs et s’étendre sur plusieurs écrans.

Arrêt d’une session

Une session est fermée par le gestionnaire de session, généralement au nom de l’utilisateur lorsque celui-ci souhaite se déconnecter. Un système peut également procéder à une fermeture automatique en cas d’urgence, par exemple si une coupure de courant est imminente. Il existe manifestement une différence significative entre ces deux types d’arrêt. Dans le premier cas, l’utilisateur peut souhaiter interagir avec l’application, en précisant exactement quels fichiers doivent être enregistrés et lesquels doivent être ignorés. Dans le second cas, il n’y a pas le temps d’interagir. Il se peut même qu’aucun utilisateur ne soit assis devant la machine !

Protocoles et prise en charge sur différentes plateformes

Sous macOS et sur les versions de Microsoft Windows antérieures à Windows 2000, il n’existe pas encore de véritable gestion complète des sessions pour les applications, c’est-à-dire qu’il n’est pas possible de restaurer des sessions précédentes. (Windows 2000 et XP proposent un mode « veille prolongée » dans lequel l’intégralité de la mémoire est sauvegardée sur le disque et restaurée au redémarrage de la machine.) Ils prennent toutefois en charge les déconnexions en douceur, au cours desquelles les applications ont la possibilité d’annuler le processus après avoir obtenu la confirmation de l’utilisateur. Il s’agit de la fonctionnalité correspondant au signal ` QGuiApplication::commitDataRequest()`.

X11 prend en charge la gestion complète des sessions depuis la version X11R6.

Mise en œuvre de la gestion des sessions avec Qt

Commencez par associer un slot au signal QGuiApplication::commitDataRequest() afin de permettre à votre application de participer au processus de déconnexion en douceur. Si vous ne ciblez que la plate-forme Microsoft Windows, c’est tout ce que vous pouvez et devez fournir. Idéalement, votre application devrait proposer une boîte de dialogue d’arrêt similaire à celle-ci :

Vous trouverez un exemple de code pour cette boîte de dialogue dans la documentation de la fonction QSessionManager::allowsInteraction().

Pour une gestion complète de la session (actuellement prise en charge uniquement sur X11R6), vous devez également veiller à sauvegarder l'état de l'application et, éventuellement, à le restaurer lors du prochain cycle de vie de la session. Cette sauvegarde s'effectue en implémentant un slot connecté au signal ` QGuiApplication::saveStateRequest()`. Toutes les données d’état que vous enregistrez dans cette fonction doivent être marquées avec l’identifiant de session QGuiApplication::sessionId(). Cet identifiant spécifique à l’application est unique au niveau global, ce qui évite tout conflit. (Voir QSessionManager pour plus d’informations sur l’enregistrement et la restauration de l’état d’une application Qt particulière.)

La restauration s’effectue généralement dans la fonction `main()` de l’application. Vérifiez si ` QGuiApplication::isSessionRestored()` renvoie ` true`. Si c’est le cas, utilisez à nouveau l’identifiant de session ` QGuiApplication::sessionId()` pour accéder à vos données d’état et restaurer l’état de l’application.

Important : afin de permettre au gestionnaire de fenêtres de restaurer les attributs des fenêtres, tels que l’ordre d’empilement ou les informations géométriques, vous devez identifier vos widgets de niveau supérieur à l’aide de noms d’objets uniques à l’échelle de l’application (voir QObject::setObjectName()). Lors de la restauration de l’application, vous devez vous assurer que tous les widgets de niveau supérieur restaurés se voient attribuer les mêmes noms uniques qu’auparavant.

Test et débogage de la gestion des sessions

La prise en charge de la gestion des sessions sous macOS et Windows est assez limitée en raison de l’absence de cette fonctionnalité dans le système d’exploitation lui-même. Il suffit de fermer la session et de vérifier que votre application se comporte comme prévu. Il peut être utile de lancer une autre application, généralement l’environnement de développement intégré, avant de démarrer votre application. Cette autre application recevra ensuite le message d’arrêt, ce qui vous permettra d’annuler l’arrêt. Sinon, vous devriez vous reconnecter après chaque exécution de test, ce qui n’est pas un problème en soi, mais prend du temps.

Sous Unix, vous pouvez soit utiliser un environnement de bureau prenant en charge la gestion de session standard X11R6, soit, méthode recommandée, utiliser l’implémentation de référence du gestionnaire de session fournie par le X Consortium. Cet exemple de gestionnaire s’appelle « xsm » et fait partie d’une installation standard de X11R6. Comme toujours avec X11, une page de manuel utile et informative est fournie. L’utilisation de ` xsm ` est simple (mis à part l’interface utilisateur peu pratique basée sur Athena). Voici une approche simple :

• Lancez X11R6.
• Créez un fichier . .xsmstartup dans votre répertoire personnel contenant la ligne suivante :

  xterm

  Cela indique à xsm que la session par défaut/de secours se limite à un xterm et rien d’autre. Sinon, xsm tenterait de lancer de nombreux clients, notamment le gestionnaire de fenêtres twm, ce qui n’est pas très utile.

• Lancez maintenant xsm depuis une autre fenêtre de terminal. Une fenêtre du gestionnaire de session et le xterm s'afficheront tous les deux. Le xterm possède une propriété intéressante qui le distingue de tous les autres shells que vous exécutez actuellement : au sein de ce shell, la variable d'environnement SESSION_MANAGER pointe vers le gestionnaire de session que vous venez de démarrer.
• Lancez votre application depuis la nouvelle fenêtre xterm. Elle se connectera automatiquement au gestionnaire de sessions. Vous pouvez vérifier si la connexion a abouti à l’aide du bouton ClientList.

  Remarque : ne laissezjamais la fenêtre « ClientList » ouverte lorsque vous démarrez ou fermez des clients gérés par le gestionnaire de session ! Sinon, « xsm » risque de planter.

• Utilisez les boutons « Checkpoint » et « Shutdown » du gestionnaire de session avec différents paramètres et observez le comportement de votre application. Le type de sauvegarde « local » signifie que les clients doivent enregistrer leur état. Il correspond au signal ` QGuiApplication::saveStateRequest()`. Le type de sauvegarde « global » demande aux applications d’enregistrer leurs modifications non sauvegardées dans un espace de stockage permanent et accessible globalement. Il invoque ` QGuiApplication::commitDataRequest()`.
• En cas de plantage, imputez la responsabilité à ` xsm ` et non à Qt. ` xsm ` est loin d’être un gestionnaire de session utilisable sur le bureau d’un utilisateur. Il est toutefois suffisamment stable et utile pour servir d’environnement de test.