Re: Google Summer of Code 2011 ideas needed!

I was brainstorming a bit in IRC [1]. I'll just drop the ideas we had since they're not formalized enough to put them on the ideas page. Perhaps we can brainstorm together. * Redesigning the db to allow more flexible queries and to be more efficient (and because the current db is practically u

Re: WPS on RaaA

Am 25.02.2011 12:43, schrieb Alex Parker: Er, I somehow managed to send that while typing... So, If the notification goes away on pause I'd be a fan of that. Done now. Hopefully we don't need a separate stop button now. Best regards.

Re: FS#8961 - Anti-Aliased Fonts

Am 25.02.2011 17:04, schrieb Thomas Martitz: * alpha fonts are ~4 times bigger I played a bit with convttf and noticed that this isn't quite true. The bitmap data is 4x bigger (see MWIMAGEBITS in [1]), but the other data stays the same. Depending on the font size the bitmap data c

Re: FS#8961 - Anti-Aliased Fonts

Am 25.02.2011 17:10, schrieb Paul Louden: Any chance we could get antialiased versions of the fonts used for color targets in the default theme (and an appropriate update to the theme) to go in with the patch? That's a good question. I think our .bdf fonts have customized charsets that are no

FS#8961 - Anti-Aliased Fonts

Hello folks, I'm using FS#8961 and I really like it. So I would like to commit it. I reviewed the patch and I think it's good enough. Some notes: * convttf converts straight from .ttf to .fnt and cannot generate mono fonts * existing .fnt installed on the dap are still working * alpha fonts a

Re: WPS on RaaA

Am 24.02.2011 23:06, schrieb Alex Parker: Any thoughts/objections? Alex I don't mind any of the points except the extra stop button. There's just too little space for it on the WPS. However, we can change that the notification symbol goes away at pause already. I made the cabbies with e

Re: Embedded albumart

Am 13.02.2011 21:31, schrieb Alex Parker: Now I'm guessing here that by directory art you meant e.g. folder.jpg, that is applied to all tracks in the directory, in which case I disagree with you (for the reasons below). If you meant on the other hand track art, such as filename.jpg, where th

Re: kugel: r29259 - in trunk/apps: . metadata recorder

Am 09.02.2011 21:51, schrieb Jeff Goode: Oh, nice. I look forward to trying this one out! Thanks. Give it a try :) But it was not needed to quote the entire diff and we also don't like top posts. Best regards.

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 04.01.2011 10:11, sideral wrote: Additionally, and that's probably because it's not my use case, but I find the preciousness you put into a resume point exaggerated. In a later message, Thomas writes: Although I'd like to add that resume points are also not stored within the *last* 15s of a

Re: Upgrading coldfire gcc

On 27.12.2010 12:59, Nils Wallménius wrote: There are some things i'm not sure about though. Should we keep the old toolchain around? And if so, should rockboxdev.sh be able to select which version to build and should configure deal with the different versons (they need different command line arg

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 27.12.2010 00:36, sideral wrote: Paul Louden writes: On 12/21/2010 7:47 PM, Mike Giacomelli wrote: That seems reasonable. List the parts that are of concern to you and we can commit the rest in the mean time. The option to turn auto-resume on/off. No other options, with the default behavi

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 22.12.2010 10:37, sideral wrote: Second, even if the current playback position would be preserved, there is no simple way to return to it. You'd have to skip away from the track, then play it again. Stopping the track and then resuming playback wouldn't work because the Resume Playback funct

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 22.12.2010 02:47, Mike Giacomelli wrote: As I've said a few times, we should take a step back and try to come to a consensus of what should be addressed ignoring what this patch does or does not address, then hold this patch up against that and see if it fits within that scope. Are you actua

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 18.12.2010 00:10, sideral wrote: The existing skipping-prevention features do not work for me because my goal actually is not losing the resume position, rather than preventing skipping. In fact, I'd hate to loose the ability to jump between tracks (party mode) or even to use any other Rockb

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 21.12.2010 20:44, Al Le wrote: So do I understand correctly that no consensus has been reached and that the patch will eternally rot on the tracker? From what I've gathered from the thread, that's because we haven't discussed or considered proposed alternatives. Instead the author insiste

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 15.12.2010 22:35, David Hall wrote: Which is why I think simply replicating what Sansa does (podcast specific "special" folder) is the best solution. No additional configurations / options, and one can not place files from said folder into a mixed playlist w/o explicitly choosing to do so.

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 15.12.2010 20:02, Paul Louden wrote: I just feel this feature is very complicated in terms of offered options for a feature that should be relatively simple and intuitive. It feels engineered toward what I see as a fringe use case, rather than being a significant convenience feature for mo

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 15.12.2010 19:32, Alex Parker wrote: I don't see this as being at all the same. The recording dir is where all files go when you record, i.e. when you create them. The file browser option selects where the browsing starts. Here it is that Rockbox behaves differently depending on where you

Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)

