Subscription date : 02 September 2009
Messages : 539
|
bon, aller hop j ose me lancer
mon tout premier applet en version ALPHA donc excusez moi si vous rencontrez des bugs ou qu il vous indique des choses pas forcement desirés
donc bon je vous explique mon truc
donc applet pour aMule ou aMuleD
attention, il necessite les paquets amule-utils et amule-utils-gui et perl-tk.
donc son but est d envoyer des commandes a amule ou d afficher des statistiques d amule.
grosso modo voila le comportement a l utilisation :
clic gauche sur le desklet : affichage de statistiques rapides
clic central : affichage des stats completes dernierement utilisés
roulette haut et bas : affichage des diverses statistiques completes ( voir plus bas pour toutes les stats )
clic droit : acces au menu
le menu comprend les fonctions suivantes :
Lancer aMule : lance l excutable mis dans la configuration du desklet
Lance aMule Gui : lance le gestionnaire graphique d amule ( utile pour amule daemon )
eteindre aMule : kill le pid d amule
--
connecter amule : connection a ed2k et a kad d amule
deconnecter amule : deconnecte amule
--
ajouter un lien ed2k : ouvre une appli perl tk dont nous verrons apres
ajouter un lien e/r : ouvre une appli perl tk dont nous verrons apres
--
lancer les statistiques completes : ouvre une appli perl tk dont nous verrons apres
le perl/tk vous ouvre une fenetre ( couleurs parametrables dans le configurateur du desklet ) en fonction de ce qui est lancé :
image a gauche ( un clic dessus vous fait aparaitre les stats rapides )
ed2k :
boite de texte ou mettre vos liens ed2k ( les separer par une virgule )
e/r :
boite de texte ou mettre vos nouvelles limites d emission et de reception
stats completes :
bouton rapides : affiche les stats rapides
bouton infos : affiche les infos sur aMule
bouton transferts : affiche les infos du transfert
bouton uploads : affiche les infos d upload
bouton downloads : affiche les infos de download
bouton connexion : affiche les infos de connexion
bouton clients : affiche les stats des clients
bouton serveurs : affiche les stats du serveurs
dans le reglage de configuration du desklet on retrouve :
box avec le lanceur d amule
sous menu de forme de l affichage rapide :
version
e2dk
kad
reception
emission
systeme
partage
sous menu de couleur des menus tk :
couleur du theme
couleur du fond
couleur des textes
les themes proposés sont tres simples, il s agit de simple changement de couleur : noir,blanc,bleu,rouge,jaune,rose,violet,orange,gris,vert,autre
attention, autre prendra en compte les couleurs de fond et de texte reglable apres.
malheureusement, Tk ne gerant pas a ma connaissance l opacité, le reglage n aura aucun effet.
j essaierai de mettre ulterieurement divers screens des menus.
bon, je pense ne rien avoir oublié
bon, c est mon premier applet, donc soyez pas trop dur avec moi et le code
il me reste pas mal de choses a ajouter, entre autre, les commentaires mais le coeur du prog est a mon avis fini, mais ca reste de l alpha
alors explication sur chaque fichier :
aMule <=== fichier a executer, il est la copie conforme de celui de nochka85, a la difference pres qu il lance un .pl et non un .sh
aMule.pl <==== coeur du prog, il analyse les infos du DBus et les renvois aux bons acteurs
gui_stats.pl <==== menu tk des stats completes
stats_complete.db <==== fichier de sauvegarde du dernier choix des stats completes
aMule_all.conf <==== fichier de configuration contenant toutes les infos de l applet et de DBus, l interet etant de ne devoir modifier qu un seul fichier pour changer tout
gui_ed2k.pl <==== menu tk de l envoi de liens ed2k
icon <=== fichier icone utilisé dans CD
stats_complete.pl <=== fichier d analyse et d envoi des stats completes
aMule.conf <=== fichier de conf de CD
gui_er.pl <=== menu tk de la gestion de reglage des emissions receptions
icon.png <=== icone utilisé dans les menus Tk
stats_rapide.pl <==== stats rapides
bon, voila, me reste pu qu a vous mettre deux choses : le lien ou le dl et mon proverbe
http://deliriazone.free.fr/cairo-dock/applet/aMule/aMule0.0.1-alpha.tar.gz
--
Au travail, l'autorite d'une personne est inversement proportionnelle au nombre de stylos qu'elle porte sur elle. |
fabounet, Thursday 01 October 2009 à 13:55
|
|
Subscription date : 30 November 2007
Messages : 17118
|
wow ça a l'air vachement complet !
je dl ça de suite  |
sdf11, Thursday 01 October 2009 à 16:33
|
|
Subscription date : 09 October 2008
Messages : 129
|
Yes, une nouvelle applet, ça faisait longtemps !! Toujours utile, même si je n'utilise quasiment plus *mule  |
fabounet, Friday 02 October 2009 à 10:13
|
|
Subscription date : 30 November 2007
Messages : 17118
|
qques remarques pour te permettre d'améliorer l'applet
il y'a sûrement un binding perl de DBus, ce serait 1000 fois mieux de l'utiliser pour avoir un seul script perl (le mélange python+bash+perl est assez infâme à relire )
le fichier de conf devrait être en anglais et traduit en français dans un .po (si possible hein )
les copyrights sont au nom de Nochka
les noms des variables reflètent ton avatar, mais il faut le savoir ($ourson )
le fichier de conf ne devrait être lu qu'une seule fois (en fait 2, lors de l'init, et lors du reload), j'en vois dans tous les fichiers.
je ne connais pas le perl pour le reste.
PS : je pensais rajouter une fonction pour permettre à l'applet de contrôler l'icône de l'appli (façon MusicPlayer), ça pourrait t'interesser. |
nochka85, Friday 02 October 2009 à 10:56
|
|
Subscription date : 29 November 2007
Messages : 7408
|
le fichier de conf ne devrait être lu qu'une seule fois (en fait 2, lors de l'init, et lors du reload), j'en vois dans tous les fichiers.
Vu qu'il se sert du fichier python pour "piloter" ses scripts perl, il perd les infos à chaque fois (vu que le script perl est lancé pour une action puis se ferme ... et seul le script python continue). De plus, vu que le but était d'avoir un script "pilote" python STANDARD, je ne voulais pas récupérer les données de la config dans ce dernier ... d'où l'importance de relire la conf (ou du moins la ou les valeurs utiles) à chaque fois ... j'ai du faire pareil pour quick_rss_reader
les copyrights sont au nom de Nochka
çà c'est pas bien -> surtout concernant une applet Amule ... vu les temps qui courent, je veux pas me retrouver en tôle !!!
Par contre, le fichier python tu dois le laisser tel quel pour qu'il reste standard et qu'on puisse facilement le gérer (je t'ai envoyé un message perso )
il y'a sûrement un binding perl de DBus, ce serait 1000 fois mieux de l'utiliser pour avoir un seul script perl (le mélange python+bash+perl est assez infâme à relire )
C'est vrai que si tu peux faire une boucle qui surveille DBusen en fond en perl, faut pas te priver ! Le fichier python qui pilote un .sh c'est juste parce que cette boucle n'est pas possible en bash ....En plus, en faisant tout en perl, cela te permettra jsutement de ne lire la config qu'une seule fois et de stocker çà dans des paramètres ... mais bon, c'est toi qui voit
PS : je pensais rajouter une fonction pour permettre à l'applet de contrôler l'icône de l'appli (façon MusicPlayer), ça pourrait t'interesser.
Que veux tu dire par là ? |
fabounet, Friday 02 October 2009 à 11:19
|
|
nochka85, Friday 02 October 2009 à 11:23
|
|
Subscription date : 29 November 2007
Messages : 7408
|
dbus-send --session --dest=org.cairodock.CairoDock /org/cairodock/CairoDock/demo org.cairodock.CairoDock.applet.ControlAppli string:pidgin
Je comprend pas trop le but |
matttbe, Friday 02 October 2009 à 12:33
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Je suppose que son but est de prendre l'icône de l'application/voler l'icône de la barre des tâches |
nochka85, Friday 02 October 2009 à 12:47
|
|
Subscription date : 29 November 2007
Messages : 7408
|
D'accord |
Subscription date : 02 September 2009
Messages : 539
|
plop
alors concernant le script de nochka85, je remet son texte d origine juste apres, desolé :/
alors, je vais zieuter ca pour "le pack langue"
comme l a souligné nochka85, j ai mis l applet de nochka85 en python dans le but d en faire une base commune ce qui permettrait une standardisation des applets externes, pour une evolutivité plus facile, dans ce meme optique, perso je pensais mettre l extension dans un fichier externe .conf de maniere a avoir un core completement commun a tous les applets.
c est pour cette meme raison que je n ai pas fait une gestion DBus en perl ( cela evite aussi d installer d autres dependances, puisque le DBus n est pas natif en perl ) et donc que j utilise les `` qui envoi des commandes bash en dur.
alors la variable %ourson ( c est un tableau auquel je fais appel avec le $ourson{'nom de mon entree'} c est une tite histoire perso ) mais je vais la restandardiser et rendre le code ainsi plus comprehensible.
les fichiers de conf effectivement relus plusieurs fois pour des raisons simples, j avais deux possibilités, soit faire un pl avec des dependances en .pm que j aurais chargé a la demande, utilisant ainsi des variables globales, permettant de ne charger qu une seule fois les confs, mais j ai utilisé un autre procédé.
a l heure actuelle chaque script est independant de son parent ( je sais j en ai pas parlé pour le moment car ce n est pas assez developpé a l heure actuelle, j avais prevu ca dans une autre rev ), je vous explique, si vous lancez './gui_ed2k.pl' il fonctionnera parfaitement seul, autrement dit un utilisateur qui ne souhaite pas utiliser l applet, mais veux quand meme pouvoir lancé des liens ed2k pourra le faire quand meme, je pensais rajouter des variables permettant de choisir comment on utilise chaque script, par exemple le lancer avec des options --with-applet-amule ou --no-applet ou --no-CD permettant ainsi une gestion completement differente de l affichage. ce n est peut etre pas une bonne idée, a vous de me dire ce que je dois en faire de cette idee.
apres, je suis ouvert a tous vos avis
--
Certains hommes n'ont que ce qu'ils meritent; les autres sont celibataires.Sacha Guitry |
nochka85, Friday 02 October 2009 à 17:41
|
|
Subscription date : 29 November 2007
Messages : 7408
|
comme l a souligné nochka85, j ai mis l applet de nochka85 en python dans le but d en faire une base commune ce qui permettrait une standardisation des applets externes, pour une evolutivité plus facile, dans ce meme optique, perso je pensais mettre l extension dans un fichier externe .conf de maniere a avoir un core completement commun a tous les applets.
J'ai trouvé mieux et j'ai mis mon script python à jour -> http://bazaar.launchpad.net/~nochka85/cairo-dock-plug-ins/quick_rss_reader/revision/6 |
Subscription date : 02 September 2009
Messages : 539
|
bon alors deux possibilités :
soit je me tourne vers une independance totale de chaque script ce qui permettra aux users de soit lancés l applet soit de creer des lanceurs pour n afficher ou n utiliser que ce qu ils souhaite
soit je regroupe tout en interdependance pour eviter les redondances ( genre recharger les variables a chaque script )
je me lance vers quoi ??
--
Je me sens tres optimiste quant a l'avenir du pessimisme.Rostand (Jean) |
nochka85, Friday 02 October 2009 à 18:01
|
|
Subscription date : 29 November 2007
Messages : 7408
|
@ours_en_pluche : Tu as vu la modif ? |
Subscription date : 02 September 2009
Messages : 539
|
oui nochka85
je vais faire la mise a jour de ma branche
ce qui vaudrait peut etre le coup, ce serait de creer un LP rien qu avec ca, et de le declarer comme dependance aux autres applets externes. une sorte de cairo-dock-plug-ins-externe comme il y a deja cairo-dock-core et cairo-dock-plug-ins
et ainsi on mettrait dans ce compte tous les applets externes considérés comme valide
--
La liberte n'est pas au commencement mais a la fin. La liberte est le fruit du bon ordre.Gaxotte (Pierre) |
fabounet, Friday 02 October 2009 à 18:24
|
|
Subscription date : 30 November 2007
Messages : 17118
|
honnêtement ça fait peur à lire ces mélange de langages
je vote pour une vraie appli perl (qui permettra à d'autres adeptes du perl d'en profiter aussi)
le coup de l'applet en bash, c'était juste un tour de force, pour montrer à quel point l'API est versatile.
et si j'ai choisi python c'est juste que j'avais des exemples sous la main, il n'a pas DBus de base non plus
bon, après c'est toi le chef de ton applet
PS : de manière générale en informatique : simple is best (je l'ai appris à mes dépens)
Edit : l'idée de la branche spéciale pourrait le faire !
à terme les applets sont bien entendu appelées à être intégrées comme toute applet qui se respecte dans les .deb |
Subscription date : 02 September 2009
Messages : 539
|
@nochka85
j ai modifié legerement ton code :
if app_folder == "":
app_folder = os.getcwd()
extension =os.popen("GLOBAL_NAME=`ls " + app_name + ".* |grep -v .conf` && FORMAT=${GLOBAL_NAME##*.} && echo $FORMAT ").read().rstrip()
## let's connect to the dock.###
ainsi quiconque peux l utiliser sans le modifier
--
Le plaisir le plus delicat est de faire celui d'autrui.La Bruyere (Jean de) |
nochka85, Friday 02 October 2009 à 18:45
|
|
Subscription date : 02 September 2009
Messages : 539
|
oué et fab pendant qu on y est, je pars dans quelle direction ?? :
soit je me tourne vers une independance totale de chaque script ce qui permettra aux users de soit lancés l applet soit de creer des lanceurs pour n afficher ou n utiliser que ce qu ils souhaite
soit je regroupe tout en interdependance pour eviter les redondances ( genre recharger les variables a chaque script )
--
Notre vie est un livre qui s'ecrit tout seul. Nous sommes des personnages de roman qui ne comprennent pas toujours bien ce que veut l'auteur.Green (Julien) |
nochka85, Friday 02 October 2009 à 19:47
|
|
Subscription date : 29 November 2007
Messages : 7408
|
Tu as demandé l'avis de Fab mais je me permets de répondre aussi :- C'est une applet qui , une fois finie et si elle marche bien, ira s'installer dans /usr.share/cairo-dock/plug-ins/.../third-party/ (ou un truc du genre) .... donc, cela ne sert à rien de garder les scripts indépendant -> Il faut résonner en applet ! ... et donc en un seul programme .... donc, il faut optimiser
(rien ne t'empêche ensuite de faire un autre programme indépendant du dock ) .... mais bon, c'est toi qui voit sur ce point là
- Je suis d'accord avec Fab sur le fait que le principe d'une "applet externe pilotée" (<- je trouve ce nom sympa
... et çà dit ce que çà veut dire ) par un script python est un GROS "tour de force" pour faire fonctionner un script bash derrière ... et par conséquent, que s'il y a moyen de faire une "boucle de surveillance" des signaux DBus en perl (cela ne peut "apparemment" pas ce faire en bash), alors il ne faut pas hésiter et partir sur une applet 100% Perl ! ... quitte à rajouter une dépendance <- Cela t'évitera tous les soucis de re-lecture du fichier de config et te permettra de t'éviter de passer par des "gros hacks" pour ton applet ( <- regarde l'applet quick_rss_reader : Je suis obligé d'écrire des infos dans un fichier temporaire dans /tmp pour pouvoir m'en servir le moment venu )
- Si l'applet peut tourner en 100% perl, alors ce serait pas mal de faire une applet démo_perl très simple (type demo_bash ou demo_python)
... voilà ... c'est mon humble avis |
|