Copier/Coller dans la fenêtre d'enregistrement
Moderators: XnTriq, helmut, xnview
Copier/Coller dans la fenêtre d'enregistrement
Bonjour.
J'utilise XnViewMP 0.88 64bits sur mon portable équipé de Xubuntu (gestionnaire de fichiers : Thunar). Un "ennui" me gêne souvent : j'espérais qu'il disparaisse au cours des versions successives, mais il n'en est rien, apparemment.
Lorsque je fais par exemple des enregistrements de plusieurs captures effectuées avec XnViewMP, je lance le premier enregistrement par CTRL+S, ce qui ouvre la fenêtre ad hoc. Là, j'utilise le bouton prévu pour créer un nouveau dossier auquel j'attribue un nom ; mais, avant de valider, je sélectionne ce que j'ai frappé et fais un clic droit (ou CTRL+C) pour copier ce que je viens de taper (but : utiliser tout ou partie du nom de dossier pour nommer les fichiers à enregistrer — en ajoutant un mot différent pour chaque fichier, évidemment). Cela fonctionne avec d'autres logiciels installés sur Xubuntu, mais pas avec XnViewMP, qui se fige aussitôt : il faut tuer le processus pour s'en sortir.
Pour éviter cela, je ne dispose (pour l'instant) que d'une solution : créer le nom de dossier dans un éditeur de texte externe (ex : gedit), où je le copie (CTRL+C), puis le coller lors de la création du dossier dans XnViewMP, puis des noms de fichiers : cette méthode fonctionne parfaitement. C'est donc selon toute apparence l'opération COPIER qui provoque le "gel" de XnView lorsque la fenêtre d'enregistrement est ouverte.
Est-ce un bug ou une impossibilité liée à la conformation de XnViewMP ? — Pour mémoire, rien de tel avec XnViewMP 64bits sous Windows 10 : fonctionnement sans accroc lors de manipulations identiques !
J'utilise XnViewMP 0.88 64bits sur mon portable équipé de Xubuntu (gestionnaire de fichiers : Thunar). Un "ennui" me gêne souvent : j'espérais qu'il disparaisse au cours des versions successives, mais il n'en est rien, apparemment.
Lorsque je fais par exemple des enregistrements de plusieurs captures effectuées avec XnViewMP, je lance le premier enregistrement par CTRL+S, ce qui ouvre la fenêtre ad hoc. Là, j'utilise le bouton prévu pour créer un nouveau dossier auquel j'attribue un nom ; mais, avant de valider, je sélectionne ce que j'ai frappé et fais un clic droit (ou CTRL+C) pour copier ce que je viens de taper (but : utiliser tout ou partie du nom de dossier pour nommer les fichiers à enregistrer — en ajoutant un mot différent pour chaque fichier, évidemment). Cela fonctionne avec d'autres logiciels installés sur Xubuntu, mais pas avec XnViewMP, qui se fige aussitôt : il faut tuer le processus pour s'en sortir.
Pour éviter cela, je ne dispose (pour l'instant) que d'une solution : créer le nom de dossier dans un éditeur de texte externe (ex : gedit), où je le copie (CTRL+C), puis le coller lors de la création du dossier dans XnViewMP, puis des noms de fichiers : cette méthode fonctionne parfaitement. C'est donc selon toute apparence l'opération COPIER qui provoque le "gel" de XnView lorsque la fenêtre d'enregistrement est ouverte.
Est-ce un bug ou une impossibilité liée à la conformation de XnViewMP ? — Pour mémoire, rien de tel avec XnViewMP 64bits sous Windows 10 : fonctionnement sans accroc lors de manipulations identiques !
Re: Copier/Coller dans la fenêtre d'enregistrement
il semble que cela soit un bug de la librairie QT
Pierre.
Re: Copier/Coller dans la fenêtre d'enregistrement
Eh bien ! Il me semble que c'était déjà cette librairie qui était en cause dans l'affaire des caractères accentués...
Cf : viewtopic.php?f=83&t=36615
Cf : viewtopic.php?f=83&t=36615
Re: Copier/Coller dans la fenêtre d'enregistrement
Bonjour.
Je me permets de réactiver ce fil, car, fréquemment, il m'arrive encore de faire planter XnViewMP en tentant un copier/coller dans un champ de nom présent au sein de la fenêtre d'enregistrement ! Quand j'y pense, je passe par un éditeur de textes qui fait alors office de presse-papiers "manuel", mais j'hy pense toujours après un premier plantage ! Si je n'ai qu'une seule image à enregistrer, ce n'est pas trop grave, mais quand il y en a une floppée, c'est assez rageant !
Depuis le temps, aucune correction n'est en vue ?...
(pour info : je suis sous Xubuntu 18.04 LTS)
Je me permets de réactiver ce fil, car, fréquemment, il m'arrive encore de faire planter XnViewMP en tentant un copier/coller dans un champ de nom présent au sein de la fenêtre d'enregistrement ! Quand j'y pense, je passe par un éditeur de textes qui fait alors office de presse-papiers "manuel", mais j'hy pense toujours après un premier plantage ! Si je n'ai qu'une seule image à enregistrer, ce n'est pas trop grave, mais quand il y en a une floppée, c'est assez rageant !
Depuis le temps, aucune correction n'est en vue ?...
(pour info : je suis sous Xubuntu 18.04 LTS)
Re: Copier/Coller dans la fenêtre d'enregistrement
Che disastro ! Le bug persiste (version 0.93) ! Grrrrrrrrrr...
[test effectué sous Xubuntu]
[test effectué sous Xubuntu]
Re: Copier/Coller dans la fenêtre d'enregistrement
Régression dans la version 0.96.5 : en même temps que certains apports de la version précédente ont disparu (par ex possibilité de corriger n'importe quel nom de fichiers/dossiers dans la fenêtre d'ouverture ou d'enregistrement, y compris sous Xubuntu où c'est impossible en principe !), le "copier" dans le champ de saisie du nom du fichier à enregistrer provoque un freeze de toute l'appli, qu'on ne peut plus quitter autrement qu'en tuant le processus.
Sauf erreur de ma part, l'interface a régressé : le mode de gestion de la version précédente que j'utilisais (0.94.5, sous Xubuntu) était différent (et, à mon goût, plus fluide). Par ex :
Pour le moment, je désinstalle la version 0.96.5 et reviens à la version 0.96.4 qui avait apporté une fluidité bienvenue (heureusement que je renomme mes DEB).
Quoi qu'il en soit, merci infiniment, Pierre !!! Peut-être avez-vous choisi de retourner à une version antérieure de QT pour quelque raison que j'ignore évidemment !
Sauf erreur de ma part, l'interface a régressé : le mode de gestion de la version précédente que j'utilisais (0.94.5, sous Xubuntu) était différent (et, à mon goût, plus fluide). Par ex :
- dans la fenêtre d'enregistrement, une fois la création du nouveau dossier validée en vue d'enregistrer un fichier, on n'était pas immédiatement/automatiquement envoyé dans ce dossier ; commencer à créer le nom du fichier pour lequel on avait créé le nouveau dossier provoquait la suggestion de noms commençant de la même façon, ce qui était bien pratique pour moi : dossier et fichiers contenus commencent souvent de la même façon ! Restait juste ensuite à ne pas oublier d'effectivement aller DANS le dossier.
- [je me répète : ]toujours dans la fenêtre d'enregistrement, tout "copier" (CTRL + C) du nom tapé dans le champ de saisie du nom de fichier à enregistrer fait freezer XnViewMP 0.96.5 de manière irrémédiable, ce qui avait été corrigé dans la version précédente
- le bug du "glisser horizontal" du bord vertical d'une sélection en cours lorsque XnViewMP est maximisé (voir fil), qui avait disparu un moment, est toujours/à nouveau présent.
Pour le moment, je désinstalle la version 0.96.5 et reviens à la version 0.96.4 qui avait apporté une fluidité bienvenue (heureusement que je renomme mes DEB).
Quoi qu'il en soit, merci infiniment, Pierre !!! Peut-être avez-vous choisi de retourner à une version antérieure de QT pour quelque raison que j'ignore évidemment !
Re: Copier/Coller dans la fenêtre d'enregistrement
Je ne comprends pas, rien n'a été modifié de ce coté, et la version de Qt (5.12. n'a pas été changé...
Pierre.
Re: Copier/Coller dans la fenêtre d'enregistrement
en reprenant la 0.96.4, vous n'avez plus de problemes? en installant la 0.96.5, a nouveau?
Pierre.
Re: Copier/Coller dans la fenêtre d'enregistrement
Ah, ça, je n’ai pas essayé (ré-installation de la version 0.96.5)… Le souhaitez-vous ?
Rappel : la régression du glisser horizontal (blocage latéral quand la fenêtre de XNVmp est au max) est antérieure
Quant aux autres petits “soucis”, ils ont disparu sitôt la version 0.96.4 ré-installée
Re: Copier/Coller dans la fenêtre d'enregistrement
1/ Copier(-coller) dans le champ de saisie de nom de la fenêtre d’enregistrement
Je confirme : j’ai d’abord vérifié que le copier-coller dans la fenêtre d’enregistrement (menu contextuel ou CTRL + C) fonctionnait bien dans le champ de saisie ; après suppression de la version 0.96.4, en utilisant
Code: Select all
sudo apt remove xnview
2/ Création d’un dossier qui est interrompue par ex pour aller vérifier une information dans un autre logiciel ouvert
Je confirme : si je commence à taper un nom pour le dossier fraîchement créé (dans la fenêtre d’enregistrement d’une image) et que je quitte momentanément XnViewMP, à mon retour à XnViewMP, la création du dossier a été annulée dans la version 0.96.5 ; dans la version 0.96.4, le fait d’avoir quitté XnVMP a provoqué la validation de ce qui avait déjà été tapé, il suffit de faire (tjs dans la fenêtre d’enregistrement laissée ouverte) un clic droit et de choisir “Renommer” pour finir de taper le nom du nouveau dossier… Or, de toute façon, tout renommage est impossible depuis la fenêtre d’enregistrement dans la version 0.96.5 (clic droit inopérant)…
3/ Accès immédiat à l’intérieur du nouveau dossier, dès validation du nom renseigné
Je confirme : dans la version 0.96.5, dès qu’on valide par [Entrée] le nom du nouveau dossier, on est envoyé “dedans” ; alors que dans la version 0.96.4, la validation “éteint” juste le mode “saisie”, il faut ré-appuyer sur [Entrée] pour pénétrer dans le dossier. Je préfère personnellement le fonctionnement de la version 0.96.4, car, non seulement, en restant dans la fenêtre d’enregistrement d’un fichier, on peut corriger des noms d’autres fichiers ou d’autres dossiers, mais encore, en tapant dans le champ de saisie du nom du fichier à enregistrer, pour peu qu’on choisisse un nom commençant de la même manière que le nouveau dossier fraîchement créé, le système propose ce nom (gain de rapidité pour qui, comme moi, souhaite faire commencer dossier et fichiers contenus de la même manière).
4/ Sélection d’une portion d’image débordant la fenêtre
Je confirme le vieux bug (avait disparu de la seule version 0.94) : le glisser latéral ne déplace pas l’image :
- si celle-ci déborde la fenêtre d’XnViewMP
- et que la fenêtre d’XnViewMP occupe tout le bureau en largeur (par maximisation, ou en amenant les bords verticaux de la fenêtre de XnViewMP aux extrémités de l’écran
---
En tout état de cause, je reviens à la version 0.96.4, nettement plus… pratique !!!
Pour le bug cité en 4/, je mets la fenêtre de XnViewMP avec tous ses bords contre le bord d’écran, sauf le bord droit que j’écarte un tout petit peu du bord : le glisser latéral lors d’une sélection fonctionne impeccablement (bug contourné).
Le bug le plus pénible est le bug cité en 1/…