On 13.12.2010 21:32, Paul Louden wrote: Can someone point me to where 11748 was deeply discussed? It looks like the patch currently adds an awful lot of options. Is there a discussion of whether we want all this? It seems very complex. I agree that auto-resume would be nice, but do we really n

Re: kugel: r28753 - in trunk: firmware/export tools

On 07.12.2010 13:18, Teruaki Kawashima wrote: (2010/12/07 7:28), mai...@svn.rockbox.org wrote: > Date: 2010-12-06 23:28:14 +0100 (Mon, 06 Dec 2010) > New Revision: 28753 > > Log Message: > Fix configure and lib path > > Modified: > trunk/firmware/export/rbpaths.h > trunk/tools/configure >

Re: how to avoid a "make install" on simdisk after each change

"Maurus Cuelenaere" schrieb: >"Michael Stummvoll" wrote: > >>Hello, >> >>when I am developing on an application, I often work in little steps >>(make a change, build it, test it, make the next change, build this, >>...). >> >>First I did this by typing "make && make install" at my build-dir >a

Re: Withdrawl from S9 development

"Andrew Poelstra" schrieb: >For those who haven't heard of me, I haven't done much of anything >since the school year started. That's why. > >When I was working, my goal was to port Rockbox to the Cowon S9 >platform. Unfortunately, a few days ago, my only S9 was run over >by a truck. > >Therefo

Re: brain dump regarding playlist management

On 17.11.2010 13:33, Jeff Goode wrote: On 11/17/2010 02:48, Paul Louden wrote: On 11/17/2010 1:38 AM, Marcin Bukat wrote: 3) the default action on .m3u files should be to open it in the viewer I *always* use m3u files to play whole album in order. It is stored in the same dir as the files. Suc

Re: kugel: r28548 - in trunk: android/src/org/rockbox apps/gui/bitmap firmware/drivers firmware/export firmware/export/config firmware/target/hosted/android firmware/target/hosted/sdl

On 11.11.2010 13:48, Maurus Cuelenaere wrote: Op 11-11-10 13:43, Björn Stenberg schreef: Op 11-11-10 12:18, Teruaki Kawashima schreef: +/* this are not actually the correct dimensions (480x272 is correct) + * should be fixed once there's a working LCD driver */ +#define LCD_WIDTH 480 +#define

FS#11727 - Touchscreen: Improved scroll threshold

Am 05.11.2010 10:38, schrieb Thomas Martitz: I'm working on a patch for which I need to know the DPI of a display (the scroll threshold for touchscreens, i.e. how many pixels you can move before the list code thinks you want to scroll). Alright, I posted the patch to FS#11727.

Re: re r28480

Am 05.11.2010 17:39, schrieb Thomas Martitz: I just realized that commit also broke the SDL app and changed the allocation scheme for the sim. Don't we want the sim run code as close as possible as on target? And act as a tool to create themes (in which case it'd be handy if it

Re: re r28480

I just realized that commit also broke the SDL app and changed the allocation scheme for the sim. Don't we want the sim run code as close as possible as on target? And act as a tool to create themes (in which case it'd be handy if it showed the theme size)? Best regards

Re: Onda VX767 LCD dimensions

Am 05.11.2010 15:59, schrieb Karl Kurbjun: Thomas, Please also cover the M:Robe 500 with this work, the sensitivity is too high for the screen with your current scrolling code. I noticed in the email list it appeared that you thought it was a dead target, but I still use it and know a few othe

Re: Onda VX767 LCD dimensions

Am Fr, 5.11.2010, 10:41 schrieb Maurus Cuelenaere: > > [2] is the manufacturers site, which has the same resolution (480x272), so > the value in Rockbox is probably wrong. > Keep in mind that I never found adequate testers/devs with a VX767, so > this port doesn't have a working LCD driver (apart f

Onda VX767 LCD dimensions

I'm working on a patch for which I need to know the DPI of a display (the scroll threshold for touchscreens, i.e. how many pixels you can move before the list code thinks you want to scroll). I noticed that what the Onda vx767 has for LCD_WIDTH (320) and LCD_HEIGHT (240) doesn't match with what I

Re: re r28480

Am 04.11.2010 23:13, schrieb Jonathan Gordon: Tell you what, go and implement it better in such a way that it doesnt make dynamic screen sizing difficult or reintroduce artificial limits on the buffer size for APPLICATION builds and then we can talk, untill then, well... I think you missed

Re: re r28480

Am 04.11.2010 16:30, schrieb Al Le: Hello. I have a couple of questions / suggestions about the patch. 1. Shouldn't the vars 'first' and 'last' be declared static? And renamed to something more specific, e.g. 'alloced_list_head' and '..._tail'? 2. Shouldn't the result of the call to malloc be

Re: FS#11696 - scrollwheel not responding on e200 v1

Am 04.11.2010 21:32, schrieb Magnus Holmgren: Hi, I had a look at FS#11696, and I may have found the cause. My theory is that button release events aren't always posted, e.g., if repeat events haven't been processed while the UI is busy with other things. This in turn can cause get_action_worker

Re: FS#8806 - MikMod MOD, S3M, IT, XM player

Am 04.11.2010 14:43, schrieb Frank Gevaerts: Hi, Are there fundamental reasons not to commit FS#8806? I know that ideally we want all sound formats to play via a codec and not a plugin, but the way I understand these tracker formats, the codec buffer size would really limit the usefulness of suc

Re: kugel: r28423 - trunk/apps

Am 02.11.2010 00:43, schrieb Jonathan Gordon: Thomas should have done the work to fix all touchscreen targets instead of being lazy and passing the buck. You're doing nothing different to "passing the buck" (to me). And see, trying to put all the load of work that our touchscreen target

Re: kugel: r28423 - trunk/apps

Am 01.11.2010 23:37, schrieb Jonathan Gordon: Amazingly I have absolutly no faith that you will fix onda if it is left in this state. You want this change, you broke onda, it is your responsibility to fix it. Right. I said very early in the thread that I won't do the work for the other tar

Re: kugel: r28423 - trunk/apps

Am 01.11.2010 22:42, schrieb Jonathan Gordon: RaaA is not the only touchscreen target, But your mail and mine before was about reverting on RaaA. Why argue with the Ondas now? I maintain that there's nothing to fix on RaaA. So why would you want to revert it for RaaA too? You broke onda a

Re: kugel: r28423 - trunk/apps

Am 01.11.2010 22:14, schrieb Jonathan Gordon: From your opening post on the topic.. "I'd propose to make the change for all and force people to adapt the missing parts finally (the absolute point mode is not a new thing at all)? " Reverting android also gives you more motivation to fix it instea

Re: kugel: r28423 - trunk/apps

Am Mo, 1.11.2010, 14:19 schrieb Jonathan Gordon: > As per the other thread my view is this should be reverted (for both > targets), no one is objecting to this when the target is ready (as > defined by not being able to get stuck in any screen except panic when > in stylus mode, and giving visual f

Re: Making absolute point mode default

Am 01.11.2010 01:21, schrieb Jonathan Gordon: On 1 November 2010 03:24, Thomas Martitz wrote: Ok, I made absolute point mode default on RaaA and the Onda targets now. I left the others (d2, mr500) out because I'm tired of this discussion. May those never get fixed. Best re

Re: Making absolute point mode default

Am 31.10.2010 23:14, schrieb Daniel Stenberg: On Sun, 31 Oct 2010, Thomas Martitz wrote: Ok, I made absolute point mode default on RaaA and the Onda targets now. I left the others (d2, mr500) out because I'm tired of this discussion. May those never get fixed. Please leave the vi

Re: Making absolute point mode default

Ok, I made absolute point mode default on RaaA and the Onda targets now. I left the others (d2, mr500) out because I'm tired of this discussion. May those never get fixed. Best regards.

Re: Fwd: kugel: r28386 - in trunk: android/src/org/rockbox firmware/target/hosted/android

Am 30.10.2010 15:36, schrieb Jonathan Gordon: QUOTE == Date: 2010-10-30 01:12:08 +0200 (Sat, 30 Oct 2010) New Revision: 28386 Log Message: Initialize (instantiate) RockboxFramebuffer from the C code like with the othe java objects. Remove some @Override annotations to make the

Re: Feature proposal: received signal strength indicator for fm radio

Am 28.10.2010 21:10, schrieb Jens Arnold: I am in favour of this feature. I think this would be nice, not really useful but nice to have. And if 1) is mostly done, 2) and 3) should not be too difficult I guess (JdGordon -> correct me if I'm wrong). The question is how too handle chips which d

Re: Making absolute point mode default

On 27.10.2010 01:40, Paul Louden wrote: You and I seem to have a different definition of "usable." Can we step back for a moment and settle on the English definition of "can be used"? Ok, for a moment. I agree the grid can be used. Can we now step up to usability (as in http://en.wikipedia

Re: Making absolute point mode default

On 27.10.2010 00:40, Paul Louden wrote: Since the grid mode actually works on every screen, and is quite usable (just unintuitive) wouldn't the obvious solution be JdGordon's idea of adding some visual feedback to make it more obvious that it's there be a good solution to keep things working.

Re: Making absolute point mode default

On 27.10.2010 00:45, Paul Louden wrote: DPI mismatch is only relevant at all if we're going to be creating different versions of the screen for each DPI of device at each resolution. If the screen is only to have one version per resolution, it's obvious that the DPI excuse is irrelevant since

Re: Making absolute point mode default

On 27.10.2010 00:40, Paul Louden wrote: Rather than breaking screens entirely, when there's little-to-no chance that they'll be repaired soon, shouldn't we be looking for a way to try to keep them working through the transition? If I remember correctly, the idea of overriding settings and for

Re: Making absolute point mode default

On 27.10.2010 00:20, Paul Louden wrote: On 10/26/2010 5:15 PM, Thomas Martitz wrote: As if the grid mode was usable. In my opinion the absolute point mode is much more usable even if some screens are not converted. Is there a screen that doesn't work with grid mode and cannot be used

Re: Making absolute point mode default

On 27.10.2010 00:04, Jonathan Gordon wrote: On 27 October 2010 00:52, Thomas Martitz wrote: With "covered" I didn't mean "fixed" but "I'm aware of this and this is how I proposed to deal with it". Breaking useability is not a way with dealing wit

Re: Making absolute point mode default

On 26.10.2010 15:28, Jonathan Gordon wrote: On 27 October 2010 00:17, Thomas Martitz wrote: On 26.10.2010 15:04, Jonathan Gordon wrote: On 26 October 2010 22:16, Thomas Martitz wrote: So, I'm planning to make the absolute point mode default very soon after kinetic scrolling

Re: Making absolute point mode default

On 26.10.2010 15:04, Jonathan Gordon wrote: On 26 October 2010 22:16, Thomas Martitz wrote: So, I'm planning to make the absolute point mode default very soon after kinetic scrolling is in. Amazingly I'm against this change (At least for a global change anyway). I have a few re

Re: Make Clipv1 and AMSv2 (Fuzev2, Clipv2, Clip+) stable for 3.7

On 26.10.2010 14:41, Bertrik Sikken wrote: IMO this is not a feature required for a release. Maybe we should disable this feature when making a release. Kind regards, Bertrik I agree.

Re: Make Clipv1 and AMSv2 (Fuzev2, Clipv2, Clip+) stable for 3.7

On 26.10.2010 14:23, Amaury Pouly wrote: I think these are very stable, I have no problem with my Clip+. Regarding USB, the patch on FS seems to work well even though under Windows it get the device connected in 1.1 mode (Full Speed) instead of 2.0 mode (High Speed) for an unknown reason. The q

Make Clipv1 and AMSv2 (Fuzev2, Clipv2, Clip+) stable for 3.7

I would like to see them stable and be part of 3.7. Rockbox is very stable on my fuzev2. Is there anything blocking them? FWIW I don't think missing USB is a blocker. Best regards.

Re: Making absolute point mode default

On 26.10.2010 13:40, Paul Louden wrote: On 10/26/2010 6:27 AM, Thomas Martitz wrote: On 26.10.2010 13:20, Paul Louden wrote: I would maybe do it myself if I had access to the devices. And I bet I'm not the only one the switch-over is needed badly. Isn't this purely touchscreen+

Re: Making absolute point mode default

On 26.10.2010 13:20, Maurus Cuelenaere wrote: +1, grid mode has been the default for way too long. I take that as the Ondas are also ready for the change? Best regards

Re: Making absolute point mode default

On 26.10.2010 13:20, Paul Louden wrote: On 10/26/2010 6:16 AM, Thomas Martitz wrote: I'd propose to make the change for all and force people to adapt the missing parts finally (the absolute point mode is not a new thing at all)? So wait, the idea is to enable this mode so that yo

Making absolute point mode default

So, I'm planning to make the absolute point mode default very soon after kinetic scrolling is in. The argument is that Rockbox appears to be broken for new users that are surprised when confronted with the grid mode (which has no visual indications). And I can say Rockbox works nicely[*] with

Re: FS#11689 - User settings in skins, and user translation in skins

On 26.10.2010 01:33, Jonathan Gordon wrote: The plan has changed to be one settings file per theme so themers don't have to work together (not that that is a bad thing). I fail to see how that's different from changing the theme directly. If that's the plan, then it adds nothing. For the same

Re: FS#11689 - User settings in skins, and user translation in skins

On 26.10.2010 00:28, Jonathan Gordon wrote: Whether it gets used or not obviously remains to be seen. That is not the bar for inclusion (however for removal later maybe *cough* charcell). I know for sure themes which would use this if it were available. I think the bar should at least be

Re: FS#11689 - User settings in skins, and user translation in skins

On 19.10.2010 15:37, Jonathan Gordon wrote: This is an idea I've had for ages which I never got around to coding. Each time I've brought it up in IRC its had a different response so time for some actual official discussion. The idea behind this patch is giving themers a way to make their themes

Re: FS#11686 - Kinetic list scrolling for touchscreen

On 25.10.2010 23:14, Alex Parker wrote: I think you got no objections after a good number of days, which works for me. I suspect the lack of response may slightly be down to the relative lack of people with touchscreen targets (although a few have android phones). Alex The "no objections" sy

Re: FS#11686 - Kinetic list scrolling for touchscreen

On 25.10.2010 23:17, Bertrik Sikken wrote: I'm not completely sure if I know what kinetic scrolling is. I can't really comment on the implementatiom because I'm not very familiar with the list handling code. Kinetic scrolling is simply that you (s)wipe over the screen with your finger to accel

Re: FS#11686 - Kinetic list scrolling for touchscreen

On 19.10.2010 17:58, Jonas Häggqvist wrote: On 19-10-2010 12:07, Thomas Martitz wrote: So I uploaded my kinetic scrolling patch. [snip] I guess I can commit in a week if I get a) enough votes or b) nobody cares at all? How about posting a test build for D2 and the Onda(s?) in the relevant

