detail.
I have also document 3D enhancement in the manual, feel free to have a pick
before I push it:
http://gerrit.rockbox.org/r/#/c/1374/1
I have more audio documentation in the pipes but this is a first step.
Thanks,
Amaury
Hello all!
Two days ago I posted on gerrit a (binary) patch to give the screenshots
to the Sansa Clip Zip manual. It's located at
http://gerrit.rockbox.org/r/#/c/357/
(so I'm asking for a review, which shouldn't be problematic, given that
there is no code modification involve
On 07/11/11 05:08, Jonathan Gordon wrote:
On 7 November 2011 01:47, Thomas Martitz wrote:
Am 05.11.2011 12:16, schrieb Alex Parker:
Excellent, thanks very much :)
Looks like both issues are resolved, so we should be ready to freeze.
Best regards.
In Alex's absence (as the person who's b
On 7 November 2011 01:47, Thomas Martitz wrote:
> Am 05.11.2011 12:16, schrieb Alex Parker:
>>
>> Excellent, thanks very much :)
>
> Looks like both issues are resolved, so we should be ready to freeze.
>
> Best regards.
>
In Alex's absence (as the person who's been pushing the last few
release)
Am 05.11.2011 12:16, schrieb Alex Parker:
Excellent, thanks very much :)
Looks like both issues are resolved, so we should be ready to freeze.
Best regards.
On 05/11/11 11:04, Thomas Martitz wrote:
Am 05.11.2011 11:47, schrieb Alex Parker:
Hi guys,
So, FS#12325, FS#12337 and FS#12279 are marked as being fixed which is
good news, leaving FS#12310 outstanding as a blocker.
My feeling is that it would be handy to get that fixed before
branching, wha
Am 05.11.2011 11:47, schrieb Alex Parker:
Hi guys,
So, FS#12325, FS#12337 and FS#12279 are marked as being fixed which is
good news, leaving FS#12310 outstanding as a blocker.
My feeling is that it would be handy to get that fixed before
branching, what do people think?
I tend to agree.
On 27/10/11 08:31, Björn Stenberg wrote:
Alex Parker wrote:
Speaking of which, where are we with this? Any show stoppers people
are aware of? Things that need focussing on?
We are in pretty poor shape, with a number of regressions. The way I see it, at
least the following bugs need to be sol
On 27 October 2011 19:33, Björn Stenberg wrote:
> Thomas Martitz wrote:
>> >FS#12279 - Sansa Clip+: Music playback is returned to the head when wps is
>> >changed since r30486
>>
>> The last one isn't easily fixable (according to jhMikeS), and I also
>> don't consider it release critical (though
> Add option to exchange the left and right stereo channels. Patch by Dave
> Chapman and Martin S?\195?\164gm?\195?\188ller. Also add manual entry (by
> Michael Giacomelli). Note that this setting will confuse non-software
> effect options like channel balance. This should be ad
Thomas Martitz wrote:
> >FS#12279 - Sansa Clip+: Music playback is returned to the head when wps is
> >changed since r30486
>
> The last one isn't easily fixable (according to jhMikeS), and I also
> don't consider it release critical (though it's technically a
> regression indeed).
The bug in th
Am 27.10.2011 09:31, schrieb Björn Stenberg:
FS#12310 - Crash when inserting USB while playback (since r30097)
FS#12325 - e200v1 screen corruption after USB connection since r30475
FS#12337 - r30773 breaks all skin fonts
FS#12279 - Sansa Clip+: Music playback is returned to the head when wps is
Alex Parker wrote:
> Speaking of which, where are we with this? Any show stoppers people
> are aware of? Things that need focussing on?
We are in pretty poor shape, with a number of regressions. The way I see it, at
least the following bugs need to be solved before release:
FS#12310 - Crash whe
On Thu, Oct 27, 2011 at 06:25, Mike Giacomelli wrote:
> Unless i'm missing something, the samples are interleaved, so we can't just
> swap the pointers. We could offset the pointer one, but we'd lose a sample
> and perhaps introduce a gap.
I'm pretty sure the internal format still is non-interl
>
> And regarding the implementation (when it is re-committed), why not just swap
> the pointers? No point in looping there...
Unless i'm missing something, the samples are interleaved, so we can't just
swap the pointers. We could offset the pointer one, but we'd lose a sample and
perhaps
On 2011-10-26 20:28, Alex Parker wrote:
I have nothing against this in general, but we are supposed to be in feature
freeze at the moment.
And regarding the implementation (when it is re-committed), why not just swap
the pointers? No point in looping there...
--
Magnus
On 26/10/11 19:28, Alex Parker wrote:
I have nothing against this in general, but we are supposed to be in
feature freeze at the moment.
Alex
Speaking of which, where are we with this? Any show stoppers people are
aware of? Things that need focussing on?
Alex
I have nothing against this in general, but we are supposed to be in feature
freeze at the moment.
Alex
explanations of hotkey where it's mentioned.
Flyspray: FS#11188
Author: Alexander Levin
Modified:
trunk/manual/rockbox_interface/browsing_and_playing.tex
trunk/manual/rockbox_interface/wps.tex
trunk/manual/working_with_playlists/main.tex
Modified: trunk/manual/rockbox_interface/brow
+0200 (Fri, 02 Apr 2010)
New Revision: 25440
Log Message:
Manual update for keymaps, hotkeys
Modified:
trunk/apps/keymaps/keymap-player.c
trunk/manual/platform/keymap-archosplayer.tex
trunk/manual/platform/keymap-archosrecorder.tex
trunk/manual/platform/keymap-gigabeatfx.tex
This one seems to miss a new file, hotkeys.tex
Frank
On Fri, Apr 02, 2010 at 10:11:12PM +0200, mai...@svn.rockbox.org wrote:
> Date: 2010-04-02 22:11:11 +0200 (Fri, 02 Apr 2010)
> New Revision: 25440
>
> Log Message:
> Manual update for keymaps, hotkeys
>
> Modified:
&g
Alex Parker wrote:
> This is all getting a bit academic - it has become clear for whatever
> reason that some people are unwilling/incapable of keeping the manual
> up-to-date. OK, fine. All I personally am asking is that they maintain
> a list of what needs adding/changing/removi
This is all getting a bit academic - it has become clear for whatever
reason that some people are unwilling/incapable of keeping the manual
up-to-date. OK, fine. All I personally am asking is that they maintain
a list of what needs adding/changing/removing so that I (and others) can
make
On Sat, Feb 27, 2010 at 3:32 PM, Thomas Martitz
wrote:
> With "ship" I mean pre-installed on the live cd. Surely you can download the
> lot of packages, but that's different.
so you run your system purely from a live CD? Besides, for development
you need to install the cross compilers anyway (whi
On 27.02.2010 14:12, Mike Holden wrote:
So you're saying that most major distros DON'T ship with LaTeX? Or are you
saying
that they do, but that it is a large package set? I can only speak for Fedora,
but
Fedora 12 certainly ships with a number of LaTeX packages.
With "ship" I mean pre-i
27;t suggest being to write Latex stuff.
> They're completely separate beasts, and latex is not trivial at all.
Surely much of it will be a simple "copy, paste, change the text" process though
using already-existing entries from the same part of that manual, rather than
w
On 27.02.2010 11:43, Dominik Riebeling wrote:
On Fri, Feb 26, 2010 at 8:46 AM, Jonathan Gordon wrote:
2) its updated too frequently
the manual is built once per day, so what's the point? People who want
something changing slower are likely to use releases anyway, and those
On Fri, Feb 26, 2010 at 8:46 AM, Jonathan Gordon wrote:
> 2) its updated too frequently
the manual is built once per day, so what's the point? People who want
something changing slower are likely to use releases anyway, and those
don't change at all. People who want to use bleeding
2010/2/26 Jonas Häggqvist :
> and available on all or at least nearly all platforms we build on (don't
> know if you can build the manual on OS X?).
you can build the manual on OS X just fine. LaTeX is a separate
install, but that's about it (well, you need the usual build too
On 26.02.2010 20:46, Karl Kurbjun wrote:
I would not want to see the manual holding up the addition of features.
I agree that it is a noble cause to keep it up to date, but I do not see
it as critical enough to potentially deter developers from adding
features or making changes because they
On Fri, Feb 26, 2010 at 12:26 PM, Al Le wrote:
> On 26.02.2010 14:59, Paul Louden wrote:
>
> This could be solved rather easily by saying "if you can't figure out how
>> to update the manual, post a basic text file to Flyspray containing a
>> description of
On 26.02.2010 14:59, Paul Louden wrote:
This could be solved rather easily by saying "if you can't figure out
how to update the manual, post a basic text file to Flyspray containing
a description of the tags added and what they do."
Or, even better, just ask (e.g. in IRC) for
On 26-02-2010 08:46, Jonathan Gordon wrote:
On 25 February 2010 23:20, Al Le wrote:
r24917 introduced new WPS tags. But again: where is the manual patch?
WPS tags should NOT be in the manual.
I respectfully disagree.
1) its too bloodu long which scares people away from reading it (yes
>
>
>> If the problem is making people go back through the history of the wiki
>> page to figure out what has changed and what isn't in the manual. As long as
>> there's a tracker entry describing _every_ new tag (and/or new feature) that
>> isn't
>
On Fri, Feb 26, 2010 at 6:59 AM, Paul Louden wrote:
> Alex Parker wrote:
>
>>
>>3) TeX is a PITA to work in and not everyone has the required tools
>>
>>
>> Adding to a list is not difficult. At the very least could contributors
>> who can't b
Alex Parker wrote:
3) TeX is a PITA to work in and not everyone has the required tools
Adding to a list is not difficult. At the very least could
contributors who can't be bothered to update the manual please create
a list of things such as tags they add so that others can upda
a of the site especially for them,
>> otherwise its information overload for those who just want to figure
>> out how to play music.
The Wiki is not exactly the most navigable wiki out there.
> No - the manual should be the place to go to find out everything about how
> to use Roc
damn
> quickly after a commit.
>
And they could go in the manual at the same time as the commit.
>
>
> I'm not saying to not document them, I'm saying not to document them
> in the manual. understanding themeing and the config file format are
> not a requirement to use rockbox
>
They should be in the manual in my opinion.
>
>
> WPS tags should NOT be in the manual.
> 1) its too bloodu long which scares people away from reading it (yes
> its in an appendix but still, seeing 100+ pages is enough to turn
> people off)
>
I disagree, but either way having a half and half mix is the worst possible
On 26 February 2010 00:18, Bryan Childs wrote:
> No - the manual should be the place to go to find out everything about how
> to use Rockbox - not just the parts of it that you deem worth documenting.
I'm not saying to not document them, I'm saying not to document th
figure
> out how to play music.
>
No - the manual should be the place to go to find out everything about how
to use Rockbox - not just the parts of it that you deem worth documenting.
On 26 February 2010 00:05, Björn Stenberg wrote:
> Jonathan Gordon wrote:
>> WPS tags should NOT be in the manual.
>> 1) its too bloodu long which scares people away from reading it (yes
>> its in an appendix but still, seeing 100+ pages is enough to turn
>> people
Jonathan Gordon wrote:
> WPS tags should NOT be in the manual.
> 1) its too bloodu long which scares people away from reading it (yes
> its in an appendix but still, seeing 100+ pages is enough to turn
> people off)
We already have 10 pages of WPS tags in the manual. Unless
On 25 February 2010 23:20, Al Le wrote:
> r24917 introduced new WPS tags. But again: where is the manual patch? It's
> very hard to do it afterwards because one has to find what is not documented.
> Besides, I think we once agreed on the rule that every feature is only
> com
r24917 introduced new WPS tags. But again: where is the manual patch? It's very
hard to do it afterwards because one has to find what is not documented.
Besides, I think we once agreed on the rule that every feature is only
committed along with an entry in the manual. So dear Sirs, p
On Sat, Jan 23, 2010 at 08:28:26PM +0100, mai...@svn.rockbox.org wrote:
> Date: 2010-01-23 20:28:26 +0100 (Sat, 23 Jan 2010)
> New Revision: 24318
>
> Log Message:
> Commit FS#10082, enlarge volume control range for WM8758. This will enable
> volume control down to -90 dB for iPod Video targets.
Frank Gevaerts wrote:
On Wed, Nov 11, 2009 at 02:20:44PM -0500, Neil Snat wrote:
2009/11/11 Antony Stone :
Where does the "skip" come in here, though? Surely skip means "missing
something out" (either a whole track, or the remainder of the current track).
Automatically playing the nex
2009/11/11 Frank Gevaerts
>
>
> I think "automatic track change" would work better
>
> Frank
>
>
+1
On Wed, Nov 11, 2009 at 02:20:44PM -0500, Neil Snat wrote:
> 2009/11/11 Antony Stone :
> >
> > Where does the "skip" come in here, though? Surely skip means "missing
> > something out" (either a whole track, or the remainder of the current
> > track).
> >
> > Automatically playing the next track
2009/11/11 Antony Stone :
>
> Where does the "skip" come in here, though? Surely skip means "missing
> something out" (either a whole track, or the remainder of the current track).
>
> Automatically playing the next track at the end of the current one is
> just "continuous play" (aka "normal"), is
On Wednesday 11 November 2009, Jeff Goode wrote:
> Magnus Holmgren wrote:
> >
> > But what is an automatic track skip? :)
> Anyway, an automatic track skip is the opposite of a manual track skip:
> the next track automatically plays at the end of the current track
> w
Magnus Holmgren wrote:
On Wed, Nov 11, 2009 at 1:48 AM, wrote:
Date: 2009-11-11 01:48:17 +0100 (Wed, 11 Nov 2009)
New Revision: 23605
Log Message:
Crossfade: added a new option, rewrote decision logic, updated manual and menus.
Translators please note that updated translations may be
On Wed, Nov 11, 2009 at 1:48 AM, wrote:
> Date: 2009-11-11 01:48:17 +0100 (Wed, 11 Nov 2009)
> New Revision: 23605
>
> Log Message:
> Crossfade: added a new option, rewrote decision logic, updated manual and
> menus.
> Translators please note that updated translations may
s 0.11.3, which does know about this option. I
haven't followed the development of elinks, but maybe that option was
removed? Though I can't think of any reason why. Which version are you
using?
On my system:
Links 2.2
ELinks 0.12pre2
A trivial
fgrep -rn -- -no-numbering rockbox
On Sat, Sep 19, 2009 at 3:44 PM, asettico wrote:
> A note: the makefile runs "links -no-numbering", that it isn't a legal
> option. Also, installing the package elinks in Ubuntu, the right alternative
My system has elinks 0.11.3, which does know about this option. I
haven't followed the developme
*In data 16/09/2009 22:27, Dominik Riebeling ha scritto*:
On Wed, Sep 16, 2009 at 12:13 PM, asettico wrote:
It requires the Tex package and I also installed html2text, but I still get
the same error. Where is my mistake?
You need elinks to create the txt manual, not html2text -- it's
On Wed, Sep 16, 2009 at 12:13 PM, asettico wrote:
> It requires the Tex package and I also installed html2text, but I still get
> the same error. Where is my mistake?
You need elinks to create the txt manual, not html2text -- it's used
for converting the html version to txt.
- Dominik
2009/9/16 asettico
> I get a vry long log file (more than 4600 lines) and it exits with
> status 2.
>
> It requires the Tex package and I also installed html2text, but I still get
> the same error. Where is my mistake?
> Thanks for any hint.
>
>
Pasting the log somewhere would be useful. W
Hi all,
I'm getting an error while building the plain text version of the manual.
I'm doing always the same:
mkdir build_manual
cd build_manual
../tools/configure --...
make manual-txt > manual-txt.log 2>&1
I get a vry long log file (more
Am Montag, den 20.10.2008, 15:55 +0200 schrieb Daniel Stenberg:
> On Mon, 20 Oct 2008, Bernhard Vodicka wrote:
>
> > I have the sources from SVN and a Linux build environment. When i try to
> > build the manual for the Cowon D2 this error occurs:
>
> I get a complet
On Mon, 20 Oct 2008, Bernhard Vodicka wrote:
I have the sources from SVN and a Linux build environment. When i try to
build the manual for the Cowon D2 this error occurs:
I get a completely different error. But instead of trying to figure out
exactly why that is, we can just consider the
Hi!
I have the sources from SVN and a Linux build environment.
When i try to build the manual for the Cowon D2 this error occurs:
,~
| make[1]: *** No rule to make target
| `/home/bernhard/Rockbox/rockbox-18846/d2_manual/max_language_size.h',
| needed by
| `/home/bernhard/Ro
> > Updated screenshot for H10-5GB recording screen, the previous one was
> > showing an illegal gain value
>
> Shouldn't this also go to 3.0?
right you are... I'll try to find a minute somewhere today
Peter
7;t this also go to 3.0?
Frank
> Modified:
>trunk/manual/main_menu/images/ss-while-recording-screen-128x128x16.png
>
> Modified:
> trunk/manual/main_menu/images/ss-while-recording-screen-128x128x16.png
> =
Dominik Riebeling wrote:
> On 5/10/07, Martin Arver <[EMAIL PROTECTED]> wrote:
>
>> Do you think we should use this approach for all features not
>> supported by a certain target? Like sw/hw-codec stuff, color display
>
>
> hmm, I think that would make the
On 5/10/07, Martin Arver <[EMAIL PROTECTED]> wrote:
Do you think we should use this approach for all features not
supported by a certain target? Like sw/hw-codec stuff, color display
hmm, I think that would make the manual somewhat torn, which isn't
good either. Maybe just ignore
On 5/10/07, Jerry Van Baren wrote:
...or you have a "not supported" chapter for the units that don't
support a particular feature. In the above example, for a unit
incapable of recording, Chapter 5 would become:
--
Chapter 5 Re
Martin Arver wrote:
I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
How about putting an a "This target does not have the capabilities to
" so we always have a chapter for everything and the numbers
stay constant...?
Nah, should we really? We do provide target specific manuals and i
think those should only include what the target supports without the
need to wri
I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure
I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure
It's already been a while, but I always wanted to reply on this topic, so ...
On 5/2/07, Martin Arver <[EMAIL PROTECTED]> wrote:
I think we can simplify certain parts of the manual, and move stuff around.
For one, i think the "root menu" could be described as early as in th
On 5/3/07, RaeNye <[EMAIL PROTECTED]> wrote:
A little OT here, but what do you think about a flash (or other semi-video
thingy) ~30 seconds promotion clip for RB?
That would be fun, but to be a little more on-topic, wouldn't an
(interactive) animation showing what happens after you have install
A little OT here, but what do you think about a flash (or other semi-video
thingy) ~30 seconds promotion clip for RB?
Neither a media designer nor a flash programmer, it's easy to suggest this,
but I can imagine parts, e.g., a series of supported platforms flying across
or the "Order now, just $0.0
After the main menu hit the repos and the fact that this is now the
first contact with Rockbox, I don't think I am alone in thinking that
the manual could use some restructuring.
A lot of problems users had in the past, was to understand the nature
of rockbox. E.g. that the filebrowser i
Hi devs,
finally we can build a html version of the manual. You need tex4ht
installed (http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html, most
linux distributions should have packages for this). Also, as the make
process changed a bit you need to reconfigure your manual build.
Afterwards you
cd my_manual
../tools/configure
Select platform (ie 9 for H1x0)
Select M for manual
Make
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED] On Behalf Of Anton Romanov
|Sent: 15 April 2006 20:05
|To: Rockbox development
|Subject: Manual
|
|how to build manual from
Not that I've already built the manual myself, but I thought you had to
select the manual with configure and then just make?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Anton Romanov
> Sent: Saturday, April 15, 2006 9:05
how to build manual from source?
cause 'make manual' just says
make[1]: Nothing to be done for `buildmanual'.
--
Mark Bright wrote:
OK... I had assumed that rockbox-devel would include everything... Yet
another lesson learned today :-)
That's our mistake, not yours. I'll fix that.
Linus
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED] On Behalf Of Linus
|Nielsen Feltzing
|Sent: 12 February 2006 12:38
|To: Rockbox development
|Subject: Re: Building Manual Fails - SDL Sim fails to Run
|
|Mark Bright wrote:
|>It was the 3rd attempt BTW befor
this step be present in the instructions
>
>
Yes, that would help a lot of users
>No... I assume from that remark that "cvs -z3
>-d:pserver:[EMAIL PROTECTED]:/cvsroot/rockbox co rockbox-devel" does
>not include the manual... Sorry - my bad
>
>
That sounds like a
above. It didn't occur to me that people would try to start it from
the Windows Explorer.
When I try to build the Manual it fails. What have I missed?
[EMAIL PROTECTED] ~/rockbox-devel
$ mkdir manual
[EMAIL PROTECTED] ~/rockbox-devel
$ cd manual
You have missed to checkout the manual from
L file was actually in
cygwin\usr\local\bin... Is there
A)some config required to avoid having to copy this file
B)should the build process copy this file automatically
C)Should this step be present in the instructions
|> $ make
|> make: *** /home/Boffin/rockbox-devel/manual/platform: No
Mark Bright wrote:
> I have been using the DevKit for some time to make my own build but
> recently ran into problems with the SDL Sim and Manual builds.
>
> To avoid getting embroiled in the middle of the current argument I
> decided to follow the dev's advice and I did the
Title: Building Manual Fails - SDL Sim fails to Run
I have been using the DevKit for some time to make my own build but recently ran into problems with the SDL Sim and Manual builds.
To avoid getting embroiled in the middle of the current argument I decided to follow the dev's advice
87 matches
Mail list logo
