Notices

add the whole path of the filename.
See usage details on the frontpage.

Yeah, the .desktop file for AppLock runs it with the "-ui" command. That command has not yet been implemented so the menu icon doesn't actually do anything yet. As soon as the GUI is done that will work though.

As for not adding when you only enter the file name, I will recode that part of it shortly to improve the file recognition. May even add the ability to select an app based on its name from the CLI. That being said, right now I am focusing on writing a GUI for the app that is usable, that should at least make it easier to control it all without having to use the CLI.

Hi i installed applock but after installing wen i try to open it frm menu it is jus getting selected but not opening and later on wen i touch the screen its getting disselected and wen i try to lock the app frm x terminal it hows the folling lines

aap --add fring
Adding fring to the list of locked applications
Failed to open Desktop file

add the whole path of the filename.
See usage details on the frontpage.

i tried to find the file frm file manager but i dint get . how to find the path of the file by easy method . suppose i am trying to lock conversation and also filebox .


thanking u

Hi I tried to find the file frm file manager but i dint get . how to find the path of the file by easy method . suppose i am trying to lock conversation and also filebox .

The .desktop files are stored in /usr/share/applications/hildon
The easiest way to view a list of them is to open up a terminal, type:
and choose the ones from there.

That being said, this app is still in a pre-beta state and really shouldn't be considered stable enough for popular use yet so be prepared for it to break. If it does, you best know how to recover from that (something which I suspect you don't. Then again, there is only one way to learn so let me know if you do find a problem and don't know how to fix it, I'll do my best to help).

I would however recommend that you wait at least until v0.3.0 comes out (it will have a GUI which will make this all a lot easier). I am busy working on the GUI and with any luck will have a usable version finished within the next 1-3 days.

Hi there.

sorry for possibly dumb question, but I'm little confused about result of methods currently used to determine applaunch.

At first page, you confirmed that i check for apps every 5 seconds. I'm not expert on this topic, but Your further investigation make me thought that You're working on/already did better method of getting applaunch info.

So, how does it looks now? Does this app impact CPU/RAM usage, and drain battery? i'm, out of curiosity, interested even if that isn't any problem in real-life situations, but theoretically should affect CPu/RAM/Battery by way that it works.

applock --add /usr/share/applications/hildon/conversations.desktop

applock --add /usr/share/applications/hildon/filebox.desktop

@Estel,
I will update the front page accordingly, the original pre-release/dev version of this app did check every 5 seconds to see what applications were running. However I have subsequently moved over to a DBus based approach which, while reducing reliability on certain apps, means it shouldn't drain your battery anywhere near as much as it would have.

To answer your question, the application does use RAM (all apps do), does use CPU whenever it detects an application being launched, and will drain your battery if you sit there opening and closing apps repeatedly. Unfortunately, due to the information that DBus transmits, AppLock has to check each and every app that is launched, so if you are in the habbit of launching LOTS of apps you may notice a small hit on battery life. Shouldn't be anything significant though.

Okay, excellent news. I have spent the better part of this morning working on v0.2.2 which aims to fix a whole lot of problems and make the daemon a lot more powerful.
This was after I discovered that typing a name on the keyboard opened the contacts list without locking the phone (even though it was blacklisted).

The changes aren't really all that noticeable unless you look at the DBus methods now available on the Daemon. There are now 2 new methods, the first is AddApp(string Name, string Path) and the second AddSearch(string Name, string DBus, string Search).

The AddSearch method adds a search filter to the specified DBus, currently only the Session bus is available, which is structured the same way as a watch expression in dbus-monitor. This allows you to listen for any method calls (signal and method_return support will be added soon) to any interface and any method.

To demonstrate how this works you can try entering this into a terminal when running v0.2.2:
This will then cause the phone to lock whenever you start searching through your addressbook from your desktop.

There is also the com.nokia.CallUI.ShowDialpad method which shows the phone when you enter a number, it can be watched in a similar fashion.

Additionally, adding a program to the application while the daemon is running will now take effect almost immediately (there is a 5 second delay) and now all the commands that are processed by the command line are handled on the daemon using DBus. This means I am one step closed to having a usable UI to work with.

And on a side note, when you upgrade to v0.2.2 (which is currently in the build que) remember to delete your /opt/applock/settings.db file. Due to the changes in how apps are monitored they are not compatible.