[PATCH] gnu: engineering: Add qucs-s.

> this patch adds "Qucs-S", a GUI for different circuit simulation

> +    (propagated-inputs (list ngspice))

> Often GUIs have problems with finding icons, could you check whether

> qucs-s works in a pure environment?

> Propagation is not very robust (e.g. if run directly from the store with $(guix

> build qucs-s)/bin/the-binary), would it be possible to not propagate this? E.g.,

> if you are propagating it because of not finding a binary, you could use

> substitute* to insert an appropriate absolute file name.

> Hello Maxime,

>

> thanks you for the patch review!

>

>> Often GUIs have problems with finding icons, could you check whether

>> qucs-s works in a pure environment?

> I tried to run Qucs-S installed through Guix, like the follows:

>

> --8<---------------cut here---------------start------------->8---

> guix shell -D guix

> ./pre-inst-env guix shell -D --pure qucs-s

> qucs-s

> --8<---------------cut here---------------end--------------->8---

>

> And all the icons seem to be fine

>

> Although it can be that I don't fully understand what you mean by "pure

> environment" in that case.

>> Propagation is not very robust (e.g. if run directly from the store with $(guix

>> build qucs-s)/bin/the-binary), would it be possible to not propagate this? E.g.,

>> if you are propagating it because of not finding a binary, you could use

>> substitute* to insert an appropriate absolute file name.

> Okay, that's a good point. I checked the sources for the places where

> Qucs-S uses executable paths and added substitutions for that.

> + (("QucsSettings.NgspiceExecutable = ngsp_exe")

> +                      (string-append "QucsSettings.NgspiceExecutable

> = \""

> +                                     (assoc-ref inputs "ngspice")

> +                                     "/bin/ngspice"

> +                                     "\""))

> +                     (("QucsSettings.OctaveExecutable = \"octave\" +

> QString(executableSuffix)")

> +                      (string-append "QucsSettings.OctaveExecutable = \""

> +                                     (assoc-ref inputs "octave")

> +                                     "/bin/octave"

> +                                     "\""))))))))

> I kept NGSpice in "propagated-inputs" because Qucs-S requires it to do

> the simulations in runtime.

>

> Also I've added GNU Octave to the "propagated-inputs" and substituted

> the path to Octave too.

> I tried to run simulations from the examples provided with the Qucs-S

> and it seems to me that Qucs-S mostly works as it should.

> That's what I meant, thanks.  I guess the icons issue is GTK-specific

> and doesn't happen for Qt.

> These substitutions look fine ... ... ... but they can be improved, by

> replacing the assoc-ref with search-input-file: (search-input-file

> inputs "/bin/ngspice"). That way, it doesn't depend on the package

> name anymore, which is preferred by

> <https://guix.gnu.org/blog/2021/the-big-change/> (*) and makes in some

> cases --with-input more usable. That blog post also has en example.

> By that logic, since qtbase and qtsvg are used at runtime too, they

> should be propagated as well, but ...

> > I tried to run simulations from the examples provided with the

> > Qucs-S and it seems to me that Qucs-S mostly works as it should.

> ... as you have observed, things work even when they aren't propagated

> (at least for qtbase etc., ngspice and octave have not yet been

> tested).

> In theory, the propagation shouldn't be required because you added a

> 'substitute*', so in principle qucs-s should know where to find it.

> Also, I noticed these substitutions modify configuration, could you

> verify they aren't saved in wherever qucs-s' configuration file is

> located? Because if they are, then even after an update of octave etc.

> it would seem that qucs-s would still use the old octave.

>+ (description

>+ "@code{Qucs-S} provides a fancy graphical user interface for a number of

>Yet at least Qucs-S will always use the right Octave/NGSpice path from

>GNU Guix.

> if(settings.contains("NgspiceExecutable")) QucsSettings.NgspiceExecutable = settings.value("NgspiceExecutable").toString();

> else {

> QString ngsp_exe = QCoreApplication::applicationDirPath() +

> QDir::separator() + "ngspice" + executableSuffix;

> if (!QFile::exists(ngsp_exe)) ngsp_exe = QString("ngspice") + executableSuffix;

> QucsSettings.NgspiceExecutable = ngsp_exe;

> }

>> ... as you have observed, things work even when they aren't propagated

>> (at least for qtbase etc., ngspice and octave have not yet been

>> tested).

> I usually put into "propagated-inputs" packages that provide some binary

> that the current package use in the runtime.

>

> So do you mean that I should rely only on "inputs" package property, and

> the inputs will be propagated anyway if they're in use by the package?

>

> Less experimentally, the propagated- in propagated-inputs means only

> that: propagation -- the dependencies are still installed even if they

> aren't propagated, because the substitute* inserts a reference so the

> GC knows to not delete it, the only difference is that the dependency

> isn't automatically put in the profile when not propagating.

> So the next time Qucs-S run it gets the paths from the configuration

> file.

>

> I changed the substitutions so Qucs-S will ignore the paths to Octave

> and NGSpice from the configuration and will always use the paths

> provided by Guix. Also any custom paths to Octave and NGSpice will be

> overwritten in the config when the application exits.

>

> That is sub-optimal in my view as we're messing up with the application

> configuration logic and if a user wants to change those paths he or she

> will be able to remove the config and set the paths in the startup

> configuration dialogue, but the settings will have no effect; that will

> be a bit confusing.

>

> Yet at least Qucs-S will always use the right Octave/NGSpice path from

> GNU Guix.

>

> What do you think?

>

> Here's the patch.