On Thu, 12 Oct 2006, Linus Nielsen Feltzing wrote:
> StÃ©phane Doyon wrote:
>> -And there's a few features that would be useful to audio book readers...
>> for one, it's too easy to skip to the next track when you just wanted to
>> adjust the volume, and the bus happened to hit a bump at that moment...
>> Audio book tracks can be very long, so it can be VERY annoying to find
>> your place again.
> I don't really see how it is too easy, and not how it could be made less
> sensitive without losing the FF/REW functionality. Any ideas?
Indeed, so I think it'd have to be a different mode somehow. Actually a
secondary problem is just with FF/REW: those you do want to have quick
access to, so you can repeat the last sentence. But if you have to FF/REW
a lot, say like when finding the place you had lost, and the bus hits
another bump, bang again you skip a track :-). And in fact it would be
convenient for a quick press and release LEFT to do a skip backward of
some small delay, say 2secs or 5secs. So it'd have to be a different mode
/ button context. We would just need a way to get in and out of that mode,
for when you really do want to skip tracks... But the WPS context is
pretty crowded already. Can we do a combination of PLAY and SELECT maybe?
Is that even supported? I need to think more on this and experiment.
I believe I've glimpsed a task related to this. Let me check... Hadn't
gotten to that part of my TODO list yet :-). Here, is FS#2041 about this
very subject? It's OLD!
A related wish: It would be nice if we could associate this sort of
preference with the audio book, such as by putting some flag file in the
directory. Other audio book preferences might be a different pitch
setting, perhaps some eq settings, auto--bookmarking for audio books
only... Perhaps a more generic approach would be the notion of
automatically loaded cfg files per directory, I noticed a task about that
too. (But it seems to me I'd want the automatically applied settings to
revert on getting out of that directory).
>> Anyway I'd like to work on some of that, in what little spare time I have
>> :-). I just wanted to make sure there's no actual opposition to this sort
>> of stuff.
> Absolutely not! We are delighted to have a coder that gives these things some
>> Also I am a bit disconcerted at the number of patches that appear to be
>> languishing in FlySpray. Is there an issue with getting stuff reviewed and
>> committed? It's hard to find anything in there... Will it be hard to get
>> my code into RB?
> Most patches lay around in the tracker because they are unfinished, unwanted
> or unmaintained. We often have problems accepting large patches, so it would
> be best if you developed your patches in small iterations.
Sure. Well that's what I did, except perhaps the one that replaces str()
with ID2P() in about 100places, which is a bit of a special case...
Received on 2006-10-12