Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?
Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur... quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)
Surtout que si on essaye de remonter à l'origine de ce problème, ça n'est pas le blocage de ton navigateur de fichier (qui n'est qu'un symptôme), mais de mon expérience personnelle c'est très souvent dû à des sessions effacées inutilement, que ça soit niveau firewall, NAT, ou système d'authentification : encore des modalités qui n'ont parfois aucune raison d'être (le NAT et autre état intermédiaire là pour contourner une difficulté technique plus ou moins involontairement créée par l'homme) et qui doivent être résolues par l'utilisateur, en rechargeant, se reloggant, en fermant/rouvrant, en redémarrant, etc ! C'est débile. Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.
Tu vas me dire « oui mais en attendant on pourrait avoir ces workaround dans la GUI », mais si ça fait 20 ans qu'il y a les même problèmes (car ça fait vingt ans que la complexification des réseaux fout la merde) et qu'ils n'ont toujours pas été résolus dans la GUI, c'est peut-être qu'il faut arrêter de chercher des workaround et corriger les problèmes dans le réseau.
Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . En réponse au journal GNOME avec un scheduler temps réel. Évalué à 0.
Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?
Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur... quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)
Surtout que si on essaye de remonter à l'origine de ce problème, ça n'est pas le blocage de ton navigateur de fichier (qui n'est qu'un symptôme), mais de mon expérience personnelle c'est très souvent dû à des sessions effacées inutilement, que ça soit niveau firewall, NAT, ou système d'authentification : encore des modalités qui n'ont parfois aucune raison d'être (le NAT et autre état intermédiaire là pour contourner une difficulté technique plus ou moins involontairement créée par l'homme) et qui doivent être résolues par l'utilisateur, en rechargeant, se reloggant, en fermant/rouvrant, en redémarrant, etc ! C'est débile. Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.
Tu vas me dire « oui mais en attendant on pourrait avoir ces workaround dans la GUI », mais si ça fait 20 ans qu'il y a les même problèmes (car ça fait vingt ans que la complexification des réseaux fout la merde) et qu'ils n'ont toujours pas été résolus dans la GUI, c'est peut-être qu'il faut arrêter de chercher des workaround et corriger les problèmes dans le réseau.
Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.