Re: Feature proposal: received signal strength indicator for fm radio

On 25.10.2010 21:10, Misieq Haker305 wrote: That's basically very good idea IMO. RockBox radio WPS remains unchanged from large amount of time - why don't finally change it a little? Player's which doesn't support such a RSSI read, may just don't have signal bars/value on WPS - that's it IMO. I

FS#11686 - Kinetic list scrolling for touchscreen

Let's try this concept we discussed in the "Getting Agreements" thread. So I uploaded my kinetic scrolling patch. I plan to commit it in a week (unless we're still frozen by then, although nothing changes for release targets), but I would like comments from cowond2 and/or onda users as to how

Re: release 3.7 agenda

Are we still frozen, or did we actually freeze already? I'm bitter that we don't appear to have a coordinated release plan this time. Nobody seems to know where we are at yet (apart from the idea to release on October 29). I would also like to see a call for translators again, they've been

Re: rolling stable builds

On 19.10.2010 10:49, Jonathan Gordon wrote: On 19 October 2010 19:32, Thomas Martitz wrote: I think we should work a lot more with RC builds to let users test on targets for which we don't currently have a maintainer around. If an RC build is untested then it's likely that only ve

Re: rolling stable builds

On 19.10.2010 09:22, Linus Nielsen Feltzing wrote: On 2010-10-19 05:17, Jonathan Gordon wrote: My view would be that any bugfix for a flyspray task would be a candidate to go in the stable branch. Fixes which are too fiddly to backport would probably miss out (or at that point we talk about a n

Re: Segfault with Faster MDCT patch and -fPIC

On 13.10.2010 13:14, Dave Hooper wrote: I'd be interested to know what the cpu benefit on android is when optimisations are enabled.. :) I just did some tests: http://www.alice-dsl.net/simonemartitz/rockbox/test_codec_stats.pdf (armv5 build even though my phone is armv6). Best regards

Re: replace quickscreen key with hotkey

On 12.10.2010 12:21, Jonathan Gordon wrote: you only sent this to me... anyway, yes, the way it will have to happen is both actions will be hotkey actions, so noone will lose anything On 12 October 2010 20:47, Thomas Martitz wrote: I use both quick screen and hotkey very frequently, for me

Re: Segfault with Faster MDCT patch and -fPIC

On 13.10.2010 01:36, Dave Hooper wrote: Slawomir and Thomas - I have updated the patch at FS#11666, would you be able to retest please? (to confirm that it still works, and that it now works, respectively :-) ) Additionally, I've already committed this patch to rockbox sources. I figure

Re: Segfault with Faster MDCT patch and -fPIC

Am Mo, 11.10.2010, 14:37 schrieb Dave Hooper: > I didn't get much chance to investigate (I believe I > have some working changes to remove the macro-hell which gcc should now > have > more luck with, but my arm-elf-objdump seems incompatible with eabi so > unable to easily check the disassembly) >

Re: Segfault with Faster MDCT patch and -fPIC

On 10.10.2010 12:35, Dave Hooper wrote: I hope to take a look today Nice, thanks! PS: May I remind you that we don't like top posting on this list? You're consistently doing it.

Re: Segfault with Faster MDCT patch and -fPIC

On 17.09.2010 09:32, Slawomir Testowy wrote: Hi all! For some time I have been using tremor with fastermdct patch found on http://www.rockbox.org/wiki/FasterMDCT. This patch gives huge speedup on i686/x86_64 machines and smaller, but still significant, speedup on ARM. Everything works great un

Re: Getting agreements

On 09.10.2010 14:39, Daniel Stenberg wrote: My suggestion for what's required to get a new feature added: Three devs (expressed) in favour (+1), and none being against (-1) given enough time to react (ie more than 24 hours). If there's anyone agaist it, there must be reasons specified for th

Re: Release 3.7, freeze on monday

On 08.10.2010 19:11, Rafaël Carré wrote: On Fri, 8 Oct 2010 18:16:42 +1100 Jonathan Gordon wrote: Hi all, Amazingly we have enough consensus to get a release done! So, I propose we freeze on Monday 11th and release sometime in the week of the 18th. OK with me, Do we branch immediately on Mo

Re: Fwd: Re: kugel: r28125 - in trunk/firmware: . export target/hosted/android

On 20.09.2010 20:58, Maurus Cuelenaere wrote: Modified: trunk/firmware/export/debug.h === --- trunk/firmware/export/debug.h 2010-09-20 17:09:55 UTC (rev 28124) +++ trunk/firmware/export/debug.h 2010-09-20 17:38:47 UTC (

Commit message post-editing breaks Git

I just noticed that changing the commit message after the commit (as done in r28078) breaks git/git svn/the rockbox git mirror. The editing caused the git mirror to be out of sync, it has still the old message while git svn gets the

Re: Segfault with Faster MDCT patch and -fPIC

On 20.09.2010 19:27, Dave Hooper wrote: Oh sorry, you mean changing the register used for pic. I got mixed up. I personally don't know if that's expected to work for r11 or not, although that's not really the actual problem (or solution) here Isn't it the only way to determine the pic reg

Re: Segfault with Faster MDCT patch and -fPIC

On 20.09.2010 11:02, Slawomir Testowy wrote: 2010/9/18 Nils Wallménius: gcc lets you specify the pic register with -mpic-register= so it would be a qucick test to try with r11 or something. Nils Unfortunately, this doesn't work: configure:3276: checking whether the C compiler works configu

Re: A commit message template?

Am 15.09.2010 21:12, schrieb Dominik Riebeling: On Wed, Sep 15, 2010 at 8:47 PM, Thomas Martitz wrote: I really like the suggestion, but it would be hugely annoying for the "fix red" or "fix typo in comment" kind of changes which is the topic we're discussin

Re: A commit message template?

Am 15.09.2010 19:18, schrieb Daniel Stenberg: On Tue, 14 Sep 2010, Dominik Riebeling wrote: (I changed subject since I try to change the direction of the discussion a bit here.) I don't know if it's just me but at least *I* would really appreciate descriptive commit messages since it allows

Re: jdgordon: r28078 - trunk/apps/radio

Am 15.09.2010 17:28, schrieb Amaury Pouly: You seem to always think about the users but I think you are missing the point. Developers too want clear commit messages (or at the very least, several people on this ML have shown interest in good commit messages). When I sync my repo with the SVN, *

Re: jdgordon: r28078 - trunk/apps/radio

On 14.09.2010 22:55, Paul Louden wrote: On 9/14/2010 3:47 PM, Rafaël Carré wrote: This commit log isn't really much less descriptive than, say, "fix red", which seems to be an acceptable commit log though. So while I prefer long and descriptive log messages, this particular log doesn't rea

Re: RockBox on Samsung Galaxy S

On 12.09.2010 19:01, Dave Hooper wrote: Regarding an explicit way to Quit: without one, is there any way to actually enable the various settings that require a restart of the application ("reboot to enable") ? Well yes, reboot, the phone :) I think we eventually don't want these in the app a

Re: RockBox on Samsung Galaxy S

On 12.09.2010 15:52, Thomas Martitz wrote: What's the minimum on the galaxy s? I'm thinking doing something like MIN(old_buffer, getMinBuffer()) is maybe better than just getMinBuffer(). MAX() of course :)

