Any plans to switch to Qt5?

[yurivict]

Qt4 is EOLed.

[ra3xdh]

@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).

[yurivict]

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

[yurivict]

@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?

[ra3xdh]

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

[felix-salfelder]

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?

[ra3xdh]

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-salfelder]

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]

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.

[felix-salfelder]

Code has been ported to Qt5. ("ported", not "wrapped"). Need to fix a couple of bugs still. Complaining or recommending non-free tools won't accomplish anything.

[ra3xdh]

Just for interest. What were the reasons to revive an old Qucs project and port it to Qt5 after almost six years pause in development?

[felix-salfelder]

on tue, jul 02, 2024 at 03:45:46am -0700, vadim kuznetsov wrote:

just for interest. what were the reasons to revive an old qucs project and port it to qt5 after almost six years pause in development?

Dear Vadim.

The Qt5 port was in fact needed for much longer. Maybe there was no activity in this repo for six years, but on this time scale I've been working on (Modular) Qucs until recently...

Now, as we are moving towards Verilog-AMS, Qucs has been identified as a potential schematic editor for it, supporting the standard.

Best wishes felix

[ra3xdh]

Now, as we are moving towards Verilog-AMS

Could be a development roadmap found anywhere? And who are "we"? I see only one contributor in the recent commits.

[felix-salfelder]

On Tue, Jul 02, 2024 at 04:04:16AM -0700, Vadim Kuznetsov wrote:

Now, as we are moving towards Verilog-AMS

Could be a development roadmap found anywhere? And who are "we"? I see only one contributor in the recent commits.

We have this [0, 1]. It is not strictly a roadmap, but a task list.

Recent commits can be a misleading concept in a decentralised development approach. And it's just about code, which is a little narrow. Figuring out what to code can be difficult at times. To value some underused achievements, I recommend do download, read and study the Verilog-AMS LRM [2]. There is also a list of contributors on the first few pages.

Anyone is welcome to join the effort. We also offer paid internships suporting relevant work on the code now. This may include some flavor of Qucs. I can't be sure, only keeping the lights on. Time will tell.

[0] http://gnucap.org/dokuwiki/doku.php/gnucap:projects:nlnet:verilogams [1] http://gnucap.org/dokuwiki/doku.php/gnucap:projects:nlnet:verilogamscontd [2] https://accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf

[ra3xdh]

Thanks! I will learn the information at the provided links.