Give the lunchinator the option to read/write to stdin/stdout

[hannesrauhe]

Because Great!

[hannesrauhe]

You can now call the lunchinator with -i and it will read from stdin. Instead of delivering this directly it will send this (as HELO_LOCAL_PIPE) to the locally running instance which will then broadcast the call as HELO_PIPE. This way I avoid the necessity to initialized peers and so on, instead you can just pipe into a running instance.

CLI Versions of the lunchinator will just print this call, qt version will just ignore it (maybe forever). Obviously logging-output will get in the way of the piped things.

Still todo: possibility to specify a client to send to.

[hannesrauhe]

It's now a peer action of the message plugin. :-) There are no safe guards yet: sending of binary files or very large files will not be handled. Let's stress our error handling. :-)

ascinator.py someting.png 1 1 | ./start_lunchinator.py -i

[hannesrauhe]

Two things left on my mind:

I would add another -o switch which starts the --nogui version and surpresses all output except for the piped stuff.

To allow piping of multiple Texts (or ASCII-Pictures :-) ) I have to change the message box to something with a text-edit field. Either I move the stuff from the messages plugin to its own plugin which only has a large TEXT-Edit, or I think of something else...

[entropia1]

As far as I know, we don't write much to stdout. Hence, piping should work already.

I'm not quite sure what you mean by "the message box". Which message box can be used for piping?

[hannesrauhe]

I added one as part of the message plugin (with peeractions) in 319516e.

However, I might add the asciinator to the peer actions as well, so maybe it should be in its own plugin.

[hannesrauhe]

My idea is that if I want to pipe an ascii-video through the lunchinator I would use the asciinator and the lunchinator with -i on the sending side.

On the receiving side there could either be a --nogui-lunchinator for console output or the standard gui lunchinator that has it own window to display.

[entropia1]

Ah, it's for displaying, not for entering. Well, you can refactor the ErrorLogDialog (error_dialog.py). Or just copy it, because it's quite simple ;-)

[entropia1]

Ascii-Video on the console might be difficult; how do you want to "clear" the page?

[entropia1]

When I do echo foo | python start_lunchinator.py -i, the receiving instance writes the following to stdout:

foo

foo

by Corny1

Note: I currently have only one IP.

[hannesrauhe]

Ah, you are right, because the core and the messages plugin write to stdout when there is no GUI. I'll fix that.

I'm thinking about not clearing the page at all. For a start it would be OK if the console has the right dimensions. A new picture will the by default appear where the old one was... Another idea would be to get the dimensions and add newlines at the end of every picture so that it fills the screen.

[entropia1]

Writing to stdout is fine; but why does it appear twice?

[hannesrauhe]

Because they both write the message (once in _handle_core_events and once in the plugin code)

[hannesrauhe]

OK, -o is now just a --no-gui --no-plugins.

Double Output is fixed and the whole piping on the GUI is handled in the Pipe Out plugin.