Notices

For killing the Applock Process Id, the process ID seems to change every second randomly. Hence,

/home/user # ps | grep AppLock
18583 root 2088 S grep AppLock
/home/user # kill 18583
sh: cannot kill pid 18583: No such process
This is because the pid keeps changing randomly.

And the output for this:
/opt/applock # chown users:user settings.db
chown: unknown user/group users:user

Oh, wow okay. If that is happening it means there is something causing the daemon to crash... Very bad news, could be that there is another daemon running, say in a terminal? If that isn't the case though, then what you could do is make sure that you have sent the "initctl emit AppLockStopDaemon" event and run a daemon in a terminal to see what it says.

Ah, sorry about the chown thing, got them the wrong way around it is supposed to be "user:users"

Wow, it worked this time. And we are making progress. Changing the permissions made the UI responsive. Now locking and unlocking the UI adds and removes the lock icon accordingly.
As an example, this is the output when locking and unlocking "contacts' in the UI:

For example this is the output when locking and unlocking "Contacts" in the GUI.

~ $ 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:
"type='method_call',interface='com.nokia.Messaging UI',member='top_application'"
"type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
Adding Filter: "type='method_call',interface='com.nokia.Messaging UI',member='top_application'"
DATA:
Adding Filter: "type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
DATA:
DBus Monitor Connected
DBus Monitor Running
Message Recieved on DBus Type= "signal" Sender= "org.freedesktop.DBus" Destination= ":1.1142"
Signal - Interface: "org.freedesktop.DBus" && Member: "NameAcquired"
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
Removing Filter: "type='method_call',interface='com.nokia.osso_addr essbook',member='search_append'"
DATA: pxpe
SETTINGS - Removing Search: "Contacts_Keypress"
Message Recieved on DBus Type= "error" Sender= "org.freedesktop.DBus" Destination= ":1.1142"
Removing Filter: "type='method_call',interface='com.nokia.osso_addr essbook',member='top_application'"
DATA:
SETTINGS - Removing Search: "Contacts_Shortcut"
Removing Filter: "type='method_call',interface='com.nokia.Messaging UI',member='top_application'"
DATA: type='method_call',interface='com.nokia.MessagingU I',member='top_application'
SETTINGS - Removing Search: "Conversations"
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

And now the sad part, like I told before, even though the terminal indicates that the UI detects the input, the application still fails to lock in reality.

Though applications added directly through the command line will lock like I showed before in the case of Dorian.

Hmm, okay, since you now have a semi-functional version of it

1. If you lock an app that uses a path (say, Dorian)
a) Does the lock appear?
b) Upon launching Dorian does the phone lock?
2. If you lock an app that uses a DBus call, but not one that is overriden (say, Conversations)
a) Does the lock appear?
b) Upon clicking Menu->Refresh Daemon does the UI crash?
c) If you launch the app after b) does the phone lock?

3. If you lock an app that uses an override (say, Conversations)
a) Does the lock appear?
b) Upon clicking menu->Refresh Daemon does the UI crash?
c) If you launch the app after b) does the phone lock?
d) Upon pressing a letter on the desktop does the phone lock (conversations only)

4, 5, 6: Repeat for unlocking

In the case of 5 and 6, b) won't be necessary and the UI should hang but if it doesn't then I am going to be EXTREMELY happy

WOW!! SUCCESS!! CONGRATS!!

Locking applications work through the GUI now.
Even pressing a key on the keyboard locks the phone if the contacts application is checked in the GUI.

Note that we have to refresh daemon at times for changes to take effect.

And now about unlocking, everything works normally except Contacts, which shows a weird bug i.e, upon unlocking contacts, the "Keyboard press search" gets unlocked like it should but the phone still locks if we try launching contacts directly from the menu launcher.

And I dont know whether you missed it out, but Contacts can still be accessed through the Phone application when we launch Phone and click "Select Contacts". This is possible even when contacts is locked. Have you looked into this?

The GUI doesnt crash when refreshing the daemon, though there are random delays at times when unlocking an app.

This was a great leap! And I guess the main change you should make in your next update is to make sure the permissions for settings.db are correct.

Guess this app can slowly step into beta stage now. Thanks and congrats!!

Haha, excellent.

Yeah, the way it works is that anything that adds a search to the DBus monitor will only be applied AFTER you refresh the daemon. Can you let me know if there is a delay or a hang on the UI when you remove the locks on DBus apps, if there isn't or it is very short then I will add in the immediate add support again.

As for why contacts doesn't get unlocked correctly, it may be that the daemon is hanging, if you restart the daemon does it fix it?

Cool, thanks for pointing that out, unfortunately that is built into the phone application so I can't lock it when you open it there. But on second thoughts, since it is a very limited version of the contacts app it may be possible for us to class it as part of the Phone rather than Contacts. If you do want to lock it completely though then you best lock Phone and Contacts

I also need to get around to finding out what DBus methods get called when you open a notification for a message since that opens Conversations.


Sounds like it, though I am also working on a lot of other stuff for the next release, like command line matching so we can start locking scripts and python applications

As for a Beta, not quite yet, will do when we have a stable install -> run cycle

Yeah, there is a momentary delay when unlocking dbus apps like conversations.
And just like contacts can be accessed through the Phone, Conversations with the numbers in the Call Log can also be accessed this way even when conversations is locked.

Open Phone > Click on a contact in call log > Call or SMS > click SMS and this opens our conversation with them. This is not a big deal anyways as we can always lock the phone app if we want like you told.

Will locking the phone app also lock the Phone when a call comes in? I was just wondering. This would be a problem if so. But I dont think this will happen as Maemo always gives top priority to Phone call events which explains why we are able to answer calls even when phone is auto locked. But I asked because I was wondering whether the applock daemon would bypass it.

And what about the contacts application not unlocking even when we unlock it in the UI. I mean the contacts app still locks when we try to launch it from the menu launcher. It isnt the daemon hanging, as the keyboard search gets unlocked on unlocking contacts from GUI. Its just the actual launching via menu that locks the phone. But this isnt a dealbreaker for me. Its still a wierd bug though.

I guess you can push a v.3.1 with the updated permissions for settings file. This would solve most problems reported by various users before.

EDIT: Also dont forget to fix that issue where the UI cant be launched from the menu in the next release. I was just reminding

when i type dis in xterminal

cd /usr/share/applications/hildon
sudo gainroot
nano AppLock.desktop

i got dis



BusyBox v1.18.5 (Debian 1.18.5power2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ cd /usr/share/applications/hildon
/usr/share/applications/hildon $ sudo gainroot
Root shell enabled


BusyBox v1.18.5 (Debian 1.18.5power2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/usr/share/applications/hildon # nano AppLock.desktop
/bin/sh: nano: not found





and wen i enter the below in x term

ps | grep AppLock
kill <process code for AppLock -d>
applock -d




i got dis

failed to register service: ""


and wen i enter

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


it shows the same failed to register service: ""

better onething i wanna know .... if i uninstall applock frm app manager ... will it get uninstalled totally? and then i wil try to install the latest version ....
tell me how to uninstall applock frm x term

Okay, so update on my progress so far in the dev version.

• FIXED - Not starting when menu item clicked
• FIXED - Permissions problem on settings.db
• FIXED - Daemon runs as user now
• FIXED - Daemon is now automatically started if it was not running when the UI starts
• FIXED - Menu button no longer requires 2 clicks on the first attempt to show the menu
• FIXED - Portrait mode menu no longer clips the daemon status text over the button
• ADDED - Added a border around the menu button to show that it is clickable
• ADDED - Click indication on the menu button
• ADDED - Support for checking command line arguments
• ADDED - Descriptions for applications in the list
• ADDED - Descriptions for applications in the override files
• ADDED - /etc/init.d control script for the daemon
• ADDED - Current AppLock version displayed in the menu
• UPDATED - QML Files are now better organised to make my life easier
• CHANGED - Notification bar has been modified to provide more space
• CHANGED - More informative crash messages when starting the daemon

Bugs in the dev version that are preventing release:

• CRITICAL - Apps that are not locked show the lock icon next to their names
• TESTING - Daemon needs to restart correctly when you choose to apply settings
• TESTING - Detection of scripts in command lines

Functionality I want to add:

• Detect whether something is a script by inspecting its file's header
• Use a combination of executable and command line if a script is detected using the detected interpreter