On Mon, Oct 28, 2019, 3:56 PM Franklin Wei via rockbox-dev <
rockbox-dev@cool.haxx.se> wrote:
> All,
>
> There has been some discussion between William and I on IRC regarding a
> 3.15 release in the near future. We are currently aiming for a November 15
> release date. I will be serving as
On 6 July 2014 05:28, Richard Quirk richard.qu...@gmail.com wrote:
Please let me know if you find any crashes - or even better if this fixes
any crashes with your troublesome skins!
I didn't see any crashes, but the clock_lock2 theme I use on the WPS
didn't work any more. This is on the
Hi
On 19 June 2014 16:19, Thomas Orgis thomas-fo...@orgis.org wrote:
1. Is there an API call to get a file selection dialog or should the
plugin instead register as handler/codec for tempo map files to be started
from the main files menu? Excuse me for not finding that answer
myself, I
On 18 June 2014 16:25, Thomas Martitz ku...@rockbox.org wrote:
I think we should still have a formal freeze period with RC builds. There
are some open bugs that we can address too, perhaps. Alex is inactive so I
don't think we have a release manager.
Considering the state of the project
So everyone is agreed on melbourne then?
On 4 April 2014 04:35, Tomasz Moń deso...@gmail.com wrote:
I'll definitely be there!
On 2 December 2013 07:49, Thomas Martitz ku...@rockbox.org wrote:
Hey folks,
this is not the usual kind of Ladies and Gentlemen mail. Instead of a new
port I have managed to get Rockbox play sound in a new environment.
What I am working on is to to detach the playback core (including
On 12 March 2013 02:42, Amaury Pouly amaury.po...@gmail.com wrote:
Hi all,
As you know, many of our targets features a soft-lock in the WPS which
locks all the keys except the unlock key, to prevent accidental changes.
This is a very useful feature but recent targets like the Fuze+ have shown
On 20 February 2013 22:34, Thomas Martitz ku...@rockbox.org wrote:
I start with list.c because that's the most extensive user, but other
screens can follow easily, e.g. various plugins. The API that I suggest can
print the whole line (indent, spacing, icon and text) in a single call so
it's
On 18 February 2013 07:40, Thomas Martitz ku...@rockbox.org wrote:
Am 16.02.2013 10:46, schrieb Jonathan Gordon:
On 16 February 2013 08:30, Thomas Martitz ku...@rockbox.org mailto:
ku...@rockbox.org wrote:
Hello guys,
I'm working on a new line print API in apps that's supposed
On 16 February 2013 08:30, Thomas Martitz ku...@rockbox.org wrote:
Hello guys,
I'm working on a new line print API in apps that's supposed to replaces
most of lcd_puts_* and lcd_putsxy_*.
The lcd_puts* became really messy and it still doesn't support scrolling
properly (not at all for
Hi Mike,
Can you please have a look at FS#12797 when you get a chance? It looks
like da6cebb6b0b17b4a75a2bd4f51b7cf70b5dafe40 broke radio art (found by
bisecting and testing in the fuzev2 sim).
Thanks
Jonathan
On 6 October 2012 05:47, Richard Quirk richard.qu...@gmail.com wrote:
A couple of patches to do with the default sleep duration setting, the first
adds a set_sleeptimer_duration function that will be used in the second.
http://gerrit.rockbox.org/327
http://gerrit.rockbox.org/328
My
On 22 August 2012 00:50, Bertrik Sikken bert...@sikken.nl wrote:
The archos recorder build has tipped over the limit for size, and now the
autobuild always fails.
The tipping point was commit bd6e6ed but the code has been growing
steadily so I wouldn't say this particular commit is any more
On 3 August 2012 23:51, Jonas Wielicki j.wieli...@sotecware.net wrote:
Hi all,
I'm (still *sigh*) hunting my SSD issues on iriver (as posted previously
on the list[1][2]). I think it basically reduces to a “have you tried
turning it off and on again” fix, because somehow the SSD seems to get
On 28 March 2012 20:49, Torne Wuff to...@wolfpuppy.org.uk wrote:
Hi folks,
I would like to propose that we change our terminology used to
describe the builds and releases, on the website and in Rockbox
Utility. Currently we talk about release and current build a lot,
and this confuses users
Hi,
This wasnt caught when the sleep timer changes were commited, and its
not really a big deal but it should be changed.
IIUC the sleep timer is now broken into a few different settings:
1) set timer on boot
2) restart timer on keypress
3) start the timer with the chosen minutes value
On 28 March 2012 01:05, Nick Peskett rock...@peskett.co.uk wrote:
Unfortunately this has been the case with the callback since 2007;
http://svn.rockbox.org/viewvc.cgi/trunk/apps/menus/main_menu.c?view=diffpathrev=30777r1=12548r2=12549
As you move through the menu items the sleep timer
On 28 February 2012 15:22, Sean Bartell wingedtachik...@gmail.com wrote:
Hi, everyone,
I realize I all but disappeared last summer when GSoC ended, and I'm sorry for
leaving my work unfinished. I've spent some more time on it, and completed the
patches that create librbcodec[0].
I think
Hi all,
Please remember we have mostly switched to gerrit for patch tracking
and would like to only use flyspray for bugs. If your patches
(translations especially) are submitted to gerrit it is much more
likely they will be merged quickly (they can be done wih a single
click from the website
On 2 March 2012 09:56, Jonathan Gordon jdgo...@gmail.com wrote:
Hi all,
Please remember we have mostly switched to gerrit for patch tracking
and would like to only use flyspray for bugs. If your patches
(translations especially) are submitted to gerrit it is much more
likely
On 26 February 2012 20:53, Yohan LEE-TIN-YIEN
yohan.leetiny...@gmail.com wrote:
Please download for your targets and use it for a bit to see if there
is any issues with the LCD (redrawing, screen updates, etc).
I've been testing on Sansa Clip+ for 2 days now, and basically what I
experienced
Hi all,
http://gerrit.rockbox.org/r/#/c/120/ changes the way lcd drivers work
internally and every single target needs testing (or at least a few to
make sure it probably works for all of them).
gevaerts has kindly built and hosted builds at
http://rockbox.hostname.be/lcd-test/
Please download
On 6 January 2012 00:16, Jean-Louis Biasini jlbias...@gmail.com wrote:
Hi,
Best Regards,
Jean-Louis Biasini
The biggest issue with PLA is that quite a few of the plugins use the
same button loop for their menus and their actual game button
handling. That makes PLA unusable because buttons
On 3 January 2012 15:12, austin galloway even...@gmail.com wrote:
ok i have rockbox on my ipod video , and when i turn it on it has boot menu
, with turnoff button , rockbox , then emor console , settings, how do i
boot the original firmware ,ur directions on manual dont help because the
apple
On 22 December 2011 00:31, Nick Peskett rock...@peskett.co.uk wrote:
The root of what I'd like to change; only clock related options having a
stonking great clock embedded at top of the menu, all non-RTC options having
a permanent home.
yeah, the system settings submenu :)
On 19 December 2011 04:39, Thomas Martitz ku...@rockbox.org wrote:
Am 15.12.2011 00:21, schrieb Mike Giacomelli:
The alternative I think is to keep both together indefinitely while
accepting that people may not want to upgrade from what they're
already running. I think this is a bad way
On 17 December 2011 15:57, Scott Berry scottbb1...@gmail.com wrote:
Hey all devs,
I am going to begin work on the fm presets. A couple of questions is there
any way that there could be a branch made for just uploading presets like
you do the actual code and also is there any way we could
This is exactly what we don't want to do!
On 16 December 2011 07:58, mai...@svn.rockbox.org wrote:
Date: 2011-12-15 21:58:14 +0100 (Thu, 15 Dec 2011)
New Revision: 31296
Log Message:
Add conditionals for functions only needed on SWCODEC targets.
Modified:
trunk/apps/metadata/id3tags.c
On 15 December 2011 10:58, Rafaël Carré fun...@videolan.org wrote:
Hello,
Le Wed, 14 Dec 2011 18:21:42 -0500,
Mike Giacomelli giac2...@hotmail.com a écrit :
Advantages:
***Greatly simplify large parts of the code for SWCODEC targets (see
JdGordon's forum posts in rockbox general)
So, my
On 15 December 2011 12:50, Boris Gjenero boris.gjen...@gmail.com wrote:
Apparently, there are few HWCODEC users, and I'm not sure if any developers
regularly use current builds on HWCODEC targets. Because of that, there
isn't much focus on improving things for HWCODEC.
On this point, I
On 30 November 2011 07:23, Thomas Jarosch t...@simonv.com wrote:
Hi,
I've just given rockbox 3.10RC0 a spin and I really like
the way it improved on touchscreen targets like the Nokia N900.
This is probably thanks to kugel's list spacer patch.
One small thing lacking for a nice
Please don't add special actions for a single device. We try to make
all rockbox targets consistant with eachother so anyone picking up an
ipod immediately knows how to use it if they are coming from a clip.
Not only that, I'm very suspicious about how you plan on getting all
the standard buttons
On 28 November 2011 11:44, Mike Giacomelli giac2...@hotmail.com wrote:
Alright does someone want to help me with that? Zip is 96x96 color. Fuze+
is the same gigabeat (320 x 240).
Mike
Done, though we need target images for the table
On 16 November 2011 18:37, Thomas Martitz ku...@rockbox.org wrote:
Am 16.11.2011 05:33, schrieb Jonathan Gordon:
Hey all,
Does anyone know why http://www.rockbox.org/tracker/task/5111 is not in
svn?
Jonathan
Last time I looked I complained that it didn't integrate with the software
Hey all,
Does anyone know why http://www.rockbox.org/tracker/task/5111 is not in svn?
Jonathan
On 14 November 2011 01:09, Frank Gevaerts fr...@gevaerts.be wrote:
On Wed, Nov 09, 2011 at 12:17:02AM +1100, Jonathan Gordon wrote:
I'm not entirely sure what to do about the conversion macros. I am
going to keep the OFFSETTYPE() one (though open to a better name)
because it is helpful
On 8 November 2011 22:58, Thomas Martitz ku...@rockbox.org wrote:
Am 07.11.2011 14:54, schrieb Magnus Holmgren:
I agree that the macros are a bit long. Also, there are no _ chars to
separate things, making them a little harder to read. What about changing
SKINOFFSETTOPTR to SKIN_TO_POINTER
On 9 November 2011 01:06, Magnus Holmgren magnus...@gmail.com wrote:
On Tue, Nov 8, 2011 at 14:17, Jonathan Gordon jdgo...@gmail.com wrote:
Well,
I honestly didnt think it would be this simple! Attached is the
changes removing all dynamic pointers from the skin engine!
One question: Since
On 9 November 2011 01:12, Michael Chicoine mc2...@gmail.com wrote:
On Tue, Nov 8, 2011 at 7:17 AM, Jonathan Gordon jdgo...@gmail.com wrote:
Testing is pretty much: Apply and run your themes. If it works there
should be no difference at all.
A quick test on e200v1 with cabbiev2 (r30933
Test builds are available at http://jdgordon.info/rockbox/skintestbuilds/output/
On 9 November 2011 09:01, Jonathan Gordon jdgo...@gmail.com wrote:
On 9 November 2011 01:12, Michael Chicoine mc2...@gmail.com wrote:
On Tue, Nov 8, 2011 at 7:17 AM, Jonathan Gordon jdgo...@gmail.com wrote
Hi all,
I've just created the 3.10 release branch. To check it out, run:
svn co svn://svn.rockbox.org/rockbox/branches/v3_10 rockbox-3.10
This means that trunk is again free for regular development. However,
please don't be afraid to concentrate on bugs for the time being, and
maybe don't do
Hi all,
The only long term solution to the issue of the skin buffer size is to
completly redo how the skin engine uses its buffer, to that end I have
just started the rather large task of replacing every pointer in it to
an offset into the (currently) shared buffer which is then turned back
into a
On 7 November 2011 01:47, Thomas Martitz ku...@rockbox.org 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
Hi all,
So I've been working on this patch for a while, and when I started I
didnt really intend on pushing for this to get committed, but now it
is pretty much finished I feel that it would be a shame if it isnt as
it fixes pretty much everyones complaint with the menus and
quickscreen (and adds
On 1 November 2011 22:39, Peter D'Hoye peter.dh...@telenet.be wrote:
What this does it add a new menu item Shortcuts to the end of the
menu which is populated from /.rockbox/shortcuts.txt. I've made it
very flexible and tried to add anything which anyone would find
useable. The following are
On 27 October 2011 19:33, Björn Stenberg bj...@haxx.se 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
The patch earlier had a compile error, this one should be good to go.
On 26 October 2011 01:03, Jonathan Gordon jdgo...@gmail.com wrote:
On 26 October 2011 00:52, Thomas Martitz ku...@rockbox.org wrote:
Am 25.10.2011 15:40, schrieb Jonathan Gordon:
There is an argument that setuifont() must
On 25 October 2011 17:35, Thomas Martitz ku...@rockbox.org wrote:
Plugins can use the screen_access api. Ideally those should be using a
custom viewport if they want a custom font, right?
Any plugins which are not using the screen acess api are probably so
old that yes, they dont use a custom
On 25 October 2011 19:49, Thomas Martitz ku...@rockbox.org wrote:
Am 25.10.2011 09:36, schrieb Jonathan Gordon:
One question about the patch though: Why separate setfont() and
setuifont()?
I imagine one could be sufficient, but perhaps I'm missing something.
Best regards.
There are a few
On 25 October 2011 16:50, Jonathan Gordon jdgo...@gmail.com wrote:
Attached is 90% of the work to do this somewhat more nicely.
The remaining work is to check each plugin and make sure they don't
use lcd_setfont() directly (which a quick look shows alot do :( ) the
quick fix for that is just
On 26 October 2011 00:52, Thomas Martitz ku...@rockbox.org wrote:
Am 25.10.2011 15:40, schrieb Jonathan Gordon:
There is an argument that setuifont() must call lcd_setfont(), but if
setfont() sets global_status that would be wrong. Proof of that is
what should global_status.font_id
bringing it up on the mailing list.
This message: [ Message body ] [ More options ]
Related messages: [ Next message ] [ Previous message ]
From: Jonathan Gordon jdgordy_at_gmail.com
Date: Sun, 23 Oct 2011 16:31:50 +1100
Can this please be reverted? firmware/fonts.c should now know or care
for the screen_access api.
On 23 October 2011 16:31, Jonathan Gordon jdgo...@gmail.com wrote:
Can this please be reverted? firmware/fonts.c should now know or care
about the ui font at all, and post buflib fonts it doesnt.
screen_access.c added a helper to set the font
(screens[screen].set_font
Can this please be reverted? firmware/fonts.c should now know or care
about the ui font at all, and post buflib fonts it doesnt.
screen_access.c added a helper to set the font
(screens[screen].set_font() ) which should be being used by the
keyboard and lrcviewer. If those are still having issues
On 18 October 2011 19:14, Francisco Vila paconet@gmail.com wrote:
Good work. BTW I like this style of announcing, with ladies and
gentlemen and a log of the first track played and so on. Gives an
epic flavour to the whole thing. Thanks
It is quite a tradition here :)
On 13 October 2011 07:19, Björn Stenberg bj...@haxx.se wrote:
However there is certainly a point in not requiring all arguments all the
time, so two functions make sense. Since they are vararg enabled, I'd say a
more suitable name than lcd_puts is lcd_printf and its extended companion
On 13 October 2011 19:48, Thomas Martitz ku...@rockbox.org wrote:
Am 13.10.2011 10:42, schrieb Thomas Martitz:
Alright, thanks for the comments discussion. I'll commit part 1) (move TD
to settings) and 3) (the actual sleep timer remake) and leave the
System-About rename out for now.
That
On 15 October 2011 20:53, Björn Stenberg bj...@haxx.se wrote:
Jonathan Gordon wrote:
So one objection isnt enough? commit the sleep timer rework by all
means, but dont move td unless the rest of the discusison is settled.
Your objection as I understood it was that the patch does less than
On 10 October 2011 20:27, Thomas Martitz ku...@rockbox.org wrote:
I'd like to add that it's worthwhile to invest into our UI code. We
shouldn't forget that android isn't the only touch-enabled target. We should
have something workable on other touch targets as well.
HELLO! I don't think we've
On 11 October 2011 08:45, Björn Stenberg bj...@haxx.se wrote:
Thomas Martitz wrote:
I agree it's less than ideal that there are two list
implementations, and I see the skin engine eventually taking things
over.
But as of now there just are two implementations, and the classic
lists aren't
On 9 October 2011 18:38, Jonathan Gordon jdgo...@gmail.com wrote:
30min of fiddling around, attached is the screenshot from the e200 sim
and the patch to do it, notice there is no code needed anywhere
outside of the skin engine (infact its only done there because that
pulls in the generated
On 9 October 2011 21:03, Thomas Martitz ku...@rockbox.org wrote:
Am 09.10.2011 09:38, schrieb Jonathan Gordon:
30min of fiddling around, attached is the screenshot from the e200 sim
and the patch to do it, notice there is no code needed anywhere
outside of the skin engine (infact its only
On 9 October 2011 21:32, Thomas Martitz ku...@rockbox.org wrote:
Am 09.10.2011 12:24, schrieb Jonathan Gordon:
Did you completly ignore the part where I said it was a *quick proof*
that your patch is wrong? I've already admitted that the skin engine
is lacking some minor issues *which need
Braindump for someone to pick up to fix the skin buffer memory
allocation issue.
The problem is that The vast majority of the skin buffers static
allocation goes to the struct skin_element which is allocted for every
single item in the skin file. Every line, tag, subline, comment, etc.
on e200
On 9 October 2011 23:48, Thomas Martitz ku...@rockbox.org wrote:
Am 09.10.2011 14:37, schrieb Jonathan Gordon:
3) in skin_render_viewport() (and a few other places) lock all those
handles
Is locking even needed? The lcd functions (except the final
lcd_update()/_rect()) don't yield().
Best
On 10 October 2011 01:38, Thomas Martitz ku...@rockbox.org wrote:
Bah,
Move the whole System menu into settings and call it whatever you
want. It really doesnt deserve such a high placement in the menu
system
Is this a strong objection, or just stating that the patches don't go far
enough
On 8 October 2011 05:18, Thomas Martitz ku...@rockbox.org wrote:
Hello folks,
I finally uploaded the patch that's lived long in my git repo (although in
very hacked together fashion). I'm making this post here too since I want to
get it in quickly. So please have a play with it and speak up
On 8 October 2011 23:36, Dave Hooper d...@beermex.com wrote:
If this is already possible in the theme, then I agree with Jon and don't
see the need for the patch. Putting the padding into the theme itself makes
more sense to me, since the theme author will already appreciate what
spacing
On 9 October 2011 07:43, Torne Wuff torne+rockbox...@wolfpuppy.org.uk wrote:
On 8 October 2011 11:47, Jonathan Gordon jdgo...@gmail.com wrote:
On 8 October 2011 05:18, Thomas Martitz ku...@rockbox.org wrote:
* Automatic (default, line height calculated using a lcd dpi aware
function)
1
On 9 October 2011 12:31, Thomas Martitz ku...@rockbox.org wrote:
Am 23.08.2011 01:08, schrieb sideral:
So here's the plan:
* Move the entire Time Date menu out of System to Settings
* Rename System to About
* In the Time Date menu:
* Sleep Timer offers the last-used timer value as
On 5 October 2011 18:19, Thomas Martitz ku...@rockbox.org wrote:
Am 28.09.2011 09:00, schrieb Thomas Martitz:
TBH, I would like to revert this commit.
Best regards.
Alright, as a few people agreed with me I'm going to revert this in a few
hours.
Best regards.
Go ahead, just remember
On 5 October 2011 18:50, Hayden Pearce saint.lascivi...@gmail.com wrote:
I found the wording of a few people agree, so I'm reverting amusing.
The amount of times a few people agreed something should be committed, and
it wasn't, most often blocked by the same one or two people, vs the ease of
I already explained why it was needed, noone replied to that email so
apparently noone actually cares.
I see its been reverted, oh well.
On 6 October 2011 01:23, pondlife pondl...@pondlife.me wrote:
is just a dick thing to do
Hrmf, don't be a shitweasel.*
Reverting this is definitely not
On 6 October 2011 14:10, Dave Hooper d...@beermex.com wrote:
I did reply to your email. I could repost my response if you think it would
be useful.
You replied to the thread, but not to the email explaining the situation.
Someone may as well go and bump the #define in skin_engine.h now as
I'm
On 28 September 2011 21:54, XavierGr xavie...@gmail.com wrote:
On 28 September 2011 10:15, Jonathan Gordon jdgo...@gmail.com wrote:
I'm saying this publicly because I don't want anyone to think I'd
simply lost interest in the project or found another itch elsewhere. I
very much have stuff I
On 28 September 2011 17:24, pondlife pondl...@pondlife.me wrote:
TBH, I would like to revert this commit.
FWIW, I agree. A solution is needed to this memory waste, but this isn't
it.
pondlife
Very quickly, the skin buffer always was a memory hog, but now that
the big items (images,
I'm happy to talk about technical issues...
On 26 September 2011 16:15, Amaury Pouly amaury.po...@gmail.com wrote:
Hi All,
Furthermore this user setting is implemented in a totally obscure way (a
magic file containing a magic number, which isn't checked if it's even
plausible). It's
a) 3.10
b) because history says that whatever I suggest will be outright rejected
On 25 September 2011 09:59, Alex Parker parker.ale...@gmail.com wrote:
Hi guys,
So the next release is due towards the end of October, and in the past there
has been some discussion as to whether the version
serious response:
a) 4.0
b) 1 - there has been plenty of stuff commited in the last release
which gives us a good enough reason to bump the major number
2 - 3.10 looks a bit funny
3 - no other target has caused a major bump so why should android
be different?
4 - the numbers are
2011/9/25 Jonas Häggqvist ras...@rasher.dk:
+1. 2.x-3.x was when SWCODEC was added (and initially 3.0 was planned for
Archos+Iriver Hxx0 only IIRC). I'd say the addition of (releasable) Raaa is
on the same level.
From a technical point of view, RaaA is a pretty uninteresting target.
SWCODEC
Hi all,
http://www.rockbox.org/tracker/task/12273 Is very ready for mass
testing so please everyone get it into your private builds and help
out!
What this does is use buflib instead of a static array for *all* fonts
loaded by the system. This is a big patch and im not really willing to
just
On 7 September 2011 00:40, Torne Wuff torne+rockbox...@wolfpuppy.org.uk wrote:
4) We write up policies and documentation on how to use git via
gerrit, though only two parts are crucial at this point: how to clone
the repositories, and how committers can commit directly to master.
Do we
On Sep 7, 2011 5:43 PM, bryan.chi...@rbs.com wrote:
Do we really want to allow commits directly? so little of our code ever
gets
reviewed so I would quite happily force everyone to go through gerrit
and
require someone else to OK it. It isnt hard to get someone else in IRC
to have
a quick
On 7 September 2011 21:02, Nils Wallménius nils.wallmen...@gmail.com wrote:
On Wed, Sep 7, 2011 at 10:53 AM, Thomas Martitz ku...@rockbox.org wrote:
Am 07.09.2011 10:29, schrieb Nils Wallménius:
I think it could be interesting to test it actually.
Testing it will probably show that it
On 7 September 2011 21:38, Nils Wallménius nils.wallmen...@gmail.com wrote:
I guess we will see if people use the review stuff voluontarily but i
expect not as it's easier to just push directly (as we do it now). If
everyone has to get their changes reviewed i think that would make
people
On 25 August 2011 22:50, Paul Louden paulthen...@gmail.com wrote:
Okay, what I'd like to see here is this:
People who actually want to directly contribute to this process
(filling out a list of categories at each step, etc), please respond
to this saying so, so that we can come up with dates
On 29 August 2011 16:22, Johannes Linke johannes.li...@gmx.de wrote:
As users will need Settings way more often than System, it seems absurd to
give System a higher priority and move Settings one level down.
From my origional email:
As a compromise I would accept removing the settings submenu
On 29 August 2011 03:13, Al Le al...@gmx.de wrote:
That said, a patch to even just allow simple reordering of the main
menu isnt going to be trivial so we should figure out a better layout
I once tried to do exactly that (in FS#6718 (only the main menu) and FS#7809
(general menu reordering
*Everyone* agrees Time Date does not belong in system as it
currently is. Hypothetically, if it were moved out of System and put
into Settings it begs the question as to the point of the system menu
at all. Most people agree Rockbox Info is the most important item in
that menu, and running time
On 28 August 2011 23:22, Paul Louden paulthen...@gmail.com wrote:
Equally, why are the settings given such high priority in the main
menu? Sure they are useful, but after the initial player setup how
many settings does one need access to? and given how poor the setting
layout is it is likely
On 29 August 2011 02:04, Johannes Linke johannes.li...@gmx.de wrote:
Hi,
why can't you just move System into Settings? Ok, credits are not a setting,
as well as Rockbox info isn't. But look at this from a users point of view:
meaningful menu item names are for remembering where to look for
On 28 August 2011 06:15, Thomas Martitz ku...@rockbox.org wrote:
Its unfortunate that you let the single hypocrite win. Really everyone else
agreed with moving td to settings.
Perhaps I'll just move it afterwards...just cause.
Best regards.
how to win friends and influence people (y)
On 23 August 2011 18:29, Jonathan Gordon jdgo...@gmail.com wrote:
Hi,
This is my view on the other thread about moving the Time Date menu.
Get rid of the System menu. it is entirely pointless.
The items hat will be in it once TD is moved (which sounds like a
given) are: Rockbox info
Hi,
This is my view on the other thread about moving the Time Date menu.
Get rid of the System menu. it is entirely pointless.
The items hat will be in it once TD is moved (which sounds like a
given) are: Rockbox info, credits, running time, debug.
Rockbox info has very little actually useful
On 23 August 2011 18:29, Jonathan Gordon jdgo...@gmail.com wrote:
Hi,
This is my view on the other thread about moving the Time Date menu.
Get rid of the System menu. it is entirely pointless.
The items hat will be in it once TD is moved (which sounds like a
given) are: Rockbox info
I've already put my hand up to help out. Ideally as many comitters as
possible say they are either in principle backing the committe and
waiting for the results, against the whole notion of this change, or
abstain completly (including the final vote).
This is going to be alot of work for those
On 24 August 2011 00:05, bryan.chi...@rbs.com wrote:
I think it's worth trying to set a guideline for the maximum desirable menu
depth too - I don't think we'd want to go to fine grained for everything
unless it's just otherwise unworkable?
Yes, but lets agree that we are going to do this
On 23 August 2011 22:39, Paul Louden paulthen...@gmail.com wrote:
You should probably also mention that included in those diffs is also
a rearranging of the main menu as you mentioned in your first message,
but left out in your summarized descriptions here.
Like you said, it was mentioned in
On 23 August 2011 09:08, sideral side...@rockbox.org wrote:
Given that it looks like there's overwhelming support for (and little to
no concern about) moving Time Date to Settings, I now think it's fine
to do that change along with the proposed sleep-timer extensions. Also,
I'd like to pick
On 23 August 2011 10:27, Paul Louden paulthen...@gmail.com wrote:
On Mon, Aug 22, 2011 at 7:10 PM, Jonathan Gordon jdgo...@gmail.com wrote:
I disagree with the first part of this change.
Time date doesnt make any more sense in settings than it does in
system (or info if you want to rename
1 - 100 of 675 matches
Mail list logo
