Pierrick Le Gall a écrit 215 commentaires

- Support des tags en plus de la posibilité de créer des albums photos.

Les tags existent et sont gérés par l'administrateur, pas par les visiteurs. La notion d'album photo n'existe pas dans PhpWebGallery. Les 2 principales méthodes de classification sont les catégories hierarchiques et les tags.

- Possibilité de partager des albums ou des thèmes entre plusieurs contributeurs.

Non supporté. PhpWebGallery a vocation à être une galerie mono-administrateur. Il ne s'agit pas de créer un site communautaire où plusieurs photographes publieraient leurs oeuvres. (on aboutirait à un Flickr, d'ailleurs). Je ne dis pas qu'on ne peut pas le faire, car certains l'ont fait comme la galerie concours de megapixel, mais PhpWebGallery n'est pas conçu pour ce type d'utilisation.

- Fonctions avancées de gestion des ACLs sur les photos et les albums.

Supporté à moitié. Les catégories sont soumises à des droits que l'on peut donner à un utilisateur en particulier ou à un groupe d'utilisateurs. Les droits sur les photos indépendantes ne sont pas supportés. Je compte lancer une réflexion à ce sujet cet été pour voir ce qu'on garde et ce qu'on améliore dans le fonctionnement actuel des permissions.

- Fonctions de retouches basiques

Non désolé. Je milite fortement pour que PhpWebGallery ne soit qu'un système de publication de photos en ligne, pas un système de retouche de photos.

- Visualisation chronologique (à la Flickr)

Supporté depuis la 1.6. Basé sur le même principe que Flickr, mais en mieux car n'importe quel ensemble de photos peut être affiché chronologiquement, pas uniquement la totalité des photos. Par exemple, je peux afficher le calendrier des photos tagguées "noir et blanc".

- Fils RSS ou mailing automatique.

Le flux RSS sert à la notification des nouveautés apparues sur la galerie. Le mailing est semi-automatique : seul un administrateur peut déclencher l'envoi des mail sous forme de résumé des nouveautés. Chaque membre inscrit à la notification par mail reçoit les informations de nouveautés par rapport à sa dernière notification.

Koha [...] (ca tourne peut être avec postgres maintenant)

Non, ça ne tourne toujours pas sur PostgreSQL. Certaines requêtes restent spécifiques à MySQL. De toute façon, pour la future 3.0, un second moteur d'indexation de notices bibliographiques sera nécessaire, il s'agit de Zebra. On pourrait penser que ça ne répond pas à la question, mais je veux dire que si on "impose" le quasi inconnu Zebra, alors on peut aussi "imposer" le très classique MySQL.

ta gallerie fait beaucoup de "pro" que la mienne, y'a pas a dire, félicitation

Merci. Public visé = agence de presse, photographes indépendants et amateurs (comme moi et la plupart des membres de l'équipe). Public non visé = sites communautaires (même si les membres du forum Megapixel l'utilise pour leurs concours photo).

ton système de zoom est interessant

Mais, de quoi parles-tu ? le fait de passer de la page des miniatures à la page qui présente la photo en taille "normale" ?

Je ne souhaite pas polluer ton topic Snarky, mais ton journal m'a inspiré un billet sur mon blog : http://le-gall.net/pierrick/blog/index.php/2006/02/03/60 à propos de la prolifération des applications de galerie photos. Pour information, je suis à l'origine d'une autre galerie photo qui s'appelle PhpWebGallery, qui n'a pas les mêmes objectifs que VisualPic.

Bon courage avec ton projet. (il manque quand même la démo sur le site de présentation)

Et j'ajoute que la 1.4.2 n'est pas sortie la semaine dernière, faute de temps disponible. Elle devrait sortir le WE prochain.

A propos des bogues de sécurité corrigés par la 1.5.2... j'ai trouvé la notification de ces bogues quasiment par hasard en faisant une recherche sur Google. Le testeur a d'abord écrit sur son blog puis a notifié les Securityfocus et compagnie. La notification initiale datait du 13 décembre, j'ai trouvé l'information le 24, la correction a été publiée le 25. Je trouve dommage de ne pas avoir été averti directement sur le bugtracker du projet :-/

