So do you just mean it identifies itself as being from BrailleBlaster?I had thought you meant identify which part of BrailleBlaster (eg BrailleBlaster, liblouisutdml, liblouis, etc).
Just to insert BrailleBlaster into one of the strings is simple enough. Michael Whapples On 08/08/2014 11:36, Larry Skutchan wrote:
Yes, 3 is what I am concerned about. When the user's work gets interrupted, they need to know from where the error came. Take the situation where the user may actually have BB running in the background and it crashes. The user needs some context to know where to look. This is especially important as we stabilize and forget about this message box, then two years down the road, it pops up unexpectedly. -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Friday, August 8, 2014 6:26 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: 4 new revisions pushed by mwhapples on 2014-08-08 08:14 GMT OK, I think there are three types of error and what we can do for each may differ. 1. Something in BrailleBlaster does not work as the user expects but it does not affect BrailleBlaster's ability to run. An example of this might be a translation error where the Braille is not what the user expects. As no programatic error condition is encountered there is little to be done automatically. May be what we could do is have it that in the log viewer the user can press a button to insert a marker message in the log to help the developer locate the part of the log where the error occurred. It would require the user to open the log viewer and mark the log immediately for it to be effective. 2. Expected errors. These are error conditions we expect may occur from time to time and so may specifically handle. An example of this might be the user trying to write to a location where the user has no write permissions. These errors should not require the user to view the log as the error message should explain what is wrong and help the user correct what they are doing. 3. Uncaught exceptions. These are error conditions where the Java code has thrown an exception but it has not been specifically handled. An example of this might include that error with a space in the URI of the DTD preventing loading nimas files we had at the beginning of the week. I have covered this situation and an error message is automatically inserted into the log at that point and the user is asked whether they want to view the log (so they can send it to a developer). 4. A crash, BrailleBlaster falls over ungracefully. There is little we can do here. However with proper coding this should never happen. If BrailleBlaster and its dependencies were all pure Java it would never occur. It is one thing which hopefully would be improved by rewriting liblouisutdml. Whilst I think liblouis is not immune to this issue I think it is rare enough now that it should not be a problem to us if we use liblouis correctly. If the user knows where to locate the log file then this could be sent to the developer, whether it would contain enough detail to explain why the crash happened might be questionable but at least the developer would know what was done leading up to the crash. So situation 2 I think is irrelevant to what we are discussing at the moment as the user should be able to sort it out themself. Situation 1 we cannot do anything automatically but with cooperation from the user they can help the developer. The exact cause though cannot be identified by software. Situation 4 is too complicated I think for dealing with now and in the ideal world should not be an issue. Situation 3 is the only one I think we can consider at the moment for what you describe. The error dialog presented to the user does not identify the source (as I said I have doubts to the value of that and how accurate we could really be anyway) but the log file does contain information to identify this interruption so the developer can see where things went wrong and why. Is this doing what you want or is there something else needed? Michael Whapples On 08/08/2014 10:51, Larry Skutchan wrote:All we really want for now is a way to identify an interruption to the user's use of the program. Does the technique of initializing the log file with Braille Blaster Log offer us a simple way to accomplish this? -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Friday, August 8, 2014 5:47 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: 4 new revisions pushed by mwhapples on 2014-08-08 08:14 GMT I forgot also to say, of course if the user selects the "View log" option from the help menu there is no cause other than the user choosing to. Again in such a situation the individual log messages in the log file contain information on where they come from. My thought here is going a bit, how useful is it really for the user to be informed as to the cause of the error in the title? If the user sends the log to a developer then the developer will have sufficient detail to know where the source of the error is. Is there sufficient value to the effort to implement? Michael Whapples On 08/08/2014 10:35, Michael Whapples (Redacted sender mwhapples@xxxxxxx for DMARC) wrote:Hello, Could you expand a little on the topic of wording of where the error comes from? At the moment, if an unexpected error is encountered (a more technical explanation is if an uncaught exception is thrown) then a message box appears: Message box title: "Unexpected error" Message box message: "An unexpected error was encountered, would you like to view the log?" Message box buttons: "Yes" or "No" At the moment I doubt the exception will contain enough information to identify whether the exception was thrown by LibLouis, LibLouisUTDML, BrailleBlaster or other package. Basically the issue is that liblouis and liblouisutdml being written in C, these never will throw exceptions and thus exceptions related to liblouis or liblouisutdml errors will be thrown by a BrailleBlaster wrapper. I have an idea how to possibly make this work. It is also worth noting that the actual log messages in the log file are different to the exception, these will at least identify whether they are related to liblouis or liblouisutdml or whether they come from BrailleBlaster. It is also very important to note that should there be a crash (eg. memory access violation in C), using the current approach there is no chance of capturing any useful information. I am not sure how much could be done to catch crashes, the solution would be much more complicated. Michael Whapples On 08/08/2014 10:18, Larry Skutchan wrote:Also, I wish to ensure that the title of the dialog contains wording to let the user know from where this error comes , especially if it appears as the result of a crash. Something like: Braille Blaster Problem Alert -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Friday, August 8, 2014 5:10 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: 4 new revisions pushed by mwhapples on 2014-08-08 08:14 GMT Go to the help menu and choose "View log". Alternatively if an unexpected error is encountered then it will ask you whether you want to view the log. It is worth noting that at the moment the log does not start from fresh each time you run BrailleBlaster, it might be something we should do now that you can view the log in BrailleBlaster. Michael Whapples On 08/08/2014 09:58, Vic Beckley wrote:Michael, How do you view the log? Best regards from Ohio, Vic -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of brailleblaster@xxxxxxxxxxxxxx Sent: Friday, August 08, 2014 4:15 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] 4 new revisions pushed by mwhapples on 2014-08-08 08:14 GMT 4 new revisions: Revision: afd8c23f74d0 Branch: rt762 Author: Michael Whapples Date: Thu Aug 7 13:13:23 2014 UTC Log: Add a error message should the log file not be possible to read http://code.google.com/p/brailleblaster/source/detail?r=afd8c23f74d 0 Revision: 38cee9143f7b Branch: rt762 Author: Michael Whapples Date: Thu Aug 7 13:15:07 2014 UTC Log: merge with default http://code.google.com/p/brailleblaster/source/detail?r=38cee9143f7 b Revision: d454363fbce3 Branch: rt762 Author: Michael Whapples Date: Fri Aug 8 08:13:03 2014 UTC Log: Add select all to log view http://code.google.com/p/brailleblaster/source/detail?r=d454363fbce 3 Revision: 74caf8f12ecf Branch: rt762 Author: Michael Whapples Date: Fri Aug 8 08:14:23 2014 UTC Log: Merge with default http://code.google.com/p/brailleblaster/source/detail?r=74caf8f12ec f =================================================================== = ======== == Revision: afd8c23f74d0 Branch: rt762 Author: Michael Whapples Date: Thu Aug 7 13:13:23 2014 UTC Log: Add a error message should the log file not be possible to read http://code.google.com/p/brailleblaster/source/detail?r=afd8c23f74d 0 Modified: /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java ======================================= --- /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java Thu Aug 7 11:01:32 2014 UTC +++ /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java +++ Thu Aug 7 13:13:23 2014 UTC @@ -18,10 +18,14 @@ import org.eclipse.swt.widgets.Control; import org.eclipse.swt.widgets.Dialog; import org.eclipse.swt.widgets.Display; +import org.eclipse.swt.widgets.MessageBox; import org.eclipse.swt.widgets.Shell; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; public class LogViewerDialog extends Dialog { + private static Logger log = LoggerFactory.getLogger(LogViewerDialog.class); boolean result = false; private static String readFileToString(File inFile) throws IOException { StringBuffer buf = new StringBuffer(); @@ -78,7 +82,12 @@ try { logText.setText(readFileToString(new File(BBIni.getLogFilesPath(), "bb.log"))); } catch(IOException e) { - // Give some error message. + log.error("Problem opening the log file", e); + MessageBox msgBox = new MessageBox(parent, SWT.ICON_ERROR | SWT.OK); + msgBox.setText("Unable to open log file"); + msgBox.setMessage("There was a problem in reading the log file, so the log viewer will not be opened."); + result = false; + return result; } dialogShell.setTabList(new Control[] {logText, closeButton, logText}); dialogShell.pack(); =================================================================== = ======== == Revision: 38cee9143f7b Branch: rt762 Author: Michael Whapples Date: Thu Aug 7 13:15:07 2014 UTC Log: merge with default http://code.google.com/p/brailleblaster/source/detail?r=38cee9143f7 b =================================================================== = ======== == Revision: d454363fbce3 Branch: rt762 Author: Michael Whapples Date: Fri Aug 8 08:13:03 2014 UTC Log: Add select all to log view http://code.google.com/p/brailleblaster/source/detail?r=d454363fbce 3 Modified: /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java ======================================= --- /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java Thu Aug 7 13:13:23 2014 UTC +++ /src/main/org/brailleblaster/wordprocessor/LogViewerDialog.java +++ Fri Aug 8 08:13:03 2014 UTC @@ -7,6 +7,7 @@ import org.brailleblaster.BBIni; import org.eclipse.swt.SWT; +import org.eclipse.swt.custom.ST; import org.eclipse.swt.custom.StyledText; import org.eclipse.swt.events.SelectionAdapter; import org.eclipse.swt.events.SelectionEvent; @@ -89,6 +90,7 @@ result = false; return result; } + logText.setKeyBinding('a' | SWT.MOD1, ST.SELECT_ALL); dialogShell.setTabList(new Control[] {logText, closeButton, logText}); dialogShell.pack(); dialogShell.open(); =================================================================== = ======== == Revision: 74caf8f12ecf Branch: rt762 Author: Michael Whapples Date: Fri Aug 8 08:14:23 2014 UTC Log: Merge with default http://code.google.com/p/brailleblaster/source/detail?r=74caf8f12ec f