Re: RockBox on Samsung Galaxy S

Taking this to the -dev mailing list. On 12.09.2010 14:54, Nagy István wrote: Hi! On Sun, Sep 12, 2010 at 11:59 AM, Thomas Martitz <mailto:thomas.mart...@student.htw-berlin.de>> wrote: On 12.09.2010 10:21, Nagy István wrote: Hello, I hope that i'm writ

Re: [RaaA] Weekly status report

On 07.09.2010 17:16, Maurus Cuelenaere wrote: Also, the skin library could be made less strict wrt backdrop dimensions etc., so for example 240x320 themes could be loaded and displayed on 240x400 screens (at least until a native theme is available). This already (sort of) works. Rockbox loa

Re: [RaaA] Weekly status report

On 23.06.2010 13:59, Maurus Cuelenaere wrote: And yes, you can specify what screen dimensions are supported in the manifest packaged with your Android app AFAIK. Could we also have 1 apk for each supported dimension (e.g. 1 for 320x480 which only 320x480 users will see, 1 for 480x800 which

Re: kugel: r27977 - in trunk: android firmware/export firmware/target/hosted/android tools uisimulator/common

On 02.09.2010 03:18, Maurus Cuelenaere wrote: #define storage_num_drives() NUM_DRIVES -#if (CONFIG_STORAGE& STORAGE_ATA) +#if (CONFIG_STORAGE == 0) /* application */ +#define STORANGE_FUNCTION(NAME) (stub_## NAME) Shouldn't this be STORAGE_FUNCTION? Oh yes, my bad :) B

Re: gain settings in recording screen

On 24.08.2010 16:59, Nils Wallménius wrote: On Tue, Aug 24, 2010 at 8:19 AM, Marcin Bukat wrote: Hello rockboxers! I would like to get some feedback for FS#11534 as I got no single comment on FS. Currently the step when changing gain/vol settings in recscreen is always 0.1dB. Many (most?) cod

Re: DB refresh on clip+ UI simulator

On 24.08.2010 01:40, Alan Peter Fitch wrote: I've been playing with the database to add the possibility to sort albums by "albumsort" field (because I've used the albumsort field in my music files). Please have a look at http://www.rockbox.org/tracker/task/7287 I would be interested in some

