Have multiple command line --command= options for multiple commands

[ZjYwMj]

The reader is kindly asked to pay attention for the s letter, or absent of, and to the = character, or absent of, in the seemingly no different --command, --command= and --commands= terms. In what follows, these 3 different terms are totally different. With the current stable implementation, with multiple --command= command line options, only the last one is used. It override the previous occurrences of --command=. As promised at https://github.com/lxde/lxterminal/pull/98#issuecomment-888600876, this code modifies that. With it, all the commands specified with --command= option will run. (This code also does not include --commands= that was present in https://github.com/lxde/lxterminal/pull/98.) Each one at a different tab. Each command is automatically paired with a tab. After exhausting existing tabs, new tabs will be automatically created.

This feature does not lift the basic limitation of commands in lxterminal command line. Which is, that short lived processes makes the tab they ran within, or the whole window in case of only short lived processes, to get closed as soon as the short lived processes have terminated. This limitation is shortly described in the modified man page.

This patch constitutes of modifying 3 files:

1. src/lxterminal.h
2. src/lxterminal.c
3. man/lxterminal.xml

Lightly tested.

The modification of lxterminal.xml, beside describing the new behavior of the --command= option, also describes, in some length, some pitfalls of lxterminal.

[ZjYwMj]

As an aside, some of the comments at https://github.com/lxde/lxterminal/pull/98#issuecomment-888600876 were discussing possible usage of asynchronous ptys. I am not sure I understand why it might be a necessity. Is it because it is desired not to get short lived processes close the tab, or window, when they are done? To enable more parallelism? To prevent slow, or problematic, processes from slowing down run able processes? In any case, I would like to point out the 17 years old Konsole for me!. Which is part of The Grumpy Editor's guide to terminal emulators. Perhaps dcop, or what looks to me its modern follow up dbus, should be considered? Or do they less useful here? Too heavy? Require yet more dependencies?

[FinboySlick]

I am not sure I understand why it might be a necessity. Is it because it is desired not to get short lived processes close the tab, or window, when they are done? To enable more parallelism? Too prevent slow, or problematic, processes from slowing down run able processes?

Nothing so fancy. It's merely because VTE is deprecating non-async spawning.

[ZjYwMj]

VTE is deprecating non-async spawning.

Why would they do that? Which specific functions, in lxterminal source, you are referring to?

[FinboySlick]

After your patch, that would be the call to vte_terminal_spawn_sync() on line 1320. As for why? They probably just think it's better (which it arguably is) and as such everybody should be using it.

https://developer-old.gnome.org/vte/unstable/VteTerminal.html#vte-terminal-spawn-sync

vte_terminal_spawn_sync has been deprecated since version 0.48 and should not be used in newly-written code.

Use vte_terminal_spawn_async() instead.

If you want some extra fun with deprecated features, try to make the terminal keep its size when tabs appear/disappear under GTK3. Good luck. They removed all the parts that made it (somewhat) possible with GTK2 and no good solution has been found since. You have to guess what the new size of the window will be but there is no way to pre-compute the size without rendering it first. So basically, we need to draw the new window with the wrong terminal size(smaller), then resize it essentially while it is visible.