the Academic topic

[ChrisGreaves]

For questions of no real impact to the general user.
An example follows.
Cheers, Chris

[ChrisGreaves]

I choose Tools, Debug, Config and a Notepad.exe copy of the INI file pops up. I use INI files to govern all my applications, but am curious about Everything's use of an INI file.

Does the sequence of keys matter to Everything?

For example, suppose I sorted the INI file on the third character in each line - a somewhat random sequence - would Everything collapse in a heap? Probably not.

But to the best of my knowledge there are no "rules" surrounding a developer's use of sequence in INI files.

Some developers make use of named sections within an INI file; some developers check for duplicate keys, most I think do not.

Thanks, Chris

[tuska]

I choose Tools, Debug, Config and a Notepad.exe copy of the INI file pops up.

With Tools > Debug > Config the file "Everything.ini" is opened in an editor.
This is NOT a copy of this file that is opened.

[ChrisGreaves]

Code: Select all

Folder count:	68,220
...
Folders created:	2,811
Folders modified:	259,715
Folders deleted:	1,047
Folders moved:	6
Files created:	31,111

I can believe that I have 68,220 folders spread across my boot partition C: and my data partition T:.

I can't believe that I have created 2,811 folders since Everything 1.5.0.1341a was installed on my laptop a month or two ago.

259,715 folders in which a file has been modified seems a bit high, even for me. I spend my day working in MSWord documents, and have a Normal.dot macro that saves each open (and "dirty") document every 1 to 9 seconds; usually set at every one second, but even so 259,715 "saves" of documents in two months seems a bit high.
As does 1,047 folders deleted.

As well, I works hard, and I works fast, but not fast enough to create 31,111 files, even if they were ~*.* temporary files used by MSWord.

Comments and suggestions welcome.

P.S. I might take a similar snapshot at lunch time tomorrow, just to see how these selected data have changed.
Cheers, Chris

[ChrisGreaves]

And while we are at it,

Query Count: 2,721

, have I really made 2,721 queries (which I interpret to mean "executed search strings or filters")?
Cheers, Chris

[NotNull]

Does the sequence of keys matter to Everything?

For example, suppose I sorted the INI file on the third character in each line - a somewhat random sequence - would Everything collapse in a heap? Probably not.

But to the best of my knowledge there are no "rules" surrounding a developer's use of sequence in INI files.

Some developers make use of named sections within an INI file; some developers check for duplicate keys, most I think do not.

The sequence of the entries does not matter. However, when Everything exits and writes its ini-file to disk, it will be in a fixed order (per "module").
So all your hard work craftfully rearranging the ini-entries will be lost in the end.
A bit more practical use, commenting INI entries, is not an option either for that same reason.


Suppose a random INI file that looks like the following:

Code: Select all

[First section]
color=blue
color=red

[Second section]

The default way ini-files are processed by Windows is that the first entry (color=blue) wins.

In Everything, the last entry wins (color=red)

As their is just one INI-section - [Everything] - that means that you can safely add new/changed entries at the end of the INI file and they will be picked up by Everything.
(I hope this behaviour does not change in the near future, as that would mean I have to rewrite dozens of scripts ...)

[therube]

Shouldn't it be It's Academic or It’s Academic .

[ChrisGreaves]

... However, when Everything exits and writes its ini-file to disk, it will be in a fixed order (per "module")

Thanks for this, NotNull

As their is just one INI-section - [Everything] - that means that you can safely add new/changed entries at the end of the INI file and they will be picked up by Everything.

So an experimental version of a single INI setting had best be parked at the end of the file if it is to be used.

But your first comment suggests that Everything will read the INI file into some sort of structure when Everything is loaded, and then re-create the INI file on exit, so that any duplicate keys would be dropped anyway?
Thanks, Chris

[ChrisGreaves]

Shouldn't it be It's Academic or It’s Academic .

Yes!
Cheers, Chris

[NotNull]

So an experimental version of a single INI setting had best be parked at the end of the file if it is to be used.

