Output window++

#1

My apps usually have a lot of output, which is important for me to analyze on each run and therefore, a convenient way to present the info is desired.
I decided that the output window is not good enough for me. I can’t do the most basic things such as controlling the font size, write in color, or search through the UI. The output window hangs if maya crashes or is debugged. Actually, the console for stand alone apps isn’t better.

I came up with the following design:

  1. There is a standalone listener app that opens a window and shows the output. Communication with it is done through an interprocess communication (named pipe/socket).
  2. It needs to be cross platform (Windows/Linux/OS X), preferable written in Python.
  3. It would come up with API for C++ (, Python, and Matlab) that would enable the user to easily write output. For example, for C++ it would provide a logger class that uses both cout and printf syntax.
  4. There would be special commands to support basic rich text: color, font size, boldness, underline.
  5. There would be an option to write in blocks in a tree level structure, where branches would have a plus sign that would enable collapsing (hiding the branch).
  6. There would be an option to patch stdout and stderr and forward their output (e.g. from standard cout and printf commands).

Any thoughts about the suggestion or something open source that is already close to it?

The format the logger would show sounds like html.
I already have a C++ class that patches stdout, and supports cout and printf syntax.

UPDATE:

Here is a basic implementation of the idea:

http://svn.code.sf.net/p/mymayaplugins/code-0/trunk/outputpp/

#2

Hi Zohar,

yes, the Maya output window is limited and hangs when Maya crashes. Thats very annoying.
I do not have additional ideas, but would be very interested in an alternative!

#3

Until I find time to write a solution, note that currently, I’m running maya with

cmd = '"C:\\Program Files\\Autodesk\\Maya2016\\bin\\maya.exe" -nosplash -log c:\\prj\\plug-ins\\output.txt'

This is the log file (where maya dumps the output) that my ensure_maya_is_running.pyw script backs up before restarting maya

http://forums.cgsociety.org/showthread.php?f=7&t=1319006

When debugging in real-time I use SnakeTail to view it.

#4

take a look http://www.scintilla.org/SciTEDownload.html
i’ve used a similar (c++ version) to organize output from 3ds max

#5

If I understand your suggestion, then this is a control to view the output as I want it (font properties and blocks). The benefit is that I should be able to send windows messages to it directly from a different process (i.e. from the logger class to the viewer with the control), instead of an interprocess communication (e.g. a socket) with my own protocol.
Thanks, I’ll take a look.

#6

If you’re creating basic c++ plugins then you can use whatever debugger is valid on your os.
gdb or equivalent.

Or are you guys talking about debugging python inside maya?

/risto

#7

We are not discussing debugging. We are discussing replacing the output window as I described in my initial post.

#8

Oh sorry, my bad.

:slight_smile:

/risto

#9

Zohar, if you embark on this are you considering open sourcing it? More in terms of permissive licensing and potential collabs than the “give it away for free” factor.

#10

sounds like stepping into the log aggregator territory, for example, LogStash ( https://www.youtube.com/watch?v=U3m0jKygAqU ). I’d also argue that some of the features does not make sense (e.g. fonts) for a logging solution. Tree-like representation of the log also only make sense if you absolutely expect the single-threaded, well-behaving logger, and the performance is not important (read: probably won’t find the feature in the existing logging middleware).

#11

It depends on how you look at it.
If it’s just a log catcher, sure, but if you stay true to the topic name of an output manager all those things make perfect sense.

Plenty amazing Unix tools related to development have and use to great extent those features. The main idea is that you want to be able to output a structure that a text renderer can do something with. Key here is thinking of text as a rendering method, and not as data that should be streamed one to one.

My shell and all the extensions I use with it for a number of toolchain components have those features (fonts, rendering options, colour, tree to text rendering, list to text rendering, live buffer flips and so on), and I can’t imagine working without those options.

#12

Raffaele: I’m not sure I would have time to embark on journeys. I would probably write something small for my needs, and I wouldn’t mind sharing it (as I usually do).

Viktoras: I agree with Raffaele’s notion. It’s not about writing a logger (I have only one app, and I want all the data before me, without clicking things). It would be similar to what I usually do with an output window or a console (command line). For example, if I run a code that does some operations on a bunch of models, and spew out warnings and errors, and run certain black boxes that spew output as well, then I find it convenient, for example, to visualize the output as follows

  • Print the model name in blue, warnings in yellow, errors in red.
  • Print the output from a black box in smaller font and collapse it inside a block (that can be expanded by pressing a ‘+’ sign), so it won’t clatter my output.
#13

I updated the original post, and now it contains a link to a basic implementation.

#14

If you’re going the way of “server that displays html” and “client that sends data”, there’s quite some room for improvement. I’d cut a lot of meat from the client, leaving only “send stuff to server” bit. No colored console shenanigans, no file handling, leave that to server. Code like “output header” should also be moved somewhere else to code that uses Logger. Don’t generate any html client side as well, send only data to server, like “here’s some text, display that as warning” or “start an indented block”.

Logging level, handle that on sever side. This will enable features like block collapse. Also, when mixing python/cpp logging, they’ll share the same indent.

I guess I’d cut the home-made communication protocol and use something like gRPC. Mainly to be able to send data in a more structured way and reduce room for error. Right now seems like you make a new connection for each message in client, and the recv(10000) does not look pretty either.

#15

Thanks for the code review :slight_smile:

So here is the thing. I already had a logger class from another system, which was a console app. So, it already had blocks, colors, and cout/printf interface (which I wanted to preserve), and all it was missing was an external viewer. I had only the weekend to work on this, and the most important thing for me was to get something operational that I can immediately use. Therefor, some compromises were made until I would have more time in the future to improve it.

It wasn’t so easy. At first, I got something running with basic functionality using QWebView. Unfortunately, after 100 lines it started crawling. Thus, I switched to QTextEdit, and a few tricks were required to make it run fast, and now it’s flying. For this reason, I also disabled for now the option to collapse blocks in the view.

I wasn’t familiar with gRPC, but it looks useful, and it could have helped me with some issues. I was considering what to do with communication and protocol, and opted for the simplest thing for now (meta and text separated with a ‘|’). I didn’t want to develop a protocol such as changing font properties, so the easiest and most flexible thing was to enable the client to send an html modifier. Thus, I can send through the logger any html fanciness without modifying it.
Also, I didn’t want to mess too much with the server side, such as separating glued messages, so I reset the connection each time. There doesn’t seem to be a performance impact since it’s a local host.
So far, I’m happy with it :slight_smile: