Home Forums Wiki Doc Install Extras Screenshots Source Code Projects Blog Users Groups Register
Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques The new DBus interface to Cairo-Dock
The latest stable release is the *3.4.0* : How to install it here.
Note: We just switched from BZR to Git on Github! (only to host the code and your future pull requests)
Technical discussions | Discussions techniques

Subjects Author Language Messages Last message
[Locked] The new DBus interface to Cairo-Dock
Page : 1 2 3 4 5
fabounet English 85 ppmt [Read]
10 November 2009 à 04:29

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é

nochka85, Monday 31 August 2009 à 23:08


Subscription date : 29 November 2007
Messages : 7408
Et si (enfin pas sur une applet standard... mais sur les applets externes, oui !), voilà ce que j'obtiens lorsque je clique sur mon applet et si je lance dans un autre terminal la commande dbus-monitor | grep on_middle_click_icon :

signal sender=:1.9997 -> dest=(null destination) serial=456 path=/org/cairodock/CairoDock; interface=org.cairodock.CairoDock; member=on_click_icon


... mais pour pouvoir utiliser çà, il faudrait 2 choses :
      • Avoir le champs dest (qui est à 'null destination') renseigner avec le nom de mon applet ... car le soucis c'est que j'obtiens le même message si je lance l'applet en python par exemple <- Bref, çà, je pense que c'est une modif à faire dans le plugin DBus du dock (mais je peux me tromper ) ... cela me permettrait de "filtrer" ce qui est pour mon applet (nommée demo_bash) en remplaçant la commande par dbus-monitor | grep demo_bash*on_middle_click_icon
      • Réussir à faire 1 seul check car le soucis est que dbus-monitor tourne en boucle et me bloque le programme ... y'aurait pas une commande qui ferait pareil mais en ne renvoyant qu'un seul résultat ? ... mais en attendant, j'arrive à m'en sortir en faisant un gros hack de la mort qui tue :


#############################################################################################################
main_loop() {
while [ 1 ]
    do

        if [ "`/usr/bin/dbus-monitor | grep n_middle_click_icon & sleep 1 && killall /usr/bin/dbus-monitor`" != "" ]; then
            echo "Left Click !"
        fi
    done
}

... mais c'est pas vraiment très propre ... et je vais avoir un soucis quand il va falloir que je rajoute les autres notifications

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


Subscription date : 29 November 2007
Messages : 7408
Ton problème, c'est que tu trouves que dbus-monitor durant X heures c'est bcp ?

Je comprends pas trop ce que tu veux dire ... C'est du belge ?

En fait, j'ai réussi hier soir en faisant çà :

############################################################################################################# 
main_loop() { 
DELAY=1  # WARNING : DO NOT change this value 
while [ 
    do 

        
SIGNAL="`/usr/bin/dbus-monitor | grep org.cairodock.CairoDock* & sleep $DELAY && killall /usr/bin/dbus-monitor`" 


        
if [ "`echo "$SIGNAL" | grep 'on_click_icon'`" != "" ]; then 
            action_on_click 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_middle_click_icon'`" != "" ]; then 
            action_on_middle_click 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_scroll_icon'`" != "" ]; then 
            action_on_scroll_icon 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_drop_data'`" != "" ]; then 
            action_on_drop_data 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_build_menu'`" != "" ]; then 
            action_on_build_menu 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_menu_select'`" != "" ]; then 
            action_on_menu_select 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_init_module'`" != "" ]; then 
            action_on_init_module 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_reload_module'`" != "" ]; then 
            action_on_reload_module 
        fi 

        
if [ "`echo "$SIGNAL" | grep 'on_stop_module'`" != "" ]; then 
            action_on_stop_module 
        fi 
 

    done 



... Bref, j'analyse les signaux DBus à la recherche de quelque chose venant du dock pendant 1 sec (= c'est le delai entre 2 mesures de dbus-monitor) et je stocke çà dans un texte PUIS je kill dbus-monitor .... ENFIN, je fais une recherche des notifications qui m'interresse sur mon texte
... mais j'ai ouvert un nouveau sujet pour ne pas poluer celui-ci : http://www.glx-dock.org/bg_topic.php?t=3269

fabounet, Tuesday 01 September 2009 à 16:15


Subscription date : 30 November 2007
Messages : 17118
hop, j'ai mis à jour et complété le tuto (il est désormais fini)
http://www.glx-dock.org/ww_page.php?p=Control_your_dock_with_DBus&lang=en#18-Write%20a%20DBus%20applet
ça explique ce que j'ai fait hier (l'API pour les applets est maintenant cloisonnée et du coup simplifiée)
le prog de demo en python est aussi à jour. faites chauffer le bus !

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 ?

