Any plans to switch to Qt5?

Question

Any plans to switch to Qt5?

yurivict opened this issue 2 years ago · comments

Qt4 is EOLed.

Vadim Kuznetsov · Answer 1 · Fri Jul 08 2022 13:09:16 GMT+0800 (China Standard Time)

@yurivict Please look at Qucs-S https://github.com/ra3xdh/qucs_s/ and https://ra3xdh.github.io/ It is fully ported to Qt5 now and uses Ngspice as default simulation kernel (required as dependency).

yuri@FreeBSD · Answer 2 · Fri Jul 08 2022 13:23:27 GMT+0800 (China Standard Time)

This project should be archived by the account owner then with explanation like you wrote above.
This would reduce confusion.

yuri@FreeBSD · Answer 3 · Fri Jul 08 2022 13:36:26 GMT+0800 (China Standard Time)

@ra3xdh I am trying to port Qucs-S to FreeBSD but it depends on the spiceopus executable. The website http://www.spiceopus.si/ says that spiceopus is free but there's no source code there.

Is spiceopus essential for Qucs-S?

Vadim Kuznetsov · Answer 4 · Fri Jul 08 2022 13:44:20 GMT+0800 (China Standard Time)

The spiceopus and Xyce are optional backends and not necessary for program operation. Only Ngspice is required for the Qucs-S operation.

felix · Answer 5 · Fri Jul 08 2022 15:40:51 GMT+0800 (China Standard Time)

On Thu, Jul 07, 2022 at 10:44:33PM -0700, Vadim Kusnetsov wrote: The spiceopus and Xyce are optional backends and not necessary for program operation. Only Ngspice is required for the Qucs-S operation.

Hi Vadim. Last time I tried, Qucs-S also worked with Qucsator. Has this changed?

Vadim Kuznetsov · Answer 6 · Fri Jul 08 2022 16:14:59 GMT+0800 (China Standard Time)

Hello Felix,
yes, Qucs-S still support Qucsator, but is not required for program operation. The Qucs-S has switched to Ngspice as the default simulation kernel since v0.0.23. I would not recommend Qucsator for new designs except some specific applications like Verilog-A models debugging or RF microstrip devices simulation. Ngspice team has recently added S-parameter simulation, so the Ngspice can now cover the most of circuit design tasks and has better compatibility with third-party models.

felix · Answer 7 · Fri Jul 08 2022 16:38:00 GMT+0800 (China Standard Time)

On Fri, Jul 08, 2022 at 01:15:09AM -0700, Vadim Kusnetsov wrote: yes, Qucs-S still support Qucsator, but is not required for program operation. The Qucs-S has switched to Ngspice as the default simulation kernel since v0.0.23. I would not recommend Qucsator for new designs except some specific applications like Verilog-A models debugging or RF microstrip devices simulation. Ngspice team has recently added S-parameter simulation, so the Ngspice can now cover the most of circuit design tasks and has better compatibility with third-party models.

Thanks for your work, Vadim. Qucs-S can be compiled against Qt5, and is a nice stopgap solution. There is also a Qucs binary package around that runs without having a Qt3 installation ready. I understand that Qucs is defaulting to Ngspice, because this is your personal preference. Instead of Qucsator, you could also use Gnucsator. Gnucsator is Gnucap based. Gnucap runs ngpice models since 2014 (including those converted with ADMS), and also many of the Qucsator components are implemented by now. I have added SParameter analysis in 2018. Gnucap has its own ADMS Verilog-A frontend. (Almost) anything else can be added to Gnucap by means of plugins. For a (native) Qt5 port, see also https://wiki.f-si.org/index.php?title=Merging_Gnucap_and_Qucs_--_The_Why_and_How

Wallacegromit · Answer 8 · Fri Jul 29 2022 23:27:01 GMT+0800 (China Standard Time)

As I see, and since no new real RF features in qucs for years (last offcial version is 19 !!! from 2017 !!!) ... I will switch to this fork using ngspice (at least this one is maintained) . thx to "vadim" : he succeded where the team looses the battle. As a very early adaptor of QUCS since the beg (0.0.1), I have also write a huge part of the doc , build some libs etc ... ... I think it is a pity, the aim of having a real unix tool (windows optional and other optional ) become further and further away ... lack of real RF dev (only cosmetics and non rf new features) ... just have a look of the new features from the QUCS Studio fork ... we run after last version of everything instead of maintaining things. .... I'll give a try to this one. for me the original QUCS is dead. In this scope we do need to keep the compatibility with qucsator fro a while, just to allow the surrounding tools to proceed with the migration.