Suggestions / Votes pour Leed 2.0

tetsumaki commented 11 years ago

Bonjour à tout les Leedonautes.

Leed 1.5 arrive bientôt et il a pour moi encore quelques défauts que je n'aimerais pas avoir avec le développement qui va débuter sur la 2.0.

Je me permet quelques suggestions/critiques à ne pas prendre mal, surtout pour les développeurs qui font un très bon boulot.

Interface de gestion non skinnable (settings.php)

Les utilisateurs apprécies sans doute que leur interface d'administration soit au couleur du template qu'ils utilisent (marigolds, greeder, tornede, xulf, hot-beer) mais c'est très pénible à intégrer pour les développeurs de template, de plus ça supprimerais énormément de bugs lié aux thèmes et les plugins de gestions comme ThemeSwitcher fonctionneraient sans aucun problèmes. Prenons l'exemple de WordPress ou DotClear, l'interface de gestion n'est pas skinnable et heureusement vu la complexité.

L'interface de gestion ne serait pas forcément au couleur du thème par défaut (marigolds).

Multi utilisateurs

Cobalt74 a déjà lancé un sondage concernant la possibilité d'utiliser Leed avec plusieurs comptes utilisateurs. Ça me branche beaucoup cette idée et ça ne l'alourdit en rien, pour mon cas ça permettrais de crée un compte à un ami.

Par exemple l'utilisateur Tetsumaki qui a ses propres flux, ses options, son thème. L'utilisateur Machin qui a aussi ses flux, ses options, son thème. Etc...

Plugins : Activé/Desactivé dans la BDD et non en dur

Actuellement un plugin activé est activé en dur. Par exemple : Non activé : themeswitcher.plugin.disabled.php Activé : themeswitcher.plugin.enabled.php Il serait sans doute plus pratique pour les MAJ que ceux-ci soient activé dans la BDD (état 0 ou 1). En cas d'erreur, si un plugin activé n'existe plus en dur il est automatiquement nettoyé de la BDD. C'est qu'une idée, je ne suis pas développeur du noyau dur Leed.

Et enfin ! les sondages :

Interface de gestion non skinnable : http://www.doodle.com/t2m8dcbp3tv7usug Sondage Multi utilisateurs : http://www.doodle.com/p4efhhzvkdc3udtp

ldleman commented 11 years ago

Yop !!

Désolé pour le retard ^^.

Interface de gestion non skinnable (settings.php) : C'est pas faux comme dirait l'autre ^^, je suis plutôt pour @Simounet @Sbgodin @cobalt74 qu'en pensez vous ?

Multi utilisateurs : Ça ne m'a jamais branché, je ne souhaite pas complexifier Leed, mais comme c'est déjà devenu une belle usine à gaz et que beaucoup de monde semble insister sur ce point, je vais y réfléchir :), en tout cas ça ne se fera pas pour la v2.0, on a pas mal d'autres choses à traiter plus en rapport avec la fonction principale de leed (la consultation) :)

Plugins : Activé/Desactivé dans la BDD et non en dur Je souhaite justement eviter tout lien avec la bdd histoire qu'en cas de suppression/ajout physique à l'arrache via ftp scp ou autre comme c'est souvent le cas pour les plugin, la bdd ne soit pas en rade et ne merde pas de partout, et je trouve dommage d'utiliser une bdd pour un simple on/off, en revanche non en avons un peu parlé et nous allons certainement passer les infos à un fichier tiers qui sera modifié histoire de ne plus influer sur les noms des fichiers plugin à proprement parler :)

cobalt74 commented 11 years ago

Aloa ! Interface de gestion non skinnable (enfin un skin fixe avec son css propre) ==> je suis pas contre mais je me demande si c'est utile. Est ce que c'est si difficile que ça de skinner cette page settings.php ? Faudrait que je tente un thème un de ces jours.

Multi utilisateurs ==> je ne trouve pas que Leed dans son état actuel soit une usine à gaz. et j'ai lu le code bien souvent pour dire ça. Si tu ne met que Leed (sans plugins). c'est simple, rapide et rapide à installer. (moi j'aime. Tu as fais un bon boulot sur le code et d'ailleurs c'est très facile de se l'approprier) Pour le multi utilisateur, je voulais surtout connaître le nombre de personnes qui s'interesse au sujet mais difficile de dire si c'est le cas aujourd'hui. Les personnes qui viennent régulièrement suivre les évolutions ont participé au sondage mais finalement aujourd'hui, bien que mon fork soit toujours à jour, Personne ne l'utilise. I'm alone ! :'( Pas grave, c'est pas assez facile de le maintenir à jour ! (vive Git)

Plugins activé / désactivé ==> pour moi c'est très bien comme ça surtout depuis que j'ai créé le plugin de mise à jour des sources de Leed (appli + plugin). les plugins activés sont aussi mis à jour.

agentcobra commented 11 years ago

@Tetsumaki dans wordpress, on a le choix entre deux teintes

tetsumaki commented 11 years ago

@agentcobra Tu fais bien de le préciser :)

qwertygc commented 11 years ago

Interface non skinnable : Perso, je suis assez contre Multi-user : pour, et archi pour Pour les plugins dans la BDD, si ca peut permettre de faire du multi-user, oui

Phyks commented 10 years ago

Interface non skinnable : clairement contre, à mon avis un thème doit être cohérent sur tout Leed. De plus, le thème greeder utilise extensivement les modifications possibles pour la page de settings.

Multi user : pour.

Plugins dans la BDD : Ils sont déjà passé dans un fichier à part récemment, non ? Donc a priori pas besoin de faire plus et de les passer en BDD ?

ldleman commented 10 years ago

Petit MAJ pour être clair :

Les plugins sont effectivement passé dans un fichier à part (sur la branche dev uniquement pour le moment) donc la question ne se pose plus
Le multi user à été adopté pour la v2.0, mais pas encore développé (j'aimerais m'en charger moi même de manière a intégrer un partage intelligent des maj de flux)
L'interface admin : avec le temps je me dis que ce n'est pas vraiment utile et que ça risque de beaucoup compliquer les choses coté dev comme coté skinneur de templates, on galère déjà beaucoup avec les thèmes coté utilisation simple

Sbgodin commented 10 years ago

@cobalt74 j'ai examiné ta branche multi-utilisateur. Si j'ai bien compris, tu crées autant d'installation de Leed qu'il y a d'utilisateurs. Chaque utilisateur ayant son propre lot de tables distingué par son préfixe. N'avais-tu pas pensé à ajouter des champs, essentiellement dépendant de l'utilisateur, plutôt que multiplier les tables ? Je vois comme avantage à cela de mutualiser les téléchargements des RSS et une économie de place si plusieurs utilisateurs exploitent les même flux.

cobalt74 commented 10 years ago

Bonsoir, oui j'avais pensé a le faire mais dans un soucis de faire simple et rapide, pour deux ou trois utilisateurs dans une famille (personnellement, on ne consulte pas les même flux) J'avais donc fait en deux parties, permettre l'authentification de l'utilisateur supplémentaire et lui charger sont environnement. ( sachant que l'administration est limité pour les non admin = id user 1)

Je suis partant bien qu'ayant peu de temps dernièrement. Voici une petite liste d'idées :

un utilisateur possède x flux (actif/inactif)
En cas de suppression du flux si personne d'autre n'utilise le flux, suppression du flux et des articles sinon retirer juste le lien entre l'utilisateur et le flux ainsi que les liens entres les articles non favoris et le flux. ( on doit pouvoir garder les favoris)
lors de l'ajout d'un flux par un utilisateur, vérifier que le flux n'existe pas déjà sinon création puis affectation à l'utilisateur. Les articles du flux doivent être passé a non lus pour l'utilisateur ou synchronisé si new flux.
lorsque l'utilisateur met a lu un article c'est uniquement sur son compte :D
la synchronisation est faite pour tous les flux
l'admin pour plus de simplicité est l'id 1.
l'admin contrôle les comptes utilisateurs (plugin ou paramètre je pense pour une inscription public)
la suppression de l'utilisateur entraine suppression des flux et des articles si personne d'autre ne les utilisent.(même contraintes)

Qu'en pensez vous, a compléter ?!

Phyks commented 10 years ago

+1 ;)

Sbgodin commented 10 years ago

C'est bon tout ça. Mais cela veut dire aussi un bon gros remaniement des familles du code de Leed.

Il faudra revoir la politique d'authentification et de gestion des flux. C'est à mon humble avis incompatible avec des mises à jour pépères sur la dev. Probablement après une période de stabilisation des fonctionnalités pour la v2 et des bugs, il faudra faire une branche de maintenance de la v2 tandis que dev sera dédiée à la construction de la v3.

Autrement dit, il faudra dédoubler les développements sur la maintenance de la (future proche) v2 en limitant les nouvelles fonctionnalités et développer la future v3. Des corrections de bug et des fonctionnalités mineures devront quand même parfois passer de l'une à l'autre.

cobalt74 commented 10 years ago

je confirme. c'est un gros morceau. C'est aussi pour ça que ma version Leed Multi user est simple. j'ai juste ajouté une propriété à l'utilisateur pour définir son environnement et quelques autres trucs aussi pour l'authentification.

tmos commented 10 years ago

L'idée a l'air d'être abandonnée mais je préfère donner mon avis en tant que créateur de thème : je veux skinner l'administration aussi! Si vous nous enlevez tout le boulot on va se faire chier :-D plus sérieusement c'est pas affreux à faire et je vois mal un leed divisé en deux (graphiquement).

Edit : c'est fou comment on peut passer à côté des dates de publication parfois... Désolé pour le déterrage !

cobalt74 commented 10 years ago

je clos le sujet, les idées ont été abordés voir développé, ou prévu dans le futur. réouvrir si pas d'accord :smile:

LeedRSS / Leed