—> helmut
• Hi !
• Such a speach sounds indeed much better, thank you.
• Here, I'll try to add more explanations, despite the most important points have been developed already here.
Flexible menu structure
With a flexible menu structure any user could change the menu structure to his/her needs. Menu items could be moved, renamed and/or even hidden. …
• This is the main advantage for the users. For Total Commander, advanced users provide alternative menus for those who don't know how to change a menu, although this is documented in the Help files for ages, and is not very complicated…
- Any level of change¦improvement can be done, from simply add a pop-up - that I do for the displayed items- up to totally different menus NC-like made by
Petermad and very appreciated…
…- Effort
Currently, on the programmer's side (Pierre), the effort for such flexible menu is not that clear. There might be the chance of combining the introduction of the really important text based language files with flexible menus. Defining the text string used for a menu and defining the structure of the menu may be done with the same implemention, maybe not. …
• This is the main bone of contention, and it seems that the workaround we proposed making templates
has not been understood really…
¤ In brief :
- Pierre
must have a kind of list of all existing internal commands. These commands are already partially available
as names for the users about the addition of buttons in the tool-bars for the three display modes.
- Let's notice that this whole command-list might be available for the user (*.INC text-file),
and managed from an appropriate dialogue-box like I proposed
HERE.
- It could be already useful for the buttons, then enhanced for the menus, or even for the short cuts too.
- One must keep in mind that
all that is around the internal commands is the same three-spoke wheel :
Menus,
buttons and
keyboard short cuts. This way to consider the problem helps a lot…
• To build menus text-files, in both cases Pierre must define each command for each menu-item, anyway. Then, with a hard-coded structure, build a whole text-file “by hand” from the sources
*.c files, in which each entry must be marked off with its
command-name, since Pierre states that he changes the numbers continually
(don't ask me why…This is unusual in other programmes).
- With structured menus, same mess, plus the need to write the structure also by hand from the source-files,
according to the commands list.
- However, there is another cleverer way we used to build the final MNU structured file
that has to be released with the programme.
- Like I showed above as a simple example with
an image, the final structured MNU file is very close of the menu which exists in the resources, say in the programme for the embedded English language, and in each language DLL…
- It's
pretty easy to extract the whole menus scripts and to convert them into a final MNU file !
We done. No programming tool needed.
- We could do that again using the internal commands
as names, hence Pierre could save a lot of hours…
- Menus written in that way are easy to translate into any language from a single original English template. It's easy to spot a menu, a main pop-up, a sub-menu pop-up and the menu-items belonging to every section…
…I think that flexible menus are a good idea. They might even solve the issue of providing a light version of XnView easily. But some issues like the effort in programming for example must be clarified and taken into account…
• That is obvious. I tried to explain above how the effort can be reduced, it's worth a try, IMHO.
…I suggest to rename this topic to something like "Flexible menus" and start a new topic to discuss Wolfang's initial issue and question, the hard-coded menu structure, which one day might become the default menu structure for flexible menus.
• Like you feel, nothing against.
G.
Claude
Clo
Hello John !