Thomas Martitz <kugel_at_rockbox.org> writes:
> Am 15.08.2011 12:33, schrieb sideral:
>> I agree with most of what [Hayden] said, but I'd prefer to discuss
>> the best placement of the Time & Date menu and the sleep timer
>> separately from the present patch.
> Perhaps it would be a good idea to discuss this first then.
> It was always awkward that time & date is in system. It should really
> be in the settings. [...]
I don't think it's a good idea to discuss this first. I'm afraid that
making the patch dependent on resolving this issue first is tantamount
to significantly delaying it and mainly serves to demotivate its
developers and promoters. That's precisely why I'm attempting to
sidestep this discussion by sticking to standard routine and avoiding to
move anything around in the user interface.
I understand the desire to improve the user interface. But please, for
the sake of getting this patch done, try to be constructive by
separating that discussion and helping to come up with a compromise that
aims at preserving the status quo as much as possible, with a minimal
set of UI changes.
That said, if it turns out in a few days' time that there's wide
agreement that Time & Date should move over to Settings, and that the
sleep timer still belongs under Time & Date, we can make that change as
well in one go; I wouldn't be opposed to it. I had not anticipated that
I seem to be the only one who's defending the status quo -- which I only
did in a (misguided?) attempt to sidestep this discussion to expedite
patch acceptance. If you'd like to get this consensus done, I
nevertheless suggest to do so in a separate thread; I don't think we
still have the necessary quorum in this one. :-)
I'll try to explain in the next few paragraphs why I think that the
patch, plus the modifications suggested by Thomas Jarosch , would
meet my goal of being minimally disruptive. Then, I'll comment on your
alternative proposal (spoiler: I kinda like it).
> I would object to have the sleep timer (or generally time & date)
> related stuff to be split into several places.
The patch under discussion here introduces two new settings. Unlike
functions, settings belong into the Settings menu by default.
If you'd like to raise the question whether splitting functions and
their settings into separate menus is a good idea or not, please open a
separate thread. If you think this particular function warrants an
exception, I'd expect a more substantiated explanation than "I object"
or "I prefer".
(I know we have a few cases where a settings menu entry actually runs a
function, but I'd like to avoid adding more exceptions to the rule.)
> Where do you draw the line between settings and functions? To me
> they're the same, particularly from the UI point of view.
A function changes the dynamic system state with side effects. A
setting changes how some function does that.
(For example, the file browser provides functions to browse files and
manipulate playlists. Its options modify how the file browser does
> I also don't see why the sleep timer needs to be so deep into
> settings->general->system->sleep timer. As I mention below, IMO
> settings->time & date would be best.
By default, options for System functions belong into this
system-settings submenu. This is the settings submenu that comes up
when you long-select the System menu in the main menu. Also, the patch
puts the sleep timer options next to the auto-power-off options, to
which they are related.
Again, this patch does not attempt to deviate from the default placement
of functions and settings.
> In fact, I thought about it a bit more and also came up with a
> proposal that makes sense to me. It is similar to the first in
> FS#10849, except that I find the "Sleep Timer Duration" item
> redundant. What I would prefer is to have two menu items (actually
> one, since I actually don't see the point in applying the sleep timer
> on boot):
> Settings -> Time & Date:
> - Set sleep timer: If inactive, then set the time and start the sleep
> timer (the initial time would be remembered, i.e. persistent). If
> active, then it transforms to "Stop sleep timer" which just cancels
> the current sleep timer and transforms back to "Set sleep timer".
In which way would the persistent initial time be used -- in the same
way as proposed by Thomas Jarosch, that is, by initially highlighting
the previously used value the next time the Set Sleep Timer function is
If so, and except for my abovementioned concern that I'd find it
confusing to have the sleep timer actuated from a settings submenu, and
rather would keep this in System for now:
That'd make the default sleep time a "hidden setting". I think I could
live with that.
 For the casual lurker: Thomas Jarosch's proposal is at:
Received on 2011-08-15