Autre cas assez fréquent qui semble lié: CTRL+F (ou accès par le menu) pour ouvrir une requête de sélection (j'utilise énormément pour faire des sélections par critère et filtrer des listes d'objets en combinant plusieurs recherches ou suppri,er certains objets dans une longue liste d'objets).
Très souvent le dialogue s'ouvre mais il est impossible de taper dans la zone de saisie (tous les boutons fonctionnent). Là encore il semble que ce soit le focus est resté captif sur un autre objet dans une autre fenêtre, alors que le champ de saisie est dans un état qui pour lui semblerait disposer du focus. Là encore il faut refermer le dialogue et retaper CTRL+F. Le transfert du focus d'une fenêtre à l'autre semble ne pas fonctionner de façon ordonnée (une fenetre ou un objet de cette fenêtre ne peut pas recevoir le focus et passer l'objet en tant qu'objet actif, tant que la demande de perte de focus n'a pas été traitée par l'objet initial qui en dispose et que cet objet est passé en état inactif). Tout semble lié à un problème de synchronisation/sérialisation des événements qui ne s'exécutent pas dans le bon ordre et cela semblerait lié au fait que l'UI n'est pas gérée dans JOSM uniquement par le thread principal; et sur un CPU multicoeur il peut y avoir facilement plusieurs threads actifs simultanément qui manipulent l'état de l'UI. Si le problème s'aggrave maintenant, c'est parce que le no,bre de threads dans JOS? a littéralement explosé (de façon excessive à mon avis : les thread pools sont mal réglés certains pools de worker threads peuvent avoir des centaines de threads inactifs: un thread pool peut améliorer les performances et la réactivité, mas pourquoi avoir autant de threads dormants... en principe on limite les thread pools qui servent surtout à pouvoir gérer de nombreuses sessions clientes d'un service et qui fonctionnent réellement de façon asynchrone entre elles; par exemple des threads d'écoute s'un port de connexion à un serveur; ,ais je ne vois pas du tout l'intérêt quand il n'y a qu'un seul utilisateur client: on peut admettre d'avoir un thread d'arrière-plan pour s'occuper du rafraichissement de la carte à l'écran mais ce thread ne doit surtout pas influer sur l'état du focus ni en dépendre alors qu'il n'y a qu'un seul utilisateur avec un seul focus pour "tout le monde", une seule fenêtre modale active, une seule file d'événements pour l'UI d'entrée qui doit rester ordonnée; même si les entrées peuvent avoir des threads pour gérer en interne leur propre état asynchrone, par exemple l'état propre au clavier, indépendant de celui de la souris: la consommation des sources doit passer vers une autre file de synchronisation) En tout cas ces anomalies sont totalement imprévisibles, pour exactement la même interaction utilisateur (si on ignore la position légèremetn différente de la souris à l'écran même si on ne clique pas) et les mêmes données chargées en mémoire. Autre chose qui semble lié: le rafraichissement de la carte en arrière-plan ne suit pas toujours la sélection courante et laisse visible comme sélectionné (ombrage rouge) des objets qui ne le sont plus; même chose quand on a un dialogue ouvert montrant les membres d'une relation et si on utilise "charger les membres incomplets dans la fenêtre derrière : le dialogue ne se rafraihit pas correctement pour afficher le nouvel état des membres. Il y a plusieurs threads distincts pour gérer l'UI et ces threads ne se synchronisent pas ou manipulent l'état d'objets dont ils ne sont normalement pas chargés puisque c'est un autre thread qui est sensé s'en occuper et gérer leurs changements ordonnés d'état. Tant que c'est un bogue de rafraichissement ce n'est pas méchant, mais le plus problématique c'est le transfert du focus d'une fenêtre à l'autre (et il n'est pas commode d'utiliser des fenêtres natives séparées pour leur faire adopter un comportement non modal ou le focus peut passer librement d'une fenêtre à l'autre selon la fenêtre active chaque fenêtre ayant don propre objet de focus avec un focus "dormant" sur l'objet tant que la fenêtre n'est pas active (et Swing n'a pas réellement écrit pour supporter un co,portement non modal des fenêtres multiples; il ne dispose qu'aucun systéme de sychrnisation et sérialisation d'événements. En tut cas merci pour vos réponses, je vois que je ne suis pas seul et que ces problèmes inopinés surviennent aussi avec d'autres installations différentes et sur d'autres OS. Le 11 octobre 2014 16:54, Jean-Baptiste Holcroft <jb.holcr...@gmail.com> a écrit : > C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et > sauvegarder son travail devient ridiculement compliqué. > Pour moi ça apparaît avec le plugin cadastre. >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
