Active Topics
-
Maemo repository (8)
to Community by Maemish - 16 hrs, 51 mins ago -
Porting apps to Leste (44)
to Maemo 7 / Leste by norayr - 21 hrs, 24 mins ago -
List of well performing apps on Leste (35)
to Maemo 7 / Leste by smatkovi - 3 days, 18 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (13)
to SailfishOS by edp17 - 4 days, 16 hrs ago -
Sailfish OS for the Samsung Galaxy Note 4 (SM-N910C) - (treltexx) (79)
to SailfishOS by edp17 - 4 days, 16 hrs ago -
U-Boot for Nokia RX-51 with BootMenu (updated version 2012.10-rc3-1) (843)
to Alternatives by Arno_11 - 4 days, 22 hrs ago - more...
| The Following 3 Users Say Thank You to SPARTAN563 For This Useful Post: | ||
|
2011-06-24
, 08:45
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#12
|
Originally Posted by SPARTAN563
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!
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 tryI'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
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.
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!
| The Following User Says Thank You to warhawk007 For This Useful Post: | ||
 |
|
2011-06-24
, 09:10
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#13
|
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
(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).
Last edited by SPARTAN563; 2011-06-24 at 13:31.
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
(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).
__________________
Sierra Softworks
Sierra Softworks
Last edited by SPARTAN563; 2011-06-24 at 13:31.
| The Following 2 Users Say Thank You to SPARTAN563 For This Useful Post: | ||
|
|
2011-06-24
, 14:47
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#14
|
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:
* 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
You can check this page for information on the current build status.
I look forward to getting page loads of bug reports
Last edited by SPARTAN563; 2011-06-24 at 16:59. Reason: Build completed
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
__________________
Sierra Softworks
Sierra Softworks
Last edited by SPARTAN563; 2011-06-24 at 16:59. Reason: Build completed
| The Following 4 Users Say Thank You to SPARTAN563 For This Useful Post: | ||
|
|
2011-06-24
, 18:33
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#15
|
Originally Posted by SPARTAN563
Wow! Just saw the update now! Thanks a lot! Will check it out and report back as soon as possible.
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
Will we be seeing a GUI soon?
Cheers!
|
|
2011-06-24
, 18:42
|
|
Posts: 92 |
Thanked: 92 times |
Joined on May 2011
@ Stellenbosch, South Africa
|
#16
|
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:
Code:
initctl emit AppLockStopDaemon
Code:
initctl emit AppLockStartDaemon
Code:
dbus-monitor "type='method_call',sender='com.sierrasoftworks.AppLock.Daemon'"
Code:
dbus-send --print-reply --dest=com.sierrasoftworks.AppLock /com/sierrasoftworks/AppLock com.sierrasoftworks.AppLock.Daemon.GetStatus
__________________
Sierra Softworks
Sierra Softworks
| The Following User Says Thank You to SPARTAN563 For This Useful Post: | ||
|
|
2011-06-24
, 18:53
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#17
|
Originally Posted by SPARTAN563
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.
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 daemonCode:initctl emit AppLockStopDaemon
Listen to events triggered by AppLockCode:initctl emit AppLockStartDaemon
Get the current status of AppLockCode:dbus-monitor "type='method_call',sender='com.sierrasoftworks.AppLock.Daemon'"
Just a note, the last DBus call will ONLY work with v0.2.1 so rather don't try it on v0.2.0Code:dbus-send --print-reply --dest=com.sierrasoftworks.AppLock /com/sierrasoftworks/AppLock com.sierrasoftworks.AppLock.Daemon.GetStatus
Cheers!
|
|
2011-06-25
, 01:35
|
|
Posts: 96 |
Thanked: 51 times |
Joined on Jul 2010
@ India
|
#18
|
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!
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!
|
|
2011-06-25
, 10:46
|
|
Posts: 89 |
Thanked: 4 times |
Joined on Jun 2010
|
#19
|
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
aap --add fring
Adding fring to the list of locked applications
Failed to open Desktop file
|
|
2011-06-25
, 10:48
|
|
Posts: 1,729 |
Thanked: 388 times |
Joined on Jan 2010
@ Canada
|
#20
|
Originally Posted by SPARTAN563
yehey! now my n900 is gonna be bullet proof! LOL!
What is AppLock?
AppLock is an application designed to lock your phone if any one of a predetermined set of applications is launched. In layman's terms, if a locked application is started your phone will enter a lock state and wait for you to enter your password before continuing.
__________________
if i did help you, just click "Thanks" on the lower right of my post. thanks!
"The best way to break a Spell is to prevent it from being cast in the first place"
N900: 1000/1150mhz; sampling_rate 15; up_threshold 150000;
if i did help you, just click "Thanks" on the lower right of my post. thanks!
"The best way to break a Spell is to prevent it from being cast in the first place"
N900: 1000/1150mhz; sampling_rate 15; up_threshold 150000;
For A, darn well I guess it was worth a try
As for B, excellent that will be extremely helpful
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.
Sierra Softworks
Last edited by SPARTAN563; 2011-06-23 at 21:31. Reason: Victory! :D