Git Version | Version Git
matttbe, Saturday 18 January 2014 à 20:14
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Bizarre, normalement il ne devrait y en avoir qu'un seul.
C'est le dock qui va le lancer lui-même si c'est nécessaire. |
Subscription date : 21 October 2009
Messages : 1575
|
matttbe : Bizarre, normalement il ne devrait y en avoir qu'un seul.
C'est le dock qui va le lancer lui-même si c'est nécessaire.
C pe la raison de mon prob avec status-notifier-watcher...
Ce soir je test à nouveau un reboot dbus. Sinon je test la longue commande avec kill -9 et un cairo-dock & ensuite. |
Subscription date : 21 October 2009
Messages : 1575
|
Bon alors après avoir essayé plusieurs méthodes, un dbus reboot ne fonctionne pas lorsque lancé d'un script en revenant d'un resume (mais fonctionne si fait à la main dans le terminal).
Aussi, lorsque CD est lancé par un script en revenant du resume, la poubelle est non-fonctionnelle et le systray disparaît, et ce, même si je kill tous les process cairo-dock (incluant les status-notifier-watcher).
Je ne comprends pas du tout pkoi, je n'ai pas de problème avec d'autres applics lancées de cette façon.
Je vais tenter de lancer ton script python qui écoute les resume à partir du terminal et de voir lors d'un resume ce qu'il m'indiquera comme msg. |
matttbe, Monday 20 January 2014 à 23:50
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Je vais tenter de lancer ton script python qui écoute les resume à partir du terminal et de voir lors d'un resume ce qu'il m'indiquera comme msg. Yep. P-ê que le reboot serait lancé trop tôt mais ce serait étonnant car le script reçoit un signal D-Bus également.
Et pourquoi pas tester avec un délai d'une seconde: si tu rajoutes ces deux lignes juste avant la ligne avec le Reboot (attention à avoir la même indentation que cette ligne avec le Reboot )from time import sleep
sleep (1)
|
Subscription date : 21 October 2009
Messages : 1575
|
Tous mes tests étaient avec un délai de 10sec par défaut.
Mais ma notation dans le python était incorrecte, donc ces tests-là n'étaient pas avec un sleep. Je vais mettre 10s maintenant. |
Subscription date : 21 October 2009
Messages : 1575
|
def restart_dock ():
print ("restart dock")
bus = dbus.SessionBus ()
cd_dbus_object = bus.get_object('org.cairodock.CairoDock', '/org/cairodock/CairoDock')
cd_dbus_iface = dbus.Interface(cd_dbus_object, 'org.cairodock.CairoDock')
try:
# os.system("killall -9 cairo-dock")
# os.system("bash -c 'pkill cairo-dock'")
from time import sleep
sleep (10)
# os.system("gkrellm")
# os.system("cairo-dock")
cd_dbus_iface.Reboot ()
except:
pass |
Subscription date : 21 October 2009
Messages : 1575
|
C'est normal ceci lorsque je lance ton python du terminal?
$ python /home/frank/scripts/restart_cd_on_resume.py
connecting to login1 |
matttbe, Tuesday 21 January 2014 à 10:58
|
|
Subscription date : 24 January 2009
Messages : 12573
|
C'est normal ceci lorsque je lance ton python du terminal? Oui
Si tu n'as tjs rien, pourrais-tu mettre from time import sleep
sleep (3)
juste avant le print ("restart dock") |
Subscription date : 21 October 2009
Messages : 1575
|
Alors sans le sleep devant restart dock, le script ne détecte pas que je suis revenu d'un suspend.
Il reste à "connecting to login1", aucun msg.
J'ajoute le sleep devant le restart dock et je verrai demain. |
Subscription date : 21 October 2009
Messages : 1575
|
Alors même avec le sleep devant le print, aucun changement.
Je ne comprends pas. Je sais que sous 11.10 tout fonctionnait bien au retour d'un suspend. Et je crois que sous 13.10 avec une ancienne version de CD ça fonctionnait aussi. Je vais essayer de voir si j'ai pas un backup d'une vieille bzr... |
Subscription date : 21 October 2009
Messages : 1575
|
Bon alors je ne comprends rien. Rien ne semble fonctionner.
Alors j'ai choisi la solution la plus pourrie possible, le pire patch que j'ai jamais vu de ma vie. J'utilise xmacro pour reproduire mes actions de souris et de clavier. Très stupide et surtout très dépendant de plusiseurs variables, comme le temps du resume, si c'est trop long et que KDE n'est pas loadé, alors ça ne fonctionne pas. C'est également dépendant de mon desktop, pour être en mesure de lancer klauncher je dois avoir le desktop en foreground. Donc je click à un endroit très précis de mon desktop là où je sais que je n'ai jamais une appli, un widget ou autre chose. Ensuite c'est aussi très sensible à tout le reste qui reprend sa place, mon gkrellm qui lance automatique (lui pas de prob), etc. Si jamais il y a un délai, alors ce que je tape dans klauncher ne sera pas complet. Il faut aussi que la macro joue ses actions à une certaine vitesse. Trop vite et à cause que le HD est en utilisation ça ne fonctionne pas dans klauncher. Trop lent et c'est moi qui me plain que ça prend du temps et je dois attendre.
Comme je disais, un méchant patch. loll Mais lorsque tout est normal, ce qui est le cas plus souvent qu'autrement, alors ça fonctionne!!
Je kill tout process CAIRO-DOCK au suspend.
Ensuite au resume mon script lance la commande suivante :
nohup cat /home/frank/scripts/cairo-dock_macro | xmacroplay -d 100 :0 > /dev/null 2>&1 & |
Git Version | Version Git
|