But your first comment suggests that Everything will read the INI file into some sort of structure when Everything is loaded, and then re-create the INI file on exit, so that any duplicate keys would be dropped anyway?

Good thinking! (I *knew* I forgot some details ...)

Both are correct. Editing everything.ini is only useful when Everything is not running.
Or .. when you change the ini through Tools => Debug => Config. Everything will detect that the file has changed and will offer to reload settings from the modified ini-file

[Thy Grand Voidinesss]

[...]
Suppose a random INI file that looks like the following:

Code: Select all

[First section]
color=blue
color=red

[Second section]

The default way ini-files are processed by Windows is that the first entry (color=blue) wins.

In Everything, the last entry wins (color=red)
[...]

It is plain chaos with those INI files

Some programs leave them exactly as user modifies them in text editors while other become re-arranged the moment their program runs them [thus destroying visual indications a user might have implemented]

I just hate such dualities

[NotNull]

I just hate such dualities

I don't. All settings are included in the Everything.ini file. No exceptions. That is how it should be. (My opinion, of course)
I 'hate' [1] it when only exceptions are stored in the ini file, leaving no option to find out what all the settings and options of a program are.


[1] Hating is a useless activity. It does not help you forward.

[ChrisGreaves]

... Everything will detect that the file has changed and will offer to reload settings from the modified ini-file

But apparently not when the title/caption is being changed
Hmmmm.
Cheers, Chris

[NotNull]

Could very well be possible, but when I just tested, the ini settings were processed while Everything was restarting.

What I did:
- menu:Tools > Debug > Config
- In Notepad, I browsed to the end of the file
- added a new line with text

Code: Select all

window_title_format=blah blah blah

(note that there are no spaces around the = )
- Saved the file, exited Notepad
- Everything dialog: "Reload configuration file?" appears
- Yes to restart Everything

Result: Title = blah blah blah

[ChrisGreaves]

Result: Title = blah blah blah

Very strange.
Editing the INI file while Everything is running worked for me, too, Thank You.

But issuing the change by using the search box, it appears that Everything must exit and restart to effect the change.
(signed) "Puzzled" of Bonavista.

[void]

A common issue with using Tools > Debug > Config or about:config is Everything will only monitor for external changes to your config file AFTER making one of these calls.

If you open your config file with about:config or Tools > Debug > Config, make a change and save, accept the prompt in Everything to reload the config, the new instance of Everything will NOT monitor changes to your config that is left open.

It is important to close the config file in Notepad AFTER making a change and saving.



In the next alpha update, Everything will continue to monitor for external changes to your config file after Everything restarts.
(Technically, Everything will restart with the -watch-config command line option)

However, there's one caveat: Everything will stop monitoring for external changes to your config file if you close an Everything search window.
Closing an Everything window will overwrite your config file.



I recommend using search commands to set ini settings:

To set an ini setting from within Everything, type in the following search and press ENTER:
/name=value
where name is the ini setting name below.
If successful, you should see name=value in the status bar for a few seconds.

For example, in Everything, type in the following search and press ENTER:
/selected_border=1
If successful, you should see selected_border=1 in the status bar for a few seconds.



I know the /name=value search command is not very user friendly.
There is work being done on a UI to set any ini setting.

[ChrisGreaves]

A common issue with using Tools > Debug > Config or about:config is Everything will only monitor for external changes to your config file AFTER making one of these calls.

Thanks for this void; I am still on shaky ground here (with my limited understanding), but in general terms, if there is "a common issue with", ought that not to be resolved (in favour of less confusion to the user)? Perhaps that it what is involved in your further comments.

I think about this, I own about 150 applications/proof-of-concepts and make no use at all of the registry, relying always on INI files. I offer GUI forms to allow the user to change the INI files, and usually have the GUI forms update the INI file (on disk) as well as the Options data structure while the program is running. That means that the application allows only one changed item at a time. Exiting the textbox or triggering the text box Change event causes the change to be effected both during the run and in the stored INI file.

If a user edited the INI file in Notepad, saved the changes and THEN decided to check the change via the GUI file, the setting would appear unchanged because my application had no reason to think to load the GUI form from the INI file - it has its own Options data structure with which it loads the GUI form before writing the change (if any) to a single key in the GUI form back to the INI file.

More thinking needed here (by me!)

In the next alpha update, Everything will continue to monitor for external changes to your config file after Everything restarts.
(Technically, Everything will restart with the -watch-config command line option)

After the user makes a change from within Everything, does Everything rewrite the entire INI file back to disk, or only the affected key-value?

I recommend using search commands to set ini settings:
...
I know the /name=value search command is not very user friendly.
There is work being done on a UI to set any ini setting.

I understand. The great advantage of using an application to edit configuration files is that the application can choose to check the new setting for validity.

I should add that I have no great plans to edit the Everything.INI file with notepad.exe or any other editor. I suspect that Notepad came up as the only way to examine the available settings within Everything.

Thanks for all this
Chris

[ChrisGreaves]

Caveat 1: I was raised old-school windows with the maxim "Never Close, Never Minimize"
Caveat 2: I have read the two topics returned by this search.
Caveat 3: I operate a single-screen laptop, non-networked, in a home environment (although I used to work in big offices)

I am trying to dream up a working scenario where I might want to Tools, Options, Results, "Close Window on Execute". I even checked it ON, reloaded Everything, typed in a search string and tapped <Enter> and nothing closed!

Right now I suspect that the setting might be useful where Everything is invoked from a third-party application, and Everything is set up to pass the results of a search (which I see as the Result List) back to the third party application which called Everything.
That mythical scenario doesn't work for me, since I believe that on return to the third party application, that application would be maximized ("Never Close, Never Minimize") and thus hide the Everything Window from view.

Thanks for any insight
Chris

[horst.epp]

Right now I suspect that the setting might be useful where Everything is invoked from a third-party application, and Everything is set up to pass the results of a search (which I see as the Result List) back to the third party application which called Everything.
That mythical scenario doesn't work for me, since I believe that on return to the third party application, that application would be maximized ("Never Close, Never Minimize") and thus hide the Everything Window from view.

Thanks for any insight
Chris

We use scripts to get the results of the Everything GUI into a file list of a file manager.
There is no need to see the Everything results screen after the results are fetched by the script.
Everything will be closed by the script and the file manager displays the file list in its screens.
This works with many file managers like Total Commander, XYplorer or Free Commander.

[void]

Everything 1.5.0.1343a adds a -watch-config command line option.

Everything will now continue to monitor for external changes to your Everything.ini after using about:config.

if there is "a common issue with", ought that not to be resolved (in favour of less confusion to the user)?

Ideally, yes.
In practice... it takes time to rewrite features.

I think there's a line here, should Everything have advanced features in the UI? should they only be hidden in an ini/registry? do I have help in the UI/ini/registry or obscure details here on the forums.. etc..

I would like to treat the user as smart and give them the options if they know what they are doing.

about:config will make it easier for users who know what they are doing.

Everything 1.4 didn't have many hidden features.
It's getting a little out of hand with Everything 1.5.
Although, I would rather give the user options than not..

There's tonnes of room for improvement here.

If a user edited the INI file in Notepad, saved the changes and THEN decided to check the change via the GUI file, the setting would appear unchanged because my application had no reason to think to load the GUI form from the INI file - it has its own Options data structure with which it loads the GUI form before writing the change (if any) to a single key in the GUI form back to the INI file.

Everything stores settings in memory.
Everything will avoid reading/writing to disk.

After the user makes a change from within Everything, does Everything rewrite the entire INI file back to disk, or only the affected key-value?

The entire ini file.
One day, I would like to have support for writing out only the changed keys and allowing user comments.
For now, the entire ini is written for simplicity.

Maybe the experimental Tools -> Options -> Advanced page will replace the need to access the Everything.ini

I am trying to dream up a working scenario where I might want to Tools, Options, Results, "Close Window on Execute". I even checked it ON, reloaded Everything, typed in a search string and tapped <Enter> and nothing closed!

It's not close on search, it's close on execute (ie: when you open a result in Everything)
It was an option that was highly requested in early versions of Everything.
Users want to perform a search, open a result and have the Everything window closed in the background.

[NotNull]

Maybe the experimental Tools -> Options -> Advanced page will replace the need to access the Everything.ini

You tried really hard to hide/keep low profile this new feature, didn't you? Well ... you failed
This feature needs some public love and attention!

( Did you really filter all non-GUI settings manually to put them in the Advanced tab? That is *a lot* of work ... )


Opinion comes later.

[void]

It's too experimental to bring attention to yet...

There's a lot of known issues and I am working on a rewrite..
Temporarily disabling it was too much work, so I've left it in for now.

TODO list:
Show Value for current setting underneath the list. (remove the inline edit as it's too quirky)
Restore default / Reset for single item
Context menu to edit/copy/reset
Color picker
Descriptions for a few items, like window_title_format
Auto sizing the Name/Value column when resizing the window.
enum values for actions (instead of 1-4 have a drop down list of none/view/zoom/scroll etc..)

[NotNull]

remove the inline edit as it's too quirky

Is it? (can't assess as I'm quirky myself )
After all, It is Advanced: not for everyone and not for every day.

I find Firefox' about:config a perfectly fine UI /UX, for example.

[ChrisGreaves]

Ideally, yes. In practice... it takes time to rewrite features.

Tell Me!!!

I would like to treat the user as smart and give them the options if they know what they are doing.

And now that you have met me ,,, ?

Although, I would rather give the user options than not. There's tonnes of room for improvement here.

Agreed and agreed.

Can we step back a bit and first define what happens WHEN things change that cause an effect in the INI file:=

1: Will Everything claim the INI file as its own and not release it until Everything exits? If so, that doesn't mean a file-lock, but just that Everything loads the INI file into memory (a data structure of some sort), modifies the data in memory, and just before exiting, writes that memory back to the INI file. The user then is told/knows that editing the INI file while Everything is running is allowed BUT any changes WILL be clobbered on exiting Everything. And any environment changes will be lost if Everything crashes. Simple rules.

2. Will Everything treat the INI file as a shared resource? If so then Everything ought to monitor changes to the INI file whenever a value is called for. That suggests that Everything [re-]reads the INI file whenever it wants a value. To my mind that is no big deal because modern Windows buffering retains the file in RAM buffers and writes them back to disk promptly when disk activity drops. (If ***I*** were writing Windows I would check that there are no unwritten buffers before letting the user open a file)

3. With those (and possibly other design issues) established, we face the matter of how Everything edits values in the INI file.
In the case (1) just use Everything's internal data structure as the INI file, and ALWAYS write INI back to disk on exit. "Always" so that we can clobber any interim edits made by the user while Everything is running.
In the case (2) ALWAYS write INI back to disk on change. For the past ten years I have not been worried about disk activity on a 100KB file (my largest user-application INI file modified so far this month, and will you look at how effortlessly I built that search string :clapping:)

There's more, but I believe the principle of design is sound. There remains, as always, the question of what to do if a would-be expert (ahem!) makes a change to the INI file at 2a.m. on a sleepless night, and the edit carries an erroneous value. Presumably Everything has some sort of data validation in place ("window_x=10991098 looks like an erroneous value to me ... shall I set it to the default value for your system?")

As usual, the user will be responsible for his behaviour after receiving the warning "NEVER play with my INI file" but in some cases, that will be just an invitation to the user to investigate the INI file.

Consistency is the watchword. I feel right now that there are some times when I can get away with modifying INI while Everything is running, and some times when I can not.

Cheers, Chris

[Thy Grand Voidinesss]

[...]
I 'hate' [1] it when only exceptions are stored in the ini file, leaving no option to find out what all the settings and options of a program are.
[...]

With this I agree