Heres a suggestion I posted in a different thread but I think it deserves its own thread to try and promote some discusion.
If you have read this suggestion earlier then ignore this one.
But for others, see if this makes any sense.

With all this wonderful IR hackery available to us now the use of (hexidecimal) button codes makes it hard to remember what hex string does what function and/or means what button on the IR remote or on the 'Player' itself.

So, how about this idea:
Allow symbolic button names in the Ir translation (as well as existing hex button codes as now)?

I would envisage that we allow users to define symbolic button names and assign its button code somewhere in config.ini.

This table of symbolic names is read in and remembered when config.ini is read.
However the information is used as a straight TOKEN replacement in the IR mapping section in the same file.

[i.e. the symbolic button codes are used much like #defines etc are used in C code and are then 'processed' out when the C program is compiled.

Suggest example of symbolic button codes:

[Symbolicnames]
MUTEON=xxxxxx
MUTEOFF=yyyyyy
EMPEGPAUSE=zzzzzz
EMPEGTUNER=ttttttt
EMPEGPLAYER=pppppp
MYREMOTETUNER=mmmmmmm
MYREMOTEPLAYER=nnnnnnnnn
ENDOFCOMMAND=ffffffff


In the IR mappings section we can then say


MYREMOTETUNER=EMPEGTUNER
MYREMOTEPLAYER=EMPEGPLAYER,dddddd,ENDOFCOMMAND
PAUSE.L=MUTEON
PAUSE.CL=vkgkgkg


I believe something like this will
makes ir (and soon, Stalk) maps:
(a) very much more readable and
(b) allows each user to redefine what external command/button causes a thing to happen without having to change everything in the maps.

Only the symbolic IR code value needs to change, the rest of the map can stay constant.

In order to make it easy for the Hijack kernel to parse and process these symbolic names I suggest that we impose some naming rules on the Symbolic button names
such as:
They cannot have fullstops or other 'special' characters in them [unless your parser is easily able to handle it]

So for instance this would would not be allowed:

[symbolicnames]
LONGTUNER=xxxxx.L

[irmappings]

LONGTUNER.C=EMPEGTUNER.L

As it would be adding a '.C' modifier to the '.L' modifier already active against that button due to the symbolic value.

During the initial read of the IR commands [probably during the initial parsing of the config.ini], the Kernel replaces each symbolic keyname with its symbolic value as a once off exercise & then proceed to work with the maps as now.

It can then forget about the symbolic maps until next time the system is restarted as this information won't be needed.

Maps that reference symbolic keys not present could have a message logged to the serial port (as now) and then any commands using that symbolic button name could either be ignored completely, or only the symbolic code (if a multiple code command) could be ignored whatever is easiest.

Symbolic keynames that are not used anywhere in any maps merely add length to the config.ini - but do server a useful documentation purpose if nothing else.

Any comments?