Logos 8.4 Beta 4 (8.4.0.0021)

The Release Notes have:

Logging

• Added new logging to track when resources are removed, this is cumulative rather than for each session.
• On macOS the file is in the default logging folder.
• On Windows the file location is in the Faithlife folder which can be found by entering %localappdata%\Faithlife\Logs\Logos into the address bar in File Explorer.

Any reason why this logging file is not in the standard Logging file area?

It's potentially going to make it more difficult when asking people to submit logs if they are in different locations.

Graham,

The dev who worked on this is out on vacation until next week. I will ask him to respond when he gets back. He will know why it had to be saved there.

Thanks Philana 

On Windows the file location is in the Faithlife folder which can be found by entering %localappdata%\Faithlife\Logs\Logos into the address bar in File Explorer.

This sort of thing shouldn't happen. If the default folder is good enough for Mac, it should be good enough for Windows.

Graham and Dave, this was intentional. We plan to change the default location of logging files in the near future, in response to several user requests/ complaints. We didn't have time to change the default folder in this version, but we didn't want to exacerbate the problem by adding this new file. 

Adam,

What will this log reveal to Developers? EDIT: I removed 13 Local resources after the Initial State was logged, and nothing was added!?

Will it log data only when (normal) logging is enabled?

As it is cumulative, how large will it grow? Can it be deleted by the user?

I presume that the \logs folder will contain Logos, Verbum & Noet sub-folders?

Graham and Dave, this was intentional. We plan to change the default location of logging files in the near future, in response to several We didn't have time to change the default folder in this version, but we didn't want to exacerbate the problem by adding this new file. 

Thanks Adam. I wondered if that was the reason behind it, good to get confirmation.

What will this log reveal to Developers?

Developers might benefit, but they are not the primary audience. The intention is to help users and Customer Service answer questions like "why did my library count go from 1,034 last week to 1,032 this week?" 

I presume that the \logs folder will contain Logos, Verbum & Noet sub-folders?

That is the intention for the future, yes.

I don't have definitive answers to your other questions right now. (I think I know, but I don't want to risk a wrong answer.) We'll have to get back to you when Andrew is back from vacation.

This sort of thing shouldn't happen. If the default folder is good enough for Mac, it should be good enough for Windows.

Amen[Y]

I removed 13 Local resources after the Initial State was logged, and nothing was added!?

That could be a bug, or it could be that you removed those resources before the initial state got logged. In order to determine, we would need to see both the log file and the audit log.

Will it log data only when (normal) logging is enabled?

This information will always be logged.

As it is cumulative, how large will it grow?

In most cases, it's not likely to grow huge, as the number of times you add and remove resources from your library are fairly limited.

Can it be deleted by the user?

Yes, feel free to delete it whenever you wish.

I presume that the \logs folder will contain Logos, Verbum & Noet sub-folders?

Yes, correct.

I removed 13 Local resources after the Initial State was logged, and nothing was added!?

That could be a bug, or it could be that you removed those resources before the initial state got logged. In order to determine, we would need to see both the log file and the audit log.

I had noted the contents of the file before removing the resources. But here is a case with the required log files. The Audit file was created during a fresh installation.

>> "Contents entered into the Command Box are now cleared upon commit."

I was getting used to my commands being saved and not cleared. Is there anyway a user could click in the command box and then press "down" to tab through their latest history of commands? Basically how most command lines works?

>> "Contents entered into the Command Box are now cleared upon commit."

I was getting used to my commands being saved and not cleared. Is there anyway a user could click in the command box and then press "down" to tab through their latest history of commands? Basically how most command lines works?

I agree - I am missing this feature when using the beta

I'm currently working with the stable version of 8.3 (office computer) and find having the commands persist is helpful!

I seem to remember some discussions and user requests that would support this change but I can't find them now.

So interested to know what the reason is behind this change.

The reason for the change is 1) to reduce visual clutter on the screen, and 2) to reduce the friction on entering your next command. 

Having said that, I really like the idea of retaining a history of previous commands; I found myself wishing for that just this past week. 

When focus is set to an empty Go box, would you prefer a list of: 

• Previous inputs. Select from a list of things you typed, to populate the box and generate command suggestions. Pro: This would be more flexible, and would help with exploring different command options for the same input. Con: Two steps instead of one. 
• Previous commands. Show only the command that was previously executed, run immediately on click/enter. 

Thoughts?

Thanks Adam

The reason for the change is 1) to reduce visual clutter on the screen, and 2) to reduce the friction on entering your next command. 

Those both make a lot of sense!

When focus is set to an empty Go box, would you prefer a list of: 

• Previous inputs. Select from a list of things you typed, to populate the box and generate command suggestions. Pro: This would be more flexible, and would help with exploring different command options for the same input. Con: Two steps instead of one. 
• Previous commands. Show only the command that was previously executed, run immediately on click/enter. 

I think I would prefer the first option - "Previous inputs"

The reason for the change is 1) to reduce visual clutter on the screen, and 2) to reduce the friction on entering your next command. 

Having said that, I really like the idea of retaining a history of previous commands; I found myself wishing for that just this past week. 

When focus is set to an empty Go box, would you prefer a list of: 

• Previous inputs. Select from a list of things you typed, to populate the box and generate command suggestions. Pro: This would be more flexible, and would help with exploring different command options for the same input. Con: Two steps instead of one. 
• Previous commands. Show only the command that was previously executed, run immediately on click/enter. 

Thoughts?

I can't fully imagine how "Previous inputs" would work, but I do like the idea of being click/enter away from my latest command or search. And having suggestion commands is always helpful. Maybe both? Though, I do like how google does it. It should "History" on click/down and then saves suggestions for when you start typing.

The reason for the change is 1) to reduce visual clutter on the screen, and 2) to reduce the friction on entering your next command. 

I'm partly in favour of the change, because previously opening a search tab would populate the search criteria with my last command. That was annoying.

On the other hand, now, if you mistype a command, or accidentally open the wrong book, it's a pain to have to retype the whole thing.

My preference, therefore, would be to have the exact input restored to the command box (not the completed command that was executed).

When focus is set to an empty Go box, would you prefer a list of: 

• Previous inputs. Select from a list of things you typed, to populate the box and generate command suggestions. Pro: This would be more flexible, and would help with exploring different command options for the same input. Con: Two steps instead of one. 
• Previous commands. Show only the command that was previously executed, run immediately on click/enter. 

Previous inputs, as this reflects what was retained in previous versions.

I too prefer previous inputs, Google-style.

Previous inputs

When focus is set to an empty Go box, would you prefer a list of: 

• Previous inputs. Select from a list of things you typed, to populate the box and generate command suggestions. Pro: This would be more flexible, and would help with exploring different command options for the same input. Con: Two steps instead of one. 
• Previous commands. Show only the command that was previously executed, run immediately on click/enter. 

Thoughts?

Most definitely previous inputs.

Previous inputs, please.