This page is WIP.
The following is a mix of requests, suggestions and wish list. It is based on:
- bugs that need to be fixed; or,
- experience; or,
- features that are needed or desired.
The list is not sorted / order. There is no specific priority or criteria.
Hopefully some developer would be able to accept the challenge and improve Syslinux regarding the following list.
Comments / feedback / ideas / questions and patches are all welcome and appreciated; please use irc or the mailing list.
Please avoid commenting here.
The following table #1 is a resume of the behavior regarding submenus with/without TAGNAME, involving the MENU TITLE and MENU LABEL directives.
So, what's the issue?
1.1_ Correction of the documentation, which wrongly states that the MENU TITLE is inherited from a parent menu into its submenus.
1.2_ In "case #4" and in "case #8" the title is not inherited and no title is shown; the behavior should be corrected as shown in table #1.
The corresponding syslinux.cfg is as follows.
UI menu.c32 MENU TITLE Parent title # case_1 MENU BEGIN tag_1 MENU LABEL mlabel_1 MENU TITLE title_1 LABEL hello_1 COM32 hello.c32 MENU END # case_2 MENU BEGIN tag_2 MENU LABEL mlabel_2 LABEL hello_2 COM32 hello.c32 MENU END # case_3 MENU BEGIN tag_3 MENU TITLE title_3 LABEL hello_3 COM32 hello.c32 MENU END # case_4 MENU BEGIN tag_4 LABEL hello_4 COM32 hello.c32 MENU END # case_5 MENU BEGIN MENU LABEL mlabel_5 MENU TITLE title_5 LABEL hello_5 COM32 hello.c32 MENU END # case_6 MENU BEGIN MENU LABEL mlabel_6 LABEL hello_6 COM32 hello.c32 MENU END # case_7 MENU BEGIN MENU TITLE title_7 LABEL hello_7 COM32 hello.c32 MENU END # case_8 MENU BEGIN LABEL hello_8 COM32 hello.c32 MENU END
- Table 1:
|1 = directive set explicitly|
|0 = directive NOT set|
|SUB- MENU LABEL||1||1||0||0|
|SUB- MENU TITLE||1||0||1||0|
|SUBMENU ENTRY IN PARENT MENU||menu label||menu label||submenu title||tagname|
|MENU TITLE IN SUBMENU||submenu title||menu label||submenu title||tagname|
|SUB- MENU LABEL||1||1||0||0|
|SUB- MENU TITLE||1||0||1||0|
|SUBMENU ENTRY IN PARENT MENU||menu label||menu label||submenu title||blank (none)|
|MENU TITLE IN SUBMENU||submenu title||menu label||submenu title||parent menu title|
When using the Simple Menu System ([vesa]menu.c32), the menu title itself can be omitted, but the screen space for a MENU TITLE is always reserved (used), whether a title text is displayed or not. I'd like to have the optional possibility to use such space for menu entries. This would mean that the menu borders that are surrounding the menu title should be optional too, in such a way that the menu rows can optionally occupy this screen space (adding more usable rows for menu entries).
The level of control and details are subject to debate. This optional behavior could mean adding just one new directive, triggering all the necessary effects together at once, "elevating" the whole menu and allowing more rows per screen.
Or, alternatively, it could be achieved with several independent directives, with each new directive controlling each new behavior. In case the latter is chosen, the following are potential new directives, among others:
_ Some new directive to make the title space usable for menu entries;
_ MENU COLOR titleborder (or something of the sort)
_ MENU STARTROW (or some similar expression). This new directive might (or might not?) have influence on MENU ROWS, MENU ENDROW, (MENU VSHIFT?) and all other directives related to rows and vertical position(s). These are just potential ideas. I'll let the actual method, behavior and details for future eventual discussion.
The usage of negative values for MENU *ROW* directives should be maintain without modifications.
Having more directives offers more possibilities, but it might add complexity to the code and for the user too.
Return and/or improvement of the pager (more / less) functionality.
For example, when using ls.c32, the output pauses after a full screen, but there is no "Press any key to continue" or similar message, which might appear (at least to some users) as if the process hung.
For cat.c32, there is no pager functionality, so for text longer than one full screen the behavior is inadequate (at least on video console). It would be very useful to have the possibility to navigate through the displayed text, using arrow keys, PgDn, PgUp, Home, End, Shift+sth, Ctrl+sth, Esc.
In case this proposed behavior for cat.c32 would be inadequate for serial console, then I would suggest leaving cat.c32 “as-is” and bringing display.c32 back to life for video console with all this additional functionality.
For DISPLAY / Fn / message files, add the possibility to navigate through the displayed text, using arrow keys, PgDn, PgUp, Home, End, Shift+sth, Ctrl+sth, Esc, together with a pager (more / less) functionality.
This improvement should apply to DISPLAY, Fn and MENU HELP directives.
The improved new behavior needs to be tested for every possible case: from boot prompt, from [vesa]menu.c32, and for each possible output console.
Slitaz 4.0 includes 2 very useful c32 modules created by its developers: ifmem.c32 and md5sum.c32. I'd like they would be included in Syslinux official archives (v4.07-preN), with the following considerations:
1_ md5sum.c32 is currently compatible with Syslinux 4.07 only. Prior Syslinux versions contain a bug which conflicts with md5sum.c32. In addition, the source code for md5sum.c32 as in Slitaz 4.0 is incompatible with Syslinux 5.
<Gene> 5.00+ incompatibility solved.
2_ md5sum.c32 should be renamed to either md5.c32 or hash.c32 before integrating it to official Syslinux.
<Gene> c32box.c/c32box.c32 (as it's called in some parts of the source) since it's 10 tools in 1 module. If renamed to md5sum.c32, it acts like you called "c32box.c32 md5sum".
3_ It might be possible (for someone with the adequate knowledge) to extend the functionality of md5sum.c32 to other hashes / checksums. It might be accomplished on the same c32 module, or perhaps in separated c32 modules for each hash type.
<Gene> Step one is reuse library md5. Then adding other hashes should be trivial.
4_ For the checksum / hash module(s), once the final status is presented, a manual pause ("Press any key to continue") should be added, before it returns to the boot prompt. Without a manual pause, when a TIMEOUT directive is used, the resulting status can't be seen if the user is not in front of the screen at the exact adequate moment. When using serial console, this behavior would need testing (and possibly, a workaround).
<Gene> Should require a parameter rather than forcing such.
Feature Request. Unicode support for screen output (in menus, text help, DISPLAY files). This refers to being able to display Unicode characters in MENU LABEL, in TEXT HELP and in DISPLAY files (DISPLAY, Fn and/or MENU HELP). Other directives (displaying messages) might follow the same concept.
Additionally, I'd like similar support for displaying Unicode characters when using ls.c32, cat.c32, display.c32.
Note that the paths and file names might or might not use Unicode characters, which would be a separate issue / feature. My feature request is to support the possibility to display Unicode characters on screen with the aforementioned directives and/or modules.
I am only presenting the goal. Whether the entire cfg file needs to support / be saved / be parsed with some form of Unicode encoding so to achieve this goal is a discussion for developers. Support for some format of Unicode fonts, new directives or whichever means are needed, are also topics for developers to discuss.
I'd like the addition of a new directive so to automatically allow hotkeys in [vesa]menu.c32 entries. Under the current behavior, each MENU LABEL requires an optional caret character for its optional hotkey. With the addition of a new directive, pressing a printable character key would automatically move the menu entry selection to the next entry that starts with such printable character. The interaction between such new directive and the usage of the caret character would be part of the debate regarding this new directive.
Note that when using the caret character, the respective hotkey is usually displayed in a different color / brightness. This behavior is not desirable for the new directive in question (while it is indeed appropriate when using the caret character for hotkeys).
Add a new MENU SUBTITLE directive. There could be more than one such directive in each (sub)menu. This request has a lower priority, as there are some (somehow inconvenient) alternatives.
Add the possibility to correctly use the DISPLAY directive when using [vesa]menu.c32, specially when using the UI directive or the DEFAULT directive (note that with a KERNEL directive in a specific LABEL entry, this behavior could potentially be undesired in certain cases, although this usage would be uncommon anyway).
Currently, the DISPLAY file is shown first, and it is immediately "overwritten" by the menu itself. I am unsure if the current behavior is a "feature" or a "bug".
One possibility could be to adapt the interaction between UI and DISPLAY directives depending on the PROMPT directive, but I am not convinced this would be the most adequate method to pursue.
Expand MENU GOTO tagname with an optional label. Instead of going to the corresponding (sub)menu (tagname) and selecting its menu default entry, automatically select the specific label entry.
Extend MENU DISABLE and MENU HIDE directives to be applicable to TAGNAMEs used in MENU BEGIN, INCLUDE or in other directives that might make use of tagnames.
The "MENU DISABLE" and "MENU HIDE" directives are valid only after a LABEL directive. In addition to their main purpose, they are sometimes useful for troubleshooting / simplifying / improving (sections of) menus, without having to temporarily delete or comment out (possibly large) parts of an already-existent menu.
I'd like to suggest, if it is possible, the extension of these two directives, so to be also applicable to submenus (with tagnames). A submenu "parent" entry would be either disabled or hidden, respectively, just as a simple menu entry is currently affected by these two directives.
I have more ideas in mind. More comments / wish list might be added in the future.
As mentioned before, comments / feedback / ideas / questions and patches are all welcome and appreciated; please use irc or the mailing list.
Please avoid commenting here.