Rockbox

nice idea but I'd prefer having a <filesystem> entry in the tagcache view so I can quickly change without a new button. Likewise a fictive file in the root folder could change to the tagcache view.

Isn't changing shown filetypes via quickmenu quick enough?

"Likewise a fictive file in the root folder could change to the tagcache view."

Two configuration files in the root folder can do this now.

This patch seems to me a bit like a lot of those "the record button should perform my pet action" patches/requests sprung from the fact that the record button is currently unused. I think this (button assignments) is an issue that needs discussion at some point, but I doubt my support would be for this solution, since there's already a pretty quick way to perform this action.

nice idea but I'd prefer having a <filesystem> entry in the tagcache view so I can quickly change without a new button. Likewise a fictive file in the root folder could change to the tagcache view.

fair enough. I personally prefer my file tree to be a "pure" representation of what is on the disk - everything else is a menu. Especially having the searches as pseudo directories strikes me as being counter-intuitive.

Isn't changing shown filetypes via quickmenu quick enough?

not for me, especially as the quickmenu is not "quick" anymore (you get a nasty flicker with every change and need an key press to leave it), but feel free to ignore the patch if you can't see the benefit :)

"Likewise a fictive file in the root folder could change to the tagcache view."
>Two configuration files in the root folder can do this now.

Please explain. I am not aware of any mechanism that will do that? Can you point me to the documentation for these configuration files?

This patch seems to me a bit like a lot of those "the record button should perform my pet action" patches/requests sprung from the fact that the record button is >currently unused.

I can asure you that this is not the case - initially I wanted to replace the quickmenu with a single action toggle mechanism as I found it too cumbersome to use. Then I realised that the rec button is unused in the filetree so I used that instead.

I think this (button assignments) is an issue that needs discussion at some point, but I doubt my support would be for this solution, since there's already a pretty quick way to perform this action.

I am very astonished about the negative response I am getting for sharing a patch that I personally find useful. Why don't you implement your solution and show how it can work better? Frankly I will think twice now before I consider contributing again.

Please explain. I am not aware of any mechanism that will do that?
>Can you point me to the documentation for these configuration files?

Use .cfg files to change shown filetypes to 'supported' (or your favorite filetree-based browsing type) and to 'tagcache' respectively. Inspect a saved .cfg file for exact syntax.

I am very astonished about the negative response I am getting for sharing a patch that I personally find useful.
>Why don't you implement your solution and show how it can work better?
>Frankly I will think twice now before I consider contributing again.

Please do not mistake critical commentaries for malice.

There're lots of patches that sit in the tracker and will probably never get accepted since they are all too specific -
either by implementation (e.g., many platforms *don't have* unassigned buttons) or by concept (you want REC to do this, I want it to do that).
Do you have a good argument that your way is The Right Thing[TM]?
Why it should get committed to CVS in favor or other REC-button patches?

Jonas' wording might be a little too rough, but he's right.
An ideal solution would be a generic user defined button assignment patch, but nothing like this exists ATM.

ok, I overlooked the option to have a cfg file that switches to tagcache view – but how can I change back? Tagcache doesn't show me cfg files in my root folder. Is there a possibility to display a cfg file with tagnavi.config? Or add some line to tagnavi.config that does the switch? Also using cfg files has the disadvantage that on every load the disk spins up. My idea was simply a virtual folder that "holds" the other view as it seems somewhat more logical to me (tagcache is showing virtual folders at least).

Btw, I don't get a "nasty flicker" when using the quick screen (h120).

Why it should get committed to CVS in favor or other REC-button patches?

I now understand where you are all coming from. I wasn't saying this should be included in the official build. I am well aware of the fact that the approach needs to be workable for all targets. I was simply sharing a solution that suits my needs with the comunity in case someone else might find it useful. If nobody does, fair enough - we all have different preferences.

Use .cfg files to change shown filetypes to 'supported' (or your favorite filetree-based browsing type) and to 'tagcache' respectively.

I see what you mean. But as bluebrother pointed out you can't go from the tagcache to the file tree and it requires a disk spinup, whereas my method is instantenious (with dircache).

Btw, I don't get a "nasty flicker" when using the quick screen (h120).

When I move the stick while holding mode (which is how the 'quick' screen used to work), the view briefly changes back to the screen I was on before, making it hard to read what the current setting is. I can only assume, you let go of the mode key when adjusting settings? This IMHO defeats the purpose of it being a 'quick' menu. (but I supose this shouldn't really be discussed in this patch).

Robert,

when someone submits a patch to the patch tracker, we assume you want it included in CVS, as that is what the tracker is for.

when someone submits a patch to the patch tracker, we assume you want it included in CVS, as that is what the tracker is for.

I wish that had been explained somewhere, would have saved me alot of aggravation. So where do you suggest such (potentially useful but not CVS material) snippets should go?

I'm not really sure. I think there is a void to fill here. Maybe you want to set up a site for such stuff?

Just as an idea, how about setting up a new task type (or FS project), say, "cvs addons" for such stuff? This would have the advantage of being part of the tracker so if any dev finds such an idea good he still can adopt (and find!) it easily. Using an external site would make it hard to keep track of such enhancement patches IMO.

Also, I think it would be good to have something disclaimer-like page the user is required to read before signing up with Flyspray. This way we could make sure the users are aware of how the tracker is intended to work (and hopefully help keeping useless reports away – It seems to me only a few users who report bugs have actually read the bug submission guidelines).

On my h340, the record button currently turns the backlight on. I would hate for it to get hijacked for some other purpose, as all other keys currently do something when you press them. I like the idea of turning the backlight on without changing the volume or whatever.

Before someone suggests it, I HATE the option for first button press turns on backlight, as I don't like having to press a button twice to do anything - it's counter-intuitive and I don't like it being the default setting.

Just as an idea, how about setting up a new task type (or FS project), say, "cvs addons" for such stuff? This would have the
>advantage of being part of the tracker so if any dev finds such an idea good he still can adopt (and find!) it easily. Using an
>external site would make it hard to keep track of such enhancement patches IMO.

I would whole-heartedly support this suggestions. Good idea to keep everything in one place

How about making it so when you go "up" from the root dir, you switch to the other view? I only had the idea now and haven't thought about it so much, perhaps it is not good.

I like the idea and tried to create a quick patch. I'm not sure if this could be done in a better way, maybe it would also be better to just provide a virtual directory in the tagcache view which shows a (configured) file tree view (like having an entry in tagnavi.config that selects the file tree view with a settable view setting and configurable title).
Drawback of my patch: when tagcache is selected as view upon startup it switches between id3 and all files view. Apart from that I like it pretty much. Tested on h120 so far.

   id3-treeview-toggle.patch (1.3 KiB)

From what I can see, you changed my patch to use a different button (left instead of record) and introduced the additional condition of having to be in the root for it to activate? I personally can't see the advantage. Say I am playing a song from the ID3DB view and want to do a non-audio action such as reading an ebook (my motivation for the patch). I have to navigate up all the way in the tree and down again to get to the ebook (which is worse than using the quick menu). I also lose my position in the tree(s). With my patch (and the quickmenu), two independent tree positions are maintained, so with a switch of the button you can change between the ebook directory and the album listing.

Drawback of my patch: when tagcache is selected as view upon startup it switches between id3 and all files view.

Why is this a drawback? I chose SHOW_ALL as the default action since it is the most flexible - you could have changed it to something else if you didn't like it. :)

yes, nothing special there. Your patch was a nice starting point to get this quickly done.
Main motivation was the fact that Mikachu's idea sounded nice to me and I wanted to simply try it. After playing around with it I still would like to have a <filesystem> entry in tagcache (like I already described) to switch to the file tree thus having a new virtual folder. When using that concept I also would "loose" the tree position (as it will be only one virtual tree).

On the SHOW_ALL, I'd like it better if it doesn't change to some view that is hardcoded but use the one used last. Which is also another point for errors - you can trick this patch to switch between ID3↔ID3 view. My intention was mainly to get a quick possibility to play with it (to see if I like it). Feel free to dislike it

yes, nothing special there. Your patch was a nice starting point to get this quickly done.

by all means. It is open source after all. :)

On the SHOW_ALL, I'd like it better if it doesn't change to some view that is hardcoded but use the one used last.

I agree. But without introducing a new global setting that is saved to disk, I figured this was the best compromise.

you can trick this patch to switch between ID3↔ID3 view

I would be interested to see how, considering this is co-operative multitasking.

tricking the patch if fairly easy – just run into a condition where old_dirfilter is set to SHOW_ID3DB. Just switch to the file view and then change it to ID3 using the menu or the quickscreen. Then the old_dirfilter is set to ID3 upon the next switch and the current state is also ID3.
(To prevent misunderstanding, I'm referring to my patch. Haven't thought about this regarding your patch but I guess it could happen similar)

+ if(global_settings.dirfilter == SHOW_ID3DB)
+ global_settings.dirfilter = old_dirfilter;
+ else {
+ old_dirfilter = global_settings.dirfilter;
+ global_settings.dirfilter = SHOW_ID3DB;
+ }

old_dirfilter can never be set to SHOW_ID3DB, as it is only ever changed in the else branch of the if(global_settings.dirfilter == SHOW_ID3DB)

(the only exception being another thread modifying global_settings.dirfilter between the check and the assignment.)

but I suppose this discussion should go somewhere else…

the point of using left instead of record is that many players don't have any free buttons, and the left key is only unused in /

I don't like the idea to use LEFT in root to change to tagcache (and back?) because it can happen very quickly that you change views without wanting it.
A virtual folder in tagcache that gives you direct access to the tree would be the best imho. It wouldn't be important for me to have it the other way round, because with a virtual folder, tagcache would be the root where you can always get back to (don't know if you can understand what i want to say).