maemo.org - Talk - Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

maemo.org - Talk (https://talk.maemo.org/index.php)

- SailfishOS (https://talk.maemo.org/forumdisplay.php?f=52)

- - Python, dbus, fingerterm, opening app/script after last update (1.1.1.27) (https://talk.maemo.org/showthread.php?t=94353)

Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

Hi to all
I asked this question on TJC, but no answer yet... Maybe here someone can help me..

After last update I have some problem with my apps (scripts). Maybe someone can help me to fix it...

1. CAN'T get notification... if I'll run this command for example:

Code:

python /usr/share/openrepos-wazebton/notifer1.py

I get this output:

Code:

[root@Jolla ~]# python /usr/share/openrepos-wazebton/notifer1.py

Traceback (most recent call last):

File "/usr/share/openrepos-wazebton/notifer1.py", line 2, in <module>

        import dbus

ImportError: No module named dbus

[root@Jolla ~]#

The content of notifer1.py is:

Code:

#!/usr/bin/python

import dbus



bus = dbus.SessionBus()

object = bus.get_object('org.freedesktop.Notifications','/org/freedesktop/Notifications')

interface = dbus.Interface(object,'org.freedesktop.Notifications')

#print(interface.GetCapabilities())



interface.Notify("app_name",

                 0,

                 "icon-m-notifications",

                 "Waze BT APPLIED !",

                 "Waze & BT starter",

                 dbus.Array(["default", ""]),

                 dbus.Dictionary({"x-nemo-preview-body": "Waze & BT starter",

                                  "x-nemo-preview-summary": "Waze BT APPLIED !"},

                                  signature='sv'),

                 0)

What wrong here ? Why it stopped to work after update ?

2. Strange way to open script via fingerterm.
When I press on the .desktop file, it should open fingerterm and start my script inside. All worked perfectly before update, but now it work in different way, see picture:
https://together.jolla.com/upfiles/1...1378426686.jpg

1. Start window
2. Open fingerterm window with my script

BUT #2 CAN'T came to foreground automatically, like it was before update. It just stay in this mode like you can see on the image. If you will press on the #2 it came to foreground, and when you close this window it also will close the #1 window.
Maybe problem came from python/dbus problem from the first question ?

Python that I have installed:

Code:

[root@Jolla ~]# rpm -qa *python*

python-2.7.6-1.2.4.armv7hl

python-libs-2.7.6-1.2.4.armv7hl

[root@Jolla ~]#

Dbus that I have installed:

Code:

[root@Jolla ~]# rpm -qa *dbus*

qt5-qttools-qdbus-5.2.0+git0-1.6.10.armv7hl

dbus-glib-0.100.2-1.1.3.armv7hl

libdbus-qeventloop-qt5-1.27.6-1.6.7.armv7hl

qtaround-dbus-0.2.3-1.2.1.armv7hl

nemo-qml-plugin-dbus-qt5-2.0.1-1.8.1.armv7hl

qt5-qtdbus-5.2.1+git11-1.18.3.armv7hl

dbus-1.6.24+git1-1.5.1.armv7hl

ohm-plugins-dbus-1.1.63-1.7.3.armv7hl

dbus-libs-1.6.24+git1-1.5.1.armv7hl

[root@Jolla ~]#

Can someone help me with this ?

Thanks

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

I don't have a Jolla but reading the output I would guess that you need a python-dbus package for it to work.

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

Yes, thanks... Answered on TJC, I needed to install dbus-python package :)

But about the second question, now I noticed it can came to foreground, but it take like 8 sec :( Do you know how to speed up it ? Like it was before sys update, it was open almost immediately...

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

Python using own libs wrappers for system functions, so you need python-{something} packages to work.

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

show desktop for your script

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

For example:

Code:

[Desktop Entry]

Type=Application

Name=More snoozes

Exec=/usr/share/openrepos-moresnoozes/moresnoozes-root

Icon=openrepos-moresnoozes

X-Desktop-File-Install-Version=0.20

and content of moresnoozes-root

Code:

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <unistd.h>



int main()

{

   setuid( 0 );

   system( "fingerterm -e /usr/share/openrepos-moresnoozes/moresnoozes.sh");



   return 0;

}

Code:

[Desktop Entry]

Type=Application

Name=Dalvik Cleanup

Terminal=false

Exec=/usr/share/openrepos-dalvikcleanup/dalvikcleanup-start

Icon=openrepos-dalvikcleanup

X-Desktop-File-Install-Version=0.20

and content of dalvikcleanup-start

Code:

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <unistd.h>



int main()

{

   setuid( 0 );

   system( "fingerterm -e /usr/share/openrepos-dalvikcleanup/dalvikcleanup.sh");



   return 0;

}

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

try adding X-Nemo-Application-Type=no-invoker in desktop file

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

or try in reverse way:
desktop file starting script1 in fingerterm
script1 executing root helper binary
binary executing script2 with root privileges
it should work better

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

Thanks Coderus.
X-Nemo-Application-Type=no-invoker didn't change nothing, it still take too much time to open fingerterm in foreground.

I will try the second option later and will report.
Thanks

Re: Python, dbus, fingerterm, opening app/script after last update (1.1.1.27)

Quote:

Originally Posted by coderus (Post 1453701)

or try in reverse way:
desktop file starting script1 in fingerterm
script1 executing root helper binary
binary executing script2 with root privileges
it should work better

Ok, tried...
It really speed up opening of fingerterm, but it also opened another terminal window withh all processes...

But I found how to do this:
1. removed from binary "fingerterm -e" before path to script.
2. added "fingerterm -e" in the .desktop file before path to binary.

Now all work quickly like before sys update :) Strange changes in this sys update...
Thanks