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.
Journal kudev : projet de gestion aisée des règles udev.
25
août
2006
# Si toutes les bonnes volontés sont accueillies...
Posté par Diego D'OLIVEIRA GRANJA . Évalué à 2.
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 alexmic . Évalué à 1.
Je viens de tester le forum, qui fonctionne.
N'hésite pas donc à passer par ici ou par là ;)
# kudev ?
Posté par Narishma Jahar . Évalué à 4.
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 alexmic . Évalué à 2.
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 Narishma Jahar . Évalué à 2.
[^] # Re: kudev ?
Posté par alexmic . Évalué à 2.
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 Narishma Jahar . Évalué à 7.
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 alexmic . Évalué à 5.
A yait! Le débilos a fini par piger!
:D
# Trop compliqué
Posté par Matthieu . Évalué à 4.
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 alexmic . Évalué à 2.
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 Charles Nepote . Évalué à 2.
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 Matthieu . Évalué à 3.
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 Xavier Maillard . Évalué à 1.
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 Nicolas Dumoulin (site web personnel) . Évalué à 3.
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 alexmic . Évalué à 1.
Mais je crois je ne vais pas avoir le choix dans le long terme.
[^] # Re: pyqt ==> eric3
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
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 !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pyqt ==> eric3
Posté par Ph Husson (site web personnel) . Évalué à 2.
# HAL
Posté par clearstream . Évalué à 2.
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 marseillais (site web personnel) . Évalué à 1.
[^] # Re: HAL
Posté par marseillais (site web personnel) . Évalué à 1.
Mais bon n'ayant pas encore eu le loisir de l'essayer je me trompe peut étre.
[^] # Re: HAL
Posté par clearstream . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.