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
Op 23-06-10 13:59, Maurus Cuelenaere schreef:
> I hacked up this patch which replaces LCD_{WIDTH,HEIGHT} with variables.
> I've only tested the Onda VX747 simulator without plugins, but
> everything except WPS seems to be working.
A newer version of this patch is now available at
http://www.rock
Op 07-09-10 16:22, Thomas Martitz schreef:
> 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
>
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
Hello Thomas,
I have created http://www.rockbox.org/wiki/PortingApplication. I hope this is
helpful. I've written all my experience down to it, but it may lack essential
information that I cannot think of right now. But luckily it's a wiki page
that I (and everyone else) can extend where needed.
On Mon, Aug 16, 2010 at 12:52 AM, Thomas Martitz <
thomas.mart...@student.htw-berlin.de> wrote:
> I have created http://www.rockbox.org/wiki/PortingApplication. I hope this
> is helpful. I've written all my experience down to it, but it may lack
> essential information that I cannot think of right
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
On 6 August 2010 10:53, Vladimir Pantelic wrote:
>
> Great work! could you provide an .apk for testing?
>
>
I expect that if you ask nicely in IRC then a build will be provided :)
Thomas Martitz wrote:
Hey chaps,
I'm a bit behind now with my report. But that's I've forgotten about it
because I made some very exciting since the last report.
I proceeded with my stripped-down Rockbox, but surprisingly it took me
only a few days to get the basic stuff working on Android. So
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 and understandable developers documentation
s
Hey chaps,
I'm a bit behind now with my report. But that's I've forgotten about it
because I made some very exciting since the last report.
I proceeded with my stripped-down Rockbox, but surprisingly it took me
only a few days to get the basic stuff working on Android. So I switched
to the
New thread as per request :)
Hello folks,
I'm done with converting the paths so that it works with
/usr/local/{bin,lib,share} (and any $PREFIX/--prefix). This is, for now,
the last piece of the SDL app and will helpful for the other ports too.
I'll upload the patch for your review to FS#11234
Hello again,
first of all: sorry for delay.
I finally found a bit time to do some work again, although I'm in the
middle of the exam period. I committed a buildzip.pl change which can
install RaaA into /usr/local/{bin,lib,share}.
I have also made some progress in making Rockbox work with tha
Am 06.07.2010 00:26, schrieb Thomas Martitz:
> Hello people,
>
> [...]
>
> I also looked into Android development a bit and did some Hello World
> experiments on my phone. I haven't looked deeply into the NDK yet. I
> cannot say much yet how hard the android port will be.
Hello Thomas,
you might
Hello people,
I have made no real progress this week. Currently it's hard for me to do
any Rockbox work because I need to attend in 4 experimental/practical
courses per week, including working out a written protocol for each. And
I still have all the lectures. The FIFA world cup isn't making t
Op 29-06-10 11:45, Alex Bennee schreef:
> On 29 June 2010 09:15, Thomas Martitz
> wrote:
>> Am 29.06.2010 00:24, schrieb Maurus Cuelenaere:
>>> Do you have a branch containing the same commits but not merged with
>>> master (this makes it hard to find your work)?
>>>
>>>
>> No, but you can rebase
On 29 June 2010 09:15, Thomas Martitz
wrote:
> Am 29.06.2010 00:24, schrieb Maurus Cuelenaere:
>>
>> Do you have a branch containing the same commits but not merged with
>> master (this makes it hard to find your work)?
>>
>>
>
> No, but you can rebase to master locally (or grep for all commits co
Am 29.06.2010 00:24, schrieb Maurus Cuelenaere:
Do you have a branch containing the same commits but not merged with master
(this makes it hard to find your work)?
No, but you can rebase to master locally (or grep for all commits
containing my name).
Best regards.
Op 28-06-10 18:39, Thomas Martitz schreef:
> Anyway, I've put a patch to FS#11234 (you can also browse the tree at
> http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/gsoc-app-target) which
> adds an application target that compiles and runs. There's a small kludge in
> that you need to run
Hello,
I haven't been able to do very much lately. The uni workload is rather
high these days, I blame their schedule to put the intensive stuff at
the end of the semester.
Anyway, I've put a patch to FS#11234 (you can also browse the tree at
http://repo.or.cz/w/kugel-rb.git/shortlog/refs/he
On Thu, Jun 24, 2010 at 02:42:36PM +0100, Alex Bennee wrote:
> On 23 June 2010 10:25, Alex Parker wrote:
> > On 22 June 2010 18:46, Daniel Stenberg wrote:
> >> On Tue, 22 Jun 2010, Thomas Martitz wrote:
> >>> For a redistributable .zip (if we want that) we probably could stick to
> >>> the single
On 23 June 2010 10:25, Alex Parker wrote:
> On 22 June 2010 18:46, Daniel Stenberg wrote:
>> On Tue, 22 Jun 2010, Thomas Martitz wrote:
>>> For a redistributable .zip (if we want that) we probably could stick to
>>> the single .rockbox approach, but for compiling from source and for
>>> distribut
Am 23.06.2010 11:26, schrieb Maurus Cuelenaere:
I was wondering, how do you plan to handle the different screen
dimensions at runtime? For some platforms this isn't needed (Maemo only
has N900), but for others this is a requirement (Android, WinCE,
iPhoneOS, ..).
I didn't have plans yet :)
Björn Stenberg wrote:
Maurus Cuelenaere wrote:
I was wondering, how do you plan to handle the different screen dimensions at
runtime? For some platforms this
isn't needed (Maemo only has N900), but for others this is a requirement
(Android, WinCE, iPhoneOS, ..).
Android supports resolution s
On Wed, Jun 23, 2010 at 11:00 AM, Thomas Martitz
wrote:
> When later? As I said, that thing is the only real (as I see it, others
> might disagree) issue left for the SDL app. Do you mean I should work on the
> android port before the installation thing?
>
> Best regards.
>
I have not tried the s
Op 23-06-10 11:33, Jonathan Gordon schreef:
> On 23 June 2010 19:26, Maurus Cuelenaere wrote:
>
>> Op 22-06-10 18:39, Thomas Martitz schreef:
>>
>>> Hi guys,
>>>
>>> again I'm busy due to uni stuff; I got a lot of practical and
>>> laboratory experiment courses lately. But slowly I'm getti
Op 23-06-10 11:47, Björn Stenberg schreef:
> Maurus Cuelenaere wrote:
>
>> I was wondering, how do you plan to handle the different screen
>> dimensions at runtime? For some platforms this isn't needed (Maemo only
>> has N900), but for others this is a requirement (Android, WinCE,
>> iPhoneOS, .
Maurus Cuelenaere wrote:
> I was wondering, how do you plan to handle the different screen
> dimensions at runtime? For some platforms this isn't needed (Maemo only
> has N900), but for others this is a requirement (Android, WinCE,
> iPhoneOS, ..).
Android supports resolution specific resources, s
On 23 June 2010 19:26, Maurus Cuelenaere wrote:
> Op 22-06-10 18:39, Thomas Martitz schreef:
>> Hi guys,
>>
>> again I'm busy due to uni stuff; I got a lot of practical and
>> laboratory experiment courses lately. But slowly I'm getting
>> somewhere. I'm currently preparing to commit the (first) R
Op 22-06-10 18:39, Thomas Martitz schreef:
> Hi guys,
>
> again I'm busy due to uni stuff; I got a lot of practical and
> laboratory experiment courses lately. But slowly I'm getting
> somewhere. I'm currently preparing to commit the (first) RaaA target.
> It runs, but there's a few kludges which I
On 22 June 2010 18:46, Daniel Stenberg wrote:
> On Tue, 22 Jun 2010, Thomas Martitz wrote:
>
> For a redistributable .zip (if we want that) we probably could stick to
>> the single .rockbox approach, but for compiling from source and for
>> distributions/windows installers we want something more
Am 23.06.2010 10:52, schrieb Nils Wallménius:
On Tue, Jun 22, 2010 at 6:46 PM, Daniel Stenberg wrote:
IMHO, binary RaaA packages should use "native" packaging and installing
methods. That means .debs and .rpms on Linux and installer-things on
Windows.
--
/ daniel.haxx.se
I agree
On Tue, Jun 22, 2010 at 6:46 PM, Daniel Stenberg wrote:
> IMHO, binary RaaA packages should use "native" packaging and installing
> methods. That means .debs and .rpms on Linux and installer-things on
> Windows.
>
> --
>
> / daniel.haxx.se
>
I agree with that but i think that can come at a later
On Tue, 22 Jun 2010, Thomas Martitz wrote:
For a redistributable .zip (if we want that) we probably could stick to the
single .rockbox approach, but for compiling from source and for
distributions/windows installers we want something more application typical
I think.
IMHO, binary RaaA packag
Hi guys,
again I'm busy due to uni stuff; I got a lot of practical and laboratory
experiment courses lately. But slowly I'm getting somewhere. I'm
currently preparing to commit the (first) RaaA target. It runs, but
there's a few kludges which I want to sort out before. After that, I
should wo
"Frank Gevaerts" wrote:
>Hi,
>
>Can people try to use email programs that use proper In-Reply-To and/or
>References headers, so threading doesn't get broken? Apparently "K-9 Mail
>for Android" doesn't include them.
Should be fixed now.
--
Maurus Cuelenaere
Hi,
Can people try to use email programs that use proper In-Reply-To and/or
References headers, so threading doesn't get broken? Apparently "K-9 Mail
for Android" doesn't include them.
Frank
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code
"Jonathan Gordon" wrote:
>On 15 June 2010 01:07, Maurus Cuelenaere wrote:
>>
>>
>> "Bryan Childs" wrote:
>>
>>>On 14 June 2010 15:30, Maurus Cuelenaere wrote:
>>>
and you only have access to the SD card if the phone's not rooted (which is
mounted at /sdcard).
>>>Huh?
On 15 June 2010 01:07, Maurus Cuelenaere wrote:
>
>
> "Bryan Childs" wrote:
>
>>On 14 June 2010 15:30, Maurus Cuelenaere wrote:
>>
>>>
>>> and you only have access to the SD card if the phone's not rooted (which is
>>> mounted at /sdcard).
>>>
>>>
>>Huh?
>>
>>My phone is rooted, and I have acces
On 14 June 2010 16:07, Maurus Cuelenaere wrote:
>
> Hmm I misworded that :)
> What I meant was: apps only have access to /sdcard/* unless rooted AFAIK.
>
Yes, Zagor just enlightened me as to what you meant ;)
They do have access to some kind of local (and mutual agreed shared) storage
> (to sto
"Bryan Childs" wrote:
>On 14 June 2010 15:30, Maurus Cuelenaere wrote:
>
>>
>> and you only have access to the SD card if the phone's not rooted (which is
>> mounted at /sdcard).
>>
>>
>Huh?
>
>My phone is rooted, and I have access to the SDCard...
>I had access to it before it was rooted too
On 14 June 2010 15:30, Maurus Cuelenaere wrote:
>
> and you only have access to the SD card if the phone's not rooted (which is
> mounted at /sdcard).
>
>
Huh?
My phone is rooted, and I have access to the SDCard...
I had access to it before it was rooted too - for the music player app, it's
the
On 15 June 2010 00:53, Thomas Martitz
wrote:
> Am 14.06.2010 16:40, schrieb Rafaël Carré:
>>
>> Well I just understood this after hitting send button :)
>>
>> I think we could introduce a CONFIG_DIR to store configs/high scores in
>> a separate directory. But then that would break compatibility wi
Am 14.06.2010 16:40, schrieb Rafaël Carré:
Well I just understood this after hitting send button :)
I think we could introduce a CONFIG_DIR to store configs/high scores in
a separate directory. But then that would break compatibility with old
config / scores unless people move the files themselv
On Mon, 14 Jun 2010 16:29:31 +0200
Thomas Martitz wrote:
> Am 14.06.2010 16:23, schrieb Rafaël Carré:
> > On Mon, 14 Jun 2010 16:14:59 +0200
> > Thomas Martitz wrote:
> >
> >
> >> b) Where to install it? /usr/local/bin (or C:\Program
> >> Files\Rockbox) comes into my mind, but then there's t
On Tue, Jun 15, 2010 at 12:28:36AM +1000, Jonathan Gordon wrote:
> for b we should at least skirt the issue and put the executable next
> to .rockbox/ and then the paths are obvious (so it is portable
> app). I guess OS dependant paths do make sense, but do we really
> need to worry about that
On Mon, 14 Jun 2010, Thomas Martitz wrote:
a) We collected some ideas two weeks ago but we didn't manage to find a
consensus I think. I still think exposing the full / is unnecessary but OTOH
I wouldn't want to limit users.
I think / by default and a command line argument to set another one b
"Thomas Martitz" wrote:
>b) Where to install it? /usr/local/bin (or C:\Program Files\Rockbox)
>comes into my mind, but then there's the problem of not having write
>access in the installation routine. Installing somewhere into $HOME
>seems weird. Another idea would be installing the binaries
Am 14.06.2010 16:23, schrieb Rafaël Carré:
On Mon, 14 Jun 2010 16:14:59 +0200
Thomas Martitz wrote:
b) Where to install it? /usr/local/bin (or C:\Program Files\Rockbox)
comes into my mind, but then there's the problem of not having write
access in the installation routine.
What do y
On 15 June 2010 00:14, Thomas Martitz
wrote:
> I'm sorry that I left out the last week's report, the uni kept me busy this
> week (forunately at least the devcon attenders are aware of my progress).
> But it paid of, my Rockbox presentation went really really well :P
>
> Back to the topic: My proj
On Mon, Jun 14, 2010 at 04:14:59PM +0200, Thomas Martitz wrote:
> I'm sorry that I left out the last week's report, the uni kept me busy
> this week (forunately at least the devcon attenders are aware of my
> progress). But it paid of, my Rockbox presentation went really really
> well :P
>
>
On Mon, 14 Jun 2010 16:14:59 +0200
Thomas Martitz wrote:
> b) Where to install it? /usr/local/bin (or C:\Program Files\Rockbox)
> comes into my mind, but then there's the problem of not having write
> access in the installation routine.
What do you mean ?
> Another idea would be
> installing
I'm sorry that I left out the last week's report, the uni kept me busy
this week (forunately at least the devcon attenders are aware of my
progress). But it paid of, my Rockbox presentation went really really
well :P
Back to the topic: My project is in a good shape I think. I can actually
bui
On 03.06.2010 17:35, Mike Giacomelli wrote:
There is an android media player already using our codecs. I've exchanged
Which player is this out of interest?
http://code.google.com/p/andless/
Nice Acknowledgments here ...
http://code.google.com/p/andless
>
> There is an android media player already using our codecs. I've exchanged
>
> Which player is this out of interest?
>
>
http://code.google.com/p/andless/
_
The New Busy is not the old busy
On 2 June 2010 18:58, Mike Giacomelli wrote:
>
> There is an android media player already using our codecs. I've exchanged
>
Which player is this out of interest?
Bryan
Op 02-06-10 19:25, Magnus Holmgren schreef:
> On 2010-06-02 16:33, Dave Chapman wrote:
>
>> Thomas Martitz wrote:
>>> I think most of us (including me) prefer andriod. I personally
>>> *strongly* prefer it since I had an HTC legend in my hands :) Is
>>> anyone uncomfortable with that?
>>
>> It's yo
> But doesn't Android have the additional complication of requiring you to
> port RaaA as a native C library and then implement the UI in Java? What
> about audio output? Can a native C library play audio, or will that
> also require a Java layer?
There is an android media player already usin
Am 02.06.2010 16:49, schrieb Jonathan Gordon:
On 3 June 2010 00:33, Dave Chapman wrote:
Thomas Martitz wrote:
I think most of us (including me) prefer andriod. I personally *strongly*
prefer it since I had an HTC legend in my hands :) Is anyone uncomfortable
with that?
It's
On 2010-06-02 16:33, Dave Chapman wrote:
Thomas Martitz wrote:
I think most of us (including me) prefer andriod. I personally
*strongly* prefer it since I had an HTC legend in my hands :) Is
anyone uncomfortable with that?
It's your project, so ultimately I think the choice is yours - you
sho
On 6/2/2010 7:53 AM, Mike Giacomelli wrote:
While this is something I have wanted for a while, I don't think its
related
enough to the RaaA project and should probably be implemented later once
underlying app infrastructure is in place.
Well, one point I tried to make earlier on was "try to p
On 3 June 2010 00:33, Dave Chapman wrote:
> Thomas Martitz wrote:
>>
>> I think most of us (including me) prefer andriod. I personally *strongly*
>> prefer it since I had an HTC legend in my hands :) Is anyone uncomfortable
>> with that?
>
> It's your project, so ultimately I think the choice is y
On Wed, 2 Jun 2010 10:27:14 -0400
Robert Menes wrote:
> I vote for Android! (Sent from my myTouch 3G (HTC Magic))
>
> --Robert
Am I the only one still using a computer ? :(
--
Rafaël Carré
signature.asc
Description: PGP signature
Thomas Martitz wrote:
I think most of us (including me) prefer andriod. I personally
*strongly* prefer it since I had an HTC legend in my hands :) Is anyone
uncomfortable with that?
It's your project, so ultimately I think the choice is yours - you
should port RaaA to whatever interests you.
I vote for Android! (Sent from my myTouch 3G (HTC Magic))
--Robert
On Jun 1, 2010 1:29 PM, "Thomas Martitz" <
thomas.mart...@student.htw-berlin.de> wrote:
Am 01.06.2010 19:08, schrieb Thomas Martitz:
>
>
> It's possible that I overlooked some relevant #ifdef. However, I think I
am more success
On 2 June 2010 22:53, Mike Giacomelli wrote:
>
>> Maybe one option should be compiling Rockbox as a console app (which
>> might ease porting it to such a charcell device)?
>
> While this is something I have wanted for a while, I don't think its
> related
> enough to the RaaA project and should pro
> Maybe one option should be compiling Rockbox as a console app (which
> might ease porting it to such a charcell device)?
While this is something I have wanted for a while, I don't think its related
enough to the RaaA project and should probably be implemented later
onceunderlying app infra
On Wed, 2 Jun 2010, Thomas Martitz wrote:
I wonder why there seems to be interest support dead technologies.
Charcell displays are not "dead technologies", they are "dirt-cheap"
technologies.
Please consider to use a respectful tone when arguing.
--
/ daniel.haxx.se
Am 02.06.2010 11:15, schrieb Paul Louden:
Maybe one option should be compiling Rockbox as a console app (which
might ease porting it to such a charcell device)?
Unfortunately it's not as easy as adding a simple option. You'd need to
add a driver for it.
I wonder why there seems to be interes
On 6/2/2010 4:10 AM, Thomas Martitz wrote:
Porting RaaA to it is your job then :)
However working with such specific devices is not the goal of RaaA.
The purpose is to port it to *OS platforms* so that it runs on any
machine the OS runs on. And it's not realistic that there will be an
OS whi
Am 02.06.2010 11:01, schrieb Jonathan Gordon:
I've been wanting to use
http://www.crystalfontz.com/product/CFA634-NFA-KS forever and RaaA
would make it easy, so yeah assumptions are bad.
It would be helpful if there was a wiki page which listed every
#define which depends on (or negates) another,
On 2 June 2010 10:01, Jonathan Gordon wrote:
>
> I've been wanting to use
> http://www.crystalfontz.com/product/CFA634-NFA-KS forever and RaaA
> would make it easy, so yeah assumptions are bad.
>
For god's sake why?!?
On 2 June 2010 18:50, Thomas Martitz
wrote:
> Am 02.06.2010 02:48, schrieb Jonathan Gordon:
>
> Hold on... dont assume anything about #defines and IF you do then
> document them somewhere. HAVE_RECORDING is very possible with RaaA, as
> is HAVE_LCD_CHARCELL (!)
>
>
> Possible, sure, but the ports
Am 02.06.2010 02:48, schrieb Jonathan Gordon:
Hold on... dont assume anything about #defines and IF you do then
document them somewhere. HAVE_RECORDING is very possible with RaaA, as
is HAVE_LCD_CHARCELL (!)
Possible, sure, but the ports I'm working on won't have that. I find
HAVE_LCD_CHA
On 2 June 2010 03:08, Thomas Martitz
wrote:
> I considered them not relevant if they met one of the following points:
>
> * when used in conjuction with a define RaaA will most certainly not define,
> e.g. CONFIG_CODEC != SWCODEC, HAVE_RECORDING, SANSA_E200, !USB_NONE,
> HAVE_LCD_CHARCELL
> * enab
On Tue, Jun 01, 2010 at 07:28:16PM +0200, Thomas Martitz wrote:
> I forgot to add that once the above is finished I consider my work for
> the mid-term work finished, after that a port to a mobile
> platform/device would follow. Again, if anyone disagrees with that (that
> my mid-term work is
On Tue, 01 Jun 2010 19:28:16 +0200
Thomas Martitz wrote:
> Speaking if it, I would like to by a smartphone from the first Google
> money (in case they don't put a nexus one into the welcome
> package ;) ) which will arrive in about a week. I would really like
> to get the decision on which platf
On Tue, Jun 1, 2010 at 8:54 PM, Bryan Childs wrote:
>
>
> On 1 June 2010 18:39, Maurus Cuelenaere wrote:
>
>> "Thomas Martitz" wrote:
>>
>> >I think most of us (including me) prefer andriod. I personally
>> >*strongly* prefer it since I had an HTC legend in my hands :) Is anyone
>> >uncomforta
On 1 June 2010 18:39, Maurus Cuelenaere wrote:
> "Thomas Martitz" wrote:
>
> >I think most of us (including me) prefer andriod. I personally
> >*strongly* prefer it since I had an HTC legend in my hands :) Is anyone
> >uncomfortable with that?
>
> I'm in favor! (sent from my G1)
>
> Put me down
"Thomas Martitz" wrote:
>Am 01.06.2010 19:08, schrieb Thomas Martitz:
>>
>> It's possible that I overlooked some relevant #ifdef. However, I think
>> I am more successful in spotting them when I know begin to create an
>> application target without defining SIMULATOR. And this is my plan for
Am 01.06.2010 19:08, schrieb Thomas Martitz:
It's possible that I overlooked some relevant #ifdef. However, I think
I am more successful in spotting them when I know begin to create an
application target without defining SIMULATOR. And this is my plan for
the next week or 2.
I forgot to
Hello folks,
this week I started (and mostly finished) the conversion of #ifdef
SIMULATOR to #if (CONFIG_PLATFORM & PLATFORM_HOSTED) (and the like).
I was quite surprised how little individual #ifdefs I actually
converted. In fact, I could ignore most because they are not relevant
for RaaA (
On Mon, May 24, 2010 at 01:33:03PM +0200, Thomas Martitz wrote:
> 1) io.c, currently the simulator hides the rest of the filesystem and
> only shows the current working dir in the file browser (by wrapping file
> I/O functions). I think we don't want that for RaaA but I also doubt we
> want t
On Wed, May 26, 2010 at 8:02 PM, Thomas Martitz
wrote:
> I don't think the --root option will always be available, not on a
> smartphone anyway. You should double click the Rockbox icon and it should
> just work (and not mess with command line options).
You could just use a RaaA specific configur
> I don't think the --root option will always be available, not on a
> smartphone anyway. You should double click the Rockbox icon and it should
> just work (and not mess with command line options).
Indeed, I was merely pointing out that a single root is fine (IMHO, again).
pondlife
On 5/26/2010 1:02 PM, Thomas Martitz wrote:
Am 26.05.2010 08:31, schrieb pondlife:
I don't think the --root option will always be available, not on a
smartphone anyway. You should double click the Rockbox icon and it
should just work (and not mess with command line options).
Best regards.
Am 26.05.2010 08:31, schrieb pondlife:
FWIW, I use the simulator dailty as a player. I just use the --root
command-line option to set a good starting point (which is a UNC path to
remote storage in my case).
IMHO, I think a single root directory (and the entire tree beneath it) would
be fine -
FWIW, I use the simulator dailty as a player. I just use the --root
command-line option to set a good starting point (which is a UNC path to
remote storage in my case).
IMHO, I think a single root directory (and the entire tree beneath it) would
be fine - no need to worry too much about "multi
On 27 May 2010 01:01, Thomas Martitz
wrote:
> Am 26.05.2010 16:13, schrieb Jonathan Gordon:
>
> I tihnk RaaA should use the current directory as / (unless a root
> option is given on the command line). being able to mount virtual
> drives from command line args would be nice also.
>
>
> The curren
Am 26.05.2010 16:13, schrieb Jonathan Gordon:
I tihnk RaaA should use the current directory as / (unless a root
option is given on the command line). being able to mount virtual
drives from command line args would be nice also.
The current directory only will probably not work, because an app
"Thomas Martitz" wrote:
>Am 26.05.2010 01:00, schrieb Maurus Cuelenaere:
>> Op 25-05-10 23:12, Peter D'Hoye schreef:
>>
>>>
1) I don't really see why you would want to limit the file browser to
just a few dirs, rockbox has traditionally been about user freedom so
i woul
On 26 May 2010 23:58, Thomas Martitz
wrote:
> Am 26.05.2010 01:00, schrieb Maurus Cuelenaere:
>>
>> Op 25-05-10 23:12, Peter D'Hoye schreef:
>>
>>>
>>>
1) I don't really see why you would want to limit the file browser to
just a few dirs, rockbox has traditionally been about user fr
Am 26.05.2010 01:00, schrieb Maurus Cuelenaere:
Op 25-05-10 23:12, Peter D'Hoye schreef:
1) I don't really see why you would want to limit the file browser to
just a few dirs, rockbox has traditionally been about user freedom so
i would suggest letting them browse the entire fs.
Op 25-05-10 23:12, Peter D'Hoye schreef:
>
>> 1) I don't really see why you would want to limit the file browser to
>> just a few dirs, rockbox has traditionally been about user freedom so
>> i would suggest letting them browse the entire fs.
>>
>>
> On an mp3 player, your music probably sits i
1) I don't really see why you would want to limit the file browser to
just a few dirs, rockbox has traditionally been about user freedom so
i would suggest letting them browse the entire fs.
On an mp3 player, your music probably sits in a /music/ location, but on
a PC or advanced mobile, i
On Mon, May 24, 2010 at 1:33 PM, Thomas Martitz
wrote:
> Hi guys,
>
> I've been quite busy this week and so I haven't really managed to get
> further.
>
> But I have looked into what's left in uisimulator/common and a few questions
> arised which I would like to discuss a bit about:
>
> 1) io.c, c
Hi guys,
I've been quite busy this week and so I haven't really managed to get
further.
But I have looked into what's left in uisimulator/common and a few
questions arised which I would like to discuss a bit about:
1) io.c, currently the simulator hides the rest of the filesystem and
only
Sorry for being a day late, but here's my second update.
In the past week I, with the invaluable help of other people, fixed some
quirks after the 3 huge commits of the last week. Furthermore I moved
uisimulator/sdl/*.[ch] into the target tree
(firmware/target/hosted/sdl), effectively making i
Hello folks,
this is my first weekly status report. I hope I can make it weekly, I'll
definitely try to even if there's no progress.
I committed 3 patches (r25843, r25843 and r25850) which I considered
needed for a proper application, i.e. so that we can ignore our OS bits
but rely on the ta
99 matches
Mail list logo
