Bon si je me souviens bien, dans le cas du bouton "Ajouter un média" de la page "Ajouter un billet", Le premier fichier post.js, là est définie les caractéristiques du bouton, l'url de la popup et les actions à effectuer au retour. Dans la popup est charger le fichier popup.js, dans lequel il y à la fonction sendClose(), qui est chargé comme sont nom l'indique de renvoyer l'info à la page qui appel et de fermer la popup. var tb=window.opener.the_toolbar; D'après moi ce que tu veut faire devrais marcher, il ni a pas de raison qu'il ne retrouve pas la fenêtre d'origine.

On peut trouver ton code quelque part ?

médias?

L'idée que je propose : - Quand on upload, il n'y a aucun autre format de généré. - Quand on utilise le gestionnaire de médias, on a toujours la possibilité de faire un lien vers la taille "originale" mais c'est le format original qui est inséré (avec peut-être un code JS qui adapte si l'image est plus grande que le champ de texte) - Quand on insère l'image dans le billet on a la possibilité de modifier manuellement la taille de l'image (via width et height?) (en plus il y a déjà un script JS qui permet de modifier la taille sur les billets donc c'est déjà implémenté).

Ouais, j'avais pas pensé à la syntaxe wiki.... Ca rend la chose impossible du coup. nul besoin de fournir à la terre entière une image à 5M de pixels. > > Ouais, je suis d'accord, mais sans aller aussi loin, beaucoup de gens utilisent un système de miniature qui renvoie vers une image plus grande quand on clique (via lightbox par exemple) Mais ok, je vais voir sur le forum si je peux apporter mon grain de sel :-) Le 18 août 2011 10:24, Jean-Michel Royer <jeanmichelroyer(a)gmail.com&gt; a écrit : > Thomas, > > Ce ne serait pas l'occasion justement de le refaire ce gestionnaire de >> médias? > > > La refonte du Gestionnaire des Médias fait partie d'un chantier (à moins > que ma mémoire me fasse défaut, il y a eu des annonces publiques sur le blog > DC). D'ailleurs, je t'invite à lire et à enrichir le fil de discussion > sur le forum <http://forum.dotclear.org/viewtopic.php?id=44679>;. > > > >> L'idée que je propose : >> - Quand on upload, il n'y a aucun autre format de généré. >> - Quand on utilise le gestionnaire de médias, on a toujours la >> possibilité de faire un lien vers la taille "originale" mais c'est le format >> original qui est inséré (avec peut-être un code JS qui adapte si l'image est >> plus grande que le champ de texte) >> - Quand on insère l'image dans le billet on a la possibilité de modifier >> manuellement la taille de l'image (via width et height?) (en plus il y a >> déjà un script JS qui permet de modifier la taille sur les billets donc >> c'est déjà implémenté). >> > > J'ai toujours un problème face à ce genre d'arguments *(c'est qu'une > opinion personnelle)* car : > - comment tu fais le jour où tu as créé des centaines de billets avec des > width et height … et que tu décides de rechanger de thème qui lit voudrait > tel format et pas un autre ? > - comment tu fais pour les utilisateurs qui utilisent le mode wiki ? > > Et entre nous, c'est une mauvaise habitude de ne pas préparer une image > pour une utilisation web ou même bureautique, nul besoin de fournir à la > terre entière une image à 5M de pixels. > > -- > Jean-Michel > > _______________________________________________ > Dev mailing list > Dev(a)list.dotclear.org > http://ml.dotclear.org/listinfo/dev > > -- [image: Thomas] <http://thomas-daveluy.fr/> [image: Blog] <http://blog.thomas-daveluy.fr/> [image: multiprises.fr] <http://multi-prises.fr/> [image: Dailymotion] <http://www.dailymotion.com/I7b> [image: LinkedIn]<http://fr.linkedin.com/pub/thomas-daveluy/33/a07/b04> [image: RSS] <http://blog.thomas-daveluy.fr/index.php?feed/atom> [image: Gmail]&lt;t.daveluy(a)gmail.com&gt; [image: Gmail] <https://plus.google.com/112188517839388455822/posts> [image: Multi-prises] <http://multi-prises.fr/perso/thomas/> Thomas Daveluy 27 rue de Kerlin 56100 Lorient 06.34.02.09.68 _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

Le 18 août 2011 18:57, Simon <my.n(a)me.is.saymonz.net&gt; a écrit : > Et si chaque thème renseignait un paramètres donnant la taille maximale > d'une image dans un article (limitée soit en hauteur, soit en largeur) ? À > l'affichage, Dotclear générerait automatiquement l'image à la taille voulue > par le thème si ce n'est déjà fait, par exemple via un urlHandler spécial > http://blog/FitThemeImage?urlImageOriginale. Ce urlHandler pourrait > prendre via $_GET un paramètre customisé genre h=xxx et/ou w=xxx pour ceux > qui veulent paramétrer ça parfaitement. Ensuite, on modifie la balise > d'insertion d'images wiki pour accepter ces paramètres (url de l'image, > hauteur/largeur maximale [facultatif] et une option pour bypasser ce > comportement et obtenit vraiment l'image originale). > > Oui ? Non ? > Pour moi, on contourne toujours le problème alors qu'on pourrait le résoudre "avant" et il ne répond pas toutes les utilisations. Un simple * max-width* dans la thème ne vous suffit pas? Comment faire avec ta solution, si sur une même installation multi-blog, je partage les mêmes fichiers images dans un unique dossier public mais que j'utilise des thèmes différents demandant des tailles d'images différents ? _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

Le 18 août 2011 20:42, Simon <my.n(a)me.is.saymonz.net&gt; a écrit : > "Un simple *max-width* dans la thème ne vous suffit pas?" C'est > exactement ce dont je parle. Le thème définit la taille d'image idéale pour > lui. À l'affichage d'une image, celle-ci est redimensionnée à la bonne > taille (dans un fichier séparé et caché, par exemple .image_wXXX_hYYY.jpg). > Si plusieurs thèmes demandent la même image dans des formats différents, > l'image sera dupliquée à la bonne taille à chaque fois que ce sera > nécessaire. > Je parlais que de la première partie car la deuxième me parait superflue et prompte à la confusion. Mais pour ne pas rompre la réflexion, comment font les OS tel que OS X (Apple) pour afficher les médias (images) en mode CoverFlow dans le Finder où l'on peut agrandir à volonté (enfin…) ? _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

Le 18 août 2011 21:01, Simon <my.n(a)me.is.saymonz.net&gt; a écrit : > L'inconvénient de faire redimensionner une image par le client sur le web, > c'est l'utilisation superflue de bande passante (envoi de l'image en pleine > taille là où ce n'est pas nécessaire), si c'est là que tu veux en venir. > Alors que pour le print, on aurait plutôt l'inverse (des images trop petites ou pas au bon format), enfin c'est ce que je subis avec mes clients. Encore un paradoxe… _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

Le 19 août 2011 18:17, Thomas Daveluy <t.daveluy(a)gmail.com <mailto:t.daveluy@gmail.com>> a écrit : En fait moi le truc qui me gène c'est l'état du dossier public, encrassé par les 5 formats d'images générés (alors qu'on utilise au mieux 2 formats (originale et miniature) max) et le côté restrictif dans les formats d'images générés J'ai développé un petit plugin qui permet de rajouter autant de formats de miniature que nécessaire. Ça sera publié dès que j'aurais toiletté le code et fait les traductions nécessaires. Je l'utilise chez moi pour rajouter un format "large" (600 pixels max) qui me manquait.