From: Martin M. <mar...@gm...> - 2020-12-05 09:01:15
|
Hi, I looked at the qucs project structure and I've seen that in the folder qucs/qucs exists a dialogs folder, but the dialogs it self are directly stored in qucs/qucs. Is there a plan to move these files back to the dialogs folder or is the plan to make a more flat project structure? I'm trying to update the cmake files. Therefore I need this information. Cheers, Martin |
From: Felix S. <fe...@sa...> - 2020-12-05 13:25:23
|
On Sat, Dec 05, 2020 at 10:01:45AM +0100, Martin Marmsoler wrote: > I looked at the qucs project structure and I've seen that in the folder > qucs/qucs exists a dialogs folder, but the dialogs it self are directly > stored in qucs/qucs. Is there a plan to move these files back to the > dialogs folder or is the plan to make a more flat project structure? > > I'm trying to update the cmake files. Therefore I need this information. Dear Martin. Thanks for looking into the CMake files. You are probably looking at the refactor+qt5-19 branch. The relevant move forward is merge request 1007 [1]. It aims at splitting up Qucs into library and plugins, supporting arbitrary build systems, while keeping the source tree clean. If you are curious, The same has been done here [2] in a related project. I think that in Qucs, both the autotools build and the cmake build could be part of the main repo. We need $toplevel/qucs/autotools and $toplevel/qucs/cmake directories for this, and some less sketchy convention/agreement for what is supposed to be in the MakeLists. Dialogs were in qucs/qucs/dialogs, but, as different elements have different Dialogs, it does not seem sensible to expose specialised dialogs to the global namespace. It seems that the dialogs directory will go away, leaving behind only a header (in include?), and all dialogs will be implemented (independently) within plugins alongside the Element they correspond to. You will find that this is already the case for most of them. Let me know if you have any questions. regards felix [1] https://github.com/Qucs/qucs/pull/1007 [2] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:autotools |
From: Martin M. <mar...@gm...> - 2020-12-05 14:16:35
|
Hi Felix, thanks for your response. Yes I'm looking at refactor+qt5-19 branch. Why do you wanna support multiple build systems? But it makes sense to have one place where all source and header files are define if multiple build systems are needed. With plugins you mean different features of qucs? So they aren't anymore part of the core, but only plugins? For me the structure of qucs is not that clear, in the main folder there is a qucs which is the GUI it self? Qucsator is in it's own repository so that it can be included or not, to add different solvers? In the qucs folder I find some "tools" (qucs-attenuator, qucs-filter, qucs-powercombining) are they completely standalone so that they can be included or not? And then in the qucs/qucs folder, the main stuff for the GUI is stored. cheers, Martin Am Sa., 5. Dez. 2020 um 14:24 Uhr schrieb Felix Salfelder < fe...@sa...>: > On Sat, Dec 05, 2020 at 10:01:45AM +0100, Martin Marmsoler wrote: > > I looked at the qucs project structure and I've seen that in the folder > > qucs/qucs exists a dialogs folder, but the dialogs it self are directly > > stored in qucs/qucs. Is there a plan to move these files back to the > > dialogs folder or is the plan to make a more flat project structure? > > > > I'm trying to update the cmake files. Therefore I need this information. > > Dear Martin. > > Thanks for looking into the CMake files. You are probably looking at the > refactor+qt5-19 branch. > > The relevant move forward is merge request 1007 [1]. It aims at > splitting up Qucs into library and plugins, supporting arbitrary build > systems, while keeping the source tree clean. If you are curious, The > same has been done here [2] in a related project. I think that in Qucs, > both the autotools build and the cmake build could be part of the main > repo. We need $toplevel/qucs/autotools and $toplevel/qucs/cmake > directories for this, and some less sketchy convention/agreement for > what is supposed to be in the MakeLists. > > Dialogs were in qucs/qucs/dialogs, but, as different elements have > different Dialogs, it does not seem sensible to expose specialised > dialogs to the global namespace. It seems that the dialogs directory > will go away, leaving behind only a header (in include?), and all > dialogs will be implemented (independently) within plugins alongside the > Element they correspond to. You will find that this is already the case > for most of them. > > Let me know if you have any questions. > > regards > felix > > [1] https://github.com/Qucs/qucs/pull/1007 > [2] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:autotools > |
From: Felix S. <fe...@sa...> - 2020-12-05 19:26:04
|
On Sat, Dec 05, 2020 at 03:17:03PM +0100, Martin Marmsoler wrote: > thanks for your response. Yes I'm looking at refactor+qt5-19 branch. Why do > you wanna support multiple build systems? But it makes sense to have one > place where all source and header files are define if multiple build > systems are needed. This is a good question. Well, autotools is complete and working, and others wish to user other systems. why do you need cmake? I want to be able to say "go for it", without taking responsibility or maintenanceship of such additional stuff. there is autotools, plain make, qmake, cmake, meson, waf, scons (to name a few) and a new creation about every year. Which one is appropriate? which one isnt? I don't know. People do want to try. Note that there will probably be a mechanism to build extensions from an installed Qucs. and it might use neither of the build systems named above. > With plugins you mean different features of qucs? So they aren't anymore > part of the core, but only plugins? Yes. the initial motivation for plugins are circuit components, and simulator drivers (including languages). other things follow(ed) naturally. not sure what you mean by "core". the qucs package will contain the "core" library implementing the GUI + a bunch of plugins that implement 0.0.20 "legacy" behaviour, this will be optional, and pave the way for new ideas. > For me the structure of qucs is not that clear, in the main folder there is > a qucs which is the GUI it self? main/main.cc is the default entry point for the GUI application. it is in a separate directory in order to reduce complexity and increase modularity. there is still stuff in main.cc that needs to be folded back into the library. > Qucsator is in it's own repository so that > it can be included or not, to add different solvers? Qucsator is optional, as is the qucsator driver in qucs. other simulators are intended. some other drivers will likely be included with the qucs (gui) repository. The top level repo will be retained (with qucs qucsator qucs-doc or more as submodules), to provide a "starting point". this may be irrelevant in the future, once qucs will be distributed by other means (e.g. as part of operating systems). > In the qucs folder I find some "tools" (qucs-attenuator, qucs-filter, > qucs-powercombining) are they completely standalone so that they can be > included or not? I have not touched the tools yet. ideally they will be moved to an appropriate place, within the qucs package. > And then in the qucs/qucs folder, the main stuff for the > GUI is stored. qucs/qucs will be qucs/lib or qucs/src, at some point. This is meant to contain only a shared library. cheers felix |
From: Felix S. <fe...@sa...> - 2020-12-06 12:30:31
|
On Sun, Dec 06, 2020 at 12:51:55PM +0100, Martin Marmsoler wrote: > So we can also use external libraries to create diagram. Sou the wheel must > not be reinvented. Hi Martin. It is a side effect, but yes. Use whatever you think solves your problem, and whatever you are used to. The key really is to split it off the library, from the start. This way, choices will not have to be hard wired. Needless to say: this can be tricky. Having seen a lot of code & ideas going down the drain (and wheels reinvented) I believe that this is worth it. Several contributions we have seen to Qucs in the last decade were of the type "look, I have a proof of concept for $this, and it works for me [tm]". It then sits there and bit rots, as the author does not have time to mantain it. A plugin can be used by anybody, from day 0. Ideally without modification to the rest of Qucs. cheers felix |
From: Felix S. <fe...@sa...> - 2020-12-06 09:14:36
|
On Sun, Dec 06, 2020 at 09:22:51AM +0100, Martin Marmsoler wrote: > Why the diagrams are legacy? Does it mean the will be rewritten completely? Hi Martin. Diagrams dont work yet. Several options: - carry on without Diagrams for now. - try to make the legacy diagrams work. - rewrite them (I think they should use Qt widgets, and Qt implements plotting these days). Whichever happens first. See diagrams/README. thanks felix PS: qucs/diagrams needs to move one level up. |