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