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

Bruno pasbm at free.fr
Lun 3 Aou 20:11:16 UTC 2015


Bonjour,

Je reprends ce fil de discussion pour indiquer que pour ma part je n'ai 
plus de blocage clavier suite à l'utilisation de la touche F10 du cadastre.
C'était systématique au bout de deux ou trois utilisation mais 
aujourd'hui après tests et bien c'est "tombé en marche"

Je ne sais pas à quoi cela est dû car je ne l'ai pas utilisé pendant 
longtemps et il y a eu au moins une mise à jour java et aussi Josm depuis.

Par contre j'ai maintenant un plantage de Josm (j'ai fait un ticket) 
quand j'appelle la fonction adresses du plugin cadastre, là aussi c'est 
systématique.

Quelqu'un a une expérience la dessus ?

Bruno.

Le 11/10/2014 18:03, Bruno a écrit :
> Bonjour,
>
> Idem pour moi, je n'utilise plus la touche pour télécharger le 
> cadastre (F10 ou F11 suivant paramétrage) car au bout de trois à 
> quatre utilisations je perds le clavier, c'est systématique, par 
> contre la souris fonctionne dans tous les cas.
> ça fait bien un an que c'est comme ça pour moi mais je n'ai pas eu le 
> temps de chercher une explication/solution.
> Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec Java 6 
> ou 7.
>
>  Le 11/10/2014 16:54, Jean-Baptiste Holcroft 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.
>>
>> Le 11 oct. 2014 16:11, "Philippe Verdy" <verdy_p at wanadoo.fr 
>> <mailto:verdy_p at wanadoo.fr>> a écrit :
>>
>>
>>     De plus en plus souvent je constate des pertes inopinées de
>>     contrôle du clavier ou de la souris dans JOSM; rendant
>>     l'interface inopérante.
>>
>>     Par exemple :
>>     -  les touches + et - (qu'on les tape sur le pavé numérique ou le
>>     clavier alpha) du zoom cessent de répondre (dans ce cas aussi
>>     cela ne marche plus non plus avec le menu ni un raccourci posé
>>     sur une icone de la barre d'icones (c'est le cas le plus
>>     fréquent) Et pourtant le zoom sur la sélection fonctionne encore
>>     et le zoom avec + ou - dans le dialogue de téléchargement d'une
>>     zone fonctionne encore.
>>
>>     - quand on ouvre un dialogue; le focus sur le champ de saisie ne
>>     fonctionne pas et impossible de taper un texte dedans parfois
>>     aussi la sélection à la souris d'un morceau du texte ne marche
>>     plus (en revanche les autres boutons, y compris le triangle du
>>     sélecteur d'une combobox) fonctionne encore. La fermeture du
>>     dialogue et sa réouverture suffit parfois à rétablir la fonction;
>>     mais pas toujours...
>>
>>     - la suppression et le remise d'une icone de raccourci sur la
>>     barre d'icone fonctionne, mais le bouton ne produit toujours rien
>>     quand on clique dessus.
>>
>>     Il semble qu'il y a un bogue dans la bibliothèque qui gère les
>>     "bindings" attachant des événements clavier ou souris à un
>>     gestionnaire d'événement; comme si le gestionnaire avait été
>>     perdu par perte de référence (allocation en "weak pointer" et
>>     effet du garbage collector, ou mauvaise synchronisation de
>>     l'ordre des événements en cas de modification dynamique de la
>>     liste des bindings (modification non atomique, comme si la
>>     suppression de référence au gestionnaire d'événement dans une
>>     liste de gestionnaires a eu lieu *avant* l'insertion de ce même
>>     gestionnaire dans une autreliste pour un autre élément
>>     d'interface utilisateur).
>>
>>     Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses
>>     bibliothéques de construction d'UI; ou si la modification
>>     dyna,ique de l'interface a oublié de mettre un verrou entre
>>     plusieurs threads faisant des modifications concurrentes de l'UI
>>     (par exemple un thread s'occupant de la construction d'un nouveau
>>     dialogue tandis qu'un autre thread s'occupe encore de celui de la
>>     fenêtre principale; ou bien l'événement à réassigner est encore
>>     en cours de traitement par le thread principal qui gère la liste
>>     ordonnée des événements UI et synchronise les rafraichissements
>>     écran).
>>
>>
>>     Seule parade : sauver les modifs en cours dans un fichier local,
>>     fermer JOSM et le relancer pour charger le fichier à nouveau.
>>     Mais à je suis tombé sur un cas où c'était la fonction
>>     sauvegarder qui ne fonctionnait plus aussi bien au clavier
>>     (CTRL+S), qu'à la souris en cliquant l'icone de la barre d'icones
>>     ou par le menu fichier.
>>
>>     C'est de plus en plus gênant car l'anomalie se reproduit de plus
>>     en plus souvent et aboutit à des pertes de modifs en cours (très
>>     gênant quand on a eu besoin de charger beaucoup de données et
>>     vérifier des jeux compliqués de relations interdépendantes, comme
>>     la vérification des cours d'eau, des lignes de bus, vérifier le
>>     routage, refermer les trous dans des relations (par exemple par
>>     ceux qui remplacent sans faire attention des routes ou
>>     transforment un carrefour simple en rond-point tracé n'importe
>>     comment et ne tenant pas compte de l'existant qui s'y connecte
>>     (ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont
>>     totalement perdus dans iD qui presque tout le temps fait
>>     n'importe quoi et est très peu utiisable pour autre chose que
>>     d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI
>>     ou affiner le tracé existant; mais pas pour transformer des
>>     objets: d'ailleurs les mêmes beaucoup trop souvent ne
>>     s'embarassent pas de transformer l'existant, ils retracent et
>>     suppri,ent tout ce qui les gêne et ne fait doublon qu'avec leur
>>     nouveau tracé, ou qui passe une route simple bidirectionnelle en
>>     routes à deux voies unidirectionnelles séparées et oublient de
>>     router la ligne de bus en sens inverse qui passait par la
>>     première voie laissée mais devenue sens unique; créant des routes
>>     impossibles).
>>
>>     D'une façon générale JOSM a de plus en plus souvent des soucis de
>>     rafraichissement partiel de l'écran et semble souffrir de bogue
>>     de synchronisation entre ses threads de plus en plus nombreux
>>     (chez moi la moindre session prend maintenant plus de 400 threads
>>     parallèles, alors que j'tilise un jeu très réduit de plugins
>>     parmi les plus "stables".
>>
>>     Je détecte cette anomalie depuis début août, mais cela s'aggrave
>>     maintenant
>>
>>     Note: je suis toujours à jour des versions, je lance JOSM par
>>     JNLP sur la dernière version en release stable. Et ceci quelque
>>     soit le PC utilisé (sous Windows 7 ou 8.1); avec la dernière
>>     versions stable de Java (en version "Hotspot Server VM" 64 bits
>>     en Java 6 ou 7; pas la version 32 bits qui limite trop la mémoire
>>     maxi utilisée alors que j'ai beaucoup de mémoire, et sollicite
>>     énormément le garbage collector ce qui fait des pauses beaucoup
>>     trop souvent, en 64 bits mes VM Java montent sans problème à 2
>>     gigas, et le garbage collector utilise des threads en
>>     arrière-plan qui ne font jamais aucune pause; et la version
>>     serveur 64 bits sait utiliser les 8 coeurs CPU à la demande et a
>>     un bien meilleur scheduler de threads et consomme beaucoup moins
>>     de CPU pour la VM toute entière, ce qui laisse le reste de l'OS
>>     travailler correctement).
>>
>>     Constatez-vous le même problème ? avez-vous une explication ou un
>>     moyen d'éviter ça ? (paramètre de VM Java par exemple, ou package
>>     de remplacement d'une librairie système ou quelquchose qui
>>     n'était pas recommandé ni supporté officiellement par l'API mais
>>     ne fonctionne plus de la même façon sur les versions récentes de
>>     Java).
>>
>>     Je soupçonne une anomalie de Swing, ou une mauvaise utilisation
>>     (car Swing lui-même n'est pas synchronisé dans la plupart de ses
>>     APIs, pour des questions de performance et demande que soit on
>>     l'utilise uniquement dans le thread principal, soit qu'on fasse
>>     des synchrox explicites sur un verrou applicatif (et notamment
>>     dans le constructeur ou le finaliseur d'une classe ou quand on
>>     utilise des "weak pointers" pour des objets de type "cache"
>>     sensés être libérables à tout instant et reconstructibles à la
>>     demande en utilisant une méthode de factory à chaque fois et en
>>     rendant privés les constructeurs).
>>
>>     (Note : je n'utilise plus Swing dans mes applis Java : trop lent;
>>     pas assez souple; conception inutilement compliquée; mauvaise
>>     adaptation au contenu; rendu du texte et méthodes de saisie
>>     exécrables, je préfère les bibliothèques développées initialement
>>     pour l'UI d'Eclipse, mais utilisables depuis longtemps séparément
>>     car elles sont plus réactives, mieux écrites, et gèrent mieux les
>>     accélérations matérielles disponibles, Swing est également un
>>     gouffre en ressource mémoire et construit trop d'objets très
>>     temporaires, il ne gère pas leur cycle de vie correctement et
>>     sollicite trop le garbage collector: Swing est préhistorique et
>>     fonctionne très mal avec les UI qui changent dynamiquement selon
>>     le contenu, il permet juste de faire des boîtes d'alerte avec 3
>>     boutons et un texte statique)
>>
>>     _______________________________________________
>>     Talk-fr mailing list
>>     Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
>>     https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150803/05178678/attachment.html>


Plus d'informations sur la liste de diffusion Talk-fr