[OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM

[Philippe Verdy]

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.holcroft at 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.
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20141012/57b90842/attachment.htm>