En lisant ton journal, je me suis dit "super, je vais enfin pouvoir écrire foo : bar et qu'Emacs ne coupe pas la ligne entre foo et :". Et bien non, déception, Emacs coupe quand même. Je continue à faire comme en anglais : pas d'espace avant le :.

PS : si quelqu'un a la solution, je suis à l'écoute :-)

Clairement, PhpWebGallery et ZenPhoto ne poursuivent pas le même objectif. ZenPhoto s'oriente plutôt vers la sobriété extrême de l'interface utilisateur, les photos avant tout. PhpWebGallery s'oriente vers "les choses simples doivent être faciles à faire et les choses complexes doivent être possibles" (inspiré du langage de programmation Perl).

Il y a des fonctionnalités vraiment très avancées dans PhpWebGallery, notamment concernant la gestion des catégories. Ces fonctionnalités avancées ne doivent pas gêner l'utilisateur débutant qui veut simplement une galerie qui fonctionne.

En mai 2005, j'ai donné sur mon blog [1] ma vision du positionnement de PhpWebGallery. Les phrases clef sont :

- Galerie orientée mono-administrateur
- Faire facilement les choses simples, pouvoir faire des choses complexes
- Faire une seule chose, mais bien le faire.
- La simplicité est une caractéristique importante (navigation, configuration, administration)
- La rapidité est également une caractéristique clef
- PWG est une application "standalone"
- L'important, c'est l'interfaçage avec les autres applications, pas l'intégration dans d'autres applications.

[1] http://le-gall.net/pierrick/blog/index.php/2005/05/17/22

Je suis heureux que parmi le surnombre d'application de galleries photos, certaines comme Gallery ou ZenPhoto se démarquent. PhpWebGallery n'a pas atteint cette popularité, cela arrivera si l'application le mérite et si l'équipe est capable de suivre les demandes utilisateurs (et pour ça, on a besoin d'aide).

Je confirme, la conférence était très claire. J'en ressors avec l'impression que Subversion va vivre de belles années avant qu'un VCS décentralisé ne fasse l'unanimité. Pour l'heure, les prochaines années seront celles des migrations CVS vers SVN.

Les concepts de VCS décentralisé ne sont de toute façon pas encore abordable pour la majorité des développeurs. On verra dans quelques années si l'idée a fait son chemin :-) je l'espère.

D'habitude, pour les conférences Parinux, il faut s'inscrire. Cette fois-ci, je ne trouve pas cette conférence sur le site de parinux [1] et de toute façon, je n'arrive plus à m'y connecter.

Bref, on peut venir sans s'être inscrit ? je suis très intéressé.

[1] http://parinux.org/activites/conf

Je suis bien d'accord avec toi. D'ailleurs, je ne comprends pas comment un magazine d'une telle faiblesse rédactionnelle puisse être vendu en kiosque. Je donne l'impression de m'acharner, mais voici quelques extraits (les fautes d'orthographe sont d'origine) :

Il peuvent largement remplacer les solutions payantes du commerce, les suites Office Machinchose et autres logiciels de traitement d'image de Daube

Attention, bande de Blaireaux, [...] Gnome en version 2.21 [...] OpenOffice.org 2.0 baet 2

PhpWebGallery [1] permet d'associer une photo à N catégories. Attention, je parle bien de catégories et pas de tags. La fonctionnalité des tags telle qu'on la connaît sur Flickr [2] ou Blogmarks [3] n'apparaîtra qu'en branche 1.6 (mars 2006 en release officielle). J'ai rédigé [4] sur mon blog, un billet décrivant la différence entre catégories et tags (c'est un avis perso, je ne prétend pas détenir LA vérité). Pour résumer, j'oppose classification hierarchique (catégories) et plane (tags).

L'avantage avec PhpWebGallery, c'est qu'une photo peut être associée à N catégories hierrachiques. L'inconvénient, c'est qu'en branche 1.4 (la branche stable actuelle), l'ergonomie pour associer une photo à une catégorie est pourrie. La branche 1.5 offre une nouvelle ergonomie pour gérer cela dans de meilleures conditions [5]. La branche 1.5 est cours d'accouchement et comme en 1.4, une news sera proposée sur linuxfr lors de la sortie officielle.

[1] http://phpwebgallery.net(...)
[2] http://www.flickr.com/photos/tags(...)
[3] http://blogmarks.net(...)
[4] http://le-gall.net/pierrick/blog/index.php/2005/05/11/17-systeme-de(...)
[5] http://le-gall.net/pierrick/blog/index.php/2005/04/17/8-panier-et-g(...)

Désolé si ce commentaire fait un peu propagande en plein milieu d'une news sur Gallery2 (projet très actif et complémentaire, PhpWebGallery ne fait évidemment pas le poids en terme de popularité, mais c'est pas le plus important). Je pense répondre à laquestion de Chl :-)

PhpWebGallery [1], "out-of-the-box" offre la à peu près la fonctionnalité que tu cherches. L'image "haute résolution" est optionnelle et lorsqu'elle est présente, un lien supplémentaire est disponible pour afficher (et non télécharger, là est la différence) l'image en haute résolution.

[1] http://phpwebgallery.net(...)

Quant aux utilisateurs, c'est natif, comme la gestion des permissions, des groupes (pour simplifier la gestion des permissions).

Licence GPL donc tu peux modifier et proposer le patch :-)

Il y a des demandes d'évolution [2], et des discussions [3] en cours sur le sujet.

[2] http://bugs.phpwebgallery.net/view.php?id=127(...)
[3] http://forum.phpwebgallery.net/viewtopic.php?id=4384(...)

Et puis il y a sûrement plein d'autres avantages.

Oui, et à mon avis tu as oublié le plus important de tous : l'atomicité des commits. Pour moi, c'est ça la "killer-feature" de Subversion par rapport à CVS.

Sous CVS, les commits sont gérés fichier par fichier. Les numéros de version sont indépendants fichier par fichier. Et lorsqu'on fait des merges entre branches sur un module complet, faut s'accrocher. Par exemple il faut bien du courage pour faire un merge entre une branche A et une branche B à partir d'autre chose que les dernières versions des fichiers sur la branche mergée. (tout simplement parce qu'on ne peut pas faire à la fois -r <ma_branche> et -D <ma date>) La solution que j'emploie est un peu batarde, limite lourdingue : mettre des tags sur l'intégralité des mes modules sur les niveaux des commits que je suis susceptible de vouloir merger plus tard :-/

Sous SVN, tranquille, j'ai un numéro de version à merger, je le connais, il est unique : les numéros de version, en plus d'être simplifiés car sous forme d'entier incrémenté, sont propre au dépôt complet.

Je vois juste un avantage à mettre toutes les photos dans la BDD : certains hébergeurs mutualisés ne comptent pas la taille de la BDD dans le quota... plutot pratique avec de grosses bases.

Oui mais si tu es sur un hébergement mutualisé, tu as généralement des performances moins bonnes (en tout cas aux heures d'affluence) et mettre les images en base risque de bloquer complètement :-(

Je n'en ai pas la moindre idée. Il ne m'avaient d'ailleurs pas contacté pour mettre à disposition PhpWebGallery (PWG) pour leurs abonnés. Cela ne m'avait pas spécialement gêné (contrairement à d'autres auteurs d'applications, voir la controverse concernant l'excellent DotClear : http://www.neokraft.net/blog/2004/12/03/559-la-liberte-ca-a-un-prix(...) )

S'ils me contactent, je leur donnerai les billes pour faire ça proprement et sans perte d'informations stockées en base.

Pour ceux qui n'utilisent pas l'installation automatique chez free.fr, sachez que les scripts d'upgrade depuis toutes les versions de la branche 1.3 sont inclus dans l'archive. La lecture du README, section "mise à jour" vous guidera.

SQLite

C'est plus ou moins une idée qui germe dans mon esprit : supporter un autre SGBD que MySQL. PostGreSQL par exemple, SQLite ensuite. Pour cela, il sera nécessaire de rajouter une couche d'abstraction entre l'application et la base de données. C'est un tavail conséquent que je ne suis pas prêt à entreprendre pour le moment.

Sur le principe, SQLite me plaît évidemment, et il se pourrait bien qu'il soit plus rapide que MySQL pour une application du type galerie d'images.

Jusqu'à la branche 1.2 incluse, le code HTML était confondu avec le code PHP. Pour les développements de la future branche 1.3, j'ai choisi d'utiliser un moteur de template. J'ai pesé le pour et le contre de l'utilisation de templates, c'est un débat récurrent parmi les développeurs web. Même Rasmus LERDORF (développeur à l'origine de PHP) a un avis tranché : l'utilisation de moteur de template est une hérésie car PHP est lui même déjà un moteur de template, et qu'il est inutile d'avoir à réapprendre un nouveau langage.

Je ne partage pas complètement l'avis de l'auteur de PHP car seuls les moteurs de template permettent d'imposer la séparation de l'HTML et du PHP. Par contre, en effet, je trouve inutile d'avoir besoin de connaître un langage de programmation supplémentaire. C'est pour cela que le moteur de template doit selon moi rester simple (troll : éliminant ainsi Smarty, que j'utiliserai volontiers sur un projet perso). Seul, mon choix s'était porté sur VTemplate pour la branche 1.3. Malheureusement, ce moteur n'est plus maintenu et les messages d'erreurs sont difficiles à interpréter. Un nouveau membre a rejoint l'équipe (Gweltas) et a pris en main la gestion des templates. Son premier travail fut de passer à PHPLib.

La séparation actuelle du HTML et du PHP est bien plus claire et rend l'application bien plus simple à maintenir tout en restant facile à faire évoluer. Il ne faut pas non plus oublier que l'un des premiers objectifs de cette séparation est de permettre à des non développeurs (des graphistes) de créer des templates sans avoir besoin de plonger dans le code PHP.

Une partie du code html généré est déportée au niveau du moteur de templates et pas du template lui-même.

??? je ne comprend pas ce que tu veux dire. Si tu cites un exemple de code HTML généré par PHPLib qui n'est pas dans un template, je me ferai une meilleure idée.

en général, on conseille justement de stocker les données dans une BD et les fichiers dans un FS qui est fait pour ça, c'est accédé + rapidement, et évite de mettre la base à genoux.

Evidemment, je confirme que ce choix est très généralement admis comme étant le bon. Concernant PhpWebGallery, je n'ai pas hésité, ce choix n'en était pas vraiment un.

Pour anecdote, lorsque le projet débutait, j'étais stagiaire dans une boîte d'édition de CMS (Content Management System) qui avait choisi de tout stocker en base, même les documents binaires (fichiers images, vidéos, documents PDF). J'avoue sincèrement que c'était à la fois complexe et particulièrement peu fiable.

Eventuellement, le seul avantage que je vois concernant le stockage des images en base concerne la sécurité : difficile d'obliger l'application à vous montrer une image à laquelle vous n'avez pas accès normalement (sauf bug dans l'application...). Il est de toute façon très possible d'interdire l'accès à un répertoire web en navigation directe... l'argument devient donc difficile à défendre.

il existe des galleries qui stocke tout dans le FS

En effet et je trouve ça plus propre, notamment pour les sauvegardes. Malheureusement, ce choix conceptuel freine les possibilités d'abstraction logique offerte par la base de données. Je ne dis pas que certaines fonctionnalités deviennent impossible à coder, mais qu'elle seront bien plus difficiles à implémenter et risque de faire chuter les performances.

A titre d'exemples, il est intéressant de pouvoir associer une image à plusieurs catégories sans dupliquer physiquement le fichier, de créer des catégories virtuelles logiques. Ce type de fonctionnalité est triviale avec une BD comme backend, lourd à implémenter avec uniquement un FS.

NB : je conçois parfaitement que ce type de fonctionnalité puisse être considéré comme inutile par certains.

Cela m'étonne franchement. J'ai vu les 2 films et bien que le dernier trappeur offre des paysages somptueux et quelques animaux bien sympa, il est vraiment moins beau que la marche de l'empereur. Incontestablement.

le dernier trappeur [...] -apparemment, car je ne l'ai pas vu- est une ode à l'égo-centrisme

C'est y aller un peu fort :-) C'est loin d'être un film à dominante égo-centrique ! Le narrateur explique quel est l'enjeu de la trappe pour préserver l'équilibre de l'éco-système; en quoi l'homme est-il encore nécessaire dans la chaîne alimentaire naturelle.

Peut-être est-ce encore un autre débat (celui des chasseurs...) mais en France par exemple, le rôle des trappeurs d'antant est aujourd'hui assuré par des chargés de l'ONF : http://fr.wikipedia.org/wiki/ONF(...)

bon du coup, j'ai oublié l'autre moitié de l'explication de Luc JACQUET : ceux qui auraient préféré la version sans les voix des manchots, ils auront peut-être la possibilité sur le DVD d'avoir la musique sans les voix (voire même sans les voix et sans la musique ? juste les bruits de la nature)

Mais j'aimerais pouvoir vraiment profiter des images sans rajout superficiel.

Pour un film aussi attendu, je me suis rendu à l'avant première. Luc JACQUET était présent à la fin de la projection et a effectivement parlé de pari concernant les voix des manchots. Il a expliqué qu'il aurait pu faire un film comme microcosmos ou le peuple migrateur, mais en fait non, il a exploré une autre alternative.

Bizarrement, parmi les questions du public, aucune ne portait sur Tux ! Etais-je le seul linuxien de l'immense salle de cinéma ;-)

Je pense que j'étais le public visé entre mon intérêt pour GNU/Linux (donc Tux, donc manchot) et mon rôle de futur papa... Le film était absolument magnifique : nature (malheureusement si cruelle), beauté de ces animaux, innocence, des images époustouflantes avec un budget assez minimal à mon avis (en terme de moyens matériels caméra etc.) vu l'isolement.

Concernant la musique, j'ai trouvé ça bien, mais pas non plus transcendant. En même temps, je n'étais pas venu pour la musique mais plutôt pour les images.

Je conseille fortement de vous faire plaisir en allant voir ce film :-)

Merci pour ce journal ! La fonctionnalité (existante donc) offerte par nos navigateurs m'encourage à rajouter des balises meta dans PhpWebGallery http://phpwebgallery.net(...)

A mon avis, c'est tout à fait le genre d'application qui profiterait grandement de ce genre de mode de navigation !

Bonjour à tous,

Je ne sais pas s'il est très utile de rajouter un commentaire dans un journal privé [1] qui est sorti de la première page, mais je ne crois pas utile de créer un second journal, sous peine de déranger plus de monde que ça n'en intéresse...

Alors voilà, après 2 semaines de joyeux tests et de remarques toutes plus pertinentes les unes que les autres sur le forum de PhpWebGallery http://forum.phpwebgallery.net/viewtopic.php?id=2969(...) une seconde release candidate est mise à disposition.

Cette RC2 corrige de nombreux petits bugs et rajoute une fonctionnalité que les testeurs ont regretté par rapport à la branche 1.3 : la liste des utilisateurs dans la zone administration. En effet, un des grands changements pour la branche 1.4 est la capacité à gérer un grand nombre d'utilisateurs [2]. La liste de tous les utilisateurs (non paginée) avait été remplacée par un formulaire de recherche sur le nom de l'utilisateur. Un nombre suffisant de testeurs mécontents m'a convaincu de remettre en place la liste des utilisateurs, mais paginée cette fois, et triable :-)

La gestion des création de miniatures et la simulation de synchronisation entre la base de données et l'arborescence de fichiers ont été revues.

Pour découvrir la démo : http://phpwebgallery.net/bsf(...) [3] et le topic français dédié à la 1.4.0RC2 : http://forum.phpwebgallery.net/viewtopic.php?id=3061(...)

Notes

[1] j'aurai bien voulu mettre ce journal en "première page", mais l'option n'était pas disponible, j'imagine que ça doit avoir un vague rapport avec mes notes/XP, si quelqu'un pouvait m'expliquer les erreurs que j'ai commises pour perdre ce droit, je lui en serai reconnaissant.

[2] un des développeurs a commencé à contribuer au projet en proposant un MOD permettant de lier l'authentification de PhpWebGallery à celle d'un forum phpBB, potentiellement rempli de très nombreux utilisateurs.

[3] le compte admin/admin permet d'accéder à la zone adminstration

Question : est-il possible sans trop de peine de couper dans PhpWebGallery toutes les fonctionnalités exploitant la base de données ?

j'ai bien peur que non

Si non, l'abstraction est-elle sufisante pour recoder ces fonctionnalités en exploitant un autre support de stockage (fichier ou autre) ?

idem, il n'y a pas de couche d'abstraction entre les données stockées et le reste de l'application. Bref, t'as des requêtes SQL un peu partout.

voilà, je viens de la mettre en place : http://phpwebgallery.net/bsf(...)