Technical discussions | Discussions techniques
matttbe, Monday 31 August 2009 à 20:52
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Utiliser dbus-monitor ? Mais lorsque l'on clique sur une applet, il n'y a rien d'envoyé |
matttbe, Tuesday 01 September 2009 à 08:49
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Ton problème, c'est que tu trouves que dbus-monitor durant X heures c'est bcp ?
Enfin, je ne vois pas trop ça comme un problème sauf si tu mets la sortie dans une variable ou dans du texte
C'est une sortie... Ou alors, à chaque fois qu'il a trouvé qqc, tu kill dbus-monitor.
Ou encore, tu fais une sortie dans un fichier texte et tu utilises 'tail -f' |
nochka85, Tuesday 01 September 2009 à 10:26
|
|
fabounet, Tuesday 01 September 2009 à 16:15
|
|
nochka85, Tuesday 01 September 2009 à 16:32
|
|
Subscription date : 29 November 2007
Messages : 7408
|
Grab the object
When our module is registerd, Cairo-Dock creates a remote object on the bus. It is stored at
/org/cairodock/CairoDock/name-of-the-applet
So in our exemple, the path is : /org/cairodock/CairoDock/demo.
This object has a unique interface, named
org.cairodock.CairoDock.applet
So in bash, we can access this interface with the following command :
dbus-send --session --dest=org.cairodock.CairoDock /org/cairodock/CairoDock/demo org.cairodock.CairoDock.applet.xxx type1:arg1 type2:arg2 ...
where xxx is the name of the message to send, followed by the arguments : type is the type of an argument (string, int32, boolean, etc), and arg is the argument ("some text", 123, true, etc).
Ok we have a new applet inside the dock, and its corresponding remote object on the bus; now let's see how to act on it.
Je comprend pas trop ce passage ... çà sert à quoi concrètement ? C'est pour envoyer des "choses" ou pour en recevoir ?
... et c'est quoi cet "Object" ? |
fabounet, Tuesday 01 September 2009 à 16:42
|
|
Subscription date : 30 November 2007
Messages : 17118
|
est-ce que t'as lu le début aussi ? c'est tout expliqué comment marche DBus (j'ai refait l'intro)
si c'est pas assez je peux tenter d'être plus explicite |
nochka85, Tuesday 01 September 2009 à 18:31
|
|
Subscription date : 29 November 2007
Messages : 7408
|
C'est bon, j'ai tout relu et regardé l'exemple et c'est plus clair
J'ai une remarque (ou plutôt un soucis) là dessus :
Fabounet : pour agir sur une icône, on peut la définir :
soit par son nom
soit par sa commande
soit par le nom de son applet
en gros, pour une applet DBus, c'est la dernière option qui est utilisée (donc les 2 premières à "None")
j'ai pas trouvé autre chose pour pouvoir cibler une icône (sinon on pourrait aussi cibler la classe, j'aimerais juste pas avoir une liste à rallonge )
bref, à l'usage, on verra bien ce qui est le mieux
PS : suite à ta remarque, j'ai modifié le test sur les n premières lettres de la recherche, donc si tu cherches juste "nautilus", ça te le trouvera (pas besoin de tout taper, même en cherchant "nautil" ça le trouvera)
J'ai voulu lancé une anim sur l'icône du lanceur firefox de mon dock ... le soucis, c'est que j'ai aussi firefox-3.6 dans ce dernier ! Bref, voici les 'Nom de lanceur'/'Commande'/'Chemin ou nom de l'image'/'classe du programme' des 2 lanceurs :- Navigateur Web Firefox/firefox/firefox/Shiretoko
- Minefield 3.6 Web Browser/firefox-3.6/firefox-3.6/Namoroka
... bref, le soucis que j'ai, c'est qu'en faisant un :
dbus-send --session --dest=org.cairodock.CairoDock /org/cairodock/CairoDock org.cairodock.CairoDock.Animate string:default int32:2 string:any string:firefox string:none
pour animer le lanceur de Shiretoko (nom de la commande = firefox ... tout court !) via sa commande ( <- ce qui est le plus "sûr") , c'est le lanceur de Namoroka (nom de la commande = firefox-3.6) qui s'anime !
... bref, le test sur le n premières lettres c'est bien, mais il faudrait d'abord faire le test sur le nom global ... non ? |
Subscription date : 26 October 2008
Messages : 1904
|
Bon un nouveau bug si quand je suis connecte a un flux dbus si je le casse par megarde le dock crash...
Par exemple j'ai le flux de pidgin que j'envoie sur cairo-dock si je relance pidgin dans un terminal . Le dock crash.. |
nochka85, Tuesday 01 September 2009 à 20:50
|
|
nochka85, Tuesday 01 September 2009 à 22:09
|
|
Subscription date : 29 November 2007
Messages : 7408
|
@Fab : 2 toutes petites remarques concernant la demo Python -> Quand, dans le menu contextuel, on vient cliquer sur le choix 1 PUIS le choix 2 ( <- ils sont nommés ainsi ), on lit çà dans le terminal :
build menu !
choice 0 has been selected !
build menu !
choice 1 has been selected !
-> Ligne 82 :
- print "choice",iNumEntry,"has been selected !"
+ print "choice",iNumEntry+1,"has been selected !"
+ ligne 37 :
- print "the 'demo' module has not been registerd"
+ print "the 'demo' module has not been registered"
|
matttbe, Wednesday 02 September 2009 à 00:54
|
|
matttbe, Wednesday 02 September 2009 à 02:59
|
|
Subscription date : 24 January 2009
Messages : 12573
|
J'ai corrigé l'erreur Elle était sympa, je pense que tu vas sourire Fab modif
Sinon, désolé pour les mails d'erreurs. Je pensais que c'était ok au début et pour ne pas me faire engueuler par Nochka en cas d'erreurs de copie , je les ai directement envoyés sur le ppa/weekly . Puis avec Karmic ça passe mais pas avec Intrepid ou Jaunty .
PROMIS, les paquets sont maintenant ok, il n'y aura plus (autant) de mails d'erreurs !
Je pense que ce dernier est prêt d'ailleurs ! => https://edge.launchpad.net/~cairo-dock-team/+archive/weekly
Nochka : as-tu la possibilité de tester ça ? (peux-tu également tester Netspeed par exemple pour vérifier que le script bash fonctionne ?)
Une fois approuvé, j'aurai qqs annonces à faire (avec toutes une copie dans le wiki) : le ppa weekly ok, bzr ok et les traductions ok |
Mav, Wednesday 02 September 2009 à 07:23
|
|
Subscription date : 29 November 2007
Messages : 3146
|
T'as les droits pour créer des messages sur le blog ? |
matttbe, Wednesday 02 September 2009 à 10:06
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Oui, bonne idée, je ferai ça |
nochka85, Wednesday 02 September 2009 à 10:46
|
|
Subscription date : 29 November 2007
Messages : 7408
|
PROMIS, les paquets sont maintenant ok, il n'y aura plus (autant) de mails d'erreurs !
Je pense que ce dernier est prêt d'ailleurs ! => https://edge.launchpad.net/~cairo-dock-team/+archive/weekly
Nochka : as-tu la possibilité de tester ça ?
Je te réponds sur le post de bzr :
http://www.glx-dock.org/bg_topic.php?t=3234&pos=50
(peux-tu également tester Netspeed par exemple pour vérifier que le script bash fonctionne ?)
C'est à dire ?? Quel script ? |
fabounet, Wednesday 02 September 2009 à 11:39
|
|
Subscription date : 30 November 2007
Messages : 17118
|
je pense qu'il voulait dire faire Netspeed version applet DBus en bash.
ça serait en effet relativement facile à faire, et ferait de ta démo une applet "utile" (dans le sens où elle servirait à effectivement à qqch)
oki pour le test sur les commandes
par contre pour les numéros de choix ... bah ça n'est pas faux de commencer à 0 après tout |
nochka85, Wednesday 02 September 2009 à 11:49
|
|
fabounet, Wednesday 02 September 2009 à 16:37
|
|
Subscription date : 30 November 2007
Messages : 17118
|
choix 0 et choix 1
oki, c'était juste des labels pour mettre qqch.
pour le drop, tu reçois une "string"
je le rajouterai au passage.
pour le stop, c'est parce qu'il faudrait pouvoir terminer le programme proprement (et pas par un ctrl+c)
mais je sais pas comment faire en python (genre lier la touche Echap à la sortie, ou bien intercepter le kill)
il faudrait car là ça pollue le dock (l'applet reste dedans) |
nochka85, Wednesday 02 September 2009 à 17:30
|
|
Subscription date : 29 November 2007
Messages : 7408
|
Tu pourrais tout simplement mettre une nouvelle entrée dans le menu (et qu'il suffirait de laisser par défaut sur toutes les applets externes) ... du style :
def action_on_build_menu():
print "build menu !"
applet_iface.PopulateMenu(["Unregister this module", "choice 1", "choice 2"])
def action_on_menu_select(iNumEntry):
if iNumEntry != 0:
print "choice",iNumEntry,"has been selected !"
else:
stop()
... mais j'ai tester et cela ne marche pas en l'état. Cela me renvois çà dans le terminal :
build menu !
STOP
our module is stopped
et l'applet disparaît bien de la config MAIS l'icône reste dans le dock <- Tu es sûr que le stop() est bon ? ... car je n'ai pas ce soucis avec le script en bash
... d'ailleurs, tant que j'y suis , autre chose :
C'est dommage que dans le code python il faille modifier chaque passage ou il y a le nom de l'applet ... Je m'explique : Quand on crée une nouvelle applet, on duplique le répertoire de la démo et on renomme le .py et le .conf pour donner le nom de l'applet. Bref, autant se servir par défaut de ce nom pour faire toute les entrée DBus. Voilà ce que je propose :
Juste après la section 'import', on crée une nouvelle section et on met çà :
app_folder = os.getcwd() app_name = os.popen("TEMPO=`basename " + sys.argv[0] +"` && echo $TEMPO | cut -f1 -d '.' ").read().rstrip()
... comme çà, on récupère 2 variables, app_folder (j'en ai besoin pour les script en bash) et app_name, qui renvoient respectivement le répertoire du script (chemin complet) et le nom du script SANS extension ( <- Cela devient donc le nom de notre applet ). Le code pour le app_name est un peu tiré par les cheveux, mais c'est le seul truc que j'ai trouvé (avec mes connaissances nulles en python) pour avoir le nom du script python SANS l'extension .py et SANS le ./ dans le cas ou on lance le .py comme un script (si on a mis #!/usr/bin/env python en haut du fichier). Bref, une fois ces 2 variables récupérée, il suffit de faire :
dock_iface.RegisterNewModule(app_name, 3, "This is a distant applet\nIt handles right and middle click\n by Fabounet", os.path.abspath("."))
try:
applet_object = bus.get_object("org.cairodock.CairoDock",
"/org/cairodock/CairoDock/" + app_name)
except dbus.DBusException:
print "the '" + app_name + "' module has not been registered"
sys.exit(2)
applet_iface = dbus.Interface(applet_object, "org.cairodock.CairoDock.applet")
... et "roule ma poule" -> On change le nom du script python et du fichier de config et on a une nouvelle applet avec un nouveau nom dans la config du dock (<- C'est le même principe que j'avais fait pour le script en bash)
Tu vas me dire qu'il n'y a QUE dans le section "let's register our applet !" qu'il y a le nom du script à modifier ... soit ! Mais 2 choses :- c'est toujours çà de moins à gérer (et à oublier) lorsque l'on fait une nouvelle applet
- J'ai ABSOLUMENT besoin des variables app_name et app_folder (<- Celui là je peux éventuellement m'en passer) pour mes scripts en bash car je les envois en paramètres lors de l'appel de mes scripts bash (vu qu'il ont un nom différent et "standard") ... et du coup, je peux faire des trucs du genre :
def action_on_click(iState):
os.popen(app_folder + "/action_on_click.sh " + app_name)
... et je récupère le nom de l'applet dans mon script avec la variable $1
... bref, c'est juste une proposition pour "standariser" les 2 démos (python et bash)
EDIT:
Fabounet :
pour le drop, tu reçois une "string"
je le rajouterai au passage.
Pour info : J'ai réussi à récupérer les données de drop et de scroll |
Technical discussions | Discussions techniques
|