Re: Smooth animation
On Wed, 2009-12-30 at 10:46 +0100, ext Mark Clarkson wrote: Hi, I am writing an app for the n900 which requires smooth animation within a subwindow. I want to retain the top toolbar and make use of hildon's themed widgets - I want to keep, as much as possible, the maemo 5 look and feel. By top toolbar you mean the menu/title bar and close button? I have tried cairo animation and clutter (bug #7459), neither of which provide smooth tear/flicker free animation. As a beginner maemo developer, excited with the possibilities of this new device, is there a way to achieve this goal? We don't have vsync (unless you use OpenGL directly and enable it yourself and disable the compositor [which is not using it]), so the best you can do is to: 1) try to render every frame so that it's all contained in one damage event (so that the compositor will do it all in one OpenGL update). 2) try to render every frame as fast as possible to keep animations smooth. The xresponse utility is a good tool to see how long the screen updates take and how many damage events are generated for the compositor. This is easier to do in a fullscreen application because then you can disable the compositor and draw to the screen directly (which allows for better FPS, and damage events do not matter anymore). -Kimmo Cheers Mark. ___ 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: Drag Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
Claudio Saavedra wrote: El jue, 07-01-2010 a las 10:08 -0400, Anderson Lizardo escribió: On Thu, Jan 7, 2010 at 5:37 AM, Claudio Saavedra csaave...@igalia.com wrote: There is no drag 'n drop in Maemo GTK+. This has been deliberately disabled. I believe that pretty much answers Jeff's issue... Was this done for Maemo 5 ? Because according to Jeff it used to work on the N810 (Diablo). I haven't tested it myself on N810 , though. Yes, only since Maemo 5. Out of curiousity, do you have any idea why it was disabled in Maemo 5? Is there DnD in Maemo Qt? -- Jeffrey Barish ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Till Harbaum / Lists on 01/07/2010 10:15 AM wrote: - We'll have to scan all files in every geotag aware app If you want to create some sort of standard database for holding GPS metadata for any file type then you have to write it. - This consumes much CPU power Reading a file is hardly CPU intensive. - This takes a very, VERY long time Not on an SSD unless you have billions of files. - This does not work with MP3/WAV/PNG/GIF/AVI/... Quite right. Why do you expect GPS information to be available for these files? Who told you to expect GPS data from those file types? - This information can hardly be shared between different apps The standard for JPEG type files is to use EXIF for any and all metadata. Any app should and can support reading EXIF. - My app has to cache/store this information for all media files to not be forced to re-scan everything everytime it's being started I think you need to re-think what your goal is. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, thank for you for your reply. Am Donnerstag 07 Januar 2010 schrieb Michael Cronenworth: - This consumes much CPU power Reading a file is hardly CPU intensive. Reading thousands of files is. I really don't have much media stored on my n900, but it's already 400 mp3 files, 150 jpegs and 40 avi videos. Scanning them for tags aready would take a long time and even worse would consume lots of CPU (and thus battery) power. - This takes a very, VERY long time Not on an SSD unless you have billions of files. Reading several thousand media files does not take long? You'll have to scan all oif them, even if only a fraction of them actually contains geotags as you don't know which the ones with geotags are before you actually search for them. - This does not work with MP3/WAV/PNG/GIF/AVI/... Quite right. Why do you expect GPS information to be available for these files? Who told you to expect GPS data from those file types? Why should i assume that i can savely ignore them if they all may actually contain geotags? Why should i be sure that e.g. maemo-recorder nor any other app puts geotags into the wav files it stores? - This information can hardly be shared between different apps The standard for JPEG type files is to use EXIF for any and all metadata. Any app should and can support reading EXIF. But then every single app has to scan every single file. That's awful. I think you need to re-think what your goal is. That's sad as it really limits the usage of geotags. The right solution would sure be to let tracker handle this as it's the purpose of tracker to index the disk for media files and to provide meta information to all apps interested in this. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki) wrote: Hi, ext Mark Clarkson wrote: I have made a simple animation using a clutter timeline with clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the animation plays making the animation look terrible. I have tried none, dri and glx values for the CLUTTER_VBLANK environment variable but this seems to have no effect at all. Is there a way to fix this? Screen update isn't yet synched to LCD refresh. Please file a bug about it to bugs.maemo.org (it needs support from kernel display driver, X server, SGX driver, Clutter and hildon-desktop compositor, but I guess you could file it against Official platform - Core - X). Don't hold your breath with this one. At the moment it seems a proper vsync support is not going to be implemented in Maemo 5. There is a possibility to use a vsync even now, but the implementation is not good enough: if you enable the current vsync, the OpenGL application is blocked on glSwapBuffers until vsync comes, which prevents the application to prepare the next frame (and drops FPS too low). I think doing like Bounce does is the best you can do: use fullscreen window and disable the compositor (in hildon-desktop). Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
ext Andrew Flegg and...@bleb.org writes:
Also, it'd be useful to have confirmation from Marius if the
heuristics described here regarding Python apps have been implemented
in mode auto:
http://lists.maemo.org/pipermail/maemo-developers/2009-December/022807.html
Not as written. I think I have the framework in place now, and we only
need to find a working implementation of the is_python_package function.
http://maemo.gitorious.org/maemo-af/maemo-optify
http://maemo.gitorious.org/maemo-af/maemo-optify/blobs/master/maemo-optify-deb#line36
Currently, is_python_package looks like this:
sub is_python_package {
my ($dir) = @_;
# XXX - some input from Pythonistas is required here.
return (-d $dir/usr/lib/python2.5
|| -d $dir/usr/share/pyshared
|| -d $dir/usr/share/pyshared-data
|| -d $dir/usr/lib/pyshared
|| -d $dir/usr/share/python-support
|| -d $dir/usr/lib/python-support);
}
I will change that to something closer to what has actually been
proposed. Concrete patches are most welcome, of course!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, Am Donnerstag 07 Januar 2010 schrieb Michael Cronenworth: How do i access geotags? With libexif. GPS coordinates are in the EXIF data. This only works for jpeg images which are only a fraction of media files stored on an n900. I was fearing to get some answer like this. This has so many disadvantages: - We'll have to scan all files in every geotag aware app - This consumes much CPU power - This takes a very, VERY long time - This does not work with MP3/WAV/PNG/GIF/AVI/... - This information can hardly be shared between different apps - My app has to cache/store this information for all media files to not be forced to re-scan everything everytime it's being started I am afraid this will mean that such a project doesn't make much sense. Thanks, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: FM RDS data
You should take a quick look at the fmtx_client command. It already does much of what you want (with the exception of finding an unused signal) fmtx_client -f sets the frequency fmtx_client -s sets the radio station Note: This must be an eight character string, but it can be padded with blanks. This is a bug that has been fixed in the next flash e.g. fmtx_client -s aldon will not work but fmtx_client -s aldon does work fmtx_client -t sets the text. This can be any length and can have embedded blanks e.g. fmtx)client -t This is a long test works. I've used this to send messages from my N900 to the RDS display on my car radio and it has worked nicely. (and members of the family have enjoyed receiving personalized messages on the car radio) Aldon -Original Message- From: kher...@gmail.com [mailto:kher...@gmail.com]on Behalf Of Benoît HERVIER Sent: Thursday, January 07, 2010 12:19 AM To: Martin Grimme Cc: Aldon Hynes; maemo-developers@maemo.org Subject: Re: FM RDS data About FM and RDS modifying RDS signal transmited from the tablet is possible ? I'm thinking of a small usage, a app that found the freest frequency (by listening fm with the transmitter) and change the frequency of transmitted music to the found one and send an rds signal by the transmitter, so you don't have to change frequency on your car receiver (or everything else). I know that fm transmitter emit an rds signal ... but can that be changed ? Does there is documentation about the fm transmitter and receiver somewhere on Maemo ? Thanks a lot 2010/1/6 Martin Grimme martin.gri...@gmail.com Hi, the FM receiver's interface for RDS is exposed via sysfs. So any application can read RDS data from it. The frequency bands the receiver is capable of are US/EUR (87.5 - 108.00 MHz) and Japan (don't remeber, but I think starts somewhere at 70 MHz). A region switch in the driver (sysfs-Interface again but as root) switches between the frequency bands. Martin 2010/1/6, Aldon Hynes aldon.hy...@orient-lodge.com: I have been approached by a person interested in sending data from a sensor via FM to a cellphone which would in term transmit this data to the Internet. I am interested in figuring out if this is something that could be done with an N900. With that, I have a few specific questions: First, can anyone point me to information about how to programatically receive RDS data? I've read that the FM receive app is supposed to do that, but I haven't managed to receive RDS data that way yet, and I don't have the source code. Second, does anyone have any idea what frequencies the FM receiver can tune into? The programs I've seen have focused on the traditional commercial FM band, 88 Mhz to 106 Mhz. Can the FM receiver tune in higher or lower frequencies? If so, what is the real frequency range of the FM Receiver. Third, are there other data formats that can easily be sent and/or received from the Nokia phone? If so, can people point me to any of these other data formats? Any help you can provide would be greatly appreciated. Aldon ___ 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 -- Benoît HERVIER - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debugging applet causing hildon-home crash
2010/1/7 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: On Wed, 2010-01-06 at 22:46 +0100, ext Graham Cobb wrote: In Fremantle, the GPE Summary applet causes hildon-home to crash if it is removed and then re-added. I have not been able to work out what the problem is. We had several of this kind of crashes that happen when you remove and add it back. Usually the problem was in the Glib types that the applet uses: if it tries to register new types that are already there, or something similar. I guess Glib should print out some warnings for you? (notice that hildon-home probably closes stdout by default) As a side note, python-hildon suffered from these issues because the latest hildon-home (or hildon-desktop?) versions seemed to incorporate some gtype registration functions which were missing before (i.e. ones usually generated by glib-mkenums). The python bindings tried to register the same types again, which caused problems (the errors shown on console gave a hint about this). The fix consisted on not running glib-mkenums for hildon types. Maybe not related to this problem, but anyway. Any hints on how best to debug this hildon-home crash? It could help to disable all other plugins than the one that you are debugging and using gdb or good old printfs I guess. I usually also debug on scratchbox/x86 , where I can kill hildon-home and restart it again with hildon-home which then shows debug messages on the console. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
Hi, This seem to be the cause of the error Get:7 http://repository.maemo.org fremantle/non-free Packages [7966B] Failed to fetch http://repository.maemo.org/dists/fremantle/sdk/free/binary-i386/Packages.gz 504 Gateway Time-out [IP: 193.184.164.139 80] Fetched 2137kB in 5m54s (6025B/s) Reading package lists... W: GPG error: http://repository.maemo.org fremantle Release: Couldn't access keyring: 'No such file or directory' W: You may want to run apt-get update to correct these problems E: Some index files failed to download, they have been ignored, or old ones used instead. I think this isn't my fault, no? Br, Koos -- Forwarded message -- From: Maemo Extras Builder extras-cauldron-bui...@garage.maemo.org Date: 2010/1/7 Subject: [fremantle]: kmplayer 0.10.2-4 FAILED To: koos.vrie...@gmail.com [2010-01-07 19:55:02] Processing package kmplayer 0.10.2-4. Uploader: koos, builder: builder1 [2010-01-07 19:55:04] Building kmplayer 0.10.2-4 for target 'maemo-fremantle-armel-extras-devel' [2010-01-07 20:03:03] OK [2010-01-07 20:03:07] Building kmplayer 0.10.2-4 for target 'maemo-fremantle-i386-extras-devel' [2010-01-07 20:09:09] FAILED [2010-01-07 20:09:15] You can find more info about this build here: https://garage.maemo.org/builder/fremantle/kmplayer_0.10.2-4/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Thursday 07 January 2010 10:04:56 Aki Niemi wrote: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Excellent! I can't wait to try it out. I was trying latest git (e.g. 0.15+). There is some jumping through hoops required to get Phonet over USB working that would allow you to use oFono on the desktop with N900 or any other (recent) Nokia phone connected via USB in PC suite mode. I've been meaning to write a howto for that, and I guess it's high time I actually go and do that. ;) Well, that kind of sounds like what my quick dirty mini-howto is about: http://wiki.maemo.org/User:Jebba/Ofono That said, you know far more about it! Do you have a sample modem.conf for N900? And other clues would be appreciated! There's no need for modem.conf on the N900; in fact, my ofono package builds with atmodem and udev disabled. The isimodem driver automagically detects modems via netlink. Nice. :) Thanks for all the info, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
to, 2010-01-07 kello 14:04 +0100, Niemi Aki (Nokia-D/Helsinki) kirjoitti: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Right, ofono is now in extras-devel, and based on some quick testing, it seems to work fine. Note that the isimodem driver is still a work in progress and we don't have some things working properly. Most notably, the SMS or CBS drivers aren't implemented yet. Those are a bit tricky anyway, because they interfere with the regular telephony stack on the device. Cheers, Aki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Automatic optification
ext Graham Cobb g+...@cobb.uk.net writes: I still have to do something about the Python optification. I will do that in the next few days. Thanks. We really need this in order to turn on optification by default. I have some first version of a test that tries to identify Python packages in the maemo-optify Git repo. It might just work. My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. Can you explain that in more detail? Do you mean that you will optify (move) smaller and smaller files until you get to the right ratio and then stop? Yes, exactly. What if you can't get to the right ratio -- is that a failure? No, it would just make a package that is not as optified as one would hope. It would be up to the QA process to decide how to proceed with such a package. Are you still planning to allow the developer to override decisions? Yes. I should probably start with that, so that we can more easily control the heuristic from the outside. Do we actually need that level of complexity? With enough control over optification, hopefully not. I really don't like the idea of the optification changing between releases just because one file has changed size -- for example, I wouldn't want the developer to find that one of their files (e.g. a binary) has suddenly been moved because a different file (e.g. a text file) has changed size. That is asking for creating unexpected bugs. Yes, good point. But this can happen with any heuristic. Now, if a file gets bigger than 2k, it will suddenly be optified. That might be just as unexpected. I would prefer to keep the algorithm the same as we have now, as we have got some experience with that, and turn on automatic optification with that algorithm. Yes, I agree. So any change I'll make to the algorithm from now on will be off by default. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Anderson Lizardo anderson.liza...@openbossa.org writes: Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) Yes, having pymaemo-optify installed after .deb's have been created would be a indication of that package depending (directly or indirectly) on some Python package during build. That is true on the buildbot, but not on people's machines. The buildbot has close to the minimal amount of packages installed for any given build, but people's machines have a lot unrelated packages installed, usually. So I don't think we should look into the build environment, we should only look into the source tree or the packages that have been built. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
On Thu, 2010-01-07 at 20:50 +0100, ext Till Harbaum / Lists wrote: Hi, I think you need to re-think what your goal is. That's sad as it really limits the usage of geotags. The right solution would sure be to let tracker handle this as it's the purpose of tracker to index the disk for media files and to provide meta information to all apps interested in this. Yes, tracker should do it. Fortunately, tracker can be extended to index all kind of information. CC'ing Ivan Mr. Tracker Frade here... -Kimmo Till ___ 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: How to access geotag information?
Michael Cronenworth wrote: Till Harbaum on 01/07/2010 06:30 AM wrote: How do i access geotags? With libexif. GPS coordinates are in the EXIF data. I didn´t really look into this, but at least for image files tracker seems to be prepared to handle geo tags. Not sure if this functionality is available in reality, but have a look at the file /usr/share/tracker/services/image.metadata There are two properties that look interesting: Image:Location and Image:Sublocation Anyways, it´s just a guess. Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
koos vriezen wrote: I think this isn't my fault, no? No, it´s not your fault. Unfortunately I have no idea when it will work again. I guess you just have to try again later... Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
On Friday 08 January 2010 08:05:59 Cornelius Hald wrote: koos vriezen wrote: I think this isn't my fault, no? No, it´s not your fault. Unfortunately I have no idea when it will work again. I guess you just have to try again later... Outages get reported here: https://bugs.maemo.org/show_bug.cgi?id=5818 Good luck, -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
On Thu, Jan 7, 2010 at 11:34 AM, Marius Vollmer
marius.voll...@nokia.com wrote:
Currently, is_python_package looks like this:
sub is_python_package {
my ($dir) = @_;
# XXX - some input from Pythonistas is required here.
return (-d $dir/usr/lib/python2.5
|| -d $dir/usr/share/pyshared
|| -d $dir/usr/share/pyshared-data
|| -d $dir/usr/lib/pyshared
|| -d $dir/usr/share/python-support
|| -d $dir/usr/lib/python-support);
}
I will change that to something closer to what has actually been
proposed. Concrete patches are most welcome, of course!
That's almost the same directories currently handled by pymaemo-optify:
https://garage.maemo.org/svn/pymaemo/packages/pymaemo-optify/trunk/debian/default/pymaemo-optify
As a test, you could run it on all python-* .deb packages currently in
the repository, and see if it catches all/most of them. If it works,
and is used only to skip Python packages from automatic optification,
I *personally* see no problem.
It would be nice to have a option to force optification, even if the
heuristics says to ignore the package. I've seen some Python packages
that had no problems with automatic optification, so that way they can
still use maemo-optify.
BTW, if/when autobuilder changes to automatically optify packages with
no debian/optify entry, will it be done only for the newer uploaded
packages?
IMHO running optify on the live packages might break things. If it is
run only on newer packages, developers have the chance to report
auto-optify related problems.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder - Maemo-Optify
On Fri, Jan 8, 2010 at 12:55, Anderson Lizardo anderson.liza...@openbossa.org wrote: It would be nice to have a option to force optification, even if the heuristics says to ignore the package. I've seen some Python packages that had no problems with automatic optification, so that way they can still use maemo-optify. Marius, how hard would it be to implement the force option in debian/optify? This ignores all heuristics and is the exact opposite of none. BTW, if/when autobuilder changes to automatically optify packages with no debian/optify entry, will it be done only for the newer uploaded packages? I'd argue a rebuild of everything in Extras-testing and Extras into -testing with a suffix of -autooptify. That'd mean that people can upload still newer versions whilst testing/promoting the auto-optified versions up to Extras. Ideally, any developer who's package gets changed by maemo-optify-deb at this point would receive an email telling them there is a new, auto-optified version in -testing; and how to turn configure the builder through debian/optify. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
2010/1/8 Jeff Moe m...@blagblagblag.org: On Friday 08 January 2010 08:05:59 Cornelius Hald wrote: koos vriezen wrote: I think this isn't my fault, no? No, it´s not your fault. Unfortunately I have no idea when it will work again. I guess you just have to try again later... Outages get reported here: https://bugs.maemo.org/show_bug.cgi?id=5818 #31 is fortunately another error. So I just try again. FWIW, I think using a BR for all outrages is not the right way, a product in bugzilla might be. This list is another one (normally I just ask Niels, but this time I though a heads-up for all developers was appropriate). Good luck, Thanks! Koos ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
On Friday 08 January 2010 10:54:36 koos vriezen wrote: FWIW, I think using a BR for all outrages is not the right way, a product in bugzilla might be. This list is another one (normally I just ask Niels, but this time I though a heads-up for all developers was appropriate). Maemo needs something like this: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP https://fedoraproject.org/wiki/Category:Infrastructure_SOPs Perhaps they are just moving the builder *today*. Perhaps not. Maybe it's a planned outage, maybe it's not. Maybe they are aware of the outage, maybe they're not. It may be fixed in 5 minutes after a daemon restart, or it may be a day or two. Patience is what we need! -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Cornelius Hald on 01/08/2010 05:02 AM wrote: Anyways, it´s just a guess. That's for images only. Till wants it for *all* file types. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Kimmo Hämäläinen on 01/08/2010 04:58 AM wrote: Yes, tracker should do it. Fortunately, tracker can be extended to index all kind of information. CC'ing Ivan Mr. Tracker Frade here... GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED)
Guys, I appreciate the patience you are showing. Truth is we need something that is coming next week. New hardware that builds the repo offline and just pushes it visible (Thanks to Niels for that one). On hardware that beats my laptop (right now my laptop is probably faster...) The current hardware is end of life. To make it somehow chug along till next week we'll be shutting some of the things running on the old server down. Nothing that should impact normal development or use. Also comparing to Fedora is a bit wrong. Extras is updated every hour, to enable developers to upload their stuff all the time to it. It's not a traditional distro in that sense, but extras-devel is more like a repo that is opened to pretty much anyone who wants to upload. So hang on for just a bit more. Not long to go. Tero -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of ext Jeff Moe Sent: 08 January, 2010 16:07 To: maemo-developers@maemo.org Subject: Re: Auto builder failure (was [fremantle]: kmplayer 0.10.2-4 FAILED) On Friday 08 January 2010 10:54:36 koos vriezen wrote: FWIW, I think using a BR for all outrages is not the right way, a product in bugzilla might be. This list is another one (normally I just ask Niels, but this time I though a heads-up for all developers was appropriate). Maemo needs something like this: https://fedoraproject.org/wiki/Outage_Infrastructure_SOP https://fedoraproject.org/wiki/Category:Infrastructure_SOPs Perhaps they are just moving the builder *today*. Perhaps not. Maybe it's a planned outage, maybe it's not. Maybe they are aware of the outage, maybe they're not. It may be fixed in 5 minutes after a daemon restart, or it may be a day or two. Patience is what we need! -Jeff ___ 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: How to access geotag information?
Hi, Am Freitag 08 Januar 2010 schrieb Michael Cronenworth: GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. If the tracker really already has basic geotagging support, then i think it's the only acceptable solution to use it, even if this is currently limited to images only. This sounds like a classic chicken/egg problem and as long as only the image viewer supports geotagging, noone will bother to extend the tracker for other formats. So if tracker can provide geotagging info i'd be more than willing to use that. Perhaps e.g. the maemo-recorder guys can be convinced to tag their files and this might in turn cause someone to extend the tracker functionality to support geotags in sound files ... I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. What's the tracker guru's opinion? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
onscreen keyboard on N900
I had some code, which brought up the onscreen keyboard on N770-N810. It seems to bring up an onscreen keyboard on N900 too (I do not have, but I received a bug report). The problem is: When I press toolbar button to pop up software keyboard, keyboard's input string is non-empty - it always contains 'flash' word, and I have to manually relete it before typing what I need. Very inconvenient :( I could not find porting instructions for onscreen keyboard. But it seems to be handy in some cases, otherwize I would not have received a bug report:-) Any idea, what I might do to fix? Thanks a lot P.S.: The code simulates a key press in the widget, as far as I remember. It was taken from some tipps from the maemo team some 4 years ago I think. // send enter key press and release to VNC widget GdkEventKey eventKey; GdkKeymapKey *keys; gint n_keys; gdk_keymap_get_entries_for_keyval(gdk_keymap_get_default(), GDK_Return, keys, n_keys); eventKey.type = GDK_KEY_PRESS; eventKey.hardware_keycode = keys[0].keycode; eventKey.keyval = GDK_Return; eventKey.state = 0; eventKey.window = (GTK_WIDGET(mainview-vnc))-window; eventKey.length = 1; eventKey.string = \r; eventKey.send_event = 0; eventKey.group = 0; gtk_widget_grab_focus(GTK_WIDGET(mainview-vnc)); vnc_viewer_key_press_event(GTK_WIDGET(mainview-vnc), eventKey); ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Command line applications and Extras
HI, after some discussion on this topic seems that we've a winner[1]: Solution #3: A new category/switcher should be implemented in HAM A new category for the CLI apps seems very doable IMO, also these apps could use their icons in HAM or the icon done by the community for this propose. Are the responsible(s) for the Application Manager willing to implement this change and ship it in a firmware update ? (pr1.2, pr1.3) This seems to me a very trivial change, if the responsible(s) for this are very busy I can offer my help to dig the code and submit a patch, but I'm also very busy :) . [1] - http://maemo.org/community/brainstorm/view/command_line_applications_and_extras/ Best regards, -- Valério Valério Maemo Community Council Chair http://www.valeriovalerio.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
On Fri, Jan 8, 2010 at 16:05, Valerio Valerio vdv...@gmail.com wrote: [snip] A new category for the CLI apps seems very doable IMO, also these apps could use their icons in HAM or the icon done by the community for this propose. As an example of how Tim's icon looks, see here: http://maemo.org/packages/view/tf/ There are still ongoing design discussions about what we want the community icon badge to be: http://lists.maemo.org/pipermail/maemo-community/2010-January/003658.html Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, El vie, 08-01-2010 a las 15:35 +0100, ext Michael Cronenworth escribió: Cornelius Hald on 01/08/2010 05:02 AM wrote: Anyways, it´s just a guess. That's for images only. Till wants it for *all* file types. In Fremantle, tracker 0.6 can store the location of Images (basically the geotags the user set in the image viewer). Those properties contain text, so you need to use the location API to turn them into coordinates for your map application. About other media types... there is no other format containing location, so tracker cannot fill that information by itself. Our idea for the future is that _applications_ can set location values for the files (e.g. a shopping-list note in the supermarket, so i can see it when i arrive there). This will be supported in tracker 0.7 (ready to play with on desktop), but not in 0.6/fremantle. Some remarks to the previous comments in the thread: 1) EXIF is not the only format for metadata in images. There is XMP or IPTC, and you need a hierarchy to choose between them, and handle broken files and ... well, don't underestimate the problem 2) The idea of scanning and monitoring the filesystem means basically to duplicate the functionality of tracker (and probably the code ;)) 3) Scanning and reading files is not CPU expensive, but needs a lot of IO, and IO is a very precious resource. Regards, Ivan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
Hi, On Fri, Jan 8, 2010 at 4:10 PM, Andrew Flegg and...@bleb.org wrote: On Fri, Jan 8, 2010 at 16:05, Valerio Valerio vdv...@gmail.com wrote: [snip] A new category for the CLI apps seems very doable IMO, also these apps could use their icons in HAM or the icon done by the community for this propose. As an example of how Tim's icon looks, see here: http://maemo.org/packages/view/tf/ There are still ongoing design discussions about what we want the community icon badge to be: http://lists.maemo.org/pipermail/maemo-community/2010-January/003658.html Note that my proposal is not to all apps use the community icon, if we get a new category, the CLI apps could use the upstream icon(e.g htop) if it exists or the community one if not. Best regards, -- Valério Valério http://www.valeriovalerio.org Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
On Fri, Jan 8, 2010 at 16:13, Valerio Valerio vdv...@gmail.com wrote: On Fri, Jan 8, 2010 at 4:10 PM, Andrew Flegg and...@bleb.org wrote: There are still ongoing design discussions about what we want the community icon badge to be: Note that my proposal is not to all apps use the community icon, if we get a new category, the CLI apps could use the upstream icon(e.g htop) if it exists or the community one if not. Indeed. I look forward to the sight of Brainstorm having selected the most practical, implementable and deployable solution; and Nokia changing UI specs to enable this change to ripple through the stack and the process being joined up enough to get this into users' hands in a timely manner. However, in the meantime, the community icon would seem to be the stopgap. It'd be interesting to get the HAM developers' thoughts on developing shipping the proposed fix. Although maemo-developers is the official mailing list for HAM, might be worth a poke at this thread. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
Hi, I was answering the previous email :) Few more comments. El vie, 08-01-2010 a las 16:43 +0100, ext Till Harbaum / Lists escribió: Hi, Am Freitag 08 Januar 2010 schrieb Michael Cronenworth: GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. We have two problems: 1) Who set the location information? Responsibility of applications. 2) Where should that information be stored? In tracker. but ... 1) No application is really setting location information except the image viewer (and only for images) 2) Tracker 0.6 cannot store efficiently that information. We could try to add a File:Location property, so you could set location for everything known by tracker, but it is going to be very very inefficient. This will be fixed in 0.7 . Regards, Ivan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
Hi, on a related note, some people are also suggesting a category for plugins[1] and stuff that is invisible to the users until they activate them(we've already a lot of them in the repos), I think I read about some plans to add this category, not sure, but could be a good opportunity to add this category as well. [1] - http://talk.maemo.org/showpost.php?p=459428postcount=27 Best regards, -- Valério Valério http://www.valeriovalerio.org On Fri, Jan 8, 2010 at 4:13 PM, Valerio Valerio vdv...@gmail.com wrote: Hi, On Fri, Jan 8, 2010 at 4:10 PM, Andrew Flegg and...@bleb.org wrote: On Fri, Jan 8, 2010 at 16:05, Valerio Valerio vdv...@gmail.com wrote: [snip] A new category for the CLI apps seems very doable IMO, also these apps could use their icons in HAM or the icon done by the community for this propose. As an example of how Tim's icon looks, see here: http://maemo.org/packages/view/tf/ There are still ongoing design discussions about what we want the community icon badge to be: http://lists.maemo.org/pipermail/maemo-community/2010-January/003658.html Note that my proposal is not to all apps use the community icon, if we get a new category, the CLI apps could use the upstream icon(e.g htop) if it exists or the community one if not. Best regards, -- Valério Valério http://www.valeriovalerio.org Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
On Friday 08 January 2010 16:27:07 Valerio Valerio wrote: Hi, on a related note, some people are also suggesting a category for plugins[1] and stuff that is invisible to the users until they activate them(we've already a lot of them in the repos), I think I read about some plans to add this category, not sure, but could be a good opportunity to add this category as well. N!!! That is the whole problem with this solution. The **problem** is NOT command line apps! The problem is things which do not install an icon to run them. CLI apps are the most visible examples today (because they are cheap to port, and because they are mostly, but not all, quite geeky) but they won't always be. For the ordinary users they aren't interested in whether this app doesn't have an icon because it is a command line utility or because it is a behind-the-scenes daemon or because it is a control-panel applet or because it is a plugin or because it is an updated dataset for an application or ... We don't need one category for each of those. We need a solution to identify things which do not install an application as far as the naive user is concerned (i.e. they do not install an icon in the panel of icons for applications). And the answer to that is not categories at all. The category (network, office, system, game, ...) is completely othogonal to how it is invoked or used. A new set of levels for a game should be in the games category, but it will not install an application icon. openssh-server should be in the network category, but it doesn't install an application icon, nor is it a command line app. openssh-client should also be in the network category and is a command line app. The CLI apps category is the wrong solution. And adding more categories is even more wrong. The right solution is to use maemo.org instead of HAM as the way for most users to install things and for the website to show applications based on popularity. If a command line app can rise to the top of the popularity list despite not having a GUI then that is great! In practice it won't and the command line apps will be low down the lists in their categories (along with the clunky GUI apps, the non-finger-friendly apps, the buggy apps, etc.). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
HI, On Fri, Jan 8, 2010 at 5:14 PM, Graham Cobb g+...@cobb.uk.netg%2b...@cobb.uk.net wrote: On Friday 08 January 2010 16:27:07 Valerio Valerio wrote: Hi, on a related note, some people are also suggesting a category for plugins[1] and stuff that is invisible to the users until they activate them(we've already a lot of them in the repos), I think I read about some plans to add this category, not sure, but could be a good opportunity to add this category as well. Well the plugins category is out of scope here, was just a possible discussion point. N!!! Well the community made a decision, it was discussed during a long period of time here and in TMO, don't you think we should respect the community decision ? That is the whole problem with this solution. The **problem** is NOT command line apps! The problem is things which do not install an icon to run them. CLI apps are the most visible examples today (because they are cheap to port, and because they are mostly, but not all, quite geeky) but they won't always be. For the ordinary users they aren't interested in whether this app doesn't have an icon because it is a command line utility or because it is a behind-the-scenes daemon or because it is a control-panel applet or because it is a plugin or because it is an updated dataset for an application or ... We don't need one category for each of those. We need a solution to identify things which do not install an application as far as the naive user is concerned (i.e. they do not install an icon in the panel of icons for applications). And the answer to that is not categories at all. The category (network, office, system, game, ...) is completely othogonal to how it is invoked or used. A new set of levels for a game should be in the games category, but it will not install an application icon. openssh-server should be in the network category, but it doesn't install an application icon, nor is it a command line app. openssh-client should also be in the network category and is a command line app. The CLI apps category is the wrong solution. And adding more categories is even more wrong. The right solution is to use maemo.org instead of HAM as the way for most users to install things and for the website to show applications based on popularity. If a command line app can rise to the top of the popularity list despite not having a GUI then that is great! In practice it won't and the command line apps will be low down the lists in their categories (along with the clunky GUI apps, the non-finger-friendly apps, the buggy apps, etc.). Don't know if I get it, your suggestion is to not change anything ? Best regards, -- Valério Valério http://www.valeriovalerio.org Graham ___ 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: How to access geotag information?
GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. We have two problems: 1) Who set the location information? Responsibility of applications. 2) Where should that information be stored? In tracker. but ... 1) No application is really setting location information except the image viewer (and only for images) 2) Tracker 0.6 cannot store efficiently that information. We could try to add a File:Location property, so you could set location for everything known by tracker, but it is going to be very very inefficient. This will be fixed in 0.7 . It would be preferable to also store the lat/lon information so that applications could use that if they see fit (e.g. map apps) as well as the pre-reverse geocoded location name, otherwise there's additional overhead and severe inaccuracy of the geocoding. From a quick websearch I can see that video can and is geocoded at least (either once uploaded, or for e.g. some Sony camcorder with a built-in GPS), so adding support for geocoded videos would be nice. I can also envision other files adding geocoding metadata about themselves to the tracker database, even if the file itself doesn't support internal geocoding metadata (is that possible, I guess it should be?) so adding a geotag field (or fields I hope for name and lat/lon) would be a nice, cool and future proof thing to do (but yeah it will waste some space for files that don't use it, but probably not much, though I've not looked at the db so I don't know for sure). Anyway I think it's a shame we don't make more use of our geo-information and the ability to enable it in general on the N900 - the IM app doesn't report actual location data which is a real shame (and hence my interest in using Google's Latitude instead), contacts can contain addresses but not more accurate lat/lon, etc. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
On Friday 08 January 2010 17:24:22 Valerio Valerio wrote: N!!! Well the community made a decision, it was discussed during a long period of time here and in TMO, don't you think we should respect the community decision ? I don't think the community made a decision. I think the community has many different views with nothing having majority support except that users need an easy way to ignore command line apps. My recollection of the part of the community that lives on this mailing list was that the preferred option was the icon/badge and I thought that was what we were working towards. Don't know if I get it, your suggestion is to not change anything ? My suggestion is to do four things: 1) Require all user/ packages which do not install an application icon to use the community-defined icon or badge to indicate that. Note that this is nothing to do with whether the UI is GUI or command-line or no UI at all -- it is about whether it installs an application icon and it is intended to reduce user confusion. 2) Add a package field to mark the app as command-line so that future user interfaces can, if they wish, implement controls to allow users to hide command line apps. Exact mechanism was still TBD but something like debtags seemed to be favourite. 3) Enhance HAM to implement the hide/show command line apps option (using the field introduced in 2) to reduce clutter for people who don't want to see command line apps. This is how I interpreted the meaning of switcher in the brainstorm solution 3 and I would be happy to support that. I am not happy to support any abuse of the category field. 4) Meanwhile, add popularity and ratings filters to maemo.org, possibly as part of application karma or possibly separately. And strongly encourage new users to use maemo.org for finding new applications. My personal view is that 4 is the real solution to not just this but many other QA issues: let the users tell us which apps are good. If we invest the effort in that we can save a lot of angst about all sorts of arbitrary rules in QA and get the QA process back to focusing on serious issues like device stability, etc. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to access geotag information?
On Fri, 2010-01-08 at 18:19 +0200, Ivan Frade wrote: Hi, but ... 1) No application is really setting location information except the image viewer (and only for images) As far as i know, Camera is also setting location information. The GPS coordinates are stored in EXIF and the reverse geocoding strings are in XMP. The location metadata is set for both, images and videos. -- Javier Fernández García-Boente http://blogs.igalia.com/jfernandez/ www.igalia.com signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Browser Switchboard, MicroB, and application prestart in Fremantle
I'm the maintainer of Browser Switchboard [1], which is a program that's supposed to make it possible for the user to choose the default browser on his/her Maemo device. Packages are available in extras for Diablo and extras-devel for Fremantle. In order to control the default browser, Browser Switchboard takes over handling of the com.nokia.osso_browser D-Bus methods. Since launching MicroB from the menus invokes com.nokia.osso_browser.top_application, it has to be able to launch MicroB. For Diablo, we do this by exec() of /usr/bin/browser(*), but this doesn't seem to bring up a browser window in Fremantle (see the discussion on talk.maemo.org [2]). Also, at least in testing with my half-broken SDK, the Fremantle browser process remains in memory even after the last browser window closes. This poses a problem for Browser Switchboard, which releases com.nokia.osso_browser before starting MicroB (so that MicroB handles the methods while it's open, giving users an easy way to temporarily open links in MicroB no matter what their default browser is set to), and needs to be able to reclaim the name when the last browser window closes. I can only assume this behavior is related to the prestarting of the browser process in Fremantle, but I'm unclear on how Browser Switchboard interacts with prestarting in the first place (is a browser process prestarted on boot when Browser Switchboard is installed?), and I don't have a Fremantle device to test any of this on. That leaves me with the following questions: * How does one open a new browser window from an application, preferably without using the D-Bus interface? (If there is no other way to bring up a new window except D-Bus, I assume I'd have to try something like launching the browser process, waiting for it to acquire the com.nokia.osso_browser name, then making the method call, which wouldn't be pretty, and also precludes the possibility of working with a prestarted browser process). * Is there a way to ensure the browser process quits when the last browser window closes? If not, is there a way to receive a signal when the last browser window closes? (It's probably possible to poll for the existence of a browser window, but I can't think of a way of doing it that doesn't impact battery life and doesn't introduce a potential race condition.) -Steven Luo (*) Well, not quite, since the package replaces /usr/bin/browser with a shell script. We exec() /usr/bin/maemo-invoker with argv[0] set to browser, which is equivalent to invoking a symlink to maemo-invoker named browser. [1] http://browser-switch.garage.maemo.org/ [2] http://talk.maemo.org/showthread.php?p=444134#post444134 and following posts ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Command line applications and Extras
Hi, On Fri, Jan 8, 2010 at 6:14 PM, Graham Cobb g+...@cobb.uk.netg%2b...@cobb.uk.net wrote: On Friday 08 January 2010 17:24:22 Valerio Valerio wrote: N!!! Well the community made a decision, it was discussed during a long period of time here and in TMO, don't you think we should respect the community decision ? I don't think the community made a decision. I think the community has many different views with nothing having majority support except that users need an easy way to ignore command line apps. My recollection of the part of the community that lives on this mailing list was that the preferred option was the icon/badge and I thought that was what we were working towards. Seems that Andrew is right about brainstorm, will fail miserably again. Don't know if I get it, your suggestion is to not change anything ? My suggestion is to do four things: 1) Require all user/ packages which do not install an application icon to use the community-defined icon or badge to indicate that. Note that this is nothing to do with whether the UI is GUI or command-line or no UI at all -- it is about whether it installs an application icon and it is intended to reduce user confusion. 2) Add a package field to mark the app as command-line so that future user interfaces can, if they wish, implement controls to allow users to hide command line apps. Exact mechanism was still TBD but something like debtags seemed to be favourite. 3) Enhance HAM to implement the hide/show command line apps option (using the field introduced in 2) to reduce clutter for people who don't want to see command line apps. This is how I interpreted the meaning of switcher in the brainstorm solution 3 and I would be happy to support that. I am not happy to support any abuse of the category field. 4) Meanwhile, add popularity and ratings filters to maemo.org, possibly as part of application karma or possibly separately. And strongly encourage new users to use maemo.org for finding new applications. My personal view is that 4 is the real solution to not just this but many other QA issues: let the users tell us which apps are good. If we invest the effort in that we can save a lot of angst about all sorts of arbitrary rules in QA and get the QA process back to focusing on serious issues like device stability, etc. Good points, I agree with them, but I'm afraid that with all the stuff happening, we'll not seeing it happening any time soon, since it does not depends entirely on the community. Feel free to carry this task if you want. Best regards, -- Valério Valério http://www.valeriovalerio.org Graham ___ 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: How to access geotag information?
My gut feeling is that as we move forward, geotag type information really belongs with the file information. e.g. I would love to have the ability to stat a file to find out the geolocation where a file was created as well as the time that the file was created. Of course, that is a very big change right down at the OS level, so until file systems change to include something like geolocation of creation, Till's approach sounds pretty interesting. Aldon 41.3324, -72.9882 -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org]on Behalf Of Till Harbaum / Lists Sent: Friday, January 08, 2010 10:43 AM To: Michael Cronenworth Cc: maemo-developers@maemo.org Subject: Re: How to access geotag information? Hi, Am Freitag 08 Januar 2010 schrieb Michael Cronenworth: GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. If the tracker really already has basic geotagging support, then i think it's the only acceptable solution to use it, even if this is currently limited to images only. This sounds like a classic chicken/egg problem and as long as only the image viewer supports geotagging, noone will bother to extend the tracker for other formats. So if tracker can provide geotagging info i'd be more than willing to use that. Perhaps e.g. the maemo-recorder guys can be convinced to tag their files and this might in turn cause someone to extend the tracker functionality to support geotags in sound files ... I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. What's the tracker guru's opinion? Till ___ 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: How to access geotag information?
Hi, Am Freitag 08 Januar 2010 schrieb Ivan Frade: About other media types... there is no other format containing location, so tracker cannot fill that information by itself. In this web site you can download wav files which claim to be geotagged: http://www.freesound.org/samplesViewSingle.php?id=73423 That's why i thought the maemo-recorder could do the same. see it when i arrive there). This will be supported in tracker 0.7 (ready to play with on desktop), but not in 0.6/fremantle. Using tracker 0.6 limited to images is a start. Do you have example code somewhere? I have never worked with tracker before. 3) Scanning and reading files is not CPU expensive, but needs a lot of IO, and IO is a very precious resource. Whatever the limit is: You don't want to do this in every single app. Reards, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Unified map tile storage
Hi, maep 1.1 is currently in the autobuilder and is supposed to store tiles where you suggested. It is supposed to ask the user whether he wants to move the existing cache etc ... Please give it a try and check that you can live with the result. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
On Friday 08 January 2010 04:34:09 Aki Niemi wrote: to, 2010-01-07 kello 14:04 +0100, Niemi Aki (Nokia-D/Helsinki) kirjoitti: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Right, ofono is now in extras-devel, and based on some quick testing, it seems to work fine. WORKSFORME ! :) Quick dirty: sudo gainroot apt-get install ofono /etc/init.d/ofono start exit (so you're not root) # Check see wtf is up: dbus-send --system --print-reply --dest=org.ofono /isimodem0 org.ofono.Modem.GetProperties # Make call: dbus-send --print-reply --system --dest=org.ofono /isimodem0 org.ofono.VoiceCallManager.Dial string:5551212 string: I have updated my wiki page: http://wiki.maemo.org/User:Jebba/Ofono Thanks! This is fantastico. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unified map tile storage
On Friday 08 January 2010 17:01:10 Till Harbaum / Lists wrote: Hi, maep 1.1 is currently in the autobuilder and is supposed to store tiles where you suggested. It is supposed to ask the user whether he wants to move the existing cache etc ... Please give it a try and check that you can live with the result. WORKSFORME. The tile maps appear to have moved. I just did a quick test of disconnecting net and then looking at previous places and they were there and also switching from Hybrid to Google maps, etc. I didn't dig deeper, but it appears to have worked. Thanks for Maep, it's my favorite mapping program. :) -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? jaw drops Congratulations! On Fri, Jan 8, 2010 at 3:12 PM, Jeff Moe m...@blagblagblag.org wrote: On Friday 08 January 2010 04:34:09 Aki Niemi wrote: to, 2010-01-07 kello 14:04 +0100, Niemi Aki (Nokia-D/Helsinki) kirjoitti: to, 2010-01-07 kello 13:48 +0100, ext Jeff Moe kirjoitti: You should use the isimodem driver in oFono. It is specifically made to support Nokia modems, such as the one on N900. I've been told, and tried my self, and it doesn't work on the N900. It _should_ work out of the box on the N900. In fact, I did some quick packaging of the 0.15 release and just pushed ofono in Fremantle extras-devel. So let's see... Right, ofono is now in extras-devel, and based on some quick testing, it seems to work fine. WORKSFORME ! :) Quick dirty: sudo gainroot apt-get install ofono /etc/init.d/ofono start exit (so you're not root) # Check see wtf is up: dbus-send --system --print-reply --dest=org.ofono /isimodem0 org.ofono.Modem.GetProperties # Make call: dbus-send --print-reply --system --dest=org.ofono /isimodem0 org.ofono.VoiceCallManager.Dial string:5551212 string: I have updated my wiki page: http://wiki.maemo.org/User:Jebba/Ofono Thanks! This is fantastico. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- enthusiast, n. One whose mind is wholly possessed and heated by what engages it; one who is influenced by a peculiar fervor of mind; an ardent and imaginative person. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oFono
Hi, On Sat, Jan 9, 2010 at 7:40 AM, Qole qole.tab...@gmail.com wrote: So wait, you're saying we now have a fully open source telephony stack on the N900 that works to make phone calls? Whatever the result the we in the previous sentence includes Nokia, thanks!. I am loving this device more and more Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
