XYplorer Beta Club

So changing favorites data automatically saves all other configs. This is a case for concern even for those who don't have automato-phobia.

Please consider updating the favorites section separately and adding another immediate save option for the rest of <xyini>

+1

SammaySarkar wrote:

Code: Select all

      - The "Favorites" option includes Favorite Folders and Favorite Files.
        And since there is no separate disk file for Favorites but they are
        kept in XYplorer.ini, XYplorer.ini will be written on changing a
        favorite.

So changing favorites data automatically saves all other configs. This is a case for concern even for those who don't have automato-phobia.

Please consider updating the favorites section separately and adding another immediate save option for the rest of <xyini>.

1) updating the favorites section separately: The only way to do this would be to have a separate file for Favs (which BTW also include Highlighted Folders and Boxded Branches -- should have mentioned that in the change log, did that now), something like "Favs.ini". Might make sense. But (slightly) slows down startup and shutdown.

2) another immediate save option for the rest of <xyini>: That's even harder. Since XY remembers almost everything, that would mean for me: Countless code points where I would have to call the save routine; and for you: Countless save operations. I think that would be just too much for everybody.

Well, that's a pickle.

admin wrote:(which BTW also include Highlighted Folders and Boxded Branches -- should have mentioned that in the change log, did that now)

At this point, you may as well separate all sections into separate inis.
Some sort of warning or alert could be presented near the Favorites checkbox then.

Or like this:

1) Extend the "Favorites" category to include "Favorites, Custom File Icons, and Custom File Associations" AND have all this in separate file "Favs.ini" (I think this kind of makes sense conceptually). These are all actively made settings (not just MRU lists) AND they are not done in "Configuration" (F9).

2) Add a category "Configuration" which will trigger an immediate save after you OK "Configuration" (F9).

That's very acceptable.
Maybe even separate MRU into MRU.ini while you're at it.

edit. okay. favs, CFI, CFA are auto-saved. Configs are autosaved with OK on config window. Then what about the lists at List Management. OK click there should definitely save too.

SammaySarkar wrote:Maybe even separate MRU into MRU.ini while you're at it.

Yes, probably a good idea.

SammaySarkar wrote:Then what about the lists at List Management. OK click there should definitely save too.

Puuh, you are basically right but it's difficult again. These are many different types of data that belong to different config files on disk. I would rather not touch that. To me List Management is a back door entrance to various settings for advanced users -- it's okay when it does not get the all-around-pampered autosave treatment.

admin wrote:it's okay when it does not get the all-around-pampered autosave treatment.

Sorry, but I think these are equally important.

SammaySarkar wrote:

admin wrote:it's okay when it does not get the all-around-pampered autosave treatment.

Sorry, but I think these are equally important.

I did not say they are not important. I just say: When you are patching MRU lists thru the back door don't expect to get your mouth wiped afterwards by mother XY.

Surely at least highlighted and boxed branches and aliases are not MRUs? (By list mgmt, I was thinking of these specifically.)
Other recent ... lists are not extremely important, I agree with you.

OK, I probably should do that.

Sorry but really, do users play with their Favorites that often that it in the end, it justifies going to a separate ini file and slowing down Xyplorer even a couple milliseconds. I'd say no. Reverse

Sorry Ken, but I like the idea of favorites being separated. My XY configuration practically never changes but
favorites do...

I don't disagree with having separate ini files in itself, but as Don said, it will translate in to slower start times. That's the only thing that bothers me. I think users like XY in general because Don has put the time and energy into to keeping it fast even with the myriad of updates. Many years ago I moved away from other File Managers because they were dog slow. So I tend to be against anything that will slow it down even a millisecond...just my opinion.

I understand but from a developers point of view: You'll never notice the difference.

You know that I'm currently porting xy_CEA and I test every procedure for it's execution
time and trust me, as an enduser you'll never notice if the startup time is 473ms or 478ms.
And ini file handling (opening, reading, processing) is in the range of 1 - 5 ms (depending
on size and transformations to do (e.g. resolving environment variables in strings).
So even if XY uses 10 ini files instead of one, you're only adding 10-50 ms to the startup
time. Again, you'll never notice the difference...

I understand and I realize I'm not going to notice 50 milliseconds, but I do notice a changes in the hundreds. I certainly notice going from my new ultrabook with less than 400 to my desktop of more than 700 start times. Speed should be one of the developer's top concerns and I know it is with Don. So I mention this only because I worry about the cumulative affect of multiple changes that affect start and execution times. You really change your Favorites that often that this would be a concern?