Feature Script Menu customization

[MCroft]

Now I don't understand.

If things are working as designed there will be nothing in that list that is not a script file and everything in that list was either initiated directly by user interaction or a call in a script.

You might consider inspecting or clearing scriptMRUList.

I would not use "text cruft" to describe the name of anything that was important enough to put in its own script file, but if you do then I guess I understand although some of your problems are of your own making

Well, some of it is my own making, test_a.ash, test_b.ash, test_c.ash for testing. I guess "I don't want to use it like you do" is a problem of my own making, too. I've got almost no interest in my last 5 scripts, nor the entire catalog of a directory. I think "only put useful stuff on the menu" is a not-unreasonable request, and both the ways we're guessing are sub-optimal and choose too broad a brush.

A MRU menu is commonly used for documents. Text editors and word processors are often use them. You give up all advantages of a consistent menu (such as muscle memory of how to choose something) because the user rotates through a series of documents. Even in this case, they're often fixed at the first level, with a menu item to get to them (e.g. "Open Recent. >" in BBEdit).

Mirroring a file system in a menu makes sense when every file in a hierarchy is usefully selectable. Like a file-open dialog, where you might actually need to navigated to. We don't really do this, or need to do this.

But honestly, if you're satisfied with PM+'s solution and I am as well, maybe we should stop trying to explain ourselves to each other. It doesn't seem to be converging.

 

[fronobulax]

We're in the realm of exploring different vs. better and understanding different sometimes leads to better.

I figure if it is important enough to me to run and it thus shows up in a special position on a GUI, I'm OK with that. I do periodically manually edit the list if there is stuff I know I never want to see again and its presence in the menu offends me.

Since the MRU replaces the menu that appears when you click Scripts in the GUI, the state of the default display is of no interest to me. Instead I get similar functionality by using the Load Script option which gives me a file system browser where I can sort by date or size and navigate into and out of subdirectories. I have less angst about script files with the same names because I am explicitly picking exactly one and the familiar system browser helps me deal with selecting a file in the presence of case sensitivity or when the extension matters. So there is nothing new in the proposed replacement other than the fact that it support someone else's preferences better than the current system does

That said, to focus on a replacement menu that can be user configured and is hierarchical some comments and observations.

A JSON file seems like a reasonable way to define and store the menu. I would expect this to be a global file and not a per-character file. I am unlikely to want it to differ by character and it is too fiddly to find a way to synchronize global and per-character portions. Since installed scripts are global the menu might as well be global.

I look at the existing GUI for managing scripts for installation for inspiration on the automation available to build and update. Scripts that are installed by SVN and have repository entry have a category. I would advocate using that category to build an entry for a newly installed script. Scripts with no category will default to the top level of the hierarchy and the user can move them, or not. This opens up the possibility that the categories and the assignment of scripts to categories will be of interest to someone else besides the dev who last edited the repo file.

Since some users have simulated this by making subdirectories the automated build and update should mirror the directory structure.

I think the command needs to contain a partial pathname of a file in the Kolmafia file space. My mental picture is that prepending the KoLmafia "root" to whatever is there would generate a canonical path, when desired. This should eliminate any issues with duplicate filenames in different locations. It also means that the leaf nodes in the menu do not have to be unique. If I mentally tag DCQuest with both Login and Items then I could put it in two places. If I have two versions on disk then I can have both in the menu.

I assume the menu would cascade. or whatever it is called, and any level that had enough entries to trigger scrolling would do so.

I think a highly visible toggle to switch between this and the MRU version would be very useful. I can imagine a time when the MRU is integrated into this, for those who want it, or it is converted to use a similar JSON file for storage.

Obviously this will have to be supported by a preference type gui.

I think my soapbox is beginning to collapse under my weight. I've clearly been forced to think this through