|
Glenn Posts: 99
16/01/2016
|
Pondering some updates to my SyMenu installations today, and thinking about the "fully customizable menu" limitations regarding treating all the user entries as a single block, the following ideas came to mind. They are somewhat redundant in nature, in that the overall goal is to allow shared chunks of menu structure. The first has appeal, if it can be implemented, because it might also be a way to intermix blocks of "SyMenu defined" and blocks of "user defined" menu structures, which is not presently possible.
1. It would be nice if there could be multiple blocks of "user defined" menu entries. One block would come from the current directory structure, and not be deletable. Other blocks would be defined by pointing at a separate SyMenu directory structure, and borrowing, or importing, its user defined menu structure. These imported menu structures would always be read-only to this SyMenu instance, but could be added to or deleted from the main menu list as a block. Perhaps due to the different classes, all the "user defined" blocks would have to be contiguous, but perhaps not (which would be more flexible). Perhaps the "import" entry would be new type of SyItem, instead of an additional block in the "SyMenu defined" list.
The goal here would be to have pieces of menu that could be maintained separately, but used together, preferably without adding an extra level of menu nesting, just additional entries obtained from the other SyMenu directory structure.
2. The other idea is an outgrowth of one I suggested recently, which I think is on your todo list... that entries that require Read/Write access simply vanish from the menu structure when the instance discovers it should be READONLY (either with the file flag, or the read-only file system).
This variation would be menu entries that are visible or invisible based on the existence of an environmental or SyMenu variable with a specific substring found in its value at SyMenu initialization time. The default would be for entries to be visible; but the existence of a particular substring in a specified variable would make it invisible, or the default could be for entries to be invisible, but the existence of a particular substring in a specified variable would make it visible. Either way could work. It could even be required to be a SyMenu variable with a specific name, if that simplifies the configuration or implementation.
The value of the variable then would simply be a set of delimiters and substrings, such as ~abc~def~ where the check would be for either ~abc~ or ~def~. Or it could just be a list of characters, where a single character suffices to specify the visibility of the menu entry. Short strings seems easier to keep track of, the "substring existence" check would allow users to choose either of these techniques, or possibly invent other clever schemes. One advantage of allowing the menu creator to specify both variable and substring for a command is that the variable could be something like USERNAME for commands that belong to a single user... if USERNAME is unique enough for the set of users involved.
The goal here would be to have a complete menu structure maintainable as one piece, but eliminate certain menu entries for certain users that don't need them, without having to maintain multiple, nearly-identical menu structures with just one or a few extra commands in some of them.
edited by Glenn on 16/01/2016
|