Re: Questions about HildonPannableArea
Claudio Saavedra wrote 09.06.2009 19:23: You are wrong. The HildonPannableArea is an important actor in Fremantle. Look at modest, for example, where it's heavily used. Of course, you can continue using a scrolled window, but that's completely up to you and I wouldn't recommend it, since it will look really oldish. This may sound nitpicking, but I do not think that oldish or newish is a value in itself. I see too often that someone has designed a modern and attractive user interface that is really awful to use. However, I would say that it would be inconsistent to use the old scrolled window when every other application is using the new pannable area. That kind of inconsistency makes an user confused. It might be useful to notice that usually a pannable area is used to scroll a container vertically. Thus, it could be possible to select text horizontally in a text entry at the same time. Could this be the solution to the original issue? What kind of improvements that requires to be implemented for applicable Hildon widgets? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
I did so (like you, not liking the same behaviour) and it started the desktop but requiring me to press the power button to enable touchscreen and input (i.e it's expecting to be booted in ACTDEAD state). All I did, however, was to change it from ACTDEAD state to USER state if it detects charger, so more may need to be done. I do not know what provides /proc/bootreason but (if it's the kernel, like I'm hoping), it may be easier to not make it say charger in bootreason if it's booted with a charger. BR, Faheem On Tue, Jun 9, 2009 at 9:53 AM, Frantisek Dufka duf...@seznam.cz wrote: Rainer Dorsch wrote: Under which circumstances is the N800 started automatically, when the power supply is plugged in? It would be interesting to modify linuxrc to go to runlevel 2 even in this charging state and see if it manages to boot normally. Frantisek ___ 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: Playbin volume bug for OGG and WMA playback
Hi, this is very interesting. Thanks for your investigation and detailed description. I have always wondered why I get distorted sound with Ogg and gstreamer on Maemo. Now it makes sense. Thanks a lot, Martin 2009/6/10, Nick Nobody m...@nikosapi.org: This has been bugging me for quite some time and I think I've finally gotten to the bottom of it. In this message I present my (limited) understanding of how gstreamer works, what this annoying bug is, potentially why this bug occurs and perhaps how to fix it. Lets get on with it. There are several ways that audio gets played through gstreamer, the audio can either be decoded on the device's processor or it can be offloaded to one of a few different hardware decoders (DSPs). Gstreamer's playbin provides a very easy way for the developer to not have to worry about writing pipelines for every possible type of audio that can be played back by their application. For MP3 and AAC audio, gstreamer uses hardware decoding provided by dspmp3sink and dspaacsink respectively. OGG and WMA audio must first be decoded to PCM (decoderbin takes care of this nicely) and then get passed to dsppcmsink. On maemo, the audio sinks (dspmp3sink, dspaacsink, and dsppcmsink) all have their own volume property (an integer between 0 and 2^16) and another property named fvolume which seems to simply be volume/2^16 (a float between 0 and 1). Either of these can be set, they accomplish the same goal; controlling the volume level. Gstreamer also provides a nice volume control element that you can add in a pipeline to presumably control the volume before it gets to the audio sink in the event that the audio sink doesn't have a volume property. The documentation says that the volume control element can take a value from 0 to 10 but during my testing it seems that anything over 1 distorts. So in reality you'll only be using it from 0 to 1. The Problem. If you create a pipeline using playbin to playback an ogg or wma file, you end up with a volume control element stuck right before dsppcmsink (see image #1). In this case playbin's volume property is connected to both the volume control element and the dsppcmsink fvolume property. This is were it gets weird, when you set the volume property of the playbin, the volume control element gets set to that exact number BUT the dsppcmsink's fvolume property gets set to one tenth of that number. Big deal, right? Wrong. This means that you can only set the output volume to about 10% before it begins to distort. For example, if I set the playbin's volume property to 3 (referring again to image #1), the volume control element gets set to 3 (we have distortion at this level) and the dsppcmsink's fvolume property is set to 0.3. The maximum value we can set the playbin's volume property is 1 (instead of 10, like when playing mp3s), anything else sounds bad. The Solution. There are two ways I can think of to solve this problem. Make the volume control element and the dsppcmsink share the same volume property or remove the volume control element entirely for playbins. I just don't really know how to go about fixing it... I suspect this issue has something to do with the way dsp sinks work on maemo's gstreamer. When using a dspmp3sink or a dspaacsink via a playbin, the volume property is a number between 0 and 10 which gets divided by 10 and used as the sink's fvolume value (see image #2). Could it be that someone simply forgot to divide by 10 in the volume control element code? Here are some gstreamer pipelines to help you experiment with this problem yourself (use these on your NIT). The following two pipelines sound exactly alike (very distorted), the first using playbin and the second using decodebin, a volume control element and dsppcmsink. The second is essentially the same as what playbin creates, which is wrong. gst-launch-0.10 playbin uri=http://tinyurl.com/524rwv volume=6 gst-launch-0.10 gnomevfssrc location=http://tinyurl.com/524rwv \ ! decodebin ! volume volume=6 ! dsppcmsink fvolume=0.6 Now if we change the volume element's volume setting from 6 to 0.6, there's no distortion: gst-launch-0.10 gnomevfssrc location=http://tinyurl.com/524rwv \ ! decodebin ! volume volume=0.6 ! dsppcmsink fvolume=0.6 These images were generated on an n810 running Maemo 4.1 with the ogg-support 0.9 and gstreamer version 0.10.22 (the version that comes with Maemo isn't able to generate images of pipelines). Image #1 (OGG file, playbin, volume=3): http://imgur.com/H1Uiy.png Image #2 (MP3 file, playbin, volume=3): http://imgur.com/oEB4Y.png I'm pretty sure this is a bug, but if not please let me know what I'm doing wrong here. Or perhaps someone could explain how Nokia's media player handles volume or pipeline creation since it doesn't seem to experience this bug. It would be a shame to have to force the application developer to work around this problem by either
calendar-backend
Hey With Fremantle beta sdk there comes this, calendar-backend : http://maemo.org/api_refs/5.0/beta/calendar-backend/ There seems to be only C++ interface for this. How should this be used in C application, is there going to be C interface also? //Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: calendar-backend
Sampo, I would also be interested in a C api to the same calendar backend. Obviously my calendar is very simplistic and sketch based, but it would be of obvious benefit to allow system calendar entries to be visible there :) Gary On Wed, Jun 10, 2009 at 12:32 PM, Sampo Savolasampo...@paju.oulu.fi wrote: Hey With Fremantle beta sdk there comes this, calendar-backend : http://maemo.org/api_refs/5.0/beta/calendar-backend/ There seems to be only C++ interface for this. How should this be used in C application, is there going to be C interface also? //Sampo ___ 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
Feeding tracker with useful data in Fremantle
Hi, I would like to include tracker support for my note taking application. The files however are encoded in xml and therefore shouldn´t be indexed directly. So my question is, how do I write something like an indexer plug-in for my application? I would like to let tracker know that e.g. stuff inside a title tag is the title of a note and that he should ignore tags like bold or italic etc... Is this possible? If yes, how? Also, does the tracker version in Fremantle already come with all the ontology stuff? Thanks for any pointers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Feeding tracker with useful data in Fremantle
Sorry, I was a bit too fast. When looking in other places (not maemo.org) I found that: http://library.gnome.org/devel/libtracker-module/unstable/ Is this how it will work in Fremantle? Thanks! Conny Cornelius Hald wrote: Hi, I would like to include tracker support for my note taking application. The files however are encoded in xml and therefore shouldn´t be indexed directly. So my question is, how do I write something like an indexer plug-in for my application? I would like to let tracker know that e.g. stuff inside a title tag is the title of a note and that he should ignore tags like bold or italic etc... Is this possible? If yes, how? Also, does the tracker version in Fremantle already come with all the ontology stuff? Thanks for any pointers! Conny ___ 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: N800 Power cycles
Faheem Pervez wrote: I do not know what provides /proc/bootreason but (if it's the kernel, like I'm hoping), it may be easier to not make it say charger in bootreason if it's booted with a charger. linux/arch/arm/plat-omap/bootreason.c cfg = omap_get_config(OMAP_TAG_BOOT_REASON, struct omap_boot_reason_config); strncpy(boot_reason, cfg-reason_str, sizeof(cfg-reason_str)); Should be easy to replace charger for pwr_key there. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finger friendly context menu in Fremantle
On Wed, Jun 10, 2009 at 07:47:33PM +0200, Cornelius Hald wrote: using hildon_gtk_menu_new() I can create a menu with finger friendly sized menu items. It works when I'm adding GtkMenuItems to this menu. But if I'm adding GtkImageMenuItems the menu items have stylus size. For example adding stock items produces a menu with small menu items. IMO that's a bug, but I thought before I'm making screenshots and file a bug report, I'll ask if this is the expected behavior. I'm looking at the theme file and I think that should work, so if it doesn't then it's indeed a bug. Can you report it (with a small test case if possible) ? Thanks! :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Finger friendly context menu in Fremantle
Hi, using hildon_gtk_menu_new() I can create a menu with finger friendly sized menu items. It works when I'm adding GtkMenuItems to this menu. But if I'm adding GtkImageMenuItems the menu items have stylus size. For example adding stock items produces a menu with small menu items. IMO that's a bug, but I thought before I'm making screenshots and file a bug report, I'll ask if this is the expected behavior. Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finger friendly context menu in Fremantle
On Wed, 2009-06-10 at 19:56 +0200, Alberto Garcia wrote: On Wed, Jun 10, 2009 at 07:47:33PM +0200, Cornelius Hald wrote: using hildon_gtk_menu_new() I can create a menu with finger friendly sized menu items. It works when I'm adding GtkMenuItems to this menu. But if I'm adding GtkImageMenuItems the menu items have stylus size. For example adding stock items produces a menu with small menu items. IMO that's a bug, but I thought before I'm making screenshots and file a bug report, I'll ask if this is the expected behavior. I'm looking at the theme file and I think that should work, so if it doesn't then it's indeed a bug. Can you report it (with a small test case if possible) ? Ok done. Bug report + screenshot is here: http://bugs.maemo.org/show_bug.cgi?id=4654 Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
