Active Topics
-
[ANNOUNCE] MeeShop - new app store (10)
to Applications by aspergerguy - 14 hrs, 58 mins ago -
HTTP-401 Sfos-Builder when using /etc/ssu credentials (0)
to SailfishOS by insanelysexy - 1 day, 20 hrs ago -
Longtime users: What device(s) are you using today? (54)
to General by ryu1 - 4 days, 2 hrs ago -
Registering (1)
to General by Halftux - 6 days, 18 hrs ago - more...
 |
|
2011-07-11
, 16:13
|
|
Posts: 472 |
Thanked: 195 times |
Joined on Jun 2010
@ India, Mumbai
|
#72
|
Spartan563@ if i try to lock the conversation or contact app.will it work ???
__________________
Knowledge is knowing a tomato is a fruit; Wisdom is not putting it in a fruit salad
Knowledge is knowing a tomato is a fruit; Wisdom is not putting it in a fruit salad
 |
|
2011-07-11
, 16:31
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#73
|
Yeah, works here. I have written up an override system which allows you to specify overrides for certain applications (Contacts, Phone, Ovi Store, User Guide and XTerm are included by default)
All works here, so I am very confused as to why it is breaking there...
All works here, so I am very confused as to why it is breaking there...
__________________
Sierra Softworks
Sierra Softworks
|
|
2011-07-11
, 16:48
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#74
|
Originally Posted by SPARTAN563
Running as root would always give me:
Warhawk, could you try running the daemon as admin and tell me if it gives the same problems? It may be that your settings.db file is not writable, or readable, by user-level apps...
/home/user # applock -d
Maemo applications must be run with the run-standalone.sh script!
QGtkStyle was unable to detect the current GTK+ theme.
Could not connect to session bus
Running without root privileges gave me the previous output.
For your reference, I had even tried stopping and restarting the daemon. But doesnt work.
|
|
2011-07-11
, 16:51
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#75
|
Okay, try this:
Should work, that is what I have been doing most of the time for debugging purposes. I will look into the Upstart script to see whether or not that is the cause of the problem but it shouldn't be...
Code:
sudo gainroot killall AppLock ps | grep AppLock #Should give no entries, maybe a "grep AppLock" entry applock -d
__________________
Sierra Softworks
Sierra Softworks
|
|
2011-07-11
, 17:19
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#76
|
Originally Posted by SPARTAN563
Okay, try this:
Should work, that is what I have been doing most of the time for debugging purposes. I will look into the Upstart script to see whether or not that is the cause of the problem but it shouldn't be...Code:sudo gainroot killall AppLock ps | grep AppLock #Should give no entries, maybe a "grep AppLock" entry applock -d
well upon running "applock -d" as root, it always returns the same error, ie, "Could not connect to session bus"
I just restarted the daemon again. Then when I run, applock-d without root privileges, got this output.
$ applock -d
AppLock Daemon - Loading Settings
Loading Application Monitor
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QStr ing,QString,QString)
Loading Session Bus Monitor
Session Filters:
DBus Monitor Connected
DBus Monitor Running
Message Recieved on DBus Type= "signal" Sender= "org.freedesktop.DBus" Destination= ":1.993"
Signal - Interface: "org.freedesktop.DBus" && Member: "NameAcquired"
Locked application launched: "/opt/maemo/usr/bin/dorian"
Locking phone
Phone locked
Adding Filter: "Contacts_Keypress" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='search_append'"
Adding search to settings
Adding filter to monitor
Filter Added
Adding Filter: "Contacts_Shortcut" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
Adding search to settings
Adding filter to monitor
Filter Added
Adding Filter: "Contacts_Keypress" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='search_append'"
Adding search to settings
Adding filter to monitor
Filter Added
Adding Filter: "Contacts_Shortcut" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
Adding search to settings
Adding filter to monitor
Filter Added
Adding Filter: "Contacts_Keypress" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='search_append'"
Adding search to settings
Adding filter to monitor
Filter Added
Adding Filter: "Contacts_Shortcut" ( "session" )
"type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
Adding search to settings
Adding filter to monitor
Filter Added
So it successfully loaded the daemon now. And it locks the "Dorian" app which I added via command line.
But coming back to the UI, I still cant lock or unloak apps. I cant even unlock the "Dorian" app using the UI.
EDIT: Well, clicking "unlock" in the UI on "Dorian" removed it from the database but the lock icon failed to disappear in the UI. This made me confused.
Added contacts and conversations to the database using the UI. The UI fails to show a lock icon but, since I was having terminal running the daemon, it showed me that the Ui registered keypresses and added contacts to the database. This fails to show up in the UI though. And sadly the daemon fails to lock contacts or conversations even though they are in the database.
Last edited by warhawk007; 2011-07-11 at 17:35.
|
|
2011-07-11
, 18:16
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#77
|
AppLock v3.0: My views and conclusions
1. The UI fails to do anything or atleast fails to register what its doing.
This means: We run "applock-d" in terminal and start the UI from the app launcher.
In the GUI, when we click on a particular app, for example "contacts", the UI seems to do nothing but the command line shows that the UI made an attempt to add the selected application and its services to the database. But in reality, there is no effect whatsoever. The app is not locked. Tested this multiple times.
2. The UI does remove apps from the database
When clicking on unlock, even though the UI seems to do nothing again, the terminal shows that the application was removed and yes, in reality, it is removed. The UI crashes when trying to remove applications with dbus events like conversations for example but again, the application gets successfully removed. Confirmed this.
3. Applock still works like before, i.e you can add and remove apps using the CLI and this works. The only thing I was never able to get working was the "keypress events" i.e, the application should have locked contacts on pressing a key on the hardware keyboard, but it didnt. But most apps which are added to the database this way, adds a "lock" icon in the GUI and gets locked.
4. The GUI doesnt seem to behave according to what is happening in the background. Locking an application through the GUi is almost impossible though it does detect input from the user, as seen on the command line. But in reality, the app never gets locked this way.
Applications which are added using the CLI show a "lock" icon in the GUI but when unlocked through the GUI, fails to remove the "lock" icon beside the application. Tested and confirmed.
So well, these are my conclusions on v.3.0 and also the bugs I found. Hope I was able to point out the bugs clearly.
Keep up the work and keep it alive! This is definitely a good start as we reached till here. Thanks again! Patiently waiting for bug-fixes.
Cheers!
1. The UI fails to do anything or atleast fails to register what its doing.
This means: We run "applock-d" in terminal and start the UI from the app launcher.
In the GUI, when we click on a particular app, for example "contacts", the UI seems to do nothing but the command line shows that the UI made an attempt to add the selected application and its services to the database. But in reality, there is no effect whatsoever. The app is not locked. Tested this multiple times.
2. The UI does remove apps from the database
When clicking on unlock, even though the UI seems to do nothing again, the terminal shows that the application was removed and yes, in reality, it is removed. The UI crashes when trying to remove applications with dbus events like conversations for example but again, the application gets successfully removed. Confirmed this.
3. Applock still works like before, i.e you can add and remove apps using the CLI and this works. The only thing I was never able to get working was the "keypress events" i.e, the application should have locked contacts on pressing a key on the hardware keyboard, but it didnt. But most apps which are added to the database this way, adds a "lock" icon in the GUI and gets locked.
4. The GUI doesnt seem to behave according to what is happening in the background. Locking an application through the GUi is almost impossible though it does detect input from the user, as seen on the command line. But in reality, the app never gets locked this way.
Applications which are added using the CLI show a "lock" icon in the GUI but when unlocked through the GUI, fails to remove the "lock" icon beside the application. Tested and confirmed.
So well, these are my conclusions on v.3.0 and also the bugs I found. Hope I was able to point out the bugs clearly.
Keep up the work and keep it alive!
This is definitely a good start as we reached till here. Thanks again! Patiently waiting for bug-fixes.Cheers!
| The Following User Says Thank You to warhawk007 For This Useful Post: | ||
|
|
2011-07-11
, 18:33
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#78
|
Wow, thanks
Finally a useful report that I can use
Okay, lets see what I can make of it so far, and lets see if I can elaborate on what the causes are for some of the bugs.
1. Hmm, I will add an animation or notification on the UI to try and show some info there while I am doing stuff. I am actually seriously considering multithreading the entire thing, even though that is a pain in Qt (I love C#'s multithreading implementations). Anyway, I am not entirely sure what is causing the lock not to be removed. The problem may be that the DBus calls I am making do not block the thread they are called from, and since lock statuses are cached (to prevent a ton of calls to the daemon when you are scrolling the app list, read up on QML's way of creating list views for more info on why this is necessary) the lock status may be being updated before it has been changed. Will look into this ASAP
2. Now this is weird, I just ran it again on my phone and it didn't remove any apps. Thing is, it was doing so previously so I am not sure what is up, am almost certain this is a permissions problem with the settings.db file. In v0.3.1 I have changed the Upstart script to start the daemon as user rather than root. With any luck this will mean that the settings.db file gets created, and owned, by the user and this will avoid the problems we've been having. As for the UI "crashing" when you remove an app with DBus events. It doesn't actually crash, if you leave it for about 30 seconds it starts responding again. I have no idea why it takes this time, have fiddled around with all my DBus code and haven't made any difference to it. Gonna test out restarting the daemon to apply the changes in v0.3.1. I seriously think that restarting the daemon is going to be faster than the current method. That being said, Binary apps (one's where the app's path is monitored) all seem to lock and unlock immediately (when it works)
3. WOW, okay that shouldn't be the case with some apps (maybe just Contacts and Phone). Basically the override files add their own custom entries into the database. So when you add contacts to the list of locked apps it actually adds 2 entries to the database, neither one called "Contacts". So that won't appear as a locked app but it will lock when you attempt to use the shortcut. As for the keypress one not working, I got it working here so maybe you typed it in wrong? Not sure, anyway with any luck v0.3.1 will work and then you won't need to worry about manually adding them
4. Hmm, what you may find is that you added them using the CLI with the Daemon not running? If that was the case then that would definitely help me pinpoint the problem. Since the CLI falls back on its own code should the daemon not be running. What this means though, is if I am going to just restart the daemon to apply changes I can directly interact with the Settings files from the UI, making it a bit faster for one and probably increasing stability a bit. Will look into this.
Thank you SO much for sending me a decent report to work with, would be interested to know if your success with the CLI was A) as root user and B) with the daemon running
Also, if you could run an "ls -l" in /opt/applock and tell me what the owner and permissions on your settings.db file are it could be useful (I have probably messed with mine so I don't trust it)
Finally a useful report that I can use
Okay, lets see what I can make of it so far, and lets see if I can elaborate on what the causes are for some of the bugs.
1. Hmm, I will add an animation or notification on the UI to try and show some info there while I am doing stuff. I am actually seriously considering multithreading the entire thing, even though that is a pain in Qt (I love C#'s multithreading implementations). Anyway, I am not entirely sure what is causing the lock not to be removed. The problem may be that the DBus calls I am making do not block the thread they are called from, and since lock statuses are cached (to prevent a ton of calls to the daemon when you are scrolling the app list, read up on QML's way of creating list views for more info on why this is necessary) the lock status may be being updated before it has been changed. Will look into this ASAP
2. Now this is weird, I just ran it again on my phone and it didn't remove any apps. Thing is, it was doing so previously so I am not sure what is up, am almost certain this is a permissions problem with the settings.db file. In v0.3.1 I have changed the Upstart script to start the daemon as user rather than root. With any luck this will mean that the settings.db file gets created, and owned, by the user and this will avoid the problems we've been having. As for the UI "crashing" when you remove an app with DBus events. It doesn't actually crash, if you leave it for about 30 seconds it starts responding again. I have no idea why it takes this time, have fiddled around with all my DBus code and haven't made any difference to it. Gonna test out restarting the daemon to apply the changes in v0.3.1. I seriously think that restarting the daemon is going to be faster than the current method. That being said, Binary apps (one's where the app's path is monitored) all seem to lock and unlock immediately (when it works)
3. WOW, okay that shouldn't be the case with some apps (maybe just Contacts and Phone). Basically the override files add their own custom entries into the database. So when you add contacts to the list of locked apps it actually adds 2 entries to the database, neither one called "Contacts". So that won't appear as a locked app but it will lock when you attempt to use the shortcut. As for the keypress one not working, I got it working here so maybe you typed it in wrong? Not sure, anyway with any luck v0.3.1 will work and then you won't need to worry about manually adding them
4. Hmm, what you may find is that you added them using the CLI with the Daemon not running? If that was the case then that would definitely help me pinpoint the problem. Since the CLI falls back on its own code should the daemon not be running. What this means though, is if I am going to just restart the daemon to apply changes I can directly interact with the Settings files from the UI, making it a bit faster for one and probably increasing stability a bit. Will look into this.
Thank you SO much for sending me a decent report to work with, would be interested to know if your success with the CLI was A) as root user and B) with the daemon running
Also, if you could run an "ls -l" in /opt/applock and tell me what the owner and permissions on your settings.db file are it could be useful (I have probably messed with mine so I don't trust it)
__________________
Sierra Softworks
Sierra Softworks
|
|
2011-07-11
, 18:49
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#79
|
Originally Posted by SPARTAN563
Well, restarting and stopping the daemon only worked with root privileges. Also adding and removing applications required root privileges maybe due to the location of the .desktop files.
Wow, thanks
Finally a useful report that I can use
Okay, lets see what I can make of it so far, and lets see if I can elaborate on what the causes are for some of the bugs.
1. Hmm, I will add an animation or notification on the UI to try and show some info there while I am doing stuff. I am actually seriously considering multithreading the entire thing, even though that is a pain in Qt (I love C#'s multithreading implementations). Anyway, I am not entirely sure what is causing the lock not to be removed. The problem may be that the DBus calls I am making do not block the thread they are called from, and since lock statuses are cached (to prevent a ton of calls to the daemon when you are scrolling the app list, read up on QML's way of creating list views for more info on why this is necessary) the lock status may be being updated before it has been changed. Will look into this ASAP
2. Now this is weird, I just ran it again on my phone and it didn't remove any apps. Thing is, it was doing so previously so I am not sure what is up, am almost certain this is a permissions problem with the settings.db file. In v0.3.1 I have changed the Upstart script to start the daemon as user rather than root. With any luck this will mean that the settings.db file gets created, and owned, by the user and this will avoid the problems we've been having. As for the UI "crashing" when you remove an app with DBus events. It doesn't actually crash, if you leave it for about 30 seconds it starts responding again. I have no idea why it takes this time, have fiddled around with all my DBus code and haven't made any difference to it. Gonna test out restarting the daemon to apply the changes in v0.3.1. I seriously think that restarting the daemon is going to be faster than the current method. That being said, Binary apps (one's where the app's path is monitored) all seem to lock and unlock immediately (when it works)
3. WOW, okay that shouldn't be the case with some apps (maybe just Contacts and Phone). Basically the override files add their own custom entries into the database. So when you add contacts to the list of locked apps it actually adds 2 entries to the database, neither one called "Contacts". So that won't appear as a locked app but it will lock when you attempt to use the shortcut. As for the keypress one not working, I got it working here so maybe you typed it in wrong? Not sure, anyway with any luck v0.3.1 will work and then you won't need to worry about manually adding them
4. Hmm, what you may find is that you added them using the CLI with the Daemon not running? If that was the case then that would definitely help me pinpoint the problem. Since the CLI falls back on its own code should the daemon not be running. What this means though, is if I am going to just restart the daemon to apply changes I can directly interact with the Settings files from the UI, making it a bit faster for one and probably increasing stability a bit. Will look into this.
Thank you SO much for sending me a decent report to work with, would be interested to know if your success with the CLI was A) as root user and B) with the daemon running
Also, if you could run an "ls -l" in /opt/applock and tell me what the owner and permissions on your settings.db file are it could be useful (I have probably messed with mine so I don't trust it)
And running "applock -d" as root would never work for me and would return a "could not connect to session bus" error.
Hence, "applock-d" worked without root privileges. You just had to launch the terminal and run "applock-d" as it is.
And for the permissions,
/opt/applock # ls -l
-rw-r--r-- 1 root root 5120 Jul 11 23:15 settings.db
/opt/applock #
cheers!
|
|
2011-07-11
, 18:56
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#80
|
Okay, well you can try this then and let me know if it works:
Then start up the UI from another terminal and see if you can add/remove items from the UI.
Code:
sudo gainroot initctl emit AppLockStopDaemon ps | grep AppLock kill <applock process ids> cd /opt/applock chown users:user settings.db chmod 777 settings.db exit applock -d
__________________
Sierra Softworks
Sierra Softworks
Sierra Softworks