<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Bonsoir,</div><div>Je ne sais pas si ça a un rapport (mais peut-être que si, d'où mon message), mais chez moi, c'est la souris (j'utilise peu le clavier), en l'occurrence le trackpad qui pose problème. </div><div>Je crois l'avoir déjà signalé, c'est en fait la fenêtre qui devient transparente à la souris, ou autrement dit, les actions de la souris continuent de s'appliquer à la précédente fenêtre utilisée, même si elle est en arrière plan.</div><div>La parade que j'ai fini par trouver, vraiment par hasard, c'est de (sur le trackpad) simuler avec 2 doigts la molette de la souris, et de faire des mouvements rapides de haut en bas. Au bout de quelques secondes, la fenêtre visible est prise en compte par le pointeur, et on peut continuer à travailler normalement. Là où c'est moins marrant, c'est quand on change sans cesse de fenêtre (boîtes de dialogues successives, par exemple).</div><div>Mais c'est devenu chez moi un réflexe, et je commence peu à peu à oublier que ça pourrait marcher mieux<br><br>Envoyé de mon iPhone</div><div><br>Le 11 oct. 2014 à 18:03, Bruno <<a href="mailto:pasbm@free.fr">pasbm@free.fr</a>> a écrit :<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">Bonjour, <br>
<br>
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.<br>
ç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.<br>
Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec
Java 6 ou 7.<br>
<br>
Le 11/10/2014 16:54, Jean-Baptiste Holcroft a écrit :<br>
</div>
<blockquote cite="mid:CAPE+OKxvbcw6pW-yJ-YauXw2+jFr_bigYq-iK4S62rSYQ8F5mw@mail.gmail.com" type="cite">
<p dir="ltr">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é.<br>
Pour moi ça apparaît avec le plugin cadastre.</p>
<div class="gmail_quote">Le 11 oct. 2014 16:11, "Philippe Verdy"
<<a moz-do-not-send="true" href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>>
a écrit :<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br style="font-family:arial,sans-serif;font-size:11.1999998092651px">
<div dir="ltr" style="font-family:arial,sans-serif;font-size:11.1999998092651px">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.</div>
<div dir="ltr" style="font-family:arial,sans-serif;font-size:11.1999998092651px"><br>
</div>
<div dir="ltr" style="font-family:arial,sans-serif;font-size:11.1999998092651px">Par
exemple :
<div>- 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.</div>
<div><br>
</div>
<div>- 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...</div>
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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".</div>
<div><br>
</div>
<div>Je détecte cette anomalie depuis début août, mais
cela s'aggrave maintenant</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>(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)</div>
</div>
</div>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a moz-do-not-send="true" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a moz-do-not-send="true" href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-fr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Talk-fr mailing list</span><br><span><a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a></span><br><span><a href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a></span><br></div></blockquote></body></html>