qucs commandline operations (schematics -> netlist conversion) require X server

[CookiePLMonster]

As of version 0.0.19 (probably also previous builds) using qucs from commandline under Linux seems to require X server to be present. Since qucsconv does not support converting schematics (.sch) to netlists (or at least said feature is not mentioned in the Wiki) it renders the program unusable under environments where X server is unavailable.

In case it's as simple as me misusing qucs, that's what I am trying to launch:

qucs -n -i test_pwm.sch -o test_pwm.net
qucsator -i test_pwm.net -o test_pwm.output

Executing these commands where X server is available results in correct behaviour ("try to load schematic..." etc. output to stdout, files are created and they seem to contain valid data), whereas otherwise the only feedback I'm receiving is

Warning: qucs: cannot connect to X server

A quick sweep around the source code shows that a QApplication is instantiated in all cases, even when using qucs purely from commandline - which seems like an awkward design choice.

EDIT:
Issue still persists on the latest code from develop branch.

Cheers!

[felix-salfelder]

not a design choice. that's a bug. thanks for reporting.

[CookiePLMonster]

Is this going to be up for grabs or looked into by somebody? Since we're on a quite tight schedule with this I'm thinking I'll set up a development environment on Linux and look into this, even if it means making a quick-and-dirty fix. Assuming I manage to correct it maybe then somebody with a bit more knowledge about this codebase could turn it into a more sensible fix.

[in3otd]

if you are willing to take a look into this, I'll assign this issue to you, as a reminder in case someone else also wants to help.
IIRC, the command-line netlist generation was added by @guitorri , hopefully he'll be able to find some time for further comments 😁

[CookiePLMonster]

Sure! Go ahead and assign it to me - my teammate is looking into that issue right now and we may have gotten somewhere so it makes sense to claim it. I'll keep the issue updated on our findings. Also, since we preferably need a stable version does it make sense to branch it off master and only then issue a PR to develop?

[felix-salfelder]

if you find the bug, please file a PR against master.

i'm curious how many changes this requires (fingers crossed).

[cocsackie]

I changed the instantiation of application to QCoreApplication when needed. Altough it is trying to create schematic now it is resulting in segfault.

Method module::registsterModules() is called and components (such as symtrafo) are using QFontMetrics. It seems that it requires QApplication: https://bugreports.qt.io/browse/QTBUG-15758

When I removed module::registsterModules(), application started to crash while calling schematic constructor. At least that was what gdb pointed to. While I cannot find any link to QWidget from it, the message is:

fatal: QWidget: cannot create a QWidget when no GUI is being used.

I am afraid that this won't be an easy fix. The codebase seems to be very reliant on Qt.

[guitorri]

The first command line options were added before 0.0.18, see 1b817bc.
The purpose was to enable testing and avoid major regressions.

On the MacOS the command line execution also briefly fires up the application icon on the dock bar, meaning that it is not really just a command line execution.
Also on the .travis.yml, xvfb was needed to be able to run the tests in headless mode https://github.com/Qucs/qucs/blob/develop/.travis.yml#L103-L105.

You are right, the QCoreApplication might be the correct way to implement this.
I not sure, but if you remove the module::registsterModules() components won't be able to be netlisted anyway. The QWidget error might originate in the use of other classes derived form QWidget. I really don't know how easy/difficult it would be to disentangle the code in a way that QCoreApplication would work.

Can you try to set GUIenabled to false in case a command line is used?

Please try QApplication a(argc, argv, false);, see [1],
in here: https://github.com/Qucs/qucs/blob/develop/qucs/qucs/main.cpp#L521

[1] http://doc.qt.io/qt-4.8/qapplication.html#QApplication-2

[CookiePLMonster]

That doesn't help much - while it allows QApplication to instantiate, it soon throws an exception (cannot create a QWidget when no GUI is being used) in a.desktop(). That one is trivial to circumvent, however as soon as it's gone there are more identical issues in different parts of the code, namely when constructing Schematic. It seems to inherit from Q3ScrollView which is also a QWidget - thus fixing it might require decoupling some classes from Qt GUI types?

[felix-salfelder]

thus fixing it might require decoupling some classes from Qt GUI types?

lots of untangling will be required in the future... if you can't solve this one easily, it will still help a lot if you add your insights to the code. as comments.

class Schematic : public Q3Scrollview /* BUG: a schematic is not a QT widget (requires X) */

etc. nobody will look here, when refactoring happens...

[CookiePLMonster]

Fair enough - will keep this in mind and either of us will try to document such cases when we get some time. Might also have some time around January to actually sit down and assess how complex the entire thing is. It surely isn't going to be trivial though, even if this Schematic is the only case like this...

[felix-salfelder]

Future Qucs (>=0.1.0) will not require X anymore, but it needs finishing. It's not going to happen in 0.0.20.