Output area improvements

[BeayemX]

I think there are some ways the output could be improved. I'm interested in what you think and if you have other suggestions.

1. At the moment the output area just displays text. But you can't really tell where the print()-call came from. In unity for example it shows the file name and the line number. And you can also double click the text to jump directly to the print()-call (as described here Double clicking on message in output should jump to file and line where message is printed #10566 ).
2. The next thing in unity is, that there are different versions of logs. You can use Debug.Log(), Debug.LogWarning() and Debug.LogError(). These logs show up with different icons leading the text and the text is a different color. You can also selectively toggle which types of logs should be displayed. Even though this is quite nice to have 3 different options to select from, I think it would be quite interesting to go one step further. Maybe let us create our own tags to use. You could select an icon for these tags and set a specific color. And some kind of filtering mechanism would also be helpful.
3. In unity you can use rich text markup to add different styles to the string. I'm not sure if this is necessary, but it just crossed my mind when thinking about improving the output.
4. Another feature from unity is that you can use a game-object as a second parameter, like so public static void Log(object message, Object context);. When clicking only once on the output-log it highlights this object in the scene-hierarchy. In godot it could bring up the remote-inspector and show the context-object selected in the live scene tree.

I know I mentioned a lot of unity-like behavior, but I think many developers could benefit from some of these features. So what are your thoughts?

[Zireael07]

1 and 2 are very useful indeed. Less sure about 3 and 4.

[BeayemX]

I have to agree. 3 and 4 are interesting concepts but I haven't used them besides trying out the functionality and I can't think of any good use cases.

[Zylann]

The only place where I used 3) was in a very big project where there are so many logs that I can't tell mine apart when I debug realtime flows, so I output it with a special color not already in use to see it pop out.

Also note that in Unity, 1) doesn't only give you filename and line, but also the whole call stack that led to this log.
This becomes even more useful when the project reaches a stage where you need to wrap the prints into a function to handle logs in a more custom way, because doing so makes every origin end up in your custom system instead of the actual place where it was used.
Not saying it must be in Godot, just mentionning that this kind of practice exists, and some projects end up doing that.

[blurymind]

guys this is all good thinking, but currently godot's output area doesnt even output most printing messages in certain cases. There have been some regressions that have forced me to use the damned dos terminal windows has to get my prints. Text overflow now completely breaks output in godot 2.1.4
#1287
if you print a delta in a _process(delta) function, output wont print anything anymore. Try flooding the output, I dare you. Nothing will come out. The bad side of it is that key debugging messages get lost

If you print any setgets on export variables - not working any more. It doesnt even work on the dos terminal, I had to set the node to operate in tool mode to get it to print in cmd window. It never printed in godot's output debugger.
#10859

another similar bug with the output print not working in tool mode:
#10870

The output seems to be falling apart

[BeayemX]

Maybe some ideas from the latest chrome dev tools can also be incorporated?

https://youtu.be/90wNAn05Cf4?t=1m20s

i.e. filter by file / directory, group similar output, filter by input-string

[Calinou]

Closing in favor of godotengine/godot-proposals#971 and godotengine/godot-proposals#898, as feature proposals are now tracked in the Godot proposals repository.