Re: RE : RE: Proposal to enable PLL for AMSv2 players to increase PCM rate accuracy

On 15.08.2010 00:52, Rafaël Carré wrote: It's ok with me Le 15 août 2010 00:08, "Mike Giacomelli" > a écrit : > I propose to implement solution 2, see also > http://www.rockbox.org/tracker/task/10906 > Its better then what we have and has no obvious downsides.

Re: Release 3.7 timeline?

On 17.08.2010 03:31, Jonathan Gordon wrote: It isnt only the wps. I dont know any device which uses our 3x3 grid (or anything like it) and especially not as default. cabbie needs a touch sbs and default to stylus mode, otherwise 99% of users will think its just broken on first use. I understan

Re: Release 3.7 timeline?

On 17.08.2010 02:37, Jonathan Gordon wrote: If we really want to do the whole shebang with 4.0 and raaa then at the very least a fully touch aware cabbie needs to be done for all the raa lcd sizes, or better yet, someone make the lists iconable for touch devices. I think lists consisting only

Re: Release 3.7 timeline?

On 16.08.2010 22:31, Antony Stone wrote: And yes, that would be worth a major publicity announcement - aside from anything else, it will bring Rockbox firmly back into the world of "currently available players", the number of which has been sadly dwindling over the past few years. Actually, it

[RaaA] Final status report

Hello everyone, this is my last status report, the GSoC deadline is arriving soon. Since the last report I've fixed a few minor issues, but also created 2 wiki pages ([0] and [1]) which hopefully helped to understand what I achieved and how to work with it in the future. If there's any questi

Re: [RaaA] Weekly status report

On 05.08.2010 14:12, Matthias Mohr wrote: Hi Thomas, big gratulations - great work! You asked if you missed something. Well, I don't know - but one thing came to my mind: One goal of RaaA was to build a framework to make porting RaaA to new platforms easy. So I wonder if you created a good an

<    1   2   3   4   5   6   7   >