Dotclear

Vous n'êtes pas identifié(e).

Annonce

13 février 2024 Sortie de Dotclear 2.29

#1 2010-10-08 07:24:57

Dsls
Modérateur couteau-suisse
Inscription : 2004-11-18
Site Web

Appel à idées/contributions, futur plugin "devkit"

Hello,

Nous sommes en train de réfléchir à une "centralisation" des plugins dédiés aux développeurs/thémeurs.

Le but est de créer un plugin "devkit", qui permettrait à ceux qui mettent au point leur blog, leur thème ou leur plugin, d'avoir à un endroit centralisé dans l'administration des outils pour les aider.

Parmi les fonctionnalités (mis à jour à partir des suggestions du fil) :
* Un packager de thèmes/plugins (reprise du plugin actuel "Packager"/Pacman)
* une partie "aide à la documentation de plugin" éventuellement (cf ici
* fakeMail
* traduction des plugins
* plugin/theme/license Bootstrap
* clean:config / dcAdvancedCleaner


L'idée serait de faire un plugin extensible. Un peu à la manière de firebug. Pour ceux qui ne connaissent pas, firebug permet via d'autres plugins d'ajouter des onglets spécifiques (firephp, firecookie,...), toujours accessibles via l'interface de firebug.

D'où les questions : vous voyez ici que la liste des fonctionnalités de base est assez courte, donc :
* Voyez-vous des plugins qui pourraient rejoindre devkit ?
* Quelles fonctionnalités complémentaires y verriez-vous ?

Pour ma part, j'y intègrerais bien errorLogger.


Dyslexics have more fnu!

Hors ligne

#2 2010-10-08 07:29:14

osku
Membre
Lieu : 28
Inscription : 2005-06-15

Re : Appel à idées/contributions, futur plugin "devkit"

fakeMail aussi :) pour l'envoi de faux mails.

Hors ligne

