User is in contact with us, file manager isn't working, user doesn't have source code or terminal
User makes folder named lara (log ara) in their home directory
In that folder, a file with a name like run.txt sets additional environment variables
User runs built and installed file manager the regular way, off the Start menu or dock
File manager reads ~/lara/run.txt to set additional environment variables
File manager saves logs in text files in the lara folder, using the date and time and process id in the file name to avoid collisions
And, you can open Atom or Sublime to view the lara folder, and watch additional logs appear in the text files as the file manager runs. Not exactly the same as seeing the logs on the command line, but a similar experience.
Standard debugging practices assume that the software can be tested in the lab, and then shipped to the field, where it will perform equivalently well. If this is the case, debugging tools can be removed for the shipped version. With distributed apps, this may not be the case--so brainstorming ways to get the same tools working before and after shipping.
User is in contact with us, file manager isn't working, user doesn't have source code or terminal
lara(log ara) in their home directoryrun.txtsets additional environment variables~/lara/run.txtto set additional environment variableslarafolder, using the date and time and process id in the file name to avoid collisionsAnd, you can open Atom or Sublime to view the lara folder, and watch additional logs appear in the text files as the file manager runs. Not exactly the same as seeing the logs on the command line, but a similar experience.
Standard debugging practices assume that the software can be tested in the lab, and then shipped to the field, where it will perform equivalently well. If this is the case, debugging tools can be removed for the shipped version. With distributed apps, this may not be the case--so brainstorming ways to get the same tools working before and after shipping.