Journal kudev : projet de gestion aisée des règles udev.

Posté par  .
Étiquettes : aucune
0
25
août
2006
Bonjour à tous.

Les mois d'été arrivant et en ayant marre de faire des mots croisés et des sudoku, je me suis dit que ma contribution au monde du libre pouvait passer par l'écriture d'un GUI qui à mon avis manquait à Linux.

Je veux parler d'un utilitaire qui permettrait de détecter des périphériques USB, et de créer des règles udev facilement, avec intégration dans le fstab et (dans une version ultérieure) l'auto.master.

Après m'être renséigné et histoire de rendre l'aventure un peu plus ludique, j'ai décidé d'écrire tout ça en python et qt... language qu'il m'a donc fallu apprendre.

J'ai écrit une première version qui fonctionne suffisament bien chez moi pour que je pense qu'il vaille le coup de pousser l'aventure un peu plus loin.

Mais voilà mes obligations professionnelles qui reviennent à la charge (à coup de 10-13h par jour) et qui font que si d'autres versions devaient être produites je ne pourrais le faire tout seul.

Anatomie du soft
- Cest un peu Gruik pour le moment à plusieurs niveaux.
- J'ai tout codé dans qt designer 3 sans passer par kdevelop (j'ai l'impression que c'est pas évident de faire du pyqt en intégrant ces deux softs). Donc le projet n'intègre pas de répertoire SVN, et à chaque version je suis obligé de recopier mes imports dans le py.
- J'ai appris python en codant le soft qui peut donc faire mal aux yeux des plus académiques.
- Cest une version alpha mais fonctionnelle sur mon kubuntu.

Besoins
Je désire fédérer des gens autour de ce projet pour finaliser et lècher la version actuelle, et éventuellement m'aider à integrer un système de gestion des règles (supression, modification de l'existant)
- J'ai besoin que ce GUI soit testé sur quelques machines hétérogènes, pour débugger.
- Une revue du code pourrait sans doute bénéficier au soft.
- Quelqun d'aguerri sur qt designer pourrait mettre un coup de propre dans l'interface (+ intégration propre dans kdevelop?).
- Un afficionado de sourcefoge et du svn pourrait publier cette version et éventuellement prendre en charge la gestion du site.

Liens
http://web.alexmic.free.fr/kudev/
http://sourceforge.net/projects/kudev

Toute critique ou commentaire sont bienvenus.

Merci de m'avoir lu jusqu'ici.
  • # Si toutes les bonnes volontés sont accueillies...

    Posté par  . Évalué à 2.

    Salut,

    Je connais les bases en programmation Python (du moins tout ce qui était expliqué dans le livre de Gérard Swinnen) et serai ravi de contribuer en lisant ton source et en le documentant ;-) Cela me permettra de progresser sur un cas concret et "abordable" ;-)

    Le forum sur SourceForge est-il exploitable pour converser à ce sujet ?

    Voilà, voilà,
    • [^] # Re: Si toutes les bonnes volontés sont accueillies...

      Posté par  . Évalué à 1.

      J'ai lu son bouquin mais je dois avouer qu'il ne m'as pas trop servi dans le cadre de kudev (trop académique pas assez orienté interface - I/O- système).

      Je viens de tester le forum, qui fonctionne.

      N'hésite pas donc à passer par ici ou par là ;)
  • # kudev ?

    Posté par  . Évalué à 4.

    Si c'est une application pure Qt, pourquoi l'appeler kudev et pourquoi vouloir l'intégrer dans kdevelop ?

    Je vois aussi que tu mélange du python et du C++ (dans Kudev.ui.h). C'est pas bien.

    Ce que tu dois faire c'est :
    1- Créer ton interface dans designer. Ca va te donner un fichier ton_fichier.ui
    2- Utiliser pyuic pour générer un fichier python qui contiendra la classe de base ta fenêtre. (pyuic ton_fichier.ui -o ton_fichier.py)
    Ce fichier là il ne faut pas y toucher et il faudra le régérérer à chaque fois que le .ui est modifié.
    3- Créer un autre fichier .py dans lequel tu importe ton_fichier.py et tu crée une classe dérivée. C'est dans cette classe dérivée que tu ajoutera ton code.
    • [^] # Re: kudev ?

      Posté par  . Évalué à 2.

      Je ne mélange pas de C++ et de python.

      Dans qtdesigner lorsque tu crées tes slots et tes functions, il les intègre dans le fichier ui.h. J'ai ensuite tappé mon code python dans ce fichier.

      Ensuite, lorsque tu fais ton pyuic kudev.ui>kudev.py il va convertir l'interface en python et récupérer le code de présent dans le ui.h
      Si je ne tappe pas mon code dans le .ui.h tout le code du py est écrasé lors du pyuic

      1,2,3-J'ai bel et bien suivi ces étapes pour en arriver au soft au stade où il en est.

      Si c'est une application pure Qt, pourquoi l'appeler kudev
      Bonne question. je crois que j'ai préféré le 'k' au 'q' ne sachant pas au départ si j'allais avoir besoin de librairies KDE. EN fait c'est bien du pur qt (pour le moment toujours).

      et pourquoi vouloir l'intégrer dans kdevelop ?
      J'ai l'impression (peut-être fausse) que kdevelop permettrait de rationaliser une démarche colalborative (intégration dans le SVN etc).
      D'autre part cela permettrait aussi peut-être de ne pas avoir à copier coller mes imports dans le py après chaque pyuic.
      • [^] # Re: kudev ?

        Posté par  . Évalué à 2.

        Justement, il ne faut pas taper ton code dans designer. Utilise-le seulement pour créer l'interface. Comme ça tu ne te retrouvera pas avec des fichiers .ui.h
        • [^] # Re: kudev ?

          Posté par  . Évalué à 2.

          Ah j'avais lu l'inverse.
          Je croyais que si je tapais mon code dans le py généré, à la prochaine modification de l'interface je courrais au drame.

          Merci pour l'info.
          • [^] # Re: kudev ?

            Posté par  . Évalué à 7.

            Tu avais bien compris, il ne faut pas toucher au fichier .py généré. Je l'ai bien dit dans mon premier post.
            Il faut créer un autre fichier .py et une autre classe que tu dérive de celle générée par pyuic. C'est dans cette classe qu'il faut ajouter ton code.
            • [^] # Re: kudev ?

              Posté par  . Évalué à 5.

              Haaaaaa! okkkk!

              A yait! Le débilos a fini par piger!

              :D
  • # Trop compliqué

    Posté par  . Évalué à 4.

    Je suis désolé, mais je vais critique. C'est une bonne idée de faire un tel logiciel qui manquait. Mais je pense qu'il faudrait l'aborder avec une autre approche, plus simple.
    En regardant les 2 captures d'écrans, je me suis tout de suite dit : "trop compliqué, c'est un soft pour les admins ou les gurus!, pas pour un utilisateur de base".

    Si tel est ton but, alors je n'ai rien à redire. Mais pas contre, si tu espère que ton logiciel sera utilisé par tous, alors il faut le simplifier au maximum en te demandant quelle est son utilité, pourquoi un utilisateur l'exécutera, pourquoi il doit configurer udev.

    Si c'est pour que sa clé USB soit toujours montée au même endroit, alors affiche lui la liste des périphériques USB trouvé, et permet lui juste de nommer la clé (qui sera ensuite automatiquement monté dans /mnt ou /media, et qui apparaîtra sur son bureau...).

    Mon avis qui n'est pas forcément le bon.
    • [^] # Re: Trop compliqué

      Posté par  . Évalué à 2.

      Je suis d'accord.

      C'est une remarque que je me suis faite à plusieurs reprise...
      En effet le soft à ce stade nécéssite tout de même de connaître un minimum udev pour l'utiliser (quoi que en mettant à peu près n'importe quoi dans les cases ça marche quand même).

      Je pense néanmoins que ce niveau de détail doit-être accessible (peut être par le biais d'un onglet/mode expert?
      Avec typiquement un premier onglet débutant qui montre le périphérique, demande son type de fs, le fstab et le répertoire kudev et envoie la sauce...
    • [^] # Re: Trop compliqué

      Posté par  . Évalué à 2.

      Oui.
      Autant l'initiative est excellente, autant l'interface est perfectible.
      D'accord avec la proposition de Matthieu MARC mais ne peut-on réaliser une interface à deux niveaux ?
      1. à l'ouverture du logiciel, la liste des périph. avec les alias modifiables
      2. l'accès à une interface plus geekie pour le tuning fin et la configuration (exemple bouton "Mode avancé").
      (La partie 2 correspondant grosso modo à ce que tu as déjà fait.)

      Au passage, c'est vraiment le genre d'outil qui va faire progresser Linux vers de plus larges publics. Bravo. L'idéal serait d'avoir ce genre d'interfaces intégrées aux gestionnaires de fenêtres...

      Une dernière chose, je vois plein d'extensions possibles à ton appli : possibilité d'envoi à une base de données sur internet, permettant de constituer une base de matériel USB fonctionnant sous Linux ; possibilité d'association automatique d'icônes vraiment spécifiques en fonction des chaînes reconnues ; quand il n'est pas détecté, association automatique du type de filesystem en fonction des chaînes reconnues, etc.
      • [^] # Re: Trop compliqué

        Posté par  . Évalué à 3.

        Oui on peut imaginer une partie simple et un mode avancé.

        Par contre, je ne sais pas pourquoi on configure udev (je ne l'ai jamais fait). Donc je ne peux pas apporter ma pierre à l'édifice quand aux fonctionnalités de l'interface simple. Je vous donnerais juste un petit cailloux en vous conseillant de commencer par réfléchir sur l'utilité de l'outil, sur les objectifs, sur pourquoi un utilisateur l'utiliserait, dans quel but. Ensuite, l'interface découlera de vos réflexions.
      • [^] # Re: Trop compliqué

        Posté par  . Évalué à 1.

        Au passage, c'est vraiment le genre d'outil qui va faire progresser Linux vers de plus larges publics. Bravo. L'idéal serait d'avoir ce genre d'interfaces intégrées aux gestionnaires de fenêtres...

        Gni ? Je ne vois vraiment pas l'intérêt de voir ce type d'outil dans un gestionnaire de fenêtres. Par contre dans la suite KDE/Gnome/whatever, why not même si ça ne me parait plus indispensable vu les avancées de dbus/hal.
  • # pyqt ==> eric3

    Posté par  (site Web personnel) . Évalué à 3.

    «J'ai tout codé dans qt designer 3 sans passer par kdevelop (j'ai l'impression que c'est pas évident de faire du pyqt en intégrant ces deux softs). Donc le projet n'intègre pas de répertoire SVN, et à chaque version je suis obligé de recopier mes imports dans le py.»

    Salut,

    Pour coder en python-qt, je te recommande vivement eric3 qui simplifie les choses. Ça fait usine à gaz au premier lancement, mais avec 2-3 tutos, tu découvres les fonctionnalités basiques et bougrement pratique qu'apporte cet IDE.

    quelques liens : http://del.icio.us/bobuse/pyqt
    notament le dernier qui donne vraiment l'essentiel :
    http://www.diotavelli.net/PyQtWiki/DevelopmentWithEric3
    • [^] # Re: pyqt ==> eric3

      Posté par  . Évalué à 1.

      C'est clair que l'interface fait un peu cockpit. Pour tout dire je l'avais installé, lancé... Beurk fermé.

      Mais je crois je ne vais pas avoir le choix dans le long terme.
      • [^] # Re: pyqt ==> eric3

        Posté par  (site Web personnel) . Évalué à 2.

        C'est surtout que c'est tellement plus agréable une fois qu'on a fait abstraction des barres de boutons.
        En quelques clics, on crée une nouvelle fenêtre qui se lance dans le designer. D'un autre clic, on compile le fichier ui puis on génère la sous-classe, et on code !
        Vraiment top !
  • # HAL

    Posté par  . Évalué à 2.

    Je dis peut-être des conneries car je ne connais pas sur le bout des doigts HAL, mais j'ai l'impression que tu te trompes de cible.

    Du moins si l'objectif est de gérer les périphériques USB.

    D'ailleurs Fedora va retirer kudzu pour tout faire avec HAL (pour FC6 ou FC7).

    Et il manque un outil pour configurer les fichiers hdi !

    Reconnaissons que la tâche est beaucoup plus compliqué mais l'outil est également beaucoup plus puissant.

    Je ne vais pas ici te faire un topo sur HAL. Je te conseille vivement de te renseigner sur HAL.

    Pour /etc/fstab, la décision a été prise de ne plus l'éditer pour les périphériques amovible. Sous gnome c'est gnome-volume-manager qui monte ou démonte les périphériques et on peut le faire à la main avec gnome-mount. Ce n'est pas une solution qu'il m'emballe, mais l'autre avait de sérieux problèmes techniques.
    • [^] # Re: HAL

      Posté par  (site Web personnel) . Évalué à 1.

      D'ailleurs il me semble (je dis peut étre des bétises) que le dernier media-manager de kde 3.5.4 permet de gérer les config hal des périphériques amovibles et donc de faire la meme chose que kudev mais en passant par HAL.
    • [^] # Re: HAL

      Posté par  (site Web personnel) . Évalué à 1.

      Je dis peut étre moi aussi des conneries mais il me semble que le nouveau media-manager de kde 3.5.4 fait la gestion HAL des périphériques USB et donc fait la meme chose que kudev.
      Mais bon n'ayant pas encore eu le loisir de l'essayer je me trompe peut étre.
      • [^] # Re: HAL

        Posté par  . Évalué à 2.

        > le nouveau media-manager de kde 3.5.4 fait la gestion HAL des périphériques USB

        C'est ce que fait aussi Gnome-volume-manager.
        Mais ce n'est pas tout à fait la même chose que kudev transposé vers HAL. Ils (media-manager et gnome-volume-manager) ne configurent pas les fichiers *.hdi de HAL. Par exemple la configuration de HAL par défaut (du moins celle livrée dans Fedora) monte les périphériques amovibles de moins de 2 Go sans cache.
        Il serait tout à fait pertinant d'avoir un outil qui édite les fichiers *.hdi (plus probablement qui en crée de nouveaux qui dans certains cas spécifiques écrasent la valeur par défaut).
        Il y a un gnome-volume-manager-properties mais il n'édite pas les fichiers *.hdi, il configure "seulement" le fonctionnement de gnome-volume-manager.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.