#3 2010-10-08 07:36:47

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Petit précision sur la reprise de packager. Nous comptons supprimer le support des *.tar(.gz), mieux intégrer la minification des fichiers *.js/*.css ainsi que d'autres options comme exclure certains fichiers/répertoires :)


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#4 2010-10-08 07:40:17

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Tant qu'à faire, autant y inclure la série des plugin/theme/licence bootstrap. Ils sont à l'abandon sur le lab il me semble.


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#5 2010-10-08 08:40:27

Franck
Footer de merde
Lieu : Paris
Inscription : 2004-11-09
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Et la gestion des traductions peut-être ?


Dotclear addicted since 2004

Hors ligne

#6 2010-10-08 09:03:46

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Et clean:config ou dcAdvancedCleaner ?

Hors ligne

#7 2010-10-08 10:42:11

pierrevg
Membre
Inscription : 2005-04-13
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Packager déconnait il y a peu sur les hébergements 1&1 (pas testé depuis un certain temps). Pacman fonctionne sans soucis.

Hors ligne

#8 2010-10-08 12:11:31

Philippe
Stagiaire
Lieu : Toulon
Inscription : 2004-06-13
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

La killer feature serait la génération obligatoire d'une documentation intégrée :D

Hors ligne

#9 2010-10-08 14:05:46

JcDenis
Membre
Lieu : Lyon, France
Inscription : 2007-08-31
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

pour la traduction il y a translater.

Comme je suis un gros fainéant mais un tout petit peu organisé quand même, j'ai commencé par faire des plugins qui me facilite la vie de plugineur donc voici ceux qui me servent tous les jours, d'abord fait par moi:
- dcAdvancedCleaner pour le débuggage des settings/dossier/version/etc... (et peut être un futur système de désinstallation)
- translater pour la traduction (.po et .lang.php) (themes et plugins) mais ne fait pas la traduction de l'aide pour l'instant car par assez stricte dans Dotclear,
- licenceBoostrap pour inclure les licenses aux fichiers (themes et plugins),
- pacKman pour les paquetages (.zip only),

Et pour les autres:
- about:config / clean:config surtout

Auquel on pourrait facilement ajouter:
- fakeMail

De plus de mon coté pacKman, licenceBoostrap et translater sont liés par des behaviors ce qui permet de tout faire en une seule passe. (comme a pu malheureusement le voir Frankpaul je crois.)

J'avais commencé un plugin de "création de thème" (themeBoostrap) mais jamais fini. Et il existe un plugin de création de plugins (pluginBoostrap) sur le lab.
En fait ce qu'il manque c'est juste de les rassembler dans un menu dev.


Cordialement,
_JC | Intérimaire | En mode invisible

Hors ligne

#10 2010-10-20 09:51:01

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Salut à tous.

Je poste ici les nouvelles concernant le plugin dcDevKit étant donné qu'il est en cours de développement. J'ai commencé l'implémentation générale et la structure principale est en place. Concrètement, le plugin fonctionne par module, chaque module étant une classe héritant de la classe abstraite dcDevKitModule spécialement créée pour l'occasion.

Les modules doivent donc implémenter les fonctions suivantes :
- setInfo() qui permet de définir le nom, l'icone ainsi que la description du module
- gui() qui permet de définir l'interface de chaque module. Bien sur, si un module n'a pas besoin d'interface (on peut imaginer un module qui utilise uniquement les behaviors du plugin), il suffira de renvoyer null et préciser qu'il n'y a pas d'interface via le paramètre de classe $has_gui
- getConfigForm() qui permet de définir le formulaire à afficher dans le module configuration si le plugin doit enregistrer des settings. Comme pour la fonction gui(), si le module n'a pas besoin de ça, il suffit de renvoyer null
- saveConfig() qui permet d'enregistrer les settings précédemment afficher via la fonction getConfigForm()

La page principale plugin se présente sous forme de tableau de bord avec, pour chaque module ayant une interface, son icone et son nom. La partie configuration de chaque module est affiché dans un module spécial configuration.

En l'état actuel des choses, j'ai implémenté packager et je suis en train de mettre en place le bootstrap pour les plugins / thèmes. Une fois que tout sera bien intégré, je déposerai le plugin sur le lab afin que chaque développeur puisse ajouter son module directement.

Enfin, voilà quelques screenshots pour faire un peu de teasing ;)
- Le tableau de bord
- Le module configuration
- Le module bootstrap
- Le module packager


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#11 2010-10-20 10:37:29

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

D'ailleurs, en parlant du module bootstrap, je vais avoir besoin sous peu d'un themeur qui puisse me dire quelles options il faut implémenter, qu'est ce qui doit être généré, etc... Si vous vous sentez de participer à ça, je vous invite à me contacter via le forum, email, blog, etc... :)


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#12 2010-10-20 11:33:45

Moe
Responsable du mini-bar
Lieu : France
Inscription : 2004-09-19
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Peut-on enchaîner les actions ? Par exemple traduire puis packager directement en compressant les CSS ? Là je vois bien l'intérêt de passer par des classes pour ne pas écrire une interface pour chaque plugin mais je suis plus réservé sur les avantages lors de l'utilisation. S'il faut cliquer sur les icônes de chaque plugin pour y accéder tu fais autant de clics qu'actuellement, avec le menu de gauche. D'après ta description, un plugin qui afficherait des icônes vers les plugins pour les développeurs ferait à peu près la même chose.

Des systèmes d'onglets ou un menu offrant des accès directs aux sous-parties des plugins pourraient permettre d'aller plus vite. On peut aussi imaginer des navigations transversales où on choisit dés le départ un plugin ou un thème puis on arrive sur l'interface de traduction où il n'y a que le module en question. Par exemple dans ton exemple avec Packager, y'a-t-il besoin d'afficher tous les plugins alors qu'on développe généralement un plugin à la fois ?

Hors ligne

#13 2010-10-20 13:00:44

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Moe a écrit :

Peut-on enchaîner les actions ? Par exemple traduire puis packager directement en compressant les CSS ? Là je vois bien l'intérêt de passer par des classes pour ne pas écrire une interface pour chaque plugin mais je suis plus réservé sur les avantages lors de l'utilisation. S'il faut cliquer sur les icônes de chaque plugin pour y accéder tu fais autant de clics qu'actuellement, avec le menu de gauche. D'après ta description, un plugin qui afficherait des icônes vers les plugins pour les développeurs ferait à peu près la même chose.

Tout est prévu pour être lié par behavior. La description que j'ai donné ne fait que survoler ce qu'il y a en place. D'ailleurs, rien n'est fini, c'est pour cela que j'ai évité de donner trop de détails car c'est susceptible de bouger.

Moe a écrit :

Des systèmes d'onglets ou un menu offrant des accès directs aux sous-parties des plugins pourraient permettre d'aller plus vite. On peut aussi imaginer des navigations transversales où on choisit dés le départ un plugin ou un thème puis on arrive sur l'interface de traduction où il n'y a que le module en question. Par exemple dans ton exemple avec Packager, y'a-t-il besoin d'afficher tous les plugins alors qu'on développe généralement un plugin à la fois ?

Pourquoi pas mais une utilisation transversale interdit alors un traitement de gros. Imagine que je veuille modifier toutes les entêtes de fichiers pour mettre à jour la licence (date ou autre), je vais être obligé de le faire un à un.

Chaque méthode à ses avantages et inconvénients, c'est à réfléchir bien entendu. Dans l'immédiat, je vais garder ce fonctionnement afin de pouvoir déposer assez vite une version relativement stable.


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#14 2010-10-20 13:24:37

Moe
Responsable du mini-bar
Lieu : France
Inscription : 2004-09-19
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Tomtom33 a écrit :

Tout est prévu pour être lié par behavior. La description que j'ai donné ne fait que survoler ce qu'il y a en place. D'ailleurs, rien n'est fini, c'est pour cela que j'ai évité de donner trop de détails car c'est susceptible de bouger.

Mais du coup c'est moins évident de donner notre avis. À ta place, je prendrais le temps d'essayer de cerner les besoins de chacun, pour essayer d'en tirer des idées générales vu que de toute façon, tu ne pourras pas répondre à tous les besoins particuliers. Ce n'est que mon avis bien sûr. ;)

Tomtom33 a écrit :

Pourquoi pas mais une utilisation transversale interdit alors un traitement de gros. Imagine que je veuille modifier toutes les entêtes de fichiers pour mettre à jour la licence (date ou autre), je vais être obligé de le faire un à un.

C'est vrai, dans ce cas il faudrait prévoir un mode "global" et un mode "un plugin à la fois". Dans ton exemple, tu peux choisir quels plugins tu mets à jour ou tu vas modifier tous les plugins ? Y compris ceux installés par Dotclear ? On peut imaginer limiter l'action de ce plugin à un répertoire donné ou à une liste choisie de plugins.

Tomtom33 a écrit :

Chaque méthode à ses avantages et inconvénients, c'est à réfléchir bien entendu. Dans l'immédiat, je vais garder ce fonctionnement afin de pouvoir déposer assez vite une version relativement stable.

Quitte à devoir modifier plus tard en fonction des retours des utilisateurs ?

Hors ligne

#15 2010-10-20 13:55:27

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Moe a écrit :
Tomtom33 a écrit :

Tout est prévu pour être lié par behavior. La description que j'ai donné ne fait que survoler ce qu'il y a en place. D'ailleurs, rien n'est fini, c'est pour cela que j'ai évité de donner trop de détails car c'est susceptible de bouger.

Mais du coup c'est moins évident de donner notre avis. À ta place, je prendrais le temps d'essayer de cerner les besoins de chacun, pour essayer d'en tirer des idées générales vu que de toute façon, tu ne pourras pas répondre à tous les besoins particuliers. Ce n'est que mon avis bien sûr. ;)

Je ne peux pas te donner plus d'info pour la simple et bonne raison que je n'ai pas en main moi même tous les tenants et aboutissants. C'est encore en construction, l'objectif de mon message était de vous informer le plus tôt possible de la direction dans laquelle ça part. Cette vision découle d'ailleurs de tous les échanges que l'on a eu avec Dsls. Le but est aussi de faire quelque chose d'assez léger et pas une usine à gaz. Ton idée de prévoir deux modes de fonctionnement me parait assez lourd au premier abord.

Moe a écrit :
Tomtom33 a écrit :

Pourquoi pas mais une utilisation transversale interdit alors un traitement de gros. Imagine que je veuille modifier toutes les entêtes de fichiers pour mettre à jour la licence (date ou autre), je vais être obligé de le faire un à un.

C'est vrai, dans ce cas il faudrait prévoir un mode "global" et un mode "un plugin à la fois". Dans ton exemple, tu peux choisir quels plugins tu mets à jour ou tu vas modifier tous les plugins ? Y compris ceux installés par Dotclear ? On peut imaginer limiter l'action de ce plugin à un répertoire donné ou à une liste choisie de plugins.

Non, ça ne modifie que ceux que tu as sélectionné bien sur. Effectivement, on peut imaginer que le plugin fournisse à ses modules la liste des plugins / thèmes moins ceux fournis de base avec Dotclear, je note cette bonne idée ;)


Moe a écrit :
Tomtom33 a écrit :

Chaque méthode à ses avantages et inconvénients, c'est à réfléchir bien entendu. Dans l'immédiat, je vais garder ce fonctionnement afin de pouvoir déposer assez vite une version relativement stable.

Quitte à devoir modifier plus tard en fonction des retours des utilisateurs ?

Yep, mais les modifications pour passer de l'un à l'autre ne seront pas énormes je pense. Disons que ce que j'ai codé ressemble plus à PoC qu'à une véritable implémentation (même si pour un PoC, c'est assez propre :p)

Dernière modification par Tomtom33 (2010-10-20 13:57:30)


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#16 2010-10-27 16:36:26

lipki
Membre
Inscription : 2008-11-10

Re : Appel à idées/contributions, futur plugin "devkit"

Une petite liste de module qui pourrais être utile

- Un module d'édition des fichiers du plugin avec la coloration syntaxique.
- Un module de soumission de ticket, doc, description vers le lab.
- Un module front-end ( page de présentation, version, téléchargement, ticket etc ) ( litraak ).
- Un module de création de javadoc semi-automatisé ( j'en rêve depuis longtemps ).


Je suis assez d'accord avec Moe, la plupart du temps on travaille sur un plugin a la fois.
Je suis d'avis que l'on puis choisir (ou créer) un plugin sur la première page de devkit, et que l'on ai ensuite accès aux outils.

Et serais t-il possible que le plugin soit créer sur le lab, que l'on puisse y soumettre des tickets des maintenant, avant que le plugin ais pris une orientation trop franche.


Mes fautes font saigner mes propre yeux.

Hors ligne

#17 2010-10-27 17:11:57

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

lipki a écrit :

Une petite liste de module qui pourrais être utile

- Un module d'édition des fichiers du plugin avec la coloration syntaxique.
- Un module de soumission de ticket, doc, description vers le lab.
- Un module front-end ( page de présentation, version, téléchargement, ticket etc ) ( litraak ).
- Un module de création de javadoc semi-automatisé ( j'en rêve depuis longtemps ).

Les réponses que je donne sont par rapport à "la distribution de base" de devkit, sachant que le plugin est complètement étendable :

- Le module d'édition, j'aime bien l'idée mais ça reste à voir selon les dispos
- Idem pour la soumission de tickets. Tout en sachant que je ne suis pas du tout sur que trac fournisse une API pour faire ça donc ça me parait relativement compromis pour l'instant.
- Pour le coup, je dis non. Le plugin est là pour aider les développeurs, pas pour faire tout un système de présentation. De plus, il y a déjà le lab ainsi que dotaddict qui sont disponibles et qui remplissent très bien ce rôle. Après, rien ne t'empêche de modifier litraak pour un faire un module devkit ;)
- Je dis oui, c'est pas trop compliqué à faire mais ce sera encore une fois suivant les dispos.

lipki a écrit :

Je suis assez d'accord avec Moe, la plupart du temps on travaille sur un plugin a la fois.
Je suis d'avis que l'on puis choisir (ou créer) un plugin sur la première page de devkit, et que l'on ai ensuite accès aux outils.

Je note ton +1

lipki a écrit :

Et serais t-il possible que le plugin soit créer sur le lab, que l'on puisse y soumettre des tickets des maintenant, avant que le plugin ais pris une orientation trop franche.

Je le fais dès que j'ai un peu de temps.


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#18 2010-10-27 17:23:37

Kozlika
Modo dcTeam
Inscription : 2004-05-08
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

lipki, mieux que des tickets on espère des contributions, quant aux orientations l'idée est qu'elles soient issues d'une réflexion collective/collaborative – et tranchées par le pilote du projet si besoin. Un outil destiné aux devs, fait par les devs.


La documentation : http://doc.dotclear.net/2.0/fulltoc
Le module de recherche du forum : http://www.dotclear.net/forum/search.php ?

Hors ligne

#19 2010-10-28 14:10:46

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

lipki a écrit :

Et serais t-il possible que le plugin soit créer sur le lab, que l'on puisse y soumettre des tickets des maintenant, avant que le plugin ais pris une orientation trop franche.

Voilà :)


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#20 2010-12-22 16:24:27

Tomtom33
Responsable des travaux finis
Lieu : Barcelone
Inscription : 2006-06-13

Re : Appel à idées/contributions, futur plugin "devkit"

Salut.

Je viens de déposer sur le lab le premier jet du plugin. La structure est là, le packager est intégré à 100% et la partie plugin bootstrap fonctionne assez bien (le tout est envoyé pour l'instant dans le dossier /output du plugin). Maintenant, vous pouvez reprendre tout ça comme bon vous semble puisse que je sais pertinemment que la gestion/navigation ne va pas plaire à tout le monde. Donc vous êtes libre de faire toutes les modifications que vous souhaitez.

Petite précision, si vous avez le plugin packager déjà installé, il vous faudra le désactiver avant d'installer dcDevKit.

Pour le code, c'est par là que ça ce passe.


Le lab => http://lab.dotclear.org
Besoin d'un plugin? => http://plugins.dotaddict.org
Besoin d'un thème? => http://themes.dotaddict.org
Besoin d'une astuce? => http://tips.dotaddict.org

Hors ligne

#21 2011-01-20 07:14:11

JcDenis
Membre
Lieu : Lyon, France
Inscription : 2007-08-31
Site Web

Re : Appel à idées/contributions, futur plugin "devkit"

Au fait, il plante à l'install sur la ligne d'ajout de author aux settings. (Ben ouai tu appelles un settings qui n'existe pas encore.)


Cordialement,
_JC | Intérimaire | En mode invisible

Hors ligne

Vous n'êtes pas identifié(e).

Pied de page des forums

Sites map