Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
Le Fri, 6 Jan 2012 22:30:32 + (UTC) Nicolas Monnet a écrit: > >> Rien ne t'empêche d'utiliser GIT combiné avec git-svn, c'est ce que >> je fait avec le dépot de GLPI et qui me permet de sortir des patchs. >> Je gère également mes dépots git local de mes plugins GLPI hébergés >> avec subversion sur la forge indepnet sans que ça pose de soucis. > >Oui c'est ce que je fais, mais l'idéal serait d'avoir un dépôt Git >officiel, par exemple sur Github, même si le dépôt officiel central >reste sur SVN. > Calà n'a pas de réel intéret puisqu'il ne sera pas utilisé par la coreteam GLPI, il faudra quand même envoyer des patchs en contribution. David ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
> Rien ne t'empêche d'utiliser GIT combiné avec git-svn, c'est ce que je > fait avec le dépot de GLPI et qui me permet de sortir des patchs. > Je gère également mes dépots git local de mes plugins GLPI hébergés > avec subversion sur la forge indepnet sans que ça pose de soucis. Oui c'est ce que je fais, mais l'idéal serait d'avoir un dépôt Git officiel, par exemple sur Github, même si le dépôt officiel central reste sur SVN. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
> Pouvez-vous également utiliser les accents dans vos écrits car cela rend > la lecture de vos propos un peu fastidieuse. Désolé, j'utilise un clavier QWERTY et ça n'est pas toujours très pratique. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
Le Fri, 06 Jan 2012 20:10:27 +0100 jean-Mathieu Doléans a écrit: >Bonsoir, > >Le 05/01/2012 20:09, Nicolas Monnet a écrit : >(...) >> == B. git == >> >> Avez-vous envisage de passer a git? Ca rendrait les contributions >> nettement plus faciles. En l'occurence pour mon projet j'ai fait un >> checkout avec git-svn, mais ca serait quand meme plus pratique si >> tout etait deja sur github.com > >Nous réfléchissons depuis un moment à une migration vers un système de >gestion de version décentralisé pour remplacer GIT. > >Nous en avons déjà longuement discuté avec l'équipe de FusionInventory >avec qui nous collaborons et qui utilise GIT depuis la création de >leur projet. Nos échanges ne nous ont pas permis d'établir un avantage >majeur procuré par les DVS pour le projet GLPI. > Rien ne t'empêche d'utiliser GIT combiné avec git-svn, c'est ce que je fait avec le dépot de GLPI et qui me permet de sortir des patchs. Je gère également mes dépots git local de mes plugins GLPI hébergés avec subversion sur la forge indepnet sans que ça pose de soucis. David ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
Bonsoir, Le 05/01/2012 20:09, Nicolas Monnet a écrit : (...) == B. git == Avez-vous envisage de passer a git? Ca rendrait les contributions nettement plus faciles. En l'occurence pour mon projet j'ai fait un checkout avec git-svn, mais ca serait quand meme plus pratique si tout etait deja sur github.com Nous réfléchissons depuis un moment à une migration vers un système de gestion de version décentralisé pour remplacer GIT. Nous en avons déjà longuement discuté avec l'équipe de FusionInventory avec qui nous collaborons et qui utilise GIT depuis la création de leur projet. Nos échanges ne nous ont pas permis d'établir un avantage majeur procuré par les DVS pour le projet GLPI. Nous ne sommes des pragmatiques pas des fashions devs. Nous avons basculé de CVS à SVN quand il s'est avéré que cela offrait de véritables avantages au projet au regard des efforts à faire pour modifier la forge, les procédures et les habitudes de l'équipe. Je pense que comme pour tout outil, le meilleur est celui que l'on maîtrise. On pourrait discuter également des IDE, certains se sont rués sur Eclipse, d'autres ne jurent que par Netbeans quand d'autres encore n'utilisent que VI. Bonne soirée, -- Jean-Mathieu Doléans GLPI-PROJECT.ORG ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
Bonsoir, Une remarque préalable avant mes réponses détaillée sur l'UI. Beaucoup d'éléments présents dans l'interface sont là à défaut d'avoir des options meilleures et réalisables techniquement. Nous sommes donc ouverts à toutes propositions constructives. Aprés je pense que plutôt que des arguments d'autorité qui ne sont pas très probants. Il serait préférable de faire des maquettes et mockup argumentés cela fera avancer le schmilblick bien plus rapidement. Pouvez-vous également utiliser les accents dans vos écrits car cela rend la lecture de vos propos un peu fastidieuse. Le 06/01/2012 14:50, Nicolas Monnet a écrit : (...) Scroller est 100x plus rapide que de cliquer "next" 20 fois. Qui plus est tout afficher permet d'utiliser ^F. La seule raison pour limiter cette taille est pour les utilisateurs sur des ordis tres tres faibles (vintage 1999), mais honnetement, meme sur un smartphone, je n'ai jamais constate de probleme avec des listes de plusieurs milliers de ligne, en tous cas avec un navigateur suffisament recent. Oui sauf que le problème n'est pas qu'au niveau du client mais aussi du serveur en terme de charge. La pagination des listes est tout de même un élément communément accepté et validé dans la plupart des applications. (..) L'ensemble des affichages se fait de manière générique et permet un affichage uniforme. Je ne suis pas persuadé que d'avoir des affichages différents en fonction des possibilités de sélection ne soit pas plus perturbant que la situation actuelle. Mais c'est un point à discuter et à arbitrer. Je suis d'accord que ca peut poser des problemes d'alignement et de mise en page. Cela dit il faut voir ce que ca donne pour comprendre a quel point c'est exactement le contraire de perturbant pour l'utilisateur. Face a des boutons radio, l'utilisateur sait immediatement les choix disponibles et l'information qu'on attend de lui. J'avais ainsi implemente un script greasemonkey pour Jira qui faisait la transformation automatique, je ne retrouve malheureusement pas mes screenshots mais j'essayerai de trouver quelquechose pour illustrer le propos. Oui une illustration ou une maquette est plus que nécessaire. (...) Même fonctionnalité pour l'utilisateur oui mais pas du tout pour le développeur. Une case à cocher non sélectionnée n'est pas postée par un formulaire. Hors nous effectuons des modifications partielles ou complètes hors saisie par un formulaire complet. Dans ce cas comment savoir que la case est cochée ou que ce n'est pas un paramètre géré par la mise à jour en cours ? Dans ce cas une paire de boutons radio ferait l'affaire. A voir mais quand j’essaie de visualiser le résultat ça ne me semble pas convaincant. (...) C'est un point de vue de graphiste. Les filets alourdissent la vision globale et nuisent a la lecture rapide. Regardez un ecran avec un peu de recul, vous ne voyez que les filets. Remplacez les filets par un peu plus d'espacement, et le contenu prend le dessus. Pourquoi pas. (...) Il y a plusieurs facons d'arriver au meme endroit. Si je veux aller a l' inventaire des cartouches, je peux: 1. Cliquer sur inventaire, puis cliquer sur cartouches 2. Mouse over sur inventaire, puis cliquer sur catouches dans le menu deroulant 3. Cliquer sur l'icone "menu_all.png" puis cliquer sur cartouches Or ces 3 possibilites sont situees pratiquement au meme endroit, fonctionnant sur des modes pratiquement identiques; a differencier des raccourcis claviers ou gestes souris par exemple. Ca n'est pas un enorme probleme mais ca complexifie l'interface pour un benefice quasi-nul. On peut effectivement virer l'accès 1. C'était un choix de désign qu'on retrouve appliqué dans d'autres applis sans que ça soulève des débats... Mais je n'ai pas de religion en la matière. Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ? Par exemple, si je veux ajouter un ordinateur dans l'inventaire, le textarea "commentaires" fait la meme taille que ma fenetre soit 640x480 ou que je sois en fullscreen sur un 24" Oui on peut les specifier en em. Après, c'est un choix historique quand les navigateurs que je ne nommerai pas avant une interpretation très fantaisiste des tailles relatives. Aujourd'hui, cela semble tout à fait jouable d'opter pour ce choix pour l'ensemble de l'interface. Maintenant, c'est aussi une question de priorité et d'optimisation du dévelopement du projet sous contrainte de ressources humaines. Si on a des renforts sur ce point. Let's go. Comment les différentier ? Le titre des icônes me semble là pour ca. Vous voulez parler du text en hover? Ca demande de poser le pointeur sur l' icone et d'attendre, et donc ca n'est pas evident a premiere vue, et qui plus est est incompatible avec les touchscreens (ipad, smartphone ...) Il existe un plugin GLPI spécifique pour les Ipad et smartphone. Bonne soirée,
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
From: "Remi Collet" > Merci de ne pas confondre. > Github n'est qu'une offre SaaS autour de git. Je sais tres bien ce que c'est. > git existe (et heureusement) en dehors de github. > La soumission de patches est aussi beaucoup plus simples -- pull requests. > Jamais rien vu de plus lourdingue... > Alors qu'avant, pour soumettre un patch de 2 lignes à un projet, il > suffisait d'envoyer un mail avec le patch, maintenant, il faut > - forker le projet > - cloner le dépôt en local > - commiter la correction > - faire une demande de pull Avec github justement on peut editer un fichier en ligne avec leur editeur Javascript ... > Perso, ça me gonfle, et ça me donne franchement pas envie. > J'ai plein de "fork" qui ne me servent qu'une fois... Personnellement ca ne me derange pas plus que ca mais bon. > Sans parler du temps que je passe à résoudre des conflits de merge (on > m'avait pourtant dit que c'était plus simple => archi faux) C'est votre droit. Comme je le disais j'utilise git-svn pour suivre le depot svn; le probleme c'est qu'il serait tres preferable qu'il y eut un depot git officiel faisant ce suivi. J'envisage de poster l'integralite du depot sur Github. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Questions sur le style de code, git, et suggestions sur l'UI
In reply to: "MoYo" C'est un choix de programmation. Personnellement je n'écris plus depuis très longtemps du PHP sans ouvrir le tag au début du fichier et le fermer à la fin. Ce que vous proposez peut être intéressant quand on veut intégrer un peu de PHP dans du HTML. C'est le cas pour index.html. Hors GLPI c'est plutôt l'inverse, beaucoup de PHP pour générer du HTML. Cela permet aussi d'avoir un tout uniforme quand même très pratique quand on veux relire du code. Dans les editeurs que j'utilise (en l'occurence Eclipse principalement) la coloration syntaxique rend la chose plus lisible que la floppee d'apostrophes et de guillemets. Je ne comprend pas trop votre propos. Quel est le problème de proposer des valeurs même si elles ne sont pas utilisées par la majorité des gens ? Les choix disponibles sont caches, l'utilisateur doit cliquer pour les voir. Or le sens d'un widget n'est souvent evident que quand on connait les choix possibles. Ca ne change pas grand chose quand on parle d'un seul formulaire, mais pour une application web ou il y a des douzaines de formulaires avec des centaines de widgets, ca se traduit par beaucoup de confusion. Dans certains cas de listing très haut (ordi + logiciels) cela évite de scroller pendant 10 heures. Scroller est 100x plus rapide que de cliquer "next" 20 fois. Qui plus est tout afficher permet d'utiliser ^F. La seule raison pour limiter cette taille est pour les utilisateurs sur des ordis tres tres faibles (vintage 1999), mais honnetement, meme sur un smartphone, je n'ai jamais constate de probleme avec des listes de plusieurs milliers de ligne, en tous cas avec un navigateur suffisament recent. C'est un paramètre que l'utilisateur peut configurer, c'est donc à lui de définir la valeur qui lui convient le mieux. Ca encombre l'interface a chaque page avec un reglage qui n'est change qu'une fois. Ce n'est pas un probleme technique, c'est une question d'ergonomie. L'ensemble des affichages se fait de manière générique et permet un affichage uniforme. Je ne suis pas persuadé que d'avoir des affichages différents en fonction des possibilités de sélection ne soit pas plus perturbant que la situation actuelle. Mais c'est un point à discuter et à arbitrer. Je suis d'accord que ca peut poser des problemes d'alignement et de mise en page. Cela dit il faut voir ce que ca donne pour comprendre a quel point c'est exactement le contraire de perturbant pour l'utilisateur. Face a des boutons radio, l'utilisateur sait immediatement les choix disponibles et l'information qu'on attend de lui. J'avais ainsi implemente un script greasemonkey pour Jira qui faisait la transformation automatique, je ne retrouve malheureusement pas mes screenshots mais j'essayerai de trouver quelquechose pour illustrer le propos. Sachant en plus que on a déjà plusieurs mode d'affichage si vous activez ou non l'affichage dynamique. Je ne sais pas ce que c'est. Même fonctionnalité pour l'utilisateur oui mais pas du tout pour le développeur. Une case à cocher non sélectionnée n'est pas postée par un formulaire. Hors nous effectuons des modifications partielles ou complètes hors saisie par un formulaire complet. Dans ce cas comment savoir que la case est cochée ou que ce n'est pas un paramètre géré par la mise à jour en cours ? Dans ce cas une paire de boutons radio ferait l'affaire. > + Quand il y a une poignee de choix (2 a 5), un bloc de > boutons radio est pratiquement toujours preferable. Peut-être mais il prend de la place. Place, qui dans certains formulaires, est plus que précieuse. Il n'y a aussi que très peu de liste à taille fixe. L'ensemble des dropdowns étant pour la grande majorité modifiable. De mémoire on a le même problème avec les radio que les checkbox exposé plus haut. J'avais reussi a regler le probleme de la taille dynamique dans le script GM mentionne plus haut, ca n'est pas un si gros probleme honnetement; la mise en page en est un en effet. Que proposez vous pour cela ? je n'ai pas spécialement d'avis sur le sujet. Je ferai un mockup pour donner un exemple. Je ne vois pas trop non plus le soucis et la proposition que vous faites. Peut-être que des screens seraient plus compréhensible. C'est un point de vue de graphiste. Les filets alourdissent la vision globale et nuisent a la lecture rapide. Regardez un ecran avec un peu de recul, vous ne voyez que les filets. Remplacez les filets par un peu plus d'espacement, et le contenu prend le dessus. Idem, je ne comprend pas trop. C'est à dire ? un exemple précis ? Il y a plusieurs facons d'arriver au meme endroit. Si je veux aller a l' inventaire des carto
Re: [Glpi-dev] Critère uuid dans Règles d'import et de liaison des ordinateurs
Le Thu, 05 Jan 2012 14:58:19 +0100 Tsmr a écrit: >Le nouveau paramètre UUID remonté en 0.80 n'est pas utilisable comme >critère de liaison dans le moteur de règle "Règles d'import et de >liaison des ordinateurs". > >Ca vos parait jouable de l'ajouter en 0.83, car ce serait vraiment >intéressant de l'avoir comme critère celui-là. > Pour info, on l'utilise dans le moteur de critère de FusionInventory. Il faut juste savoir qu'il arrive que 2 machines aient le même UUID, donc à coupler de préférence avec un autre critère. David ++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Remontée client 0.80.5
Le 05.01.2012 20:56, Remi Collet a écrit : Pourquoi ne pas prévoir une option de config afin de positionner cette limite lors de l'utilisation du moteur de recherche ? Après il faut traiter l'erreur pour afficher un message clair. Autres idées, pour les grosses bases (config) - ne pas proposer la recherche sur "all" - sélectionner le "nom" comme critère par défaut (au lieu de éléments visualisés) Tout à fait d'accord pour ces 3 propositions : Il m'est déjà arrivé chez un client de désactiver 'Tous' car il faisait partir aussi la recherche en vrille. Et je pense qu'il n'est plus vraiment nécessaire de le conserver. Nom comme critère par défaut, aussi, ce qui limite la première recherche (surtout si on fait une globale derrière) -- Tsmr Xavier CAILLAUD http://www.thetsmr.fr ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
