Re: Details on the information required to replace the tklock (touchscreen/key lock) systemui plugin
On 5 July 2011 13:18, Jonathan Wilson jfwf...@tpgi.com.au wrote: [snip] The SYSTEMUI_TKLOCK_OPEN_REQ handler gets passed a uint argument for the lockscreen mode, can be TKLOCK_ENABLE, TKLOCK_ONEINPUT or TKLOCK_ENABLE_VISUAL. TKLOCK_ONEINPUT is for the blank screen lock mode (called event eater mode in the code) and TKLOCK_ENABLE_VISUAL is for the slide to unlock screen. Not sure what TKLOCK_ENABLE is for exactly. TKLOCK_ENABLE was used for the tklock in earlier versions of Maemo (where you'd press the power button followed by center button to unlock). The second parameter is a boolean argument labeled silent by the code. The code says true = disable infoprints, false = enable infoprints. The third parameter is a flag that seems to indicate if there is a flicker key (whatever that is). Both the second and third parameters seem to be ignored by the stock tklock plugin. The flicker key is the lock key available on the N810 and N900; the 770 and N800 doesn't have one. Called flicker because it's not a slider key -- it flickers back. And indeed these parameters are ignored. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Keeping backlight on
On Tue, 2010-05-11 at 12:45 +0200, ext saurabh aggarwal wrote: Our application on Maemo requires that the backlight be kept on for the entire time we do a process. How do we achieve that? I have already tried calling the command below (every 10 seconds), but that didn't work. usr/bin/dbus-send --system --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_tklock_mode_change string:unlocked That's because this isn't the correct method... Try: dbus-send --system --type=method_call --print-reply --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.req_display_blanking_pause instead (every 30s should be enough). An (undocumented) alternative is: gconftool -s --type int /system/osso/dsm/display/inhibit_blank_mode 3 Replace the 3 for whatever inhibit mode you want: 0 -- No display blanking inhibit 1 -- Inhibit dimming/blanking if charger is connected 2 -- Allow dimming, but inhibit blanking if charger is connected 3 -- Inhibit dimming/blanking 4 -- Allow dimming, but inhibit blanking Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
On tis, 2010-01-19 at 12:10 +0100, ext Jeff Moe wrote: On Tuesday 19 January 2010 07:13:30 Jeremiah Foster wrote: 10) Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all. Ooops! No silence here! I guess that disproves point 10. :-) (http://jaaksi.blogspot.com/ -- More non-silence.) Actually, when I cut and pasted that article snippit I was thinking about his blog *specifically*. AFAICT he has the highest position in Nokia with respect to the Maemo project (correct me if I'm wrong plz). He has a whopping 5 blog posts since the device has been out. His karma in maemo.org is 100% based on his blog posts. He gets asked lots of questions in the blog comments, but rarely answers. Since the N900 has been out, I see he only answered two comments, one of which was mine. ;) The other comment he replied to starts like this: Is there any reason why all my contact attempts with you, Mr. Makkinen and other Maemo people at Nokia are being ignored? ... Excuse me for posting it this way, but what else am I supposed to do if all I get in exchange for my emails is delivery confirmations? I wonder if he ever got a response. Blogs are often used as two way communication tools, he uses it for the occasional edict or a marketing promotion tool. So, what you're saying is that you acknowledge that Ari is the highest ranking person within Maemo. Then you are surprised that he doesn't have time to answer random comments made on his blog... Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Commands for adjusting screen brightness for N810
On ons, 2009-12-16 at 07:13 +0100, ext Jey Han Lau wrote: Hi all, I know there's an built-in application for managing the display (brightness, etc), although I am curious if there are any commands (I am guessing it'll be D-BUS commands if there's any) to manipulate the screen brightness directly, or commands to manipulate all the display settings for that matter. If there's none, are there any ways run the built-in display program (at Control panel) via commands? The display brightness control panel uses GConf for its brightness setting. You can simply change the relevant GConf key and have the brightness change immediately. The relevant GConf key in question is: /system/osso/dsm/display/display_brightness and valid values are 1-5. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On ons, 2009-09-09 at 15:20 +0200, ext Henrik Hedberg wrote: Marius Vollmer wrote: It will be hardcoded, but I think it is still negotiable. The partition itself is actually 2 GB, but it is also used for the Meta Tracker database and other things. What about making it 4 GB? Would that feel big enough? 2 GB, 4 GB... I think there is always an issue when it is hard coded. Why is the ancient VFAT and fixed partitioning still used? Would it be possible to partition eMMC into one big ext3 partition and just use some kind of loopdevice or similar when exposing a part of it as an USB storage in VFAT format? That way also the annoying not mounted right now issue would be fixed, since an USB host and the device could use the same files at the same time. I do not see technical limits, but maybe someone should just code a relevant kernel module (the virtual VFAT loopdevice ;) if that does not exist. Patches happily accepted! regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On ons, 2009-09-09 at 16:53 +0200, ext Andraž 'ruskie' Levstik wrote: :2009-09-09T17:11:Marius Vollmer: Hamalainen Kimmo (Nokia-D/Helsinki) kimmo.hamalai...@nokia.com writes: It would not be trivial task, perhaps it's easier to use some network protocol, or make ext3 support for Windows :) A file-based protocol is the way to go. With ext3, we would still need to unmount the partition to export it, which isn't nice. First time around and not really a dev just a user but: usbnet + scp as an option(winscp?)? there is an ext2/3 driver for windows... a few of them at that as well so maybe use one of those? The problem isn't finding a solution for the computer literati, but rather for normal users. Normal users that doesn't know what scp is. IMHO we have three options: - Real VFAT (with all the drawbacks it brings) - VVFAT - A separate program (PC Suite, most likely) to do the transfers (probably leaving Linux and MacOS users out in the cold) Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
On ons, 2009-09-09 at 23:48 +0200, ext Matan Ziv-Av wrote: On Wed, 9 Sep 2009, Andrew Flegg wrote: On Wed, Sep 9, 2009 at 16:22, Attila Csipama...@csipa.in.rs wrote: On Wednesday 09 September 2009 17:09:17 Andrew Flegg wrote: Of course, if maemo-optify were really clever, it'd also handle patterns like the above and produce /opt/bob/share/foo, but I'd consider this an optional enhancement. I wonder if optification could be done on the level of the autobuilder... In that case most developers wouldn't even need to think about it (and/or mess it up :) at all. There was a strong feeling on #maemo (and one I agree with) that the auto-builder shouldn't be changing things in an uploaded package. Other thoughts included: * Use of /opt is perhaps now a QA requirement for Extras * Can we somehow add a /opt check into minimae/maemian? Is it possible, and is it sensible? Please recall that maemo5 is not the only maemo. Maemo4 is the latest availble for N800/N810 and maemo2 is the latest officailly available on 770. Many packages can compile from same source for all versions. Don't add artificial obstacles to force developers to make their packages incompatible with older versions. It's not an artificial obstacle, it's a way to work around the sad reality that VFAT is a.) de facto standard, b.) a seriously useless file system, c.) most users are unable to cope with better alternatives. But by all means, if you think this is an artificial obstacle, please suggest alternative solutions; we'd be very thankful if you can come up with any solution we might've missed. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On tis, 2009-08-25 at 09:25 +0200, ext Cornelius Hald wrote: On Mon, 2009-08-24 at 23:39 +0300, David Weinehall wrote: On mån, 2009-08-24 at 22:12 +0200, ext Cornelius Hald wrote: On Mon, 2009-08-24 at 23:07 +0300, David Weinehall wrote: MCE only listens to the system bus, maybe this is your problem? Unfortunately not, I tried both the system bus and the session bus. On both I get the mentioned error. But thanks for the tip :) Well, everything in your code looks correct (well, you're not doing any error checking when you call dbus_message_new_method_call(), which means that you'll miss OOM, but that's unlikely to be the issue here). Sorry for not providing more information in my last mail, I'll try to do that now. First, I'm running Fremantle Beta2 SDK with the X86 target. The DBus connection I'm getting through libosso. So the call is: gpointer con = osso_get_sys_dbus_connection(osso_context); You and Claudio were right, mce was not running at all. I thought it will be automatically started, but that's not the case. So I now started it with: run-standalone.sh /etc/init.d/mce start The output of 'ps ax|grep -i mce' now is: 8758 ?Ss 0:00 /sbin/mce --daemon Still the error message I get is the same. I'm listening on the same DBus connection for orientation-changed messages and that seems to work. If I send DBus messages using dbus-send, my callback functions are called. For example my callbacks are called when I'm doing this: run-standalone.sh dbus-send --system --type=signal /com/nokia/mce/signal com.nokia.mce.signal.sig_device_orientation_ind string:'portrait' Hmm, ok while writing this, I noticed that mce after some time is not running anymore. So now I started it not using the init script, but directly with: run-standalone.sh mce --force-stderr --debug-mode And voila :) It's working and I'm getting the correct reply when calling into DBus. So basically my problem is solved. The question now is my does mce not startup correctly when using the init script? I suspect it's because if you're not running it in --debug-mode, it exits when it notices that it fails to connect to dsme. Check if dsme is running too... That's the only difference --debug-mode should make at least. Thanks David and Claudio for all the help :) You're welcome :) Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On mån, 2009-08-24 at 19:44 +0200, ext Cornelius Hald wrote: Hello again :) Listening to the DBus messages and setting the SUPPORT/REQUEST flags works and the outcome is as described. Now the only problem left is the orientation detection during startup. When doing the call to MCE_DEVICE_ORIENTATION_GET I'm always getting the following error message: The name com.nokia.mce was not provided by any .service files Does anyone know what I'm doing wrong? The code is as follows: DBusError error; DBusMessage *message, *reply; message = dbus_message_new_method_call(MCE_SERVICE, MCE_REQUEST_PATH, MCE_REQUEST_IF, MCE_DEVICE_ORIENTATION_GET); dbus_error_init(error); reply = dbus_connection_send_with_reply_and_block(connection, message, -1, error); I hope someone can help, oh and by the way I'm a DBus noob, so it might be that I'm missing something obvious. MCE only listens to the system bus, maybe this is your problem? Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On mån, 2009-08-24 at 22:12 +0200, ext Cornelius Hald wrote: On Mon, 2009-08-24 at 23:07 +0300, David Weinehall wrote: MCE only listens to the system bus, maybe this is your problem? Unfortunately not, I tried both the system bus and the session bus. On both I get the mentioned error. But thanks for the tip :) Well, everything in your code looks correct (well, you're not doing any error checking when you call dbus_message_new_method_call(), which means that you'll miss OOM, but that's unlikely to be the issue here). I can speculate on three possible issues: * you're not opening the bus correctly * mce is not running * your application doesn't have permission to access the system bus Without knowing your setup and the rest of your code, I cannot help any further, I'm afraid :/ Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Changing/Disabling the special button below the cursor pad
On tis, 2009-07-07 at 02:20 +0200, ext Jey Han Lau wrote: Hi all, 2 quick questions: 1. What do you call that special button below the cursor pad? It's the one that opens up the menu if pressed. here's two buttons that open menus; the home button (symbol is a house on the n800 and two overlapping boxes on the n810) and the menu button (a menu both on the n800 and the n810). 2. Is it possible to detect that special button key press or disable its functionality? Either through a program or universally. Both buttons are possible to detect, but you cannot override the home button from an application. The reason I am asking this is because we have developed a full screen program and a user can exit the program by pressing that special key, and we would like to disable it. I suspect that the key you want to mask is the home-key. This home menu is global, and presses of the home key are signalled through D-Bus in addition to the normal way, to avoid forcing all apps to implement their own home-key menu handlers. The signal is sent by mce, and the easiest way to disable it permanently is to edit /etc/mce/mce.ini and remove homekey; from the Modules. Note that this will affect all uses of the home key, so don't do this on general purpose devices. There might be more fine-grained ways to disable it, but none that I know of. Hope this helps. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: introducing friendscard -- a browser-less, gesture-based facebook client
On fre, 2009-02-06 at 05:30 +0100, ext Alex T. W. LEUNG wrote: Hi Andrew, I would like to upload it to chinook-extras-devel, non-free category. However, I was only able to find the instructions relating to diablo-extras-devel: https://wiki.maemo.org/Uploading_to_Extras#.22non-free.22_packages Any clues to help me move forward? Also, I am going to upload three .deb binary files to extras-devel, what should the dput command be? Is the below what I should use? dput -uf chinook-extras-devel-non-free PACKAGE_VERSION_*.changes If yes, what's the instruction for generating the PACKAGE_VERSION_*.changes file? If you build the Debian packages (.deb) the *proper* way (using dpkg-buildpackage or debuild), then you get the .changes file automatically (together with a .dsc file, a .tar.gz and possibly also a .diff.gz file). Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is there a roadmap for opening of binary blobs of N8x0 hardware ?
On tor, 2008-09-25 at 10:28 +0530, ext Kevin Verma wrote: Dear Nokia Maemo Community, I read the recent announcement of stlc45xx which still requires a binary tool for its calibration data. But there are other components like battery, 3D etc. I cannot make predictions about other components, but for the battery software a well-educated guess is Never, and the reasons are manifold: possible liability issues, patents, and the fact that it's software developed by another branch of Nokia rather than internally within Maemo. Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: APT archive lockup (hildon-libs0 vs osso-af)
On lör, 2008-04-12 at 09:57 -0700, ext Andrew Daviel wrote: Precis: dpkg --force-conflicts -i hildon-libs.deb screws apt-get [snip] It looks like installing hildon-libs0 has screwed future use of apt-get, which is somewhat annoying. As my host system is Fedora, not Debian, I normally use rpm/yum not dpkg/apt-get, and I don't have a manpage for apt-get (scratchbox includes one for dpkg, but not apt). (note to self; add MANPATH /scratchbox/users/andrew/targets/CHINOOK_ARMEL/usr/share/man to /etc/man.config so man dpkg works on host) This is, as you say, a .deb-based system, not a .rpm-based system. Using force when installing might be traditional in the rpm-world, but it's a very strong indication that you're doing something wrong in the .deb-world. Is there a way around this? Is there a better way of installing a Bora package such as vncviewer on Chinook ? Make sure to install all the dependencies first? Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: APT archive lockup (hildon-libs0 vs osso-af)
On lör, 2008-04-12 at 22:46 +0300, ext David Weinehall wrote: On lör, 2008-04-12 at 09:57 -0700, ext Andrew Daviel wrote: Precis: dpkg --force-conflicts -i hildon-libs.deb screws apt-get [snip] It looks like installing hildon-libs0 has screwed future use of apt-get, which is somewhat annoying. As my host system is Fedora, not Debian, I normally use rpm/yum not dpkg/apt-get, and I don't have a manpage for apt-get (scratchbox includes one for dpkg, but not apt). (note to self; add MANPATH /scratchbox/users/andrew/targets/CHINOOK_ARMEL/usr/share/man to /etc/man.config so man dpkg works on host) This is, as you say, a .deb-based system, not a .rpm-based system. Using force when installing might be traditional in the rpm-world, but it's a very strong indication that you're doing something wrong in the .deb-world. Is there a way around this? Is there a better way of installing a Bora package such as vncviewer on Chinook ? Make sure to install all the dependencies first? Hmmm, reading a bit more closely, I notice that you're trying to install a package that's built against an older distribution. You cannot combine Bora with Chinook; hildon-libs0 does not exist in the latter distribution. Either find an updated version of vncviewer (IOW one that's built against Chinook), or download the source code and port it yourself. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: source code of status bar entries?
On tis, 2007-12-04 at 10:16 +0200, ext Joni Valtanen wrote: Applets are closed source. Just make your own applets. backlight and many other can be found from /sys/devices/platform/... ...and volume is propably easiest to adjust with alsa. Adjusting the backlight directly from the applet via the sysfs entry is not gonna work; you'd race with the logic in mce dsme that takes care of it. If you want to make an applet to replace the current one, write the value to the GConf entry for brightness instead. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 14:41 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 14:19 +0300, David Weinehall wrote: On ons, 2007-10-24 at 14:14 +0300, Mohammed Hassan wrote: On Wed, 2007-10-24 at 13:54 +0300, David Weinehall wrote: On ons, 2007-10-24 at 12:47 +0300, ext Mohammed Hassan wrote: On Wed, 2007-10-24 at 12:12 +0300, Marius Vollmer wrote: The problem is the logical IDs are needed to maintain the smooth process. It's not easy to simply drop them. I did not say it's impossible. I didn't say it'll be done or it'll not. I'm just saying that they are needed ;-) This might be so, but I honestly doubt it. Can you elaborate? They are used by l10n testing to easily check for untranslated strings (By me as well), to easily determine the originating UI spec, to design test cases and I'm sure they have more uses. msgfmt will happily provide you with statistics about untranslated strings and fuzzy translations, with the added bonus that it can be automated. Yes but it will not help differentiation _visually_ between an en_US or en_GB string and an Engineering English one. It will not help quickly identifying the originating UI spec. I got myself into this thread to see what can be done to ease the community involvement. I know that logical IDs are one of the problems but I'd say it's mainly a problem for developers more than it being a problem for localzsers. Dropping the logical IDs (If it will happen. I simply do not know) will not happen today or tomorrow. Well, of course, the biggest problems currently is the fact that people are not allowed by the F:ed up license agreement to translate the software... But logical strings ARE a big problems for people doing localisation, unless they're also provided with our localisation documentation that gives all the information about what the different logical IDs represent. Then there's of course the string format issue, but that is indeed a problem mostly for programmers (but it can potentially be a big problem). Our localisation documentation is the UI specs ? Yes, the UI specs, unless we can have the relevant chapters that describe the strings extracted in an easy manner. I know that it's simple to automate for documentation written in sane ways (.tex, for instance), but I dunno if Word and similar abominations support it in an easy manner. So if you can manage to convince management that opening all the localisation documents (all lists of logical IDs and their explanations, that is), and Nokia legal that the EULA needs to be rephrased, then I bet most people will be satisfied, I never checked/had a copy of the EULA. I need to know 1st what do you mean by localisation documents. The relevant information was posted earlier in this thread. but as a programmer I cannot be happy until we get proper strings that have the same parameter format as the real strings, to allow for proper argument checking by the compiler. This is not my call. Bug the UI spec designer. What I do is to ensure that the format of the translations is the same as the format of engineering English. I guarantee that. Well, we're not using engineering English at the moment. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo localization to officially non-supported languages
On ons, 2007-10-24 at 17:53 +0300, ext Marius Vollmer wrote: Eero Tamminen [EMAIL PROTECTED] writes: In general, we should try to reduce the need for context and complicated translations. The classical example might: Searched in %d files and %d directories. You will never be able to translate this nicely for all languages because of the wierd way they handle plurals, etc, and because of the combinatorial explosion. Translator can change the order of the arguments with $. See man fprintf and the Single Unix Specification. Yep, I know. Will it be enough? I found this interesting: http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_Horror_Story:_It_Could_Happen_To_You Well, that example assumes that the programmer hasn't read the manual of gettext, and thus does not know about ngettext. A clueless programmer can always mess up. News at eleven. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to detect if the headphones are plugged?
On ons, 2007-10-17 at 16:15 -0400, ext Austin Che wrote: Daniel M German [EMAIL PROTECTED] wrote: is there a way to detect if the headphones are plugged? I am irritated that music playing software does not pause when the headphones are removed (like the ipod) and would like to write a patch to make it an option. ~ $ cat /sys/devices/platform/gpio-switch/headphone/state connected ~ $ cat /sys/devices/platform/gpio-switch/headphone/state disconnected I'd also be interested to know if there's a way to be notified about this rather than just polling. g_io_add_watch() if you're using glib, inotify if you're not (man inotify(7)). Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Nokia N810 Q
On ons, 2007-10-17 at 20:51 +0200, ext Laurent GUERBY wrote: It looks like the buttons do not have the same pictures on them, will their function change in Hildon (one is now hidden with the keyboard)? The icons were modified, since a lot of users found the old ones confusing, the keys are still the same. The buttons on the front are [home] and [cancel/escape], the key beneath the rocker is [menu]. Is the internal 2GB card slot still user accessible next to the battery? No. Will it be used to hold /usr or something like that? No, it'll hold pre-installed data (TTBOMK only information used by the GPS software; I.E. maps); any free space can be used for your own pleasure (music/movies/etc). Will the GPS drivers be open source? No idea. Guess someone else will have to answer that one. I *think* the connectivity team handles that driver. Eh eh :) Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: On 7/11/07, Igor Stoppa [EMAIL PROTECTED] wrote: [snip lots of interesting stuff] It's a similar case to sleep while idle vs user-controlled suspend: just because old devices were doing suspend that doesn't make it desirable. This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available to you with a simple: vim /etc/systemui/systemui.conf but with some minor tweaks? I guess that can be arranged =) Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: On 7/11/07, David Weinehall [EMAIL PROTECTED] wrote: On ons, 2007-07-11 at 13:28 +0100, ext Andrew Flegg wrote: This being reraised made me think about why, the other day, I *did* want user suspend. Sometimes I just want a quick way to: * Shut off all network connections. * Stop any noise (except configured alarms) * Have the screen locked * Not have to save my position * Be able to resume quickly This isn't suspend in a power sense, but in a use-case sense the purpose is clear. So what you want is basically the Soft Poweroff option that's available [...] but with some minor tweaks? Yes, exactly :-) I guess that can be arranged =) Cool. Is it anything I could do straight off (I can also imagine a control panel applet to allow users to customise[1] this suspended state as Igor describes), or does it still dependent on some relatively closed/unhookable infrastructure? systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 16:14 +0300, Igor Stoppa wrote: On Wed, 2007-07-11 at 16:01 +0300, David Weinehall wrote: On ons, 2007-07-11 at 13:53 +0100, ext Andrew Flegg wrote: systemui.xml (sorry, not conf as I wrote in my previous e-mail) file supports callbacks, to get customised behaviour. [1] Sound on/off, network on/off being the obvious ones I can make that configurable through /etc/mce/mce.ini Sorry to ruin the party, but as Mike Baker wrote some time ago (RFC: n800 suspend to ram) the suspend wouldn't be forever anyway: Mike's script or something similar should be used. So there _would_ be anyway some activity. Uhm? What's that got to do with anything? The standard soft-off in mce only relies on the excellent dynamic sleep of the device (but with display turned off, power off behaviour of the power button, touchscreen/keypad lock enabled, etc). Of course, if anyone wants to use suspend too, that's their choice, but really, Soft Poweroff doesn't rely on it. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Internet Tablet Power Management presentation from linux-pm summit 2007
On ons, 2007-07-11 at 15:16 +0200, ext Visti Andresen wrote: [snip] I could suggest using a double click on the power button First click opens the Device mode dialogue. Second click suspends the device. The idea is great, IMHO, but I doubt that Nokia's UI-team would agree; on a Nokia phone, pressing the power button when the device menu is open acts as cursor down. On our device it just ignores the press completely, which was an acceptable behaviour too. Adding a totally different behaviour would probably be regarded as too complicated for the user, or something =) [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Deleting alarms
On tor, 2007-05-03 at 11:12 +0200, ext Murray Cumming wrote: If I understand the alarm API http://www.maemo.org/platform/docs/howtos/howto_alarm_interface_bora.html properly, it can be used to specify a D-Bus method to be called at regular intervals. I guess the application/service will be started if necessary. That's the idea, at least. But how can I remove an existing alarm (to replace it with a new alarm with a different interval) if that alarm was set by a previous instance of my application. Should I save the cookie_t ID in gconf in order to use it later? You can either save the cookie_t ID (this is the preferred solution, since it's guaranteed to be correct), or request a list of all alarms happening in a specific time interval (using alarm_event_query), then iterate the list of cookies (retrieving each alarm_event_t with alarm_event_get) and see if the exec_name or dbus_name matches your application (as mentioned, this is not 100% fail-safe; think of cron-like execution schedulers for instance). Or, do the alarms only work while my application is already running, and stop working when my applications stops? No, alarms keep working even when you quit your application. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Trying to retrieve battery info on N800
On ons, 2007-04-18 at 13:06 +0200, ext Laurent GUERBY wrote: There seem to be a DBUS request/reply used by the battery applet to request current level, see here: http://maemo.org/pipermail/maemo-developers/2007-March/009300.html Plus messages sent when the level changes. However my question: I couldn't find documentation on the maemo site for these bme/mce messages, is the protocol I described considered stable (eg: supported for new releases)? Did I miss obvious messages or got wrong semantics? We cannot make any firm commitments about the interfaces, since they aer designed for internal use, but they will only be changed if there's a real need for it. As for documentation for the mce D-Bus interfaces, you can install mce-dev and read the documentation in the *.h files. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 419 scams using my Maemo Bugzilla email address
On fre, 2007-04-13 at 17:17 +0100, ext Neil MacLeod wrote: Since I have my own domain I registered with Maemo Bugzilla using a unique email address. Unfortunately in the last few days I have begun receiving several 419 scam emails that are being sent to my Maemo Bugzilla email address. Are the scammers harvesting email addresses from Maemo Bugzilla, and can anything be done to prevent it? Probably and no. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Launch maemo browser in fullscreen mode
On mån, 2007-03-19 at 18:08 +0200, ext Eero Tamminen wrote: Hi, ext Tomàs Jiménez Lozano wrote: As a first step to achieve some kind of kiosk mode I am trying to open maemo browser at startup in fullscreen mode. In this case you don't want to run Desktop. With the Home key user can always switch to Home or some other window. Not if he modifies /etc/mce.ini first: HomeKeyShortAction=disabled HomeKeyLongAction=disabled should do the trick =) [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] n800 LED interface
On ons, 2007-01-31 at 20:48 -0500, ext Larry Battraw wrote: First off, kudos to the maemo team for making such a nifty and easy-to-use interface for the keypad LED. I spent a inordinate amount of time just tinkering with the brightness, blinking period, and so forth :-) For those interested, the relevant sys entries are here: /sys/class/leds/keypad Should be self explanatory, particularly if you turn on the blinking from the control panel so you can cat out the values it uses for delay_off and delay_on, etc. My question is this: for the default trigger source (timer), is the blinking just a hardware PWM built into the CPU or is the CPU involved in counting timer interrupts to handle on/off periods and toggling the LED? I ask because there was some discussion on ITT about how someone had their n800 run down overnight with the LED left on. It seemed unlikely but I wanted to make sure a bunch of CPU cycles weren't being burned to run it. To avoid conflicts with the LED-patterns already in use on the device, I'd suggest using the LED-framework. Simply add your pattern to /etc/mce/mce.ini, and use the D-Bus interface to enable/disable the pattern. That way you'll get full control over priorities between different patterns, the possibility to disable certain patterns when the display is on, etc. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] n800 camera specs
On mån, 2007-01-15 at 11:50 -0800, ext Ty Hoffman wrote: Y'all, I haven't seen any specs on the n800 camera (resolution, etc.). Can anybody point me in the right direction? Thanks. Oh, and for what it's worth, I'm now getting annoyed with the speed of the n800 developer discount program...I want to buy an 800, but of course would like to know if I'm one of the chosen ones for the discount. Don't want to buy one and then get the 'you're a winner!' email. I don't like to complain, because I know it's probably tough to manage a discount program and be fair, but a little more alacrity would be good. Meanwhile I'll just sit here on my hands for a few days more before I make the drive to CompUSA. Any ETA out there?? Yeah, I understand how annoying it is that it has been a whole week (gasp!) since the product launch without any decisions on what developers will be picked for the developer discount program. Oh and woes if it would take another week or two. Maybe not *all* virtues are lost, but patience certainly seem to be dead and buried. On a more serious note: the reason this is taking time is simple: we've spent enormous amounts of energy on getting the N800 out in time in the first place. We simply haven't had any time to focus on the developer discount program, since it did not have a firm deadline; CES did... Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] n800 camera specs
On tis, 2007-01-16 at 13:44 +0100, ext Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Weinehall schreef: On mån, 2007-01-15 at 11:50 -0800, ext Ty Hoffman wrote: Y'all, I haven't seen any specs on the n800 camera (resolution, etc.). Can anybody point me in the right direction? Thanks. Oh, and for what it's worth, I'm now getting annoyed with the speed of the n800 developer discount program...I want to buy an 800, but of course would like to know if I'm one of the chosen ones for the discount. Don't want to buy one and then get the 'you're a winner!' email. I don't like to complain, because I know it's probably tough to manage a discount program and be fair, but a little more alacrity would be good. Meanwhile I'll just sit here on my hands for a few days more before I make the drive to CompUSA. Any ETA out there?? Yeah, I understand how annoying it is that it has been a whole week (gasp!) since the product launch without any decisions on what developers will be picked for the developer discount program. Oh and woes if it would take another week or two. Maybe not *all* virtues are lost, but patience certainly seem to be dead and buried. On a more serious note: the reason this is taking time is simple: we've spent enormous amounts of energy on getting the N800 out in time in the first place. We simply haven't had any time to focus on the developer discount program, since it did not have a firm deadline; CES did... I take nokia is going to refund the €300/$300 price difference for people that bought an n800 already but are going to be in the dev program? I have no idea... Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] How to determine if the screen has turned off?
On tor, 2006-12-14 at 11:01 +0200, ext Kimmo Hämäläinen wrote: On Wed, 2006-12-13 at 15:22 -0800, ext Aaron Levinson wrote: On Wed, 13 Dec 2006, Johan Bilien wrote: On Wed, Dec 13, 2006, Aaron Levinson wrote: In the Maemo coding style and programming guidelines document on maemo.org, it states the following: Avoid updating the GUI when the application running on the background and when the screen has been turned off. Remove unnecessary graphical elements or constantly updated screen components. Now, it appears that hildon_window_get_is_topmost() or hildon_program_get_is_topmost() can be used to determine if an application is running in the background, but how does one programmatically determine if the screen has been turned off? I see in the latest version of libosso in SVN that there is a muali API that provides the ability to access the information via a callback, but it is unclear how to determine this on 2.0 or 2.1. Perhaps I can use XScreenSaverQueryInfo() ? http://maemo.org/platform/docs/api/libosso/html/index.html You can register a callback with osso_hw_set_event_cb, set the system_inactivity_ind flag in the osso_hw_state_t argument. Well, I had already examining the libosso APIs before sending the e-mail, and I did notice the system_inactivity_ind flag in the osso_hw_state_t struct. However, according to the libosso documentation, if the callback is called for system inactivity, this means that the application should reduce its activity. I didn't directly associate this text with the screen being blanked, which I think is understandable, since screen blanking is not the same thing. What are the conditions that result in the callback for the system inactivity indicator being called? The statement the application should reduce its activity is somewhat open-ended, and perhaps this callback is used for more than just to indicate that the screen has been blanked. It's not clear to me either, but you can use the system_inactivity_ind for the display on/off information as well (I added that to the trunk libosso.h). I have verified this from the MCE guys some time ago. (MCE guys -- that'd be me, I guess?) Basically, the system_inactivity_ind should not be used for display on/off information, since activity is supposed to be tied to user activity, not screen state; the system can be inactive but still have the display on (however, MCE will not report it as inactive in that case). Sadly some applications relies on the display - activity connection, so MCE reports display on as activity, and it will still remain supported for a few releases to come. However, I want to make it clear that this is not the proper way to do it, and that such an assumption will be incorrect in the long run. I guess the big problem is that there really hasn't been any proper way to do things... The next version of MCE will introduce a new D-Bus signal for this purpose (display_status_ind, and the companion method-call get_display_status), and one or two releases later the old behaviour will no longer be supported. Hopefully these signals will also be taken in use by libosso. [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Proper documentation (was Re: HildonProgram input to gtk_widget_show()?)
On ons, 2006-11-29 at 22:39 +0200, ext Marius Gedminas wrote: [snip] [and /scratchbox/ is a bad place to put scratchbox to, am I the only one to have almost all the harddisk space on /home/ and almost none on / ?] Never heard of mount --bind? I don't have my scratchbox installation on the root-disk, I just have it bind-mounted from another partition. Works just fine. Of course, I'd rather see it packaged the way a real Debian package is supposed to be. I used to do that, but then I've learned and now I just put everything into one big partition. And yes, /scratchbox/ is a bad place. It does not follow the Filesystem Hierarchy Standard. It should be /opt/scratchbox. And the Debian packages should copy/symlink the /opt/scratchbox/login script to /usr/bin/sbox or something. No, Debian-packages should install things in /usr/bin, /usr/share and /usr/lib. It should *NOT* install things in /opt and use symlinks. Debian packages should *NEVER* install anything to /opt or /usr/local. Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Taste the Herring!
On tor, 2006-11-30 at 10:36 +, ext Andrew Flegg wrote: [snip] If Maemo is to be an open and community participated effort, rather than just an open source Nokia SDK[1], the leaders of the project (i.e. Nokia) need to start informing the community of their plans for the platform. When did Linus last announce the release date of the next kernel (and actually follow it)? Ohhh, but I guess you don't regard that as an open and community participated effort either. =) [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Taste the Herring!
On tor, 2006-11-30 at 10:53 +, ext Andrew Flegg wrote: On 11/30/06, David Weinehall [EMAIL PROTECTED] wrote: On tor, 2006-11-30 at 10:36 +, ext Andrew Flegg wrote: [snip] If Maemo is to be an open and community participated effort, rather than just an open source Nokia SDK[1], the leaders of the project (i.e. Nokia) need to start informing the community of their plans for the platform. When did Linus last announce the release date of the next kernel (and actually follow it)? Ohhh, but I guess you don't regard that as an open and community participated effort either. =) Touché, however I said plans not release date (although I did ask about the release date as well). Plans involve other stuff related to frameworks, component versions, capabilities etc. OK, our release plans for the next maemo release: We will try to fix as many bugs as we can, updating the components to newer versions where feasible, and do so within the next 6 months. This is pretty much what we can tell you at this point. We cannot specify component versions, because we don't know that ourselves (bugs or performance issues might force us to up- or downgrade). As far as capabilities go (I assume you mean features rather than the security related kind), that's something we simply cannot divulge without top management decisions, since that would commit us to a direction we might have reason to deviate from. We can of course express expected directions of development though, and I suspect that Carlos will announce such things fairly soon. Oh, and we will release the alarm framework within the same time frame. That will have version 0.4.x. As for people asking whether forthcoming releases will be free or not: all our releases have been free (as in gratis) so far. I don't know of any plans to change this, and I suspect that our management realises that such a move could kill the platform. It wouldn't surprise me if Nokia some day started selling add-on software; I haven't heard of any such plans, but it would make sense (and I cannot see how that could be objectionable). If/when new hardware is released, the software released with that hardware might not necessarily work on older hardware, although the Maemo parts likely should be easy enough to back port (and the handy hacker might even manage do disassemble the software images for the new hardware and use some of the proprietary software from those on the 770). The reason is simple -- making new software images work on old hardware would mean that some hardware upgrades would simply never be feasible. And believe it or not, Nokia doesn't make any money from giving away software for free. It makes money from selling hardware. So if we cannot leave the option open for hardware upgrades now and then, we don't have a feasible business case at all. The Internet Tablet concept isn't as simple as an mp3-player, where the same features can be sold forever on and on with just a change of plastic covers and/or storage capacity. Now all of this should be fairly evident, and I'm sure that if you sit down and think for a while, you'll realise that a company like Nokia simply cannot commit to a five-year plan (or even one-year plan) for something like this. What if someone suddenly came up with an idea that would render the Internet Tablet concept totally dead in the water? What if someone launched this really cool and new cpu that required 1/10th of the current power consumption but required rewrites of the software? What if upstream development of some component we're using suddenly stops -- we cannot maintain everything ourselves. What if... If the 770 had been Nokia's only product, or at least one of our major products, we might have been able to make this kind of promises, since we would've had a far bigger workforce, and could have easily hired several hundred developers just to maintain the SDK (I'm pretty sure the Symbian SDK numbers are in that ballpark, though I'm not sure, since I've never worked in the Symbian division, nor ever developed for that platform). But face it, the Nokia 770 is a drop in the ocean. Nokia is the largest cellphone manufacturer in the world. But we're not even a blimp on the radar screen when it comes to handheld devices. And the market for cellphones is gigantic, the market for Internet Tablets is, so far, minuscule. Until this changes, any medium- and long-term platform commitments will, I suspect, remain impossible to make. Then again, all of this are my own ramblings (even though I'm posting them from my Nokia account), so apart from the commitment on releasing the alarm framework, you'll have to take it with a grain of salt. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Taste the Herring!
On tor, 2006-11-30 at 13:05 +, ext Andrew Flegg wrote: On 11/30/06, Daniel Stone [EMAIL PROTECTED] wrote: David's mail is pretty good. Carlos is obviously doing his best, so all I can do is suggest to you that maybe doing your best to irritate the people trying to help you despite a large corporate structure that has never attempted this sort of open community development before, is a poor idea. David's email is pretty good. Especially the news about the alarm framework. Well, I'm pretty sure that I've announced that before already. This is exactly the kind of thing we want to know, and the frustration is that it takes a few emails which could/are perceived as grumbling by Nokia to find it out. Well, the amount of people working on this project isn't exactly staggering. Each day we face the choice - spend a few hours on reading the maemo-developers list and answering to questions about our schedule, thereby delaying future releases furthere, or spend the same few hours working on the things that Nokia actually pays us to do. For some reason most people pick the latter option. To increase the likelihood of actually receiving answers to your questions on this list, try reading the list archive, don't ask questions that we've already said that we cannot answer, and try not to assume that we're doing everything out of malice. Because we're not. We're doing the best we can to produce a good product, both the thing we sell (the 770 with Internet Tablet Software Edition bla bla bla or whatever the name is) and the Maemo developer platform. But all of us only have so many hours per day, and the number of people actually hired to work just on Maemo is very low (I'm not, for instance). If you perceive us as grumbling, that's going to erect a wall between them/us which is never going to be good for getting a community. Communication is a two-way street. Try reading through some of your own posts lately (especially in light of my explanations in the aforementioned e-mail) and maybe you'll realise that you *are* grumbling quite a lot. Grumbling will probably get an answer from me eventually, but by that time I'll be quite pissed off. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Proper documentation (was Re: [maemo-developers] HildonProgram input to gtk_widget_show()?)
On tor, 2006-11-30 at 16:06 +0200, ext Eero Tamminen wrote: Hi, ext Levi Bard wrote: * For SDL programs you need to export one environment variable BTW, what is this variable? Apparently, I haven't been exporting it. ;-) See: http://maemo.org/pipermail/maemo-users/2006-March/000892.html You can either export it in shell script invoking the SDL program or set it in the SDL program itself (e.g. with putenv()). Or better, setenv(), since putenv() is a non-mandatory part of SuSv3 (POSIX.1-2001), while setenv() is mandatory. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Requesting assistance concerning proper author credit at nseries.com/770experience_2/
On tis, 2006-11-21 at 14:19 -0800, ext Aaron Levinson wrote: I'm hoping that someone at Nokia can be of assistance in giving proper author credit for VNC viewer at the Nokia 770 campaign Web site at nseries.com/770experience_2/ . A few weeks ago, I received an e-mail from Ari Jaaksi, requesting permission to publish VNC viewer on the new campaign Web site. In the e-mail, it was indicated that proper credit would be given to the developer. At the time I received the e-mail, I was on vacation and didn't see the e-mail until a little over a week later, at which point I responded both to Ari and [EMAIL PROTECTED] I didn't hear back and sent another e-mail this week--so far, no response. Currently, VNC viewer shows up on the campaign Web site, but credit is given to Derek Coleman, who took the most recent version of the software that I released for IT2005 and ported it to IT2006 (the diff indicates that the changes were minimal). There were no other changes, but for whatever reason, Derek indicated that he was the sole author on the maemo IT2006 software list wiki page. Since then, Detlef Schmicker has made some changes to the source code, and I'm finally getting back to development, after taking a break in order to get married. I would appreciate it if someone from Nokia could rectify this situation. I spent many hours working on the original IT2005 version, and Detlef has also spent a good deal of time fixing outstanding bugs, making performance enhancements, adding some new features, and responding to users. I'll raise the issue with Ari. Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Requesting assistance concerning proper author credit at nseries.com/770experience_2/
On ons, 2006-11-22 at 11:42 +0200, ext David Weinehall wrote: On tis, 2006-11-21 at 14:19 -0800, ext Aaron Levinson wrote: I'm hoping that someone at Nokia can be of assistance in giving proper author credit for VNC viewer at the Nokia 770 campaign Web site at nseries.com/770experience_2/ . A few weeks ago, I received an e-mail from Ari Jaaksi, requesting permission to publish VNC viewer on the new campaign Web site. In the e-mail, it was indicated that proper credit would be given to the developer. At the time I received the e-mail, I was on vacation and didn't see the e-mail until a little over a week later, at which point I responded both to Ari and [EMAIL PROTECTED] I didn't hear back and sent another e-mail this week--so far, no response. Currently, VNC viewer shows up on the campaign Web site, but credit is given to Derek Coleman, who took the most recent version of the software that I released for IT2005 and ported it to IT2006 (the diff indicates that the changes were minimal). There were no other changes, but for whatever reason, Derek indicated that he was the sole author on the maemo IT2006 software list wiki page. Since then, Detlef Schmicker has made some changes to the source code, and I'm finally getting back to development, after taking a break in order to get married. I would appreciate it if someone from Nokia could rectify this situation. I spent many hours working on the original IT2005 version, and Detlef has also spent a good deal of time fixing outstanding bugs, making performance enhancements, adding some new features, and responding to users. I'll raise the issue with Ari. Follow-up: this issue should be fixed now; you might have to reload the page for the update to be visible. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] re-evaluating the handwriting input method - but there's a problem
On tor, 2006-11-09 at 22:04 +0200, ext David Weinehall wrote: On tor, 2006-11-09 at 18:28 +0100, ext Antonio Orlando wrote: [snip] sometimes, I need to write capital letters, of course. I don't want to define them as symbols, because they easily interfere with other ones, this is something to definetely avoid. But, the solution is simple: there should be a caps-lock button in the handwriting input application! I will continue to use my lowercase symbols, but with the caps-lock enabled they will be considered as capitals. Smooth and easy, isn't it? I can only agree. That would probably be the only thing that could make me use the HWR. On second thought, I'd prefer to be able to assign a HWR-gesture to caps-lock. [snip] Regards: David Weinehall [Disclaimer: Still not representing Nokia bla bla bla] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Battery/power status out of sysfs
On sön, 2006-09-24 at 22:13 -0400, ext Andrew Barr wrote: I was wondering, really out of sheer curiosity, how to query power information (power supply, battery level status) directly instead of going through the Maemo or D-BUS API. Surely this information is available somewhere in /proc or (more likely) /sys, but I cannot find it. This has come up before... http://maemo.org/pipermail/maemo-developers/2005-December/002217.html ..without resolution. Nope, there's public API to query it; the only API available is the D-Bus interface. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IMPORTANT: vulnerability in Application Manager, please check your repositories
On ons, 2006-10-25 at 16:30 +0100, ext Andrew Flegg wrote: On 10/25/06, David Weinehall [EMAIL PROTECTED] wrote: [snip] You know, IMO (not official Nokia policy) this isn't exactly a high risk security issue. To exploit, you need to install a package from an external, non-trusted source. Once you start installing non-trusted 3rd party applications, you're dead anyway. That's not what Marius said: The overflow happens when there is a repository in /etc/apt/sources.list that contains such a icon in one of its packages, or when you have installed a .deb file with such an icon. As such, it only requires someone to add a repository containing MyEvilPackage (and then presumably look at the AM in such a way as to display that package's icon). Well, it still is a low-level risk, since you have to add an untrusted repository to your repository-list. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] IMPORTANT: vulnerability in Application Manager, please check your repositories
On ons, 2006-10-25 at 17:44 +0200, ext Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Weinehall schreef: On ons, 2006-10-25 at 16:24 +0100, ext Andrew Flegg wrote: On 10/25/06, Ian [EMAIL PROTECTED] wrote: maybe its more helpful to ask if there is anything we (the community) can do to help get it out of the door?? ... That presupposes there *is* another official release planned. Until we know that, how can we offer to help? If the fact that marius.volmer @ *** nokia.com *** wrote: and 4.22.1 will be in the next maintenance release of IT 2006. doesn't indicated that another official release is planned from your point of view, you live in a very twisted world indeed. No, we are just used to people from nokia saying 'a' and doing 'b'. Remember the clock framework discussion? Uhm, no, but I do remember a discussion about an alarm framework, and it's still worked on. Most of the quirks have been twisted out now; it's almost functional, and our legal department is checking it at the moment. (Oh, actually, there is a clock framework too, but that's part of the kernel and has been accepted upstream to the best of my knowledge...) And smartass replies from an @nokia.com address aren't creating a lot of community goodwill either. Well, smartass replies from @dominion.kabel.utwente.nl doesn't do much good either. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Flight mode
On tor, 2006-10-19 at 16:19 -0500, ext Diego Zimet wrote: how is flight mode enabled? Is it the same as offline mode? Yes, the two are the same. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Maemo and Ubuntu Edgy: Is it safe?
On ons, 2006-10-18 at 10:06 +0100, ext Ross Burton wrote: On Wed, 2006-10-18 at 10:47 +0300, Santtu Lakkala wrote: Murray Cumming wrote: Has anyone upgraded to Ubuntu Edgy yet? Is the maemo/scratchbox environment working OK with it? Edgy has changed the default shell (/bin/sh) to dash (from bash), and the scratchbox pre/postinst scripts don't like it too much. After changing the shell back to bash everything went smoothly, and sbox is working just fine. Has someone reported this to scratchbox so the scripts are updated to ask for bash instead of sh? That's the wrong approach. The scripts should be fixed to use standard POSIX-features instead of bashism instead. From a brief look, it mainly seems to be a case of fixing the usual things: bashism / POSIX: == / = [ ... -o ... ] / [ ... ] || [ ... ] [ ... -a ... ] / [ ... ] [ ... ] I'll run chkevil on the scratchbox scripts when I have some time for it. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
