Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Not a problem, as it turns out it may yet be of use to me. As far as I can see as well there aren't any eavesdropping methods in any of the bindings, but I am also going along with the dbus_bus_add_match method and dbus_connection_add_filter to process what it spits out. Like I said though, Qt doesn't seem to like it all that much :)

For A, darn well I guess it was worth a try :) I'll do a bit of snooping myself to see if anything but from the 1 other app I tried launching (one of my own which doesn't have any DBus services) it appears that it does get triggered... If that is the case then it could come in handy for reducing drain on the battery

As for B, excellent that will be extremely helpful :D


Okay, I have some exceptional news, I have managed to get libdbus working in Qt and have subsequently managed to get it to properly snoop the top_application method calls. So now all that is required is for me to write the parsing code for those (or more correctly, the verification code) and then we are in business.

Have also updated the first page to take this into account as it means we will no longer have to modify .service or .desktop files for the application to work.

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Wow..its great to know the project is progressing quite fast. Its hardly 4 days since I requested for an app like this and its already coming up. You're one of the better developers out here and its developers like you who give me and the others here one more reason to stick to our N900s!

Wish I could help, but I'm not so good in coding. :( I used to code in C & C++ once but since I'm caught up my Management course now, I hardly get a chance to come back to programming. Have to brush up my skiils some day.

Patiently awaiting a release. :)
Cheers!

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Hmm, doesn't seem all that fast from this side, involves a lot of research and reading without all that much coding going into it to get stuff working. Maybe that's just me :)
As for "one of the better developers", I started C++ less that 2 months ago... Am still busy learning the ropes but this gives me a whole bunch of cool projects to do which all teach me useful stuff RE C++ development. I must admit though, there is something about the N900 that makes me wish I could keep it forever <3

I wouldn't worry too much about that, besides since I assume you're gonna be helping me bug test it you'll be doing more than enough :)

Now, for an update:
I can now monitor the top_application calls, lock the phone when they get picked up AND load the correct DBus service paths from the service files (despite the fact that they aren't all named correctly :)). I have also started work on using DBus to monitor ALL application launches which should make it considerably softer on battery usage.
However, there will now be a limitation on what the app can lock, most prominently that it will ONLY lock applications which have a .desktop file. I figure this isn't such a big deal since most console apps are capable of executing in under 2.5 seconds (50% of the original scan interval) which could make them undetectable, and xterm already has a desktop file.
Next, I am not sure if an application that has absolutely NO dbus calls in it will trigger this check (will do a bit of testing to confirm that) but I think it is safe to assume that most developers will have made use of at least the notification dbus calls, so that shouldn't be a massive problem.

And once that is all done, public alpha :D (with any luck, by this afternoon)


UPDATE:
Well, still spending my time trying to figure out why the hell adding a new instance of my ApplicationDescription class to a QList causes all the previous entries in the list to become equal to the new item... Even when all the pointers are different *bashes head into desk*.
As such, I may end up rewriting all the settings handling code to work purely off of SQLite rather than loading anything into memory (may work better anyway in some cases).

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Okay, first public release (v0.2.0) which meets requirements for Milestone 2 is now available in extras-devel.

Here is a rundown of the available features in this release as well as some of the known bugs and missing features:

• Allows you to add .desktop files to the database by calling "applock --add <file>" from the command line
• Allows you to remove .desktop files from the database by calling "applock --remove <file>" from the command line
• Allows you to view a list of all your monitored applications by entering "applock --show-apps" from the command line
• Will automatically lock the phone if it detects an application being launched which has been blacklisted*
• Runs as a daemon on startup which can be stopped by running "initctl emit AppLockStopDaemon" from the command line.
• Provides some basic DBus methods on the com.sierrasoftworks.AppLock.Daemon interface
• Automatically detects whether a .desktop file should be monitored as a service or as an executable

* Currently there are two ways that AppLock uses to monitor application launches. The first occurs when an application registers itself on the DBus for any reason whatsoever (this doesn't require the application to provide a service, just use a DBus service like org.freedesktop.Notifications). The second hooks into Maemo's single instance launch code. This is what is usually used for apps like Contacts and MicroB and so as soon as this code is called AppLock will lock the Phone. Unfortunately, this means that apps which are run as scripts, or apps which DO NOT use any DBus methods will not be detected. There is the possibility of enabling a continuous check system to monitor these applications however this will drain battery and (if implemented) will be optional.

Known Bugs

• Just entering a desktop file's name (say "mebook.desktop") will NOT add it to the list of locked applications. You need to enter the full path ("/usr/share/applications/hildon/mebook.desktop") for it to work. This will be fixed in Milestone 3 releases.
• The first time the application attempts to lock the phone takes a bit of time, I am not sure what is causing this but hopefully I'll be able to figure it out and fix it. Otherwise, it isn't really a big deal since most apps take longer than the delay to finish loading anyway.

You can check this page for information on the current build status.

I look forward to getting page loads of bug reports :D

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Wow! Just saw the update now! Thanks a lot! Will check it out and report back as soon as possible. :)


Will we be seeing a GUI soon?

Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

:) Just pushed v0.2.1 to the build que, fixes a few small issues (looks like the daemon wasn't starting up properly). Also, added some new commands which should prove useful and added a README file which has a whole ton of useful material in it for debugging.

As for a GUI, that is the plan. Though I haven't used a ListView in Qt before so that will be interesting ;)
Also, with any luck the lack of a GUI for the moment will keep away those who don't know how to use a terminal (and hence, those who don't know how to fix stuff if it breaks).

A quick list of some useful commands you may want for testing it:

Disabling the current daemon:
Re-enabling the daemon
Listen to events triggered by AppLock
Get the current status of AppLock
Just a note, the last DBus call will ONLY work with v0.2.1 so rather don't try it on v0.2.0 :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

I suggest you update the frontpage with the usage instructions and the important commands till we see a GUI. It would make it easier for people who would want to test it.

Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Ok, adding an application with the whole filename including the location of the desktop files would be a bit hectic at times but well, atleast it does the job. So no probs. :)
Hows your GUI work goin? ;)
I guess this thread would grab a lot more attention once the process of adding or removing applications is simplified and an apt GUI would replace the CLI.
Its great work! Keep it going.
Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

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

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

yehey! now my n900 is gonna be bullet proof! LOL!