Is there a way to get colors in the text I sent to the debug console?
This does not work:
System.out.println(DBGContext+ "\u001B[41m" + _text + "\u001B[0m");
Is there a way to get colors in the text I sent to the debug console?
This does not work:
System.out.println(DBGContext+ "\u001B[41m" + _text + "\u001B[0m");
The debug console, in this case, meaning the Netbeans-based SDK?
Iâve never tried to do this. The Apache Netbeans site has a very old HOWTO that might provide a clue.
or just use System.err.println(ââ) to output RED text.
Also one tip is to use a facade. SLF4J or Javaâs own logging API (available from Java 9 and onward). Hook the facade then to actual logging implementation such as the already mentioned ones.
This does not change the outcome of course. This is just a type of architectural choice that potentially helps you in the long run. Only downside is that you might not get access to some logger specific stuff in the code (but you need to configure logger anyway so you can probably get around this anyway).
slf4j for the win.
Thanks all, it looks like there is more to it than I had hoped. I will look into it later on. For now I need to find other ways to make debug info more readable.
You could use the system shell for a quick trial, try this or a sort of it:
Process run = Runtime.getRuntime().exec(new String[]{"echo", "-e", "\033[38;2;255;50;50m", data}); // data is your data
if (run.waitFor() == 1) {
System.out.println("Run Failed!");
}
/* release resources */
run.destroy();
run = null;
And, then you could build an API around the system shell to serve this purpose, but you might need to put in mind the system specific shells.
EDIT:
This forks your process (e.g., Unix Process) for a new shell process and destroys it releasing the resources. Destruction could be modeled to run at the end of the jMonkeyEngine application or state, the close() event, and the subprocess could be modeled to run with a JME state initialization, ideally reducing memory allocation/deallocation overheads.
By accident I found out that the output window does take colors from a string:
To debug a problem I had with my FiFo-buffers and some illegal dumping of indexes, i captured a stacktrace in a string and dumped it in the output window later. It gave me these red letters instead of the default white letters I normally get.
Next step would be to find out what kind of codes are in this string, since the regular codes do not work.
I donât believe there is any color coding going on here - by default, Java prints stack traces to stderr, not stdout. Iâm pretty sure the coloring here is just the editor applying colors to output from stderr as a display effect, not parsing color control codes from the output stream.
If someone catches the exception and prints it, it wll be neutral of no red color even though it still be printed on the stderr stream. The best way to colorize text, from my opinion, is the ANSI colors, the String formatting may help.
This was the answer from GPT:
public static final String RESET = "\u001B[0m";
public static final String RED = "\u001B[31m";
public static final String GREEN = "\u001B[32m";
public static final String YELLOW = "\u001B[33m";
public static final String BLUE = "\u001B[34m";
public static final String PURPLE = "\u001B[35m";
public static final String CYAN = "\u001B[36m";
public static void main(String[] args) {
String text = String.format("%sThis is red text%s", RED, RESET);
System.out.println(text);
text = String.format("%sThis is green text%s", GREEN, RESET);
System.out.println(text);
text = String.format("%sThis is blue text%s", BLUE, RESET);
System.out.println(text);
Better than forking a new process just to run a BASH echoâŚ
EDIT:
You can still use the RGBA system, though, just instead of this ANSI.
Just note that they were talking about the âoutput windowâ of the IDE.
âŚwhether that window supports ANSI colors is in question but the recent topic was about the stack traces in that window.
I agree with danielp that itâs likely that the IDE is specifically parsing that content looking for âstuff that looks like a stack traceâ and coloring it. There arenât necessarily any specific âcodesâ to make that color. Itâs also whatâs making the .java line numbers clickable as links⌠which is certainly not and special codes that an application can output.
Most IDEs utilize an embedded terminal as an output window, however, yes it might be for Netbeans that would make a difference.
Furthermore, Fedor has tried here before, I guess it didnât work because of missing string formatting that would likely escape these characters and render them as color codes.
@danielp: as I explained, what you see is not just a e.stacktraceprint⌠i dumped a stack trace to a string for later use and a number of cycles later that string was printed in the IDE output window. It is definetely a string containing formatting codes - it also has working links to code lines.
@pspeed: I think that would be a very complicated solution for something that the good people who wrote NetBeans could have done a lot easier using formatting codes in strings.
Iâll run the string though a hex editor to have a look.
If you click this:
Does it take you to a line of source code?
âŚif so then they are doing a lot more than just interpreting some codes that they inserted themselves after parsing the Java stack trace. Plus, thatâs quite a rube-goldberg style solution.
Regular Java stack traces definitely do not include those codes nor does it include source code links. So they definitely ARE parsing it and doing something special.
Makes me wonder what it would do if you just print random lines that look like stack traces.
Well, the hex editor does agree with your assumption.
But I can confirm the links take you to the actual line.
And did the test you suggested by dumping a line that looks like a line of a stack trace and it did come out formatted:
The code was:
Utils.LOG("---TEST DUMPING LINE THAT LOOKS LIKE A STACK TRACE--- ");
Utils.LOG("at com.jme3.app.state.AppStateManager.update(AppStateManager.java:371)");