Re: N800 Power cycles
Hi, ext Rainer Dorsch wrote: One thing I noticed and maybe I did not highlight that enough: - yesterday in the boot loops, the N800 started itself after I plugged the powersupply (no matter if I removed the battery before or not). - today plugging the power supply does not start the N800 anymore, just showing that it is charging the battery Under which circumstances is the N800 started automatically, when the power supply is plugged in? Always. It will then go to Charging mode. If you in that state: - unplug the charger - device powers down. - press power key - device comes fully up. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800 Power cycles
Rainer Dorsch wrote: Under which circumstances is the N800 started automatically, when the power supply is plugged in? N800 is always started when you plug it in. The difference is in unix runlevel the device boots into. Normal is runlevel 2 when maemo-desktop starts fully. When bootreason (/proc/bootreason) is 'charger' it boots into runlevel 5 with slightly different boot sequence which in final stage shows only charging icon but otherwise the system behind it is almost fully booted. So in theory you can have reboot loop which happens only in runlevel 5 and not in runlevel 2 if the failing part is specific to runlevel 5. Maybe you saw this? More details is in /mnt/initfs/linuxrc in function enter_state(), normal mode is USER state, charging mode is (or is one case of?) ACTDEAD state. I hope I am not wrong about this. Personally I don't like this behaviour so I am always powering device by power key and if I know battery is empty I have charger prepared and plug it in just after screen lights up to avoid this charging mode. There is short window of time to do this before dsme/bme starts and decides to shutdown the system due to low battery. 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
Re: Re: Questions about HildonPannableArea
Hi, currently i have just returned to a scrolled window instead of the pannable area and i am not completely unsatisfied with this as text selection still works this way. So unless there's be a method to use selections again with pannable areas i'd actually prefer if you don't change anything. This gives me a somewhat inconsistent mixture of scrolled windows and pannable areas but selections is important to me in that main html window (these are geocaching descriptions displayed there and sometimes i copy formulas etc over to a gtktextview to work on them there). The coolest thing would of course be if selection can be enabled in a pannable are as well. If that's the case i wouldn't mind if you completely remove the built-in panning support from gtkhtml. If there are no plans for selection support in pannable areas, how is this then to be solved? Is the fremantle xterm solution the way to go? Till - original Nachricht Betreff: Re: Questions about HildonPannableArea Gesendet: Mo, 08. Jun 2009 Von: Claudio Saavedracsaave...@igalia.com El mié, 03-06-2009 a las 20:54 +0200, Till Harbaum / Lists escribió: Hi, Am Mittwoch 03 Juni 2009 schrieb Alejandro Garcia Castro: I do not know about the current status of out gtkhtml code, but I think probably we will have to add a parameter to deactivate it in the gtkhtml widget, or maybe just ifdef it or remove it. There's no such property in gtkhtml. And what do you mean by ifdef it? I sure won't remove that feature from gtkhtml as this would then affect _all_ applications. You are right, there is no such property. In maemo, GtkHtml was patched, a long time ago, to allow panning when dragging on the widget. This panning is currently interfering with the way the pannable area works and it can't be disabled nor configured. There are two plausible approaches to fix this in GtkHtml (which I'm currently weighting): 1. Remove the patch to allow panning in the GtkHtml widget. This has the advantage to be a quite straightforward solution. The con is that any application relying on this feature will loose panning until they migrate to use a pannable area. 2. Make this hardcoded panning feature a property, enabled by default. The advantage of this approach is that no application is broken and those willing to use a pannable area have the chance to disable the property. The disadvantage of this is that it will probably take some extra effort and time to implement it, that I could pretty well use in more relevant issues. Personally, I'm more inclined to go for (1). Mainly, because GtkHtml, as André pointed out, is a dead-end widget, and any extra efforts on it are probably not worth. Anyone willing to get a nice and consistent panning experience in Fremantle should use a pannable area. Nevertheless, I'd read some opinions before doing anything. Claudio --- original Nachricht Ende ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 13:22 +0200, Till Harbaum escribió: The coolest thing would of course be if selection can be enabled in a pannable are as well. If that's the case i wouldn't mind if you completely remove the built-in panning support from gtkhtml. If there are no plans for selection support in pannable areas, how is this then to be solved? Is the fremantle xterm solution the way to go? A pannable area can't have support for text selection, because it's just a generic bin container. The only thing stopping you from doing text selection is the enabled property being TRUE. Whether we want to allow a certain gesture to turn enabled to FALSE is a different question. It has to be considered that for some use cases of the pannable area, you don't want it to be disabled at all (say, a GtkTreeView inside a pannable area). This discussion could sanely be moved to a bug report. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
Hi fellow developers! If you´re planning to use the portrait mode in Fremantle, please first have a look at this (WONTFIX) bug: https://bugs.maemo.org/show_bug.cgi?id=4618 Cheers! Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
Claudio Saavedra wrote: This discussion could sanely be moved to a bug report. I think it´s better to keep this discussion here, where every one can see it. Having the discussion in Bugzilla will just put this issue off the radar for most developers. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 13:37 +0200, Cornelius Hald escribió: Claudio Saavedra wrote: This discussion could sanely be moved to a bug report. I think it´s better to keep this discussion here, where every one can see it. Having the discussion in Bugzilla will just put this issue off the radar for most developers. Yes, and that's sane, assuming most developers are not interested on this. Those who are, however, can subscribe to the bug report. We already passed the mark where it was clear that something should be done on this regard, now it's a matter of details, and bugzilla fits better for that. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Questions about HildonPannableArea
Hi, - original Nachricht Betreff: Re: Questions about HildonPannableArea Gesendet: Di, 09. Jun 2009 Von: Claudio Saavedracsaave...@igalia.com Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. Thanks for clarifying this, Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 15:47 +0200, Till Harbaum escribió: Hi, - original Nachricht Betreff: Re: Questions about HildonPannableArea Gesendet: Di, 09. Jun 2009 Von: Claudio Saavedracsaave...@igalia.com Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. No need to misquote me in that way. FYI, the HildonPannableArea is a _very important_ widget for us in the hildon library and the reason why I'm suggesting to follow up in the bug report[1] is because I think we should come out with something to improve this particular case. Claudio [1] https://bugs.maemo.org/show_bug.cgi?id=4619 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Am Freitag, den 05.06.2009, 15:25 +0300 schrieb Eero Tamminen: and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. But I think it would be appropriate to note in API documents which widgets aren't supported by our UI guidelines / with themeing. Can you make a bug about that so that can be fixed for Fremantle (or Harmattan) API docs? I second Eero's request. If Nokia is unwilling/unable/whatever to cover all potential theming testcases than unsupported cases should at least be mentioned in the docs. Basically the same with portrait mode; that's why I filed https://bugs.maemo.org/show_bug.cgi?id=4648 about the unclear docs. andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Incantation to change Development Status on a project
Folks, I've been searching all over the site and just cannot figure out how to change the Development Status from Pre-Alpha to Beta on the Summary page of my project. The Admin page does not do it, the Summary page has no update link, so it must be hidden very well. Has anyone succeeded in finding this? Is it some sort of Easter Egg? ...Thanks, ...Ken ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Incantation to change Development Status on a project
On Tue, Jun 9, 2009 at 4:00 PM, Kenneth Loafman kenn...@loafman.com wrote: Folks, I've been searching all over the site and just cannot figure out how to change the Development Status from Pre-Alpha to Beta on the Summary page of my project. The Admin page does not do it, the Summary page has no update link, so it must be hidden very well. In your project page go to: Admin and then select the edit button in front of the string Trove Categorization (first block in the left side). Best regards, -- Valério Valério http://www.valeriovalerio.org Has anyone succeeded in finding this? Is it some sort of Easter Egg? ...Thanks, ...Ken ___ 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: Questions about HildonPannableArea
Hi, Am Dienstag 09 Juni 2009 schrieb Claudio Saavedra: Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. No need to misquote me in that way. Where do i misquote you? You said most developers aren't interested in this (so it isn't important (yet)) and that we should discuss its usage on bugzilla (meaning that its usage is still matter of dealing with bugs) . To me this means its not a widget for the end user (yet). FYI, the HildonPannableArea is a _very important_ widget for us in the hildon library and the reason why I'm suggesting to follow up in the bug report[1] is because I think we should come out with something to improve this particular case. Ok, it's important to you, because one day you want it to become a widget for daily use. But until then the scrolled window seems to be the better/more reliable choice. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 17:52 +0200, Till Harbaum / Lists escribió: Hi, Am Dienstag 09 Juni 2009 schrieb Claudio Saavedra: Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. No need to misquote me in that way. Where do i misquote you? You said most developers aren't interested in this (so it isn't important (yet)) and that we should discuss its usage on bugzilla (meaning that its usage is still matter of dealing with bugs) . To me this means its not a widget for the end user (yet). You are completely misunderstanding me. What I am trying to say is that for most of the _community developers_, getting into the details of one particular bug is not interesting. There is no point on venting the discussion on the face of developers who are not using this specific feature. That's why I suggest to use bugzilla to follow up and allow, only to the community developers interested in UI development, and in particular, to text selection inside a scrollable widget, to subscribe, stay informed, and comment on the issue. FYI, the HildonPannableArea is a _very important_ widget for us in the hildon library and the reason why I'm suggesting to follow up in the bug report[1] is because I think we should come out with something to improve this particular case. Ok, it's important to you, because one day you want it to become a widget for daily use. But until then the scrolled window seems to be the better/more reliable choice. 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. Seriously, I don't know how is it possible to make so many assumptions out of a simple suggestion to move a discussion to bugzilla. This can only be misleading for others and doesn't really help. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
Hi, Am Dienstag 09 Juni 2009 schrieb Claudio Saavedra: You are completely misunderstanding me. What I am trying to say is that for most of the _community developers_, getting into the details of one particular bug is not interesting. There is no point on venting the If the pannable area is really to be used as a scrolled window replacement today, then i'd think that this is really interesting to many developers. How many applications have a textview inside a scrollable window? Really many i'd assume. So all these developers are affected by this. Sounds pretty important to me ... 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. Wow, i just took this comment as a reason to look at modest and to see how it deals with selection ... it doesn't at all ... Very funny since today even apple learned that people will never accept that. Seriously, I don't know how is it possible to make so many assumptions out of a simple suggestion to move a discussion to bugzilla. This can only be misleading for others and doesn't really help. These were just two simple assumptions: 1) most dvelopers are not interested on this - unimportant widget and 2) bugzilla fits better - it's realted to bugs. Imho not that far-fetched ... Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
svn2git conversion testing at garage.maemo.org
Hello, I have finished the automated svn2git conversion support for garage projects that are currently using subversion for revision control. I am looking for project admins who would be willing to help me testing the whole procedure in the live environment. Please drop me an email if you are an administrator of a garage project which has a subversion repository and you would consider using git in the future. Cheers, ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [GSoC 09] - Picasa plugin for Canola - report 1
On Sun, Jun 7, 2009 at 10:22 AM, Andrei Miresteanandrei.mirest...@gmail.com wrote: Hi all, I have posted the first report on my GSoC project on the wiki: http://wiki.maemo.org/GSoC_2009/Projects/Picasa_plugin_for_Canola/Report1 Any comments or suggestions are welcomed. It looks good already! Keep up the good work. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [GSoC 09] - Remember The Milk plugin for Canola - report 1
On Mon, Jun 8, 2009 at 8:56 AM, Andrey Popeloand...@popelo.com wrote: Hello all, This is a first report for Remember The Milk plugin for Canola GSoC 09 project. In previous two weeks I was studying Canola source code and started with creating a simple skeleton of a plugin. I talked with my mentor and we decided to move forward iteratively: at first create an app which just works with network connection and shows tasks using standard ui elements. Then add local tasks storing functionality, syncronization and new ui elements. After two weeks of work we already have a plugin which allows to browse tasks for today and tomorrow, browse lists and tasks inside lists and search for tasks. I recorded a small video[1] (~30 sec) which shows how it works. Source code available at code.openbossa.org[2], installation instructions available on a wiki page[3]. Plan for the next week: * improve current plugin - add ability to view task properties and create new tasks, so we will have something a bit usable already * start implementing local tasks storing functionality good work, nice video! I hope you and the other developers are liking the Canola infrastructure and find it easy to create the plugins. Of course you have a learning curve, learn the plugin setup black-magic and how to use/extend components like lists and dialogs, but after that things come easy :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Playbin volume bug for OGG and WMA playback
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 worrying about creating different pipelines for different media types or just limiting playbin's volume to 1. I guess my point is, we should be able to take advantage of gstreamer's awesome playbin simplicity on Maemo. Thank you for your time and patience, nick ___ maemo-developers
