Tiens, c'est marrant de voir que tu integres directement le "cover" dans le processus de creation des vignettes. J'aurais pense que c'etait plutot quelque chose a gerer directement du cote CSS ?
En tous cas, quand je vois "cover", je m'imagine une regle `width: 100%` qui etire l'image si il le faut cote public. Alors que si le "cover" est applique cote admin au moment de la creation de la vignette, au final ca ne veut pas forcement dire que l'image s'adaptera au layout cote public si l'utilisateur ne prevoit pas ca dans le CSS. Peut-etre que c'est juste un bloquage que j'ai par rapport au terme "cover", alors qu'au final le principe serait tout a fait legitime a appliquer cote admin. Et de toutes facons, mieux vaut avoir trop de choix que pas assez ! :) Ceci dit, la facon dont je m'imagine le truc, ca serait plutot de tout uniformiser sous une seule methode generique (donc plus de contain/cover/crop a definir explicitement), en utilisant le zoom dont tu parles. Pour une image donnee, on aurait donc acces aux dimensions ou au ratio souhaite, au point de focale, et au niveau de zoom. Si le niveau de zoom est a 100%, dans ce cas le resultat est une image resizee. Si le niveau de zoom est superieur a 100%, dans ce cas le resultat est une image croppee et eventuellement resizee. Et niveau organisation, c'est la derniere fois que j'en parle parce que j'ai deja l'impression de faire mon relou a rabacher les memes trucs, mais je trouverais ca tellement plus facile de nommer automatiquement les fichiers avec un id unique (en utilisant `sha1_file` par exemple, ou un timestamp de la date d'upload) plutot que de devoir les nommer manuellement puis les ranger dans certains dossiers. Comme ca on aurait les memes principes et benefices qu'une table SQL : une image = 1 id unique qui ne change pas et qui sert a faire toutes les queries + 1 liste d'attributs tels que nom, description, taille, type, point de focale, etc... Par exemple, si on a une photo a laquelle on a donne comme titre "Verre a moitie plein", et qu'un jour on se decide a la renommer en "Verre a moitie vide", il n'y aurait pas d'URL ou quoi que ce soit a changer, tout continuerait a marcher tel quel et l'eventuel titre affiche cote public serait mis a jour. Apres, il suffit de faire une couche d'abstraction cote admin pour donner a l'utilisateur la possibilite d'organiser et filtrer ses images comme il le souhaite, soit par le biais de categories/sous-categories, de tags, ou bien encore d'autres attributs lies a la date d'upload par exemple. C'est ce que fait Lightroom avec ses metadata, qui au passage propose a mon avis un joli combo UI/UX dont il ne faut pas hesiter a s'inspirer. 2013/10/30 Bruno <[email protected]> > Le 28 octobre 2013 17:07, Christopher Crouzet < > [email protected] > > a écrit : > > > J'en avait deja parle ailleurs mais pour ce qui est des dimensions des > > miniatures, j'aime bien aussi l'idee de pouvoir ajouter des contraintes, > > par exemple : > > - je veux une image de 640px de large avec une hauteur auto (agrandir si > > l'image est trop petite) > > - je veux une image de maximum 640px de large avec une hauteur auto > > > > Pour le moment je suis parti sur les "propriétés" suivantes (je mets de > coté le point de focale qui est spécifique à chaque miniature, mais qui est > pris en compte en cas de crop) : > * Dimensions w et h de la miniature souhaitée > * Prise en compte ou non du mode portrait/paysage (interversion de w et h > le cas échéant selon la miniature) > * Type : "contain", "cover" ou "crop" : > * "contain" = la miniature contient l'image complète, elle peut donc > avoir des marges si le ratio n'est pas le même que celui de l'image > * "cover" = pas de marges dans la miniature, on étire au maximum l'image, > quitte à en perdre des bouts, dans ce dernier cas, on adapte au mieux en > fonction du point de focale > * "crop" : on découpe bêtement en centrant sur le point de focale > > Je ne sais pas si pour le crop il faudrait définir un niveau de zoom ou > pas. > > > Au niveau avancement de nmedia, je ne gère pour l'instant que la partie > admin, et la liste des médias : > * A un répertoire public est associé un "media provider" (probablement > traduit en "bibliothèque" en français) > * Un média provider peut être associé à un ou plusieurs blogs. Dans ce cas > pour chaque blog on peut définir une public_url particulière pour le > media_provider > * Si un blog n'a qu'un media provider, on voit une arborescence comme la > médiathèque actuelle > * Si un blog a plusieurs media providers, alors ils apparaîssent chacun > comme un nouveau niveau de répertoires depuis la racine. > * Chaque media_provider garde en mémoire son arborescence. > > Par rapport à la médiathèque actuelle la gestion des nouveaux > répertoires/médias n'est plus silencieuse : une notification demandera de > confirmer l'ajout de répertoires/images s'ils sont détectés, idem pour la > suppression de médias qui ne sont pas en base. Il faudra un droit > particulier pour ajouter/modifier des médias. > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