taiebot65, Tuesday 01 September 2009 à 20:28


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


Subscription date : 29 November 2007
Messages : 7408
même problème signalé ici -> http://www.glx-dock.org/bg_topic.php?t=3269&pos=3 ... mais plus détaillé

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


Subscription date : 24 January 2009
Messages : 12573
Il y a une erreur à la compilation (peut-être auriez vous remarqué un largage de spam )

La voici :
interface-applet.c:41:37: error: applet-dbus-applet-spec.h: No such file or directory
interface-applet.c: In function 'cd_dbus_applet_init':
interface-applet.c:222: error: 'dbus_glib_cd_dbus_applet_object_info' undeclared (first use in this function)
interface-applet.c:222: error: (Each undeclared identifier is reported only once
interface-applet.c:222: error: for each function it appears in.)
make[4]: *** [libcd_Dbus_la-interface-applet.lo] Error 1
make[4]: Leaving directory `/build/buildd/cairo-dock-plug-ins-2.1.0-alpha1/Dbus/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/build/buildd/cairo-dock-plug-ins-2.1.0-alpha1/Dbus'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/buildd/cairo-dock-plug-ins-2.1.0-alpha1'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/build/buildd/cairo-dock-plug-ins-2.1.0-alpha1'
Chose étrange, c'est que je n'ai pas cette erreur avec gcc4.4 sur mon pc !

Une fois ceci fixé, les paquets weekly seront ok

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


Subscription date : 29 November 2007
Messages : 7408
par contre pour les numéros de choix ... bah ça n'est pas faux de commencer à 0 après tout


Informatiquement parlant, c'est vrai ... mais de ce cas, il faudrait mettre dans le menu choix 0 et choix 1 (au lieu de 1 et 2)

Au fait Fab, tu pourrais "continuer" le script pour mettre les notifications manquantes (notamment on_drop_data ... car j'ai pas réussi à savoir ce que l'on glissait dessus l'applet) ... et comme çà, y'aura une demo complète avec TOUTES les notifications, et ce sera plus facile d'enlever celles qui ne servent pas à la future applet que de rajouter celles qui manquent

... de même, y'aurait pas un soucis avec stop() ? .... car le programme n'y va jamais, et donc ne fais jamais de Unregistered

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 çà :
### env variables ###
app_folder os.getcwd()    # name of the script folder
app_name os.popen("TEMPO=`basename " sys.argv[0] +"` && echo $TEMPO | cut -f1 -d '.' ").read().rstrip()    # name of the script without th '.py' extension AND without the './' if running as a script

... 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 :

### let's register our applet !###
dock_iface.RegisterNewModule(app_name3"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

Subjects Author Language Messages Last message
[Locked] The new DBus interface to Cairo-Dock
Page : 1 2 3 4 5
fabounet English 85 ppmt [Read]
10 November 2009 à 04:29


Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques The new DBus interface to Cairo-Dock Top

Online users :

Powered by ElementSpeak © 2007 Adrien Pilleboue, 2009-2013 Matthieu Baerts.
Dock based on CSS Dock Menu (Ndesign) with jQuery. Icons by zgegball
Cairo-Dock is a free software under GNU-GPL3 licence. First stable version created by Fabounet.
Many thanks to TuxFamily for the web Hosting and Mav for the domain name.