>Have you tried using the item exclude ability to reduce your
>menu options to 1 fewer than fill the full screen?

I have no idea what you meant by that.. ?

>I liked Tony's (ynot) suggestion of not moving the highlight when
>scrolling the menu. Of course this involves a bit more logic because
>you do have to allow movement when there aren't enough items
>to allow scrolling.

I've been waiting for about 3 months for somebody to ask about that. If enough people care about it, it is very easy to do. And no, I will not make it a config option. Remember, this is non-pageable kernel memory, that is taking space away from buffering music from the hard drive.

>BTW, are you going to document exactly what the "label" names are
>for removing Hijack menu items in config.ini?

Sure, just hold down the menu button for about a second, and it gives you a complete listing of them all.

>What codes do your button names represent?

They represent the RIO codes, except for a few Kenwood-specific ones like DNPP. No need for a table, as the entire idea was to not to have to deal with the hex codes for them. If you care about the exact hex code, then just use the exact hex code in the IR translation.

>Planning on supporting modifiers in Popups anytime soon?
>My primary one is for using "Detail.L" in a popup (aka Info.L)

I believe you can do that already. [see next posting]

>How about .. disallowing button codes to be sent to the player
>while one of your popups is active?

What kind of popups? I kinda like being able to adjust the volume (or mute) at ANY time, even when a menu or popup is active.

>The button that sends the "popup" code should act the same as
>pressing OK as well.

Mmm.. I considered that one when implementing it. A problem was that the popup-button's "release" code arrives after the popup is on the screen. And if one of the front-panel buttons are used to activate a popup (or the knob), then it has to still be useable to navigate the menu/options.. same thing for some of the remote buttons, and it might be even more confusing/annoying if it didn't work that way.

>Anything else other than cancel or next/prev should cancel the popup.

Nope. Disagree there. Same as with the player menus.

>as some people have pointed out, vertical player menus
>would be pretty bad.

Yup, no problem there. I've never asked for vertical menus, just vertical playlists of some kind.

>Small font with current selection large would be something to try.

A new in-kernel font would add sever KB to Hijack's size/footprint.
And it would add even more for an aliased font & rendering code.

Do it in user-space, folks. That's where a vertical playlist browser should probably go, as well.. if we ever get the two necessary serial commands for one ("append FID" and "insert FID").

>You should also update your font to the player's current font. A lot >of characters are easier to read.

I'm not willing to blow the memory needed for such an extravagence. The folks with Mk1 players have too little music buffer space as is, and even the Mk2's don't have enough to buffer a single track in most cases.

But sure, 4KB here, 2KB there, no big deal.. but Hijack has probably about 100 features or so now, and maybe that many more to come in the future. That's a whopping big impact on memory usage if we don't keep things tight. Everywhere.

-ml