Re: Inhibiting device auto-lock on N900
Thank you for this information. It is close to what I've been looking for. However, is this really what happens for example if there is an incoming call - that the phone app sends a request to the phone to unlock? Rather than use an API to show information above the lockout screen... if so this could be a security problem. I did not find any API call which allows me to turn off the backlight but still keep the application responsive however. Hmm. - Ursprungsmeddelande - Hello. To unlock the device : http://wiki.maemo.org/User:Jebba/DBUS#dbus-send-unlock To keep the display on and device unlocked : http://maemo.org/api_refs/4.0/libosso/group__Devstate.html#g93fe32aeb992e128c94b890d6f801bfd David. Per von Zweigbergk wrote: I'm writing a talking clock application. The purpose of this application is to answer the ever-so-frequent question mghhnm, what time is it in the morning, just before you've been able to open your eyes properly much less put on your glasses. I've already written the application itself, it was a fairly simple project that took a couple of hours. In testing, however, I discovered a slight drawback to my planned approach of start the program before falling asleep, mash the screen in the morning and it'll tell me the time. 1. The screen itself will stop accepting taps when the device is turned off. It seems this particular feature can be inhibited by leaving the phone slided open (with the qwerty keyboard exposed) or by setting the gconf setting /system/osso/dsm/locks/touchscreen_keypad_autolock_enabled to false. This requires you to slide the lock button on the side of the phone to unlock the screen. Annoying, but still doable even in a half-awake stupor. And besides, you can always leave the phone activated in its opened mode. 2. The device will automatically lock itself after 5 minutes, for security purposes. Now, remembering and correctly entering the device lock code in a half-awake stupor is considerably more difficult. This can be disabled by setting the gconf setting /system/osso/dsm/locks/devicelock_autolock_enabled. However - I don't really like this approach of changing gconf user settings to inhibit device locks. The last thing I want is for the phone or my application to crash (or more likely, to run out of battery) while the program is running and leaving the device unlocked, requiring the user to set the automatic lock option on again (if he even notices it's been disabled). Whoever coded the built-in media player agrees with this. He's found some way to tell the system not to automatically lock itself without changing the gconf settings. I have not yet figured out how. One other option worth considering is the fact that some applications, such as the phone (for an incoming call) and the alarm application (to silence the infernal bleeping of an alarm) will allow you to throw up a screen to the user that'll be accessible even if the lock code has not been entered. This would also solve the potential security issue of somebody stealing your phone while you're sleeping to get to it while it's unlocked. :-) So, does anybody have any ideas as to how I might acheive this in some way? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
On 2010-04-19 16:50, Dave Neary dne...@maemo.org wrote: Hi, Dave Neary wrote: I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. So I included an A to Z for this project, with the 3 files you need to create a .tar.gz using standard autotools. Let me know if it's useful. I updated this with some newer syntax and a link to some (very detailed) documentation in the wiki. I second autotools as a way to make packaging easier (once you understand them). -- David King | http://amigadave.com/ | dav...@openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Info Center library service released with first set of official maemo Fremantle 5 documentation
On 2010-04-19 17:21, Andrew Flegg and...@bleb.org wrote: On Fri, Apr 16, 2010 at 18:40, jarmo.ti...@nokia.com wrote: The Maemo documentation infrastructure project has released new Maemo Info Center documentation service for Maemo platform. Together with Maemo Info Center service we released also the first set of official Maemo Fremantle 5 documentation. More Fremantle 5 documentation will be updated to the Maemo Info Center service end of April. One thing I'd like to see is a *definitive* Maemo reference library. Currently, we have docs spread over Forum Nokia, Info Center, the maemo.org wiki - and then there's the docs that are *duplicated* (with slightly different versions) between the various places. Is it feasible to try and get things like the PyMaemo API reference into the Info Center, and any other popular developer resources (say, Gtkmm is an obvious example)? There is already API references for hildonmm and hildon-fmmm, and a tutorial for the C++ bindings in general included in Info Center. If you mean that the gtkmm API reference should be included, then that should be relatively easy. The API reference is generated by Doxygen, and the index is created with a custom XSLT script that is included in hildonmm and hildon-fmmm: https://garage.maemo.org/plugins/ggit/browse.php/?p=maemomm;a=blob;f=hildonmm/docs/reference/tagfile-to-eclipse-toc.xsl The tutorial documentation is Docbook XML, which makes use of the Docbook XSL stylesheets to generate an Eclipse table of contents: https://garage.maemo.org/plugins/ggit/browse.php/?p=maemomm;a=blob;f=maemomm-documentation/docs/tutorial/eclipse.xsl We added some paramaters to this file to make things easier: https://garage.maemo.org/plugins/ggit/browse.php/?p=maemomm;a=blob;f=maemomm-documentation/docs/tutorial/docbook2eclipse-toc.xsl -- David King | http://amigadave.com/ | dav...@openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
On Apr 20, 2010, at 11:15 AM, David King wrote: On 2010-04-19 16:50, Dave Neary dne...@maemo.org wrote: Hi, Dave Neary wrote: I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. So I included an A to Z for this project, with the 3 files you need to create a .tar.gz using standard autotools. Let me know if it's useful. I updated this with some newer syntax and a link to some (very detailed) documentation in the wiki. I second autotools as a way to make packaging easier (once you understand them). Sorry, I discovered this thread late. But it looks like you guys have done a great job without my input. Clearly there are those who know more about packaging than I do in Maemo! :-) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Inhibiting device auto-lock on N900
On Tue, 2010-04-20 at 11:05 +0200, ext Per von Zweigbergk wrote: Thank you for this information. It is close to what I've been looking for. However, is this really what happens for example if there is an incoming call - that the phone app sends a request to the phone to unlock? Rather than use an API to show information above the lockout screen... if so this could be a security problem. I did not find any API call which allows me to turn off the backlight but still keep the application responsive however. Hmm. Media Player uses the Do not disturb flag(* in its window to prevent the screen going off when you are watching a video. hildon-desktop notices the flag in the window and periodically sends do not blank the screen yet, please D-Bus messages to the MCE daemon. You could use this flag in your window, or send the D-Bus messages yourself. *) libhildon has hildon_gtk_window_set_do_not_disturb() convenience function. Or you can set the window property using the x11 API directly. -Kimmo - Ursprungsmeddelande - Hello. To unlock the device : http://wiki.maemo.org/User:Jebba/DBUS#dbus-send-unlock To keep the display on and device unlocked : http://maemo.org/api_refs/4.0/libosso/group__Devstate.html#g93fe32aeb992e128c94b890d6f801bfd David. Per von Zweigbergk wrote: I'm writing a talking clock application. The purpose of this application is to answer the ever-so-frequent question mghhnm, what time is it in the morning, just before you've been able to open your eyes properly much less put on your glasses. I've already written the application itself, it was a fairly simple project that took a couple of hours. In testing, however, I discovered a slight drawback to my planned approach of start the program before falling asleep, mash the screen in the morning and it'll tell me the time. 1. The screen itself will stop accepting taps when the device is turned off. It seems this particular feature can be inhibited by leaving the phone slided open (with the qwerty keyboard exposed) or by setting the gconf setting /system/osso/dsm/locks/touchscreen_keypad_autolock_enabled to false. This requires you to slide the lock button on the side of the phone to unlock the screen. Annoying, but still doable even in a half-awake stupor. And besides, you can always leave the phone activated in its opened mode. 2. The device will automatically lock itself after 5 minutes, for security purposes. Now, remembering and correctly entering the device lock code in a half-awake stupor is considerably more difficult. This can be disabled by setting the gconf setting /system/osso/dsm/locks/devicelock_autolock_enabled. However - I don't really like this approach of changing gconf user settings to inhibit device locks. The last thing I want is for the phone or my application to crash (or more likely, to run out of battery) while the program is running and leaving the device unlocked, requiring the user to set the automatic lock option on again (if he even notices it's been disabled). Whoever coded the built-in media player agrees with this. He's found some way to tell the system not to automatically lock itself without changing the gconf settings. I have not yet figured out how. One other option worth considering is the fact that some applications, such as the phone (for an incoming call) and the alarm application (to silence the infernal bleeping of an alarm) will allow you to throw up a screen to the user that'll be accessible even if the lock code has not been entered. This would also solve the potential security issue of somebody stealing your phone while you're sleeping to get to it while it's unlocked. :-) So, does anybody have any ideas as to how I might acheive this in some way? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Searching rootstrap for maemo5-update4
On Mon, 2010-04-19 at 15:58 +0300, daniel wilms wrote: you can take this [1] rootstrap. This is equivalent to 1.0.1. Every later version is not so trivial to install as it would take anyway the latest packages out of the repository. Hope this will help you. 1. http://repository.maemo.org/stable/fremantle-update2/ Thanks for the tip Daniel. That version should be fine! Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: j2me
Quoting Christopher Intemann intem...@gmail.com: However, /bin/cvm is set to rw and can not be executed. For some confusing reason, chmod a+x cvm appears to have no effects on the access rights and cvm would still not be executed (even not when trying as root). ls -la unveals no change of the permissions. Is there any stupid security mechanism in maemo preventing me to change permissions for files or what am I doing wrong? Thanks in advance, Chris This means probaly that the api is wrong or fileformat. Try to run file on the binary and look at the output maybee you need readelf or objdump too. Bye Henning tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Geschäftsführer: Boris Esser, Elmar Geese HRB AG Bonn 5168 - Ust-ID: DE122264941 http://www.tarent.com/ Heilsbachstr. 24, 53123 Bonn, fon +49 228 52675-0, fax +49 228 52675-25 Weigandufer 45, 12059 Berlin, fon +49 30 5682943-30, fax +49 228 52675-25 Schützenstr. 18, 10117 Berlin, fon +49 30 27594853, fax +49 30 78709617 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
problems uploading to non-free repository
hello, Ive seen many bugs related to this issue, which have been marked as solved. for example: https://bugs.maemo.org/show_bug.cgi?id=3354 https://bugs.maemo.org/show_bug.cgi?id=8077 https://bugs.maemo.org/show_bug.cgi?id=4241 Ive been getting this error today while uploading to the non-free section Uploading to fremantle-extras-devel-non-free (via scp to drop.maemo.org): Permission denied (publickey). lost connection Warning: The execution of '/usr/bin/scp' as 'scp -p /home/krk969/buddy_0.1-1_armel.deb /home/krk969/buddy_0.1-1_armel.changes krk...@drop.maemo.org:/var/www/extras-devel/incoming-nonfree/fremantle' returned a nonzero exit code. Error while uploading. could anybody help me with this please ? does it have anything to do with the public ssh key in my garage account page ? I have no clue what Im doing wrong. thanks Ram ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Help needed: packaging/distributing very small C app
Hi Dave, Cool documentation ! It helped me in revising all my basics. I am sure, it will serve a great purpose for a maemo newbie developer. Few suggestions :- 1. Adding a GTK based example with dependencies specified in configure.ac (PKG_CHECK_MODULES for gtk flags), debian/control (Depends,Build-depends) would be useful 2. What changes are required for deb packaging a QT program. P.S : I have suggested this as you also mentioned about desktop files. Regards, Chitti Message: 17 Date: Mon, 19 Apr 2010 16:50:45 -0700 From: Dave Neary dne...@maemo.org Subject: Re: Help needed: packaging/distributing very small C app To: Thomas Waelti twae...@gmail.com Cc: maemo-developers@maemo.org maemo-developers@maemo.org Message-ID: 4bccec55.1020...@maemo.org Content-Type: text/plain; charset=ISO-8859-1 Hi, Dave Neary wrote: I documented the packaging of a C app (using autotools for building) a while back in the wiki: http://wiki.maemo.org/Packaging#A_concrete_example_-_rot13 This starts with a tiny C program the minimum autotools stuff to build it (I don't include these - would that be useful?) and guides you through making a .deb. So I included an A to Z for this project, with the 3 files you need to create a .tar.gz using standard autotools. Let me know if it's useful. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
