-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NVDA Log Files should be identifiable both by version that created them and, for portable or "running from installer" versus installed #15555
Comments
I often use NVDA to examine software accessibility. The date and time of the creation of a log would also be very helpful. |
I certainly wouldn't object to date-time being added to the name of the log file. |
@britechguy, |
Desires are one thing, feature requests are another. |
I don't think it is a thing to even beeing considered.
As Abhishek already stated, all needed information is already in the
log so i'd personaly vote against any change. No need logs to be
scattered.
…On 10/1/23, Yeti ***@***.***> wrote:
Desires are one thing, feature requests are another.
I'm sorry that I didn't give sufficient consideration to the issue of
security :-(
--
Reply to this email directly or view it on GitHub:
#15555 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
--
with best regards Beqa Gozalishvili
Tell: +995593454005
Email: ***@***.***
Web: https://gozaltech.org
Skype: beqabeqa473
Telegram: https://t.me/gozaltech
facebook: https://facebook.com/gozaltech
twitter: https://twitter.com/beqabeqa473
Instagram: https://instagram.com/beqa.gozalishvili
|
No, in portable versions they are in a sub menu of the folder you put the program into.
This is also why there should be no changes as it makes it very easy to drop a batch file into each folder to grab the old log and load it into notepad. Thus if every version you are testing is in its own folder then where is the problem.
I'm sure the security in windows would complain bitterly if the info in the user config of a portable version was going to ask to be saved in app data folders.
Brian
…--
***@***.***
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
***@***.***, putting 'Brian Gaff'
in the display name field.
|
And, yet, they are. We just went through this, at length, yesterday on the NVDA group, which is part of what triggered my request. See topic: 2 bugs found in latest Beta 3 If you want to argue with Rui Fontes, myself, Sarah Alawami, & Luke Davis about where we find our nvda.log and nvda-old.log files stored, no matter what NVDA "run type" we're using, have at it. @beqabeqa473: I have no idea what you're talking about with logs being scattered. I proposed log file names that give a clear indication of their exact genesis. I did not propose having them in any folder location other than %TEMP% @AbhishekSRaut : You believe that this setup is "generally practical" and I absolutely, positively do not. It requres gyrations on the part of users that should not be necessary, and makes their participating in the debugging process more complicated than it need be. |
Although not exactly answering to this request, NVDA Dev & Test Toolbox add-on allows to save a configurable number of logs timestamped with date/time. Of course the add-on does not replace a built-in feature; and in case of assistance, it's interesting to have the feature directly built in NVDA. But the add-on can be a source of inspiration. If more than two logs (nvda.log and nvda-old.log) are saved in %temp%, we should ensure that an assisted user will be able to find and send the appropriate log. Giving instructions such as "Send us nvda-old.log and nvda.log" are clearer and more universal; but in the case of various versions of NVDA (portable, installed, etc.) I acknowledge that it can lead to confusion. |
@echo off
cd "%temp%"
start /WAIT nvda.exe -q
start notepad.exe nvda.log
rem, this line just kicks its heels for a bit to make sure the log is loaded into notepad before rebooting nvda.
ping -n 5 127.0.0.1>nul
start nvda.exe
exit
How about the above shoved somewhere and run to reboot your stable version and loading the log of the other version into notepad?
…--
***@***.***
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
***@***.***, putting 'Brian Gaff'
in the display name field.
|
While I understand your script, even is not necessary, strictly speaking, in many instances. If it's only 2 successive invocations of NVDA, the latest one would be logged in nvda.log, and the immediately prior invocation would still be available in nvda-old.log. This entire feature request has arisen out of what one has to do in order to adequately test issue #15554, which arose out of work I was doing for issue #15397. In the situation that was going on, there was no way to adequately test this without invoking the NVDA installer instance without using a command line and LOGFILE switch. I doubt that this has been, or will be, the sole instance where this is the case. Hence, this feature request. |
See also #12621 |
Is your feature request related to a problem? Please describe.
At the moment, NVDA, whether portable, running from installer, or running as installed all use %TEMP% as the location for both nvda.log, and nvda-old.log.
When attempting to diagnose issues using older versions of NVDA, run as portable or from installer, as well as running whatever the latest installed version happens to be, this results in each one respectively "clobbering" the nvda.log of the other and, potentially, even the nvda-old.log.
Describe the solution you'd like
I would like to see the generic nvda.log, and nvda-old.log, additionally identified with the version of NVDA that created them, as well as "how they were run" if the latter is practical, and I have to believe it would be.
I would far sooner see nvda2023.beta3_installed.log or nvda_2023.1_portable.log or nvda2023.2_installer.log, and the same thing for their respective -old equivalents. It makes it immediately clear what version of NVDA generated the log as well as how that particular run of NVDA was performed.
Describe alternatives you've considered
None
Additional context
N/A
The text was updated successfully, but these errors were encountered: