[Octave] [Openbox] Fails to open when run directly by Openbox

aphirst · 2018-02-05 22:39:38

It seems as if Octave is stuck in the middle between potential users who expect running "octave" to be a GUI tool or a script interpreter, and it's obvious (in my opinion) that it's actually fundamentally impossible to reconcile these.

As Trilby points out, but doesn't necessarily emphasise, because python/bash are interpreters, their respective GUI tools (terminal emulators, IDEs etc.) are distinct programs.

An example I'd give is FreeCAD, which is implemented on top of Python, and contains a Python console. Every action in the GUI causes commands in this environment, and vice versa. If, however, you just want to run a "FreeCAD script", the expectation is that you run a separate packaged binary "freecadcmd".

EDIT: You can conclude one of two things from this. Either, "octave" should be the interpreter, and its GUI be a distinct binary (ofc with a distinct name). Or, "octave" should be the GUI, and the underlying engine something like "octavecmd".

Last edited by aphirst (2018-02-05 22:41:48)

Trilby · 2018-02-05 22:44:29

What I'd really emphasize, is even if python had a default gui built in, it would certainly not default to starting the gui when run from a terminal. The fact that octave starts a gui by default when run from the terminal suggests it is not primarily an interpreter as the terminal is exactly where interpreters work.

I think octave could be primarily an interpreter and have the gui still provided by the same binary. But this is very much at odds with the current behavior when run from a terminal.

Right now, when run from a terminal where it makes perfect sense to act just as an interpreter, it defaults to starting a gui unless given an explicit flag (is it '-W') to prevent that. Meanwhile, when run from a window manager menu where it makes perfect sense to start a gui, it defaults to starting just as an interpreter (and thus exiting immediately) unless given an explit flag (--force-gui) to prevent that.

Given the clarification of goals, I think the existing code is very nearly perfect: just remove the `!` from the start of the conditional test: the logic is, at the moment, bass ackwards. (this paragraph is just slightly facetious, this would actually work well for terminal use or menu use, but not for actual script file input).

And while I'd strongly encourage robustness under any condition of stdin, clearly the window manager menu, a tty, or an on-disk file would account for an exceedingly vast majority of use-cases. The fact that octave's current logic gets two out of three of those backwards is a problem.

Last edited by Trilby (2018-02-05 22:50:55)

aphirst · 2018-05-03 22:27:40

Since the link appears to have disappeared from the thread, here's the upstream bug report that was made. https://savannah.gnu.org/bugs/?53034

Arch Linux

#26 2018-02-05 22:39:38

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#27 2018-02-05 22:44:29

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

#28 2018-05-03 22:27:40

Re: [Octave] [Openbox] Fails to open when run directly by Openbox

Board footer