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

[Bruno]

Et testé ce matin, c'est OK.
Chapeau pour la réactivité.

Le 03/08/2015 23:22, Vincent Privat a écrit :

C'est corrigé: https://josm.openstreetmap.de/ticket/11744
A+

Le 3 août 2015 22:22, Pierre-Yves Berrard 
mailto:pierre.yves.berr...@gmail.com>> 
a écrit :


Le 3 août 2015 22:11, Bruno mailto:pa...@free.fr>>
a écrit :

Bonjour,
[...]

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.


Même chose.

Pierre-Yves


___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Vincent Privat]

C'est corrigé: https://josm.openstreetmap.de/ticket/11744
A+

Le 3 août 2015 22:22, Pierre-Yves Berrard  a
écrit :

> Le 3 août 2015 22:11, Bruno  a écrit :
>
>> Bonjour,
>> [...]
>>
>> 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.
>>
>
> Même chose.
>
> Pierre-Yves
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Yves Berrard]

Le 3 août 2015 22:11, Bruno  a écrit :

> Bonjour,
> [...]
>
> 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.
>

Même chose.

Pierre-Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Bruno]

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" > 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 to

Re: [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  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

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

[Muselaar]

Bonsoir,
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. 
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.
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).
Mais c'est devenu chez moi un réflexe, et je commence peu à peu à oublier que 
ça pourrait marcher mieux

Envoyé de mon iPhone

Le 11 oct. 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"  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

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

[Bruno]

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" > 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

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

[Jean-Baptiste Holcroft]

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"  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 "H

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

[Philippe Verdy]

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 pau