More granularity for "Don't save most-recently-used lists"

[grindax]

.

[zer0]

After all, there is plenty of empty space in the "Startup & Exit" options window

Considering "List Management" has (at most) 23 entries, it would not be sensible to introduce such granularity into the GUI's already large footprint. Perhaps if it's possible via a tweak...

[grindax]

.

[zer0]

Considering "List Management" has (at most) 23 entries, it would not be sensible to introduce such granularity

Thanks for your comments. No need for 23 new entries, just a bit more granularity for the major categories within MRU lists.

I understand what you mean, but who decides what are those "major categories"? You'd rather not remember recent locations, somebody else would rather not remember something else and so on. It's difficult to accommodate everyone's preferences

[TheQwerty]

I think since the dialog that is used to manage each list is shared it would be relatively easy and make a ton of sense to add a check box there (below the list but above the Editor Mode/[Tips]/Ok/Cancel buttons) that could toggle whether that list is saved or not.

And then maybe change the option in Configuration to be a combo box that changes the value globally; Save Lists:
+Always
+Never
+As Set in List Dialogs

[zer0]

I think since the dialog that is used to manage each list is shared it would be relatively easy and make a ton of sense to add a check box there (below the list but above the Editor Mode/[Tips]/Ok/Cancel buttons) that could toggle whether that list is saved or not.

And then maybe change the option in Configuration to be a combo box that changes the value globally; Save Lists:
+Always
+Never
+As Set in List Dialogs

I have no problems with granularity as such, it's just the way it would implemented GUI-wise that concerns me. I am still miffed about the List Management dialogue not being a "one for all" place for overseeing the lists, like Configuration menu is for settings. Currently, we have no way of 1-click-switching between list management categories and we must have it. The more granularity we introduce into each list's category, the more work goes into customizing each list, so saving time by clicking less is important.

P.S. In case of such a check box, we should also have "Apply all" and "Clear all" to prolong the lives of people's mice

[grindax]

.

[admin]

I notice that the option "Don't save most-recently-used lists" is a catch-all for quite a number of different lists. Would you consider breaking this down into separate options? I'd like to have the option to not remember Recent Locations without affecting some of the other things like renaming operations or selection filters.

After all, there is plenty of empty space in the "Startup & Exit" options window

I would agree that mruBrowse (=Recent Locations) and mruGoto (these are the section names in the INI) should be controlled by "Don't save history" instead of by "Don't save most-recently-used lists". Would you agree and would this help?

[grindax]

.

[admin]

I would agree that mruBrowse (=Recent Locations) and mruGoto (these are the section names in the INI) should be controlled by "Don't save history" instead of by "Don't save most-recently-used lists". Would you agree and would this help?

I'd like to have XYplorer not remember recent locations between sessions, however I would like it to maintain the expansion state of my locked tree. Currently if I turn off saving history then the tree state goes as well. So I think ideally it would be better to have recent locations managed separately.

Backgound information: And the reason I'd like to turn off the saving of recent locations is because the tweak "AutoSelectMRUSubfolder" is not possible to be used to differentiate between up and down -- it only works for both (as discussed in separate thread). So I'm thinking of setting this tweak back to '1' but hoping to at least have the locations it uses be reset between sessions.

As I explained here (http://www.xyplorer.com/xyfc/viewtopic. ... 238#p51238) the tree states are taken as part of the history. I could easily detach this for maxi tree and also for mini tree (i.e. remember their states while History itself is forgotten). Thinking about it, for Maxi Tree I will definitely do it because it has a separate setting "Remember state of tree". So the question here is whether the Mini Tree should also be preserved if History is set to be forgotten? Any comments?

PS: In v7.90.0400 - 2009-05-29 16:08 the MiniTree began to be forgotten with the History:

Code: Select all

    * History: From now on, if "Don't save history" is ticked then also 
      the Mini Tree is not saved. On next startup, the Mini Tree 
      defaults to the Favorite MiniTree (if there is any defined).