1:25 p.m.
Hello,
Je me pose une question de fond sur le gestionnaire de médias "idéal" :
est-ce que cela fait sens de générer systématiquement toutes les miniatures
de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
tous les formats des miniatures générées ?
Derrière cette question, je m'interroge sur la potentielle pertinence d'une
génération "à la volée" des miniatures, avec une gestion d'un cache des
miniatures quelque part, et une non-imposition par défaut de la génération
des miniatures par le gestionnaire de médias.
Avant de sortir la bouée en béton armé, je précise que la génération à la
volée se ferait une fois pour toutes (sauf changement majeur de
configuration, du genre on change les tailles des miniatures), uniquement
coté administration, qu'il serait possible d'avoir des miniatures fixes si
on les définit comme actuellement,...
Et il serait peut-être intéressant de permettre de les générer / conserver
à un emplacement bien distinct du répertoire d'origine du média en
question...
Vos avis sur la question ?
--
Bruno
4:25 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
C'est une piste intéressante mais j'ai besoin d'y réfléchir un peu
Le lundi 28 octobre 2013, Bruno a écrit :
Hello,
Je me pose une question de fond sur le gestionnaire de médias "idéal" :
est-ce que cela fait sens de générer systématiquement toutes les miniatures
de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
tous les formats des miniatures générées ?
Derrière cette question, je m'interroge sur la potentielle pertinence d'une
génération "à la volée" des miniatures, avec une gestion d'un cache des
miniatures quelque part, et une non-imposition par défaut de la génération
des miniatures par le gestionnaire de médias.
Avant de sortir la bouée en béton armé, je précise que la génération à la
volée se ferait une fois pour toutes (sauf changement majeur de
configuration, du genre on change les tailles des miniatures), uniquement
coté administration, qu'il serait possible d'avoir des miniatures fixes si
on les définit comme actuellement,...
Et il serait peut-être intéressant de permettre de les générer / conserver
à un emplacement bien distinct du répertoire d'origine du média en
question...
Vos avis sur la question ?
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org <javascript:;> -
http://ml.dotclear.org/listinfo/dev
--
Franck
4:37 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le lundi 28 octobre 2013, Bruno a écrit :
> Derrière cette question, je m'interroge sur la potentielle pertinence
d'une
> génération "à la volée" des miniatures, avec une gestion d'un cache
des
> miniatures quelque part, et une non-imposition par défaut de la
génération
> des miniatures par le gestionnaire de médias.
>
C'est quelque chose que l'on retrouve sur pas mal de sites.
Prenez par exemple cette image :
http://www.ouest-france.fr/photos/2013/10/07/131007180919011_34_000_apx_4...
changez le 470 par ce que vous voulez (jusqu'à la limite de la taille
originale) et vous avez toutes les tailles désirées (ex:
http://www.ouest-france.fr/photos/2013/10/07/131007180919011_34_000_apx_3...
).
Le système est assez simple : lorsque l'on demande une image située dans le
gestionnaire de médias, si on spécifie une taille à la fin du nom de
fichier, le script vérifie si elle existe. Si ce n'est pas le cas, elle est
créée et enregistrée en dur.
Avantage : ça allège le contenu du gestionnaire de médias qui se passe des
miniatures inutiles et lors de l'insertion on peut vraiment mettre la
taille que l'on veut (on peut même imaginer une version mobile qui remplace
en chargeant des fichiers 2x plus petits). D'ailleurs côté public ça
devrait être rapide à charger vu que la miniature est appelée lorsqu'on
créé le billet en partie admin.
Inconvénient : si un petit malin s'amuse à charger 100 fois le fichier avec
+1 pixel à chaque fois ça duplique d'autant les fichiers
Moi perso je trouve que ça serait un vrai plus.
--
Thomas
4:43 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
L'inconvénient me fait très peur et qui des entêtes http expired?
Le 28 octobre 2013 16:37, Thomas Daveluy <t.daveluy(a)gmail.com> a écrit :
Inconvénient : si un petit malin s'amuse à charger 100 fois le
fichier avec
+1 pixel à chaque fois ça duplique d'autant les fichiers
4:48 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le 28 octobre 2013 16:37, Thomas Daveluy <t.daveluy(a)gmail.com> a écrit :
Inconvénient : si un petit malin s'amuse à charger 100 fois le
fichier avec
+1 pixel à chaque fois ça duplique d'autant les fichiers
Non ce n'est pas ça l'inconvénient. Le réel inconvénient c'est que
fabriquer des images demande beaucoup de ressources (mémoire et cpu) et le
p'tit malin risque de surcharger le serveur pour quelque chose qui n'est
pas prévu.
Si vraiment on veut faire ce genre de choses c'est d'en limiter l'impact
par exemple en limitant le nombre de taille possible côté admin. Si le
format n'existe pas on renvoie rien par exemple.
Si vous voulez un exemple de ce procédé, les dernières version de piwigo
font cela. Il y a N formats disponibles et les images sont fabirquées à la
volée.
4:49 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Inconvénient : si un petit malin s'amuse à charger 100 fois le fichier avec
+1 pixel à chaque fois ça duplique d'autant les fichiers
C'est la raison pour laquelle je ne veux permettre la génération de
miniatures que depuis l'admin dans un premier temps...
4:58 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Je profite de l'"attrait" sur ce sujet pour rediscuter des règles de
génération des miniatures. Savez-vous si quelque part sur la toile, on
définit les "propriétés" d'une miniature ?
Je m'explique : aujourd'hui, dans le gestionnaire de médias, on a 2 types
de miniatures : les miniatures selon un ratio (je veux une miniature à 66%
de l'image originale), et celles selon un "découpage" (je "croppe"
32px par
32 px). Ce qui empêche parfois d'avoir des crop pertinents (genre si le
visage est à droite de l'image)
En réfléchissant, je vois les "facteurs" suivants, qui pourraient aider à
calculer une miniature :
* Le ratio de la miniature par rapport à l'image (100% pour un simple crop,
à une dimension calculée pour un resizing)
* Les dimensions de la miniature
* Le point d'intérêt ("cible" lorsqu'on fait un crop, plutôt que de
rester
sur le centre de l'image).
J'ai oublié des facteurs ?
--
Bruno
Le 28 octobre 2013 13:25, Bruno <dsls(a)morefnu.org> a écrit :
Hello,
Je me pose une question de fond sur le gestionnaire de médias "idéal" :
est-ce que cela fait sens de générer systématiquement toutes les miniatures
de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
tous les formats des miniatures générées ?
Derrière cette question, je m'interroge sur la potentielle pertinence
d'une génération "à la volée" des miniatures, avec une gestion d'un
cache
des miniatures quelque part, et une non-imposition par défaut de la
génération des miniatures par le gestionnaire de médias.
Avant de sortir la bouée en béton armé, je précise que la génération à la
volée se ferait une fois pour toutes (sauf changement majeur de
configuration, du genre on change les tailles des miniatures), uniquement
coté administration, qu'il serait possible d'avoir des miniatures fixes si
on les définit comme actuellement,...
Et il serait peut-être intéressant de permettre de les générer / conserver
à un emplacement bien distinct du répertoire d'origine du média en
question...
Vos avis sur la question ?
--
Bruno
5:07 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
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
2013/10/28 Bruno <dsls(a)morefnu.org>
Je profite de l'"attrait" sur ce sujet pour rediscuter
des règles de
génération des miniatures. Savez-vous si quelque part sur la toile, on
définit les "propriétés" d'une miniature ?
Je m'explique : aujourd'hui, dans le gestionnaire de médias, on a 2 types
de miniatures : les miniatures selon un ratio (je veux une miniature à 66%
de l'image originale), et celles selon un "découpage" (je
"croppe" 32px par
32 px). Ce qui empêche parfois d'avoir des crop pertinents (genre si le
visage est à droite de l'image)
En réfléchissant, je vois les "facteurs" suivants, qui pourraient aider à
calculer une miniature :
* Le ratio de la miniature par rapport à l'image (100% pour un simple crop,
à une dimension calculée pour un resizing)
* Les dimensions de la miniature
* Le point d'intérêt ("cible" lorsqu'on fait un crop, plutôt que de
rester
sur le centre de l'image).
J'ai oublié des facteurs ?
--
Bruno
Le 28 octobre 2013 13:25, Bruno <dsls(a)morefnu.org> a écrit :
> Hello,
>
> Je me pose une question de fond sur le gestionnaire de médias "idéal" :
> est-ce que cela fait sens de générer systématiquement toutes les
miniatures
> de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
> tous les formats des miniatures générées ?
>
> Derrière cette question, je m'interroge sur la potentielle pertinence
> d'une génération "à la volée" des miniatures, avec une gestion
d'un cache
> des miniatures quelque part, et une non-imposition par défaut de la
> génération des miniatures par le gestionnaire de médias.
>
> Avant de sortir la bouée en béton armé, je précise que la génération à la
> volée se ferait une fois pour toutes (sauf changement majeur de
> configuration, du genre on change les tailles des miniatures), uniquement
> coté administration, qu'il serait possible d'avoir des miniatures fixes
si
> on les définit comme actuellement,...
>
> Et il serait peut-être intéressant de permettre de les générer /
conserver
> à un emplacement bien distinct du répertoire d'origine du média en
> question...
>
> Vos avis sur la question ?
>
> --
> Bruno
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
5:15 p.m.
Ça c'est à gérer en amont et/ou css amha
--
Patrick Olivier
Le 28 oct. 2013 à 17:07, Christopher Crouzet
<christopher.crouzet(a)gmail.com> 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
2013/10/28 Bruno <dsls(a)morefnu.org>
> Je profite de l'"attrait" sur ce sujet pour rediscuter des règles de
> génération des miniatures. Savez-vous si quelque part sur la toile, on
> définit les "propriétés" d'une miniature ?
>
> Je m'explique : aujourd'hui, dans le gestionnaire de médias, on a 2 types
> de miniatures : les miniatures selon un ratio (je veux une miniature à 66%
> de l'image originale), et celles selon un "découpage" (je
"croppe" 32px par
> 32 px). Ce qui empêche parfois d'avoir des crop pertinents (genre si le
> visage est à droite de l'image)
>
> En réfléchissant, je vois les "facteurs" suivants, qui pourraient aider à
> calculer une miniature :
> * Le ratio de la miniature par rapport à l'image (100% pour un simple crop,
> à une dimension calculée pour un resizing)
> * Les dimensions de la miniature
> * Le point d'intérêt ("cible" lorsqu'on fait un crop, plutôt que de
rester
> sur le centre de l'image).
>
> J'ai oublié des facteurs ?
>
> --
> Bruno
>
>
>
> Le 28 octobre 2013 13:25, Bruno <dsls(a)morefnu.org> a écrit :
>
>> Hello,
>>
>> Je me pose une question de fond sur le gestionnaire de médias "idéal"
:
>> est-ce que cela fait sens de générer systématiquement toutes les
> miniatures
>> de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
>> tous les formats des miniatures générées ?
>>
>> Derrière cette question, je m'interroge sur la potentielle pertinence
>> d'une génération "à la volée" des miniatures, avec une gestion
d'un cache
>> des miniatures quelque part, et une non-imposition par défaut de la
>> génération des miniatures par le gestionnaire de médias.
>>
>> Avant de sortir la bouée en béton armé, je précise que la génération à la
>> volée se ferait une fois pour toutes (sauf changement majeur de
>> configuration, du genre on change les tailles des miniatures), uniquement
>> coté administration, qu'il serait possible d'avoir des miniatures fixes
> si
>> on les définit comme actuellement,...
>>
>> Et il serait peut-être intéressant de permettre de les générer /
> conserver
>> à un emplacement bien distinct du répertoire d'origine du média en
>> question...
>>
>> Vos avis sur la question ?
>>
>> --
>> Bruno
> --
> Dev mailing list - Dev(a)list.dotclear.org -
> http://ml.dotclear.org/listinfo/dev
--
Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev
7:02 p.m.
Ce qui serait vraiment utile d'après ce que j'ai lu sur le forum, c'est :
- une fonction qui limite le format original. Exemple : les utilisateurs peu au fait des
tailles utiles et qui balance son image au format pris par son APN. On aurait un
avertisseur (comme sur Outlook ou iOS) qui leur suggérait une action de réduction (faite
par Dotclear). Même si pour moi, ce type d'action doit être fait un amont avant de
poster avec un logiciel approprié.
- une fonction qui clean le nom des fichiers (caractères exotiques) voir qui pratique une
nomenclature définie.
2:12 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le 28 octobre 2013 17:07, Christopher Crouzet <christopher.crouzet(a)gmail.com
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.
10:30 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
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 <dsls(a)morefnu.org>
Le 28 octobre 2013 17:07, Christopher Crouzet <
christopher.crouzet(a)gmail.com
> 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 - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
10:38 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le 30 octobre 2013 22:30, Christopher Crouzet <christopher.crouzet(a)gmail.com
a écrit :
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.
Ce qui, de fait, interdirait tout action directe via FTP sur le serveur.
Conserver un id "aléatoire" ou "généré" à la volée pour conserver un
lien
entre un média et un billet, ok, modifier le fichier lui-même, non. L'id
faisant le lien entre media et billet, un changement de titre comme montré
en exemple serait facilement géré.
10:41 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Encore une chose, Lightroom ne modifie pas les noms des fichiers et les
stocke dans des dossiers hiérarchiques année/mois/jour (je ne me souviens
plus si c'est le réglage par défaut, mais c'est en tout cas celui que
j'utilise et que j'ai vu utilisé ailleurs).
J'ai adopté le même principe pour la partie "photo" des médias que je mets
en ligne avec DC.
11:07 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
C'est exact, Lightroom ne modifie rien du tout des fichiers originaux,
toutes les modifs et autres donnees sont enregistrees dans des fichiers de
metadata separes.
Un ID faisant le lien entre le media et le fichier sur le filesystem
pourrait effectivement marcher aussi... si ce n'est que les images inserees
dans des posts sous forme de balise HTML ne peuvent pas utiliser de balises
genre {{tpl:getImageUrl id="12345"}} pour eventuellement referencer le vrai
chemin de l'image en utilisant un ID donne, non ? En tous cas, j'avais
essaye a l'epoque avec la syntaxe markdown, et ca ne marchait pas. Du coup
ca veut dire que le truc important serait de conserver le nom du fichier au
moment de l'upload, et que le media manager ne doive jamais le modifier,
quoi qu'il arrive. Ca devient juste chiant dans le cas ou l'utilisateur
uploade 2 images avec le meme nom, et c'est a cause de ce dernier point que
je trouvais ca plus facile et robuste de simplement renommer les fichiers a
la volee, mais je comprends que ca ne plaise pas. Ca pourrait peut-etre
etre une option ? :)
2013/10/30 Franck Paul <carnet.franck.paul(a)gmail.com>
Encore une chose, Lightroom ne modifie pas les noms des fichiers et
les
stocke dans des dossiers hiérarchiques année/mois/jour (je ne me souviens
plus si c'est le réglage par défaut, mais c'est en tout cas celui que
j'utilise et que j'ai vu utilisé ailleurs).
J'ai adopté le même principe pour la partie "photo" des médias que je mets
en ligne avec DC.
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
11:15 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le 30 octobre 2013 23:07, Christopher Crouzet <christopher.crouzet(a)gmail.com
a écrit :
C'est exact, Lightroom ne modifie rien du tout des fichiers
originaux,
toutes les modifs et autres donnees sont enregistrees dans des fichiers de
metadata separes.
Un ID faisant le lien entre le media et le fichier sur le filesystem
pourrait effectivement marcher aussi... si ce n'est que les images inserees
dans des posts sous forme de balise HTML ne peuvent pas utiliser de balises
genre {{tpl:getImageUrl id="12345"}} pour eventuellement referencer le vrai
chemin de l'image en utilisant un ID donne, non ? En tous cas, j'avais
essaye a l'epoque avec la syntaxe markdown, et ca ne marchait pas. Du coup
ca veut dire que le truc important serait de conserver le nom du fichier au
moment de l'upload, et que le media manager ne doive jamais le modifier,
quoi qu'il arrive. Ca devient juste chiant dans le cas ou l'utilisateur
uploade 2 images avec le meme nom, et c'est a cause de ce dernier point que
je trouvais ca plus facile et robuste de simplement renommer les fichiers a
la volee, mais je comprends que ca ne plaise pas. Ca pourrait peut-etre
etre une option ? :)
On pourra ajouter un SHA-1 par la suite pour gérer la détection de
doublons, mais
pas pour le nom du fichier. Il ne faut pas oublier les gens
qui uploadent autre chose que des photos, et la rétro-compatibilité avec
les médias déjà en place :)
Le répertoire de stockage est un filtre comme un autre, d'ailleurs
actuellement par défaut on affiche __tous__ les médias en base sans
distinction.
Tu soulèves un autre point qui sera un prochain chantier après la refonte
de la médiathèque, un moteur de macros indépendant (le #956), où
effectivement on mentionnera un média par son ID plutôt qu'une insertion
brute, et qui ouvrira plein de possibilités:.
Mais chaque chose en son temps, il y a encore du boulot sur le gestionnaire
de médias. Gros avantage toutefois : la médiathèque aujourd'hui, c'est 99%
coté admin, donc assez peu d'impact sur la partie publique ... pour
l'instant.
--
Bruno
5:03 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Cette génération serait déclenchée par l'appel d'un format, c'est ça ? (Je
pense aux galeries ou EntryFirstImage par exemple).
Le 28 octobre 2013 13:25, Bruno <dsls(a)morefnu.org> a écrit :
Hello,
Je me pose une question de fond sur le gestionnaire de médias "idéal" :
est-ce que cela fait sens de générer systématiquement toutes les miniatures
de tous les médias d'un blog donné ? Autrement dit, un blog utilise-t-il
tous les formats des miniatures générées ?
Derrière cette question, je m'interroge sur la potentielle pertinence d'une
génération "à la volée" des miniatures, avec une gestion d'un cache des
miniatures quelque part, et une non-imposition par défaut de la génération
des miniatures par le gestionnaire de médias.
Avant de sortir la bouée en béton armé, je précise que la génération à la
volée se ferait une fois pour toutes (sauf changement majeur de
configuration, du genre on change les tailles des miniatures), uniquement
coté administration, qu'il serait possible d'avoir des miniatures fixes si
on les définit comme actuellement,...
Et il serait peut-être intéressant de permettre de les générer / conserver
à un emplacement bien distinct du répertoire d'origine du média en
question...
Vos avis sur la question ?
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Anne / Kozlika
5:07 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
Le 28 octobre 2013 17:03, Kozlika <kozlika(a)gmail.com> a écrit :
Cette génération serait déclenchée par l'appel d'un format,
c'est ça ? (Je
pense aux galeries ou EntryFirstImage par exemple).
En fait je voudrais éviter cela, afin de ne pas avoir une surcharge coté
public. L'idée serait de pré-générer les miniatures dont on aurait besoin.
Exemple : un média inclus dans un billet verrait ses miniatures "standard"
prégénérées (si elles ne le sont pas déjà).
Ou alors : on autorise un certain nombre de formats de miniatures, qu'on
peut effectivement déclencher depuis un appel public, mais on n'autorise
pas les générations de miniatures "exotiques". Bien sûr, on garde les
miniatures en cache pour ne pas avoir à les régénérer.
--
Bruno
5:48 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
J'ai vérifié sur mon blog, plutôt hétérogène, et il s'avère que j'utilise
d'une manière ou d'une autre chacune des tailles dispos et même plus
puisque j'ai développé à cette fin un plugin qui permet d'en ajouter et
dont je me sers régulièrement sur Open-Time et Open-Eyes.
Je ne sais pas si ça apporte de l'eau au moulin, mais c'est en tout cas un
des usages actuels des miniatures.
Le 28 octobre 2013 17:07, Bruno <dsls(a)morefnu.org> a écrit :
Le 28 octobre 2013 17:03, Kozlika <kozlika(a)gmail.com> a écrit
:
> Cette génération serait déclenchée par l'appel d'un format, c'est ça ?
(Je
> pense aux galeries ou EntryFirstImage par exemple).
>
En fait je voudrais éviter cela, afin de ne pas avoir une surcharge coté
public. L'idée serait de pré-générer les miniatures dont on aurait besoin.
Exemple : un média inclus dans un billet verrait ses miniatures "standard"
prégénérées (si elles ne le sont pas déjà).
Ou alors : on autorise un certain nombre de formats de miniatures, qu'on
peut effectivement déclencher depuis un appel public, mais on n'autorise
pas les générations de miniatures "exotiques". Bien sûr, on garde les
miniatures en cache pour ne pas avoir à les régénérer.
--
Bruno
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
--
Franck
8:01 p.m.
New subject: [Dotclear Dev] [Refonte gestionnaire de médias] Réflexion sur les miniatures
En fait je voudrais éviter cela, afin de ne pas avoir une surcharge coté
public. L'idée serait de pré-générer les miniatures dont on aurait besoin.
Exemple : un média inclus dans un billet verrait ses miniatures "standard"
prégénérées (si elles ne le sont pas déjà).
Ou alors : on autorise un certain nombre de formats de miniatures, qu'on
peut effectivement déclencher depuis un appel public, mais on n'autorise
pas les générations de miniatures "exotiques". Bien sûr, on garde les
miniatures en cache pour ne pas avoir à les régénérer.
Le bon moment pourrait être au moment où on insère l'image dans le billet
ou au moment de la soumission du formulaire (On peut à la limite remplir un
champ caché avec les médias ajoutés au billet pour éviter de devoir parser
le contenu du dit billet). L'avantage est qu'on ne fabrique que les
éléments nécessaires.
En revanche, pour tous les usages non maîtrisés je ne sais pas comment
gérer cela. Je m'explique : j'ai un blog et à côté un site "ami" qui
utilise le flux rss pour récupérer les derniers billets. Ce site utilise
les miniatures carrés pour que cela s'intègre correctement dans sa charte.
3853
days inactive
3855
days old
19 comments
8 participants
participants (8)
-
Bruno -
Christopher Crouzet -
Franck Paul -
Jean-Michel Royer -
Kozlika -
Nicolas -
Patrick Olivier -
Thomas Daveluy