This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Find functionality for log viewer #4929
Comments
|
Comment 2 by leonarddr on 2015-02-17 11:56 |
|
Comment 3 by jteh on 2015-02-18 03:44 |
…is very similar to the find commands from cursorManager but also lets you search by regular expression. The search matches are selected like in Notepad. The entire text buffer is searched, which may cause problems with very large logs. Another option would be to search line-by-line.
…is very similar to the find commands from cursorManager but also lets you search by regular expression. The search matches are selected like in Notepad. The entire text buffer is searched, which may cause problems with very large logs. Another option would be to search line-by-line.
|
@dkager Could you please share further updates about related implementation work you were doing almost two years ago? |
|
No, it needs code review. |
|
Hi, |
|
For me, it is a very important, and needed, feature!
Rui Fontes
Às 14:34 de 11/08/2019, Clément Boussiron escreveu:
… Hi,
This issue is not yet solved.
I think it is an issue which allow developper to optimize there time.
Are you interested if I try to fixe this?
CC @LeonarddeR <https://github.com/leonardder> @josephsl
<https://github.com/josephsl> @feerrenrut <https://github.com/feerrenrut>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4929?email_source=notifications&email_token=ADZAPRRCW4XTVFOKT4SXI23QEAIPRA5CNFSM4DZYCWU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BBBGA#issuecomment-520229016>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADZAPRWXA3GWJRWXG3VYGGTQEAIPRANCNFSM4DZYCWUQ>.
|
|
That would be a very welcome feature.
I had it in mind to implement as part of debugHelper add-on, not being aware of
this issue, but core would be a much better place for it.
|
|
I started to implement this problem, but I do not understand what is the right way to handle keyboard shortcuts in a frame or dialog box. |
|
cc: @josephsl |
|
I argue that there are better standalone tools that already exist for reading / searching large text files. Building and maintaining something within NVDA is misguided effort considering all the other work there is to do. I would be more inclined to simplify the log viewer, make it friendlier for non-developers to use to provide logs / info when debugging an issue. |
|
What would simplifying look like? I'm not sure how it could get more simple than
it is now.
That said, if you do want to make it more friendly for non-developers, wouldn't
find functionality do that?
It is much more likely for a developer to make the added effort to select all,
copy, close, open notepad++ or whatever, paste, and then search, then for a
non-developer.
A non-developer is more likely to take one look at the log, say "I ain't dealing
with all this nonsense", and post the whole darn thing to an issue or list.
|
|
Let me make another point in favor of find functionality:
Recently, I was trying to debug an add-on against beta. The case in question is probably a bug in core, but it was hard to tell. So it involved some dozens of very slight code changes, each followed by replacing the file in scratchpad, and restarting NVDA to run the test.
The test involved many lines of log data on each side of the generated error.
Each time, if find was possible in the log viewer, I could have done a very quick search for the info text I was causing to be logged near the error, or marks inserted by debugHelper add-on, found and read the error, and figured out the next change to make.
Instead, I usually had to copy the log into, or open it in, notepad or the like, just to be able to do a control-f to look for what I wanted.
So in my case, what the lack of this feature caused, was a waste of developer time. Sure, only maybe 10-15 seconds more per attempt, but still that adds up. And in an activity full of hundreds of very similar keyboard operations, I am sure it added to errors causing a few needed repeat steps.
I would argue that if we're going to provide a log viewer at all, we should make it as efficient for the people most likely to find it useful as we can without compromising over all functionality.
And now, I will undermine my own argument.
That all happened at the end of a 16 hour day, on very little sleep to begin with. On the other side of it now, I realize I probably should have opened old and new logs in Notepad++, and used the file reload feature to keep it current. Still several more keystrokes than find functionality in log viewer, but more efficient than what I was doing.
|
|
Hi all,
Of course, I know that most of these tasks can be performed inside a text editor, but it can be tedious and I personally think that having a good log viewer is a key to success for open source projects that are constantly evolving. |
Rather than encouraging people to read the log in our log viewer, perhaps we launch the default associated application. It is fairly easy to associate say notepad++ with *.log viewer. There are essentially two types of users at the moment:
My argument is that we can quite easily provide a better experience for non-developers, and developers would be better served by a dedicated external tool. Especially since the requirements and workflow of each developer are largely specific to them. It might be something versatile like notepad++, or several other much more specific tools EG (No endorsement or warranty provided by me, just the results of a google search for "log viewer tool"): Personally I use a plugin for PyCharm called 'ideolog' which basically just provides highlighting of categories. If someone really wants to do NVDA specific development, extending a preexisting open source log viewer tool would be a better option in my opinion. |
|
I agree that attributing the log file to a Standard app like Notepad++ or even Notepad would be enough for a non developer. Notepad is installed on every Windows PC by Default so the user would not Need to install anything. |
|
with hindsight I am aware that this is not really necessary, it is true that I forget the possibility of using an external log viewer. |
|
Before closing this issue, I wonder if there is a way to force NVDA to open the log file in Notepad? Or maybe we could add a checkbox in advanced settings pannel called "use NVDA's own log editor". |
|
Rather than opening the log file using Notepad, we can tell windows to open the file directly. This way, it will use the default application that is configured with .log files and ask the user for an application if it is the first time he/she tries to open a .log file. |
|
I asked:
What would simplifying look like? I'm not sure how it could get more simple than
it is now.
@feerrenrut answered:
Rather than encouraging people to read the log in our log viewer, perhaps we launch the default associated application. It is fairly easy to associate say notepad++ with *.log viewer.
You know, I rather like that. Can you put a checkbox in advanced, unchecked by
default, that does exactly this? Unchecked by default, because people may not
have .log assigned to any application. At which point they follow somebody's
instructions on a mailing list to use NVDA+F1, and get Windows prompting for an
application choice.
There's only one real downside I can think of to this. The log viewer as it
stands, is really intended to present requested current object information, with
the log conveniently above it, and the cursor located at the boundary. If we do
things this way, that function will be lost.
But see my suggestion below for why that may not matter.
There are essentially two types of users at the moment:
* Non-developers who are trying to either capture information for debugging. Typically this is either:
Obviously dealing with this case would require some thought, and some work.
But for the developer case, you've sold me. It just requires dividing the two
issues.
I wonder if an intermediate step might be to separate dev info for objects from
the log entirely? Consider the following suggestion:
1. Keep the NVDA+F1 for log viewer, but stop logging dev info there..
2. Use log viewer only if the checkbox suggested above is off, otherwise use
system .log association.
3. Create a new key, perhaps NVDA+alt+F1, that brings up the object dev info in
a ui.browseableMessage window.
|
|
I would advice not to introduce a separate key stroke just for the developer info. This should be still part of the log file. Actually, if the log file open in Notepad or any other Editor and you search for "Developer info for navigator object" the Cursor will jump right to the developer info. |
I was picturing the following:
|
|
Adriani90 wrote:
I would advice not to introduce a separate key stroke just for the developer info. This should be still part of the log file. Actually, if the log file open
in Notepad or any other Editor and you search for "Developer info for navigator object" the Cursor will jump right to the developer info.
Unless you have been getting dev info for a long series of objects in the same
session, then you have to figure out which one it is.
That said, I have never really thought that object dev info belonged in the log.
|
|
The idea given by @feerrenrut makes a lot of sense however I personally would do it slightly differently:
Just out of curiosity what you want to have included in the system info which isn't in the log already? |
|
@XLTechie ok I see your Point. So that means, in @feerrenrut's proposed Approach the dev info for the current focused object is being displayed when pressing nvda+f1 but all other dev Infos are stored anywhere else? How do we make sure that the user or the non developer gets directed right to the dev info of a certain object? At least in a log file an user can search for an Action or a time stamp which Points near to the desired dev info. |
|
Note that opening the log file in the default text editor would
eliminate the possibility to refresh, unless you're using something
fancy as NP++.
|
|
Adriani90 wrote:
@XLTechie ok I see your Point. So that means, in @feerrenrut's proposed Approach the dev info for the current focused object is being displayed when
pressing nvda+f1 but all other dev Infos are stored anywhere else? How do we make sure that the user or the non developer gets directed right to the dev
info of a certain object? At least in a log file an user can search for an Action or a time stamp which Points near to the desired dev info.
I still maintain that the object dev info doesn't need to be, or belong, in the
log. So if you press the key to see dev info (in a ui.browseableMessage), you
can copy and paste it to an email, or whatever else. In other words: it isn't
getting stored anywhere in the new model. If you're developing a
module, and you need to look at a lot of these, you won't need to store them in
the log most of the time anyway.
But, I suggest two buttons:
copy to clipboard: puts the dev info on the clipboard, saving you the control-a,
control-c. Probably not necessary, but every app and website I come across these
days provides copy shortcuts.
Other button:
Save to log
With a keyboard shortcut, this one just sticks the dev info in the log like it
is now, for those who still find value in that functionality, such as if you
need the dev info from a lot of objects in an app you are working on or
whatever.
So here's another possible way to implement these changes.
1. I'm still not sure the log functionality and the dev info functionality
really need to be linked at all, even in the same window. So, make the NVDA-F1
bring up the dev info viewer as @feerrenrut described, with the "copy it" and
"log it" buttons I suggested above.
2. Convert the tools "View Log" item, into a submenu: view current log, view log
from last session, and @feerrenrut's zip up everything possible option. Provide
unassigned gestures for these.
3. In advanced, give the checkbox as previously mentioned, that chooses between
the internal log viewer and the registered system handler for .log files.
|
|
ukasz Golonka wrote:
4. Adding the automatic export of logs is problematic mostly because it would eliminate possibility of shortening these logs - it is not possible to edit
files for which NVDA still has an open handle, so in my opinion collecting logs should still be a manual process.
To be more specific about that: it is possible to edit them, it is just not
possible to save them. So as long as a copy is made first in this process, it
would work, although I'm not sure what that would look like either in my latest
suggestion, or @feerrenrut's idea.
I will also note that @feerrenrut's zip option, is not unlike what the Crash
Hero add-on (about to be released as Python3) by @derekriemer does.
|
seanbudd
added
the
good first issue
|
The scope of this ticket seems to have morphed into something bigger than a Find dialog; the issue may need to be edited to reflect that. The one thought I might add is that while the Log Viewer presently shows the log from the current session to the user, it does not interface with nvda-old.log. It is not clear to me why that should remain the case, especially given that there is no documentation nor is it common knowledge that the log of the previous session can be found in %temp% (even if that was not the case, it has the same qualms as opening nvda.log through %temp%). I suggest that any simplification/redesign of NVDA's Log Viewer includes or considers future inclusion of support for nvda-old.log. |
|
I suggest this long discussion to be closed, and newer issues created as result of the discussions |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Reported by leonarddr on 2015-02-17 11:51
I'd like to suggest find functionality (i.e. a find dialog, find next/find previous options) for the NVDA log viewer. Now, it is actually quite hard to explore huge logs, especially when NVDA logging is set to debug and the screen reader is running for several hours. I normally copy the contents of the log viewer to notepad and search using notepad's functionality, but it shouldn't be that difficult to incorporate such functionality in NVDA.
The text was updated successfully, but these errors were encountered: