From: Claudio G. <cla...@vi...> - 2015-04-08 19:36:22
|
Hello Kevin, nice work on the tuner dialog, will be a great addition to Qucs. If I understood correctly, you would like to know on which property of a component in a schematic the user clicked, as one does usually to change it. In the current code this is handled by the Component::getTextSelected() function, which compares the mouse pointer position with the component properties position, tries to find the one under the cursor when the user clicked and return the corresponding property index. A typical gdb backtrace showing all the functions involved when clicking on a property is this: #0 Component::getTextSelected (this=0x89e0248, x_=31, y_=29, Corr=0.0514725037) at component.cpp:171 #1 0x080ccd8a in Schematic::selectElement (this=0x89daff0, fX=119.19519, fY=233.992416, flag=false, index=0xbfffe370) at schematic_element.cpp:1137 #2 0x0806a2ff in MouseActions::MPressSelect (this=0x85af1a8, Doc=0x89daff0, Event=0xbfffe428, fX=119.19519, fY=233.992416) at mouseactions.cpp:907 #3 0x080bf108 in Schematic::contentsMousePressEvent (this=0x89daff0, Event=0xbfffe428) at schematic.cpp:575 #4 0xb6ebe7b5 in Q3ScrollView::viewportMousePressEvent(QMouseEvent*) () Hope this helps, Claudio ----Messaggio originale---- Da: kev...@gm... Data: 8-apr-2015 19.50 A: <quc...@li...> Ogg: [Qucs-devel] Getting selected Property of a Component Hi all I'm currently working on some personal extensions to Qucs which I would eventually like to share with the group. I'm working on a tuner dialog window which will update component values and restart the simulation (for example S-parameter). That way you could finetune L and C values of a filter for example without sweeping over the values and see the effect of component changes realtime. (Just take a look at AWR or ADS, Genesys, etc...). My tuner window is already OK, I can click a component and add a widget to my dialog but now I'm trying to figure out a way to determine which property of a component the user selected. For example in a microstrip you might want to edit the length and width parameter. Currently my code is setup so that when the user clicks a component an event fires. I was trying to look at the MPressSelect action and found a way to know that propertyText is selected with the focusElement->Type. Now I just need to know which exact property the user clicked. Is something like this already implemented? Kind Regards Kevin ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Qucs-devel mailing list Quc...@li... https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Claudio G. <cla...@vi...> - 2015-04-11 08:07:57
|
Hello Kevin, I cannot help much here, I do not use QtCreator and my knowledge of cmake is rather limited. Note that we maintain two build systems in parallel, one based on cmake and the other on the Autotools and I use this latter normally. Also the release build scripts use the Autotools, at present. Probably Guilherme or others could help with the cmake stuff. You might want to upload your new code to a Qucs fork on Github, so that the other developers can try the code and more easily reproduce the issues. Or in any case, post the error messages you are getting during the build, this might give us some hints about where the problem is. Regards, Claudio ----Messaggio originale---- Da: kev...@gm... Data: 11-apr-2015 8.11 A: Cc: <quc...@li...> Ogg: Re: [Qucs-devel] Getting selected Property of a Component Hi Claudio that helped, thanks. My tuner dialog is now complete ready for some first tests. I've been building/debugging with QtCreator so far without much issues. I'd like to build using make from command line. I've added my files to CMakelists.txt (was also need for QtCreator), yet the build failes while trying to link to my new objects. What do I have to do to add files to the build? Kevin On Wed, Apr 8, 2015 at 9:36 PM, Claudio Girardi <cla...@vi... > wrote: > Hello Kevin, > nice work on the tuner dialog, will be a great addition to Qucs. > If I understood correctly, you would like to know on which property of a > component in a schematic the user clicked, as one does usually to change it. > In the current code this is handled by the Component::getTextSelected() > function, which compares the mouse pointer position with the component > properties position, tries to find the one under the cursor when the user > clicked and return the corresponding property index. > A typical gdb backtrace showing all the functions involved when clicking > on a property is this: > > #0 Component::getTextSelected (this=0x89e0248, x_=31, y_=29, > Corr=0.0514725037) at component.cpp:171 > #1 0x080ccd8a in Schematic::selectElement (this=0x89daff0, fX=119.19519, > fY=233.992416, flag=false, > index=0xbfffe370) at schematic_element.cpp:1137 > #2 0x0806a2ff in MouseActions::MPressSelect (this=0x85af1a8, > Doc=0x89daff0, Event=0xbfffe428, > fX=119.19519, fY=233.992416) at mouseactions.cpp:907 > #3 0x080bf108 in Schematic::contentsMousePressEvent (this=0x89daff0, > Event=0xbfffe428) > at schematic.cpp:575 > #4 0xb6ebe7b5 in Q3ScrollView::viewportMousePressEvent(QMouseEvent*) () > > Hope this helps, > Claudio > > > ----Messaggio originale---- > Da: kev...@gm... > Data: 8-apr-2015 19.50 > A: <quc...@li...> > Ogg: [Qucs-devel] Getting selected Property of a Component > > > Hi all > > I'm currently working on some personal extensions to Qucs which I would > eventually like to share with the group. > > I'm working on a tuner dialog window which will update component values and > restart the simulation (for example S-parameter). That way you could > finetune L and C values of a filter for example without sweeping over the > values and see the effect of component changes realtime. (Just take a look > at AWR or ADS, Genesys, etc...). > > My tuner window is already OK, I can click a component and add a widget to > my dialog but now I'm trying to figure out a way to determine which > property of a component the user selected. > > For example in a microstrip you might want to edit the length and width > parameter. Currently my code is setup so that when the user clicks a > component an event fires. I was trying to look at the MPressSelect action > and found a way to know that propertyText is selected with the > focusElement->Type. Now I just need to know which exact property the user > clicked. > > Is something like this already implemented? > > Kind Regards > > Kevin > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Qucs-devel mailing list Quc...@li... https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Claudio G. <cla...@vi...> - 2015-04-11 09:44:54
|
Hello Kevin, yodalee created a brief guide on the wiki on this, https://github.com/Qucs/qucs/wiki/Contribution ; it is quite concise, feel free to ask if something is not clear. In general the different branches on the main repository are meant for long-term, wide-reaching, changes; for smaller changes, which are (supposed to be) ready to be integrated in to the master branch, you should push your new branch to your fork on Github and then create a pull request. Note that we try to keep both the Autotools and cmake build systems up-to-date, so ideally your new code should be able to be compiled with both systems; in any case you can create a pull request even if the code currently builds with the Autotools only, we can figure out later how to properly compile it with cmake as you can update your local branch and the related pull request later, before merging it into the master branch. Regards, Claudio ----Messaggio originale---- Da: kev...@gm... Data: 11-apr-2015 10.56 A: Cc: <quc...@li...> Ogg: Re: [Qucs-devel] Getting selected Property of a Component Hi Vadim that did it. I had to adjust the Makefile.am file and now everything builds fine. I've created a local branch after checking out. What is the best way forward? Fork or can I create a seperate branch on the master? I'm used to working with mercurial so git is kinda new to me Regards, Kevin |
From: Kevin V. <kev...@gm...> - 2015-04-11 10:11:25
|
Hey Claudio forking is done. I've created my own fork + tunerdialogbranch at http://sourceforge.net/u/tipofthesowrd/qucs/ci/tunerdialog/tree/ Any logged in user is free to contribute... ;-) Right now cmake is compiling fine. I'll have to check how to get autotools up and running. Thanks for all the help so far Regards Kevin On Sat, Apr 11, 2015 at 11:44 AM, Claudio Girardi < cla...@vi...> wrote: > Hello Kevin, > yodalee created a brief guide on the wiki on this, > https://github.com/Qucs/qucs/wiki/Contribution ; it is quite concise, > feel free to ask if something is not clear. > In general the different branches on the main repository are meant for > long-term, wide-reaching, changes; for smaller changes, which are (supposed > to be) ready to be integrated in to the master branch, you should push your > new branch to your fork on Github and then create a pull request. > Note that we try to keep both the Autotools and cmake build systems > up-to-date, so ideally your new code should be able to be compiled with > both systems; in any case you can create a pull request even if the code > currently builds with the Autotools only, we can figure out later how to > properly compile it with cmake as you can update your local branch and the > related pull request later, before merging it into the master branch. > > Regards, > Claudio > > ----Messaggio originale---- > Da: kev...@gm... > Data: 11-apr-2015 10.56 > A: > Cc: <quc...@li...> > Ogg: Re: [Qucs-devel] Getting selected Property of a Component > > Hi Vadim > > that did it. I had to adjust the Makefile.am file and now everything builds > fine. > I've created a local branch after checking out. What is the best way > forward? > Fork or can I create a seperate branch on the master? > > I'm used to working with mercurial so git is kinda new to me > > Regards, > Kevin > > > |
From: Kevin V. <kev...@gm...> - 2015-04-27 09:18:52
|
Hi Claudio I applied the patch (works like a charm!) and have pushed my latest changes. That should help in my development as well since I was getting frustrated about the property selection. I have the feeling selection of properties could benefit from a crosshair pointer or something similar (like when drawing wires)? I just checked the Data display remark. Indeed, Qucs-GUI cannot simulate when started from the data display. I never noticed this before. Probably because I usually drag my data displays onto the schematic. I think we should try and find a workaround for this since the whole idea of the tuner was to see the diagrams change 'live' and it shouldn't matter wheter they are on their own display or on the schematic. Regards Kevin On Fri, Apr 24, 2015 at 10:25 PM, Claudio Girardi < cla...@vi...> wrote: > Hello again... > I took a look at the code since, as you said, the selection is based on > existing code and should then work properly; it turns out you did it > *almost* right, just missed to subtract 1 to an index... Moreover, you were > a bit unlucky, since the current Qucs code has (had, actually) bug which > makes the selection of a property with the mouse somewhat imprecise. It was > corrected only recently, but it is just a single line correction, so I have > included it in the enclosed patch file. It contains also the correction to > the property selection for the tuner. You might want to rebase your code to > the current one, but that is actually not really needed. > Still, it does not work properly for schematics having a separate Data > Display, since apparently it tries to generate a netlist for the Data > Display when this is opened, which obviously does not work, you need to > manually select the schematic Tab again. Also, some of the updates for the > min/max values seem not to work correctly sometimes. > Will maybe take a longer look next week, if you update your code in the > meantime push it to SF so I can see it. > > Regards, > Claudio > > ----Messaggio originale---- > Da: kev...@gm... > Data: 24-apr-2015 18.23 > A: "Claudio Girardi"<cla...@vi...> > Ogg: Re: [Qucs] Getting selected Property of a Component > > > Hi Claudio > > hah, I'm glad you were able to compile and run it. > I'm having the same issue with the selected properties. Unfortunatly, the > selection is code is copied from the other Qucs part and I'm kind of > stumped. > (Mouse actions; Select, I think...) And i've taken a lot of hints from the > EditText part of the mouse actions. However I haven't been able to narrow > the problem down. > > I'll don't think I have more at the moment. I'll check. Hopefully I'll > have some time this weekend to work on it some more. > > Regards > Kevin > > > On Fri, Apr 24, 2015 at 6:18 PM, Claudio Girardi < > cla...@vi...> wrote: > >> Hello Kevin, >> found just today some time to play with your code. At the beginning I did >> not understand where/what I should click on :) >> Now I can get the properties into the Tune dialog (easy, once one >> knows...) but I cannot get it to run properly. The properties are often >> picked up wrongly (when I click on a resistor value often it takes the >> temperature as parameter) and the netlist generated is not valid or empty. >> Does it work correctly on your side? Which OS are you using? Do you have >> any update to the code w.r.t. the one you uploaded on Sourceforge? >> >> Thanks, >> Claudio >> >> ----Messaggio originale---- >> Da: kev...@gm... >> Data: 11-apr-2015 12.10 >> A: >> Cc: <quc...@li...> >> Ogg: Re: [Qucs-devel] Getting selected Property of a Component >> >> Hey Claudio >> >> forking is done. I've created my own fork + tunerdialogbranch at >> http://sourceforge.net/u/tipofthesowrd/qucs/ci/tunerdialog/tree/ >> Any logged in user is free to contribute... ;-) >> Right now cmake is compiling fine. I'll have to check how to get autotools >> up and running. >> Thanks for all the help so far >> >> Regards >> >> Kevin >> >> On Sat, Apr 11, 2015 at 11:44 AM, Claudio Girardi < >> cla...@vi...> wrote: >> >> > Hello Kevin, >> > yodalee created a brief guide on the wiki on this, >> > https://github.com/Qucs/qucs/wiki/Contribution ; it is quite concise, >> > feel free to ask if something is not clear. >> > In general the different branches on the main repository are meant for >> > long-term, wide-reaching, changes; for smaller changes, which are >> (supposed >> > to be) ready to be integrated in to the master branch, you should push >> your >> > new branch to your fork on Github and then create a pull request. >> > Note that we try to keep both the Autotools and cmake build systems >> > up-to-date, so ideally your new code should be able to be compiled with >> > both systems; in any case you can create a pull request even if the code >> > currently builds with the Autotools only, we can figure out later how to >> > properly compile it with cmake as you can update your local branch and >> the >> > related pull request later, before merging it into the master branch. >> > >> > Regards, >> > Claudio >> > >> > ----Messaggio originale---- >> > Da: kev...@gm... >> > Data: 11-apr-2015 10.56 >> > A: >> > Cc: <quc...@li...> >> > Ogg: Re: [Qucs-devel] Getting selected Property of a Component >> > >> > Hi Vadim >> > >> > that did it. I had to adjust the Makefile.am file and now everything >> builds >> > fine. >> > I've created a local branch after checking out. What is the best way >> > forward? >> > Fork or can I create a seperate branch on the master? >> > >> > I'm used to working with mercurial so git is kinda new to me >> > >> > Regards, >> > Kevin >> > >> > >> > >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> Qucs-devel mailing list >> Quc...@li... >> https://lists.sourceforge.net/lists/listinfo/qucs-devel >> >> >> > > > |
From: Vadim K. <ra...@gm...> - 2015-04-27 16:46:44
|
Hello Kevin, I have tested your Tuner dialog. This will be a great feature. As concerning auto-switching to display page we can solve this problem as following. We can simply put diagram on schematic and then prevent schematic from switching to display when Tuner dialog is active. And we can see results directly on schematic. --- Regards, Vadim Kuznetsov On 27.04.2015 12:18, Kevin Voet wrote: > Hi Claudio > > I applied the patch (works like a charm!) and have pushed my latest > changes. That should help in my development as well since I was getting > frustrated about the property selection. > > I have the feeling selection of properties could benefit from a crosshair > pointer or something similar (like when drawing wires)? > > I just checked the Data display remark. Indeed, Qucs-GUI cannot simulate > when started from the data display. I never noticed this before. Probably > because I usually drag my data displays onto the schematic. I think we > should try and find a workaround for this since the whole idea of the tuner > was to see the diagrams change 'live' and it shouldn't matter wheter they > are on their own display or on the schematic. > > Regards > > Kevin > > > On Fri, Apr 24, 2015 at 10:25 PM, Claudio Girardi < > cla...@vi...> wrote: > >> Hello again... >> I took a look at the code since, as you said, the selection is based on >> existing code and should then work properly; it turns out you did it >> *almost* right, just missed to subtract 1 to an index... Moreover, you were >> a bit unlucky, since the current Qucs code has (had, actually) bug which >> makes the selection of a property with the mouse somewhat imprecise. It was >> corrected only recently, but it is just a single line correction, so I have >> included it in the enclosed patch file. It contains also the correction to >> the property selection for the tuner. You might want to rebase your code to >> the current one, but that is actually not really needed. >> Still, it does not work properly for schematics having a separate Data >> Display, since apparently it tries to generate a netlist for the Data >> Display when this is opened, which obviously does not work, you need to >> manually select the schematic Tab again. Also, some of the updates for the >> min/max values seem not to work correctly sometimes. >> Will maybe take a longer look next week, if you update your code in the >> meantime push it to SF so I can see it. >> >> Regards, >> Claudio >> >> ----Messaggio originale---- >> Da: kev...@gm... >> Data: 24-apr-2015 18.23 >> A: "Claudio Girardi"<cla...@vi...> >> Ogg: Re: [Qucs] Getting selected Property of a Component >> >> >> Hi Claudio >> >> hah, I'm glad you were able to compile and run it. >> I'm having the same issue with the selected properties. Unfortunatly, the >> selection is code is copied from the other Qucs part and I'm kind of >> stumped. >> (Mouse actions; Select, I think...) And i've taken a lot of hints from the >> EditText part of the mouse actions. However I haven't been able to narrow >> the problem down. >> >> I'll don't think I have more at the moment. I'll check. Hopefully I'll >> have some time this weekend to work on it some more. >> >> Regards >> Kevin >> >> >> On Fri, Apr 24, 2015 at 6:18 PM, Claudio Girardi < >> cla...@vi...> wrote: >> >>> Hello Kevin, >>> found just today some time to play with your code. At the beginning I did >>> not understand where/what I should click on :) >>> Now I can get the properties into the Tune dialog (easy, once one >>> knows...) but I cannot get it to run properly. The properties are often >>> picked up wrongly (when I click on a resistor value often it takes the >>> temperature as parameter) and the netlist generated is not valid or empty. >>> Does it work correctly on your side? Which OS are you using? Do you have >>> any update to the code w.r.t. the one you uploaded on Sourceforge? >>> >>> Thanks, >>> Claudio >>> >>> ----Messaggio originale---- >>> Da: kev...@gm... >>> Data: 11-apr-2015 12.10 >>> A: >>> Cc: <quc...@li...> >>> Ogg: Re: [Qucs-devel] Getting selected Property of a Component >>> >>> Hey Claudio >>> >>> forking is done. I've created my own fork + tunerdialogbranch at >>> http://sourceforge.net/u/tipofthesowrd/qucs/ci/tunerdialog/tree/ >>> Any logged in user is free to contribute... ;-) >>> Right now cmake is compiling fine. I'll have to check how to get autotools >>> up and running. >>> Thanks for all the help so far >>> >>> Regards >>> >>> Kevin >>> >>> On Sat, Apr 11, 2015 at 11:44 AM, Claudio Girardi < >>> cla...@vi...> wrote: >>> >>>> Hello Kevin, >>>> yodalee created a brief guide on the wiki on this, >>>> https://github.com/Qucs/qucs/wiki/Contribution ; it is quite concise, >>>> feel free to ask if something is not clear. >>>> In general the different branches on the main repository are meant for >>>> long-term, wide-reaching, changes; for smaller changes, which are >>> (supposed >>>> to be) ready to be integrated in to the master branch, you should push >>> your >>>> new branch to your fork on Github and then create a pull request. >>>> Note that we try to keep both the Autotools and cmake build systems >>>> up-to-date, so ideally your new code should be able to be compiled with >>>> both systems; in any case you can create a pull request even if the code >>>> currently builds with the Autotools only, we can figure out later how to >>>> properly compile it with cmake as you can update your local branch and >>> the >>>> related pull request later, before merging it into the master branch. >>>> >>>> Regards, >>>> Claudio >>>> >>>> ----Messaggio originale---- >>>> Da: kev...@gm... >>>> Data: 11-apr-2015 10.56 >>>> A: >>>> Cc: <quc...@li...> >>>> Ogg: Re: [Qucs-devel] Getting selected Property of a Component >>>> >>>> Hi Vadim >>>> >>>> that did it. I had to adjust the Makefile.am file and now everything >>> builds >>>> fine. >>>> I've created a local branch after checking out. What is the best way >>>> forward? >>>> Fork or can I create a seperate branch on the master? >>>> >>>> I'm used to working with mercurial so git is kinda new to me >>>> >>>> Regards, >>>> Kevin >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> Develop your own process in accordance with the BPMN 2 standard >>> Learn Process modeling best practices with Bonita BPM through live >>> exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> _______________________________________________ >>> Qucs-devel mailing list >>> Quc...@li... >>> https://lists.sourceforge.net/lists/listinfo/qucs-devel >>> >>> >>> >> >> > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Claudio G. <cla...@vi...> - 2015-04-27 19:03:51
|
Hello Vadim and Kevin, IMHO, the best way will be that the Tuner dialog remembers the schematic that was active when it was opened and runs a simulation always of that schematic. In this way a Data Display will be opened when the simulation is finished (if the schematic is so configured) and any subsequent simulation does not require the user to go back to the original schematic. This will allow to handle schematics with embedded diagrams and the ones with a separate Data Display, so it will work with any existing schematic without forcing the user to have diagrams on the schematic only. Might need to rewrite/extend slotSimulate() to achieve this, maybe by passing which document to simulate and simulate the current one if called with Null. Moreover, I think the the Tuner Dialog should show the Qucs Simulation Messages window, since the user will see any error messages that might appear and can monitor the progress if the simulation is not so quick and also there will be a possibility to abort the simulator in case of issues or too long simulation. Main disadvantage is that there will be one more window open... We should think also at how to select which simulator to use as default for the simulation, it will be needed when the qucs4spice branch will be integrated :); should we add a property to the schematic ? Regards, Claudio ----Messaggio originale---- Da: ra...@gm... Data: 27-apr-2015 18.45 A: <quc...@li...> Ogg: Re: [Qucs-devel] [Qucs] Getting selected Property of a Component Hello Kevin, I have tested your Tuner dialog. This will be a great feature. As concerning auto-switching to display page we can solve this problem as following. We can simply put diagram on schematic and then prevent schematic from switching to display when Tuner dialog is active. And we can see results directly on schematic. --- Regards, Vadim Kuznetsov On 27.04.2015 12:18, Kevin Voet wrote: > Hi Claudio > > I applied the patch (works like a charm!) and have pushed my latest > changes. That should help in my development as well since I was getting > frustrated about the property selection. > > I have the feeling selection of properties could benefit from a crosshair > pointer or something similar (like when drawing wires)? > > I just checked the Data display remark. Indeed, Qucs-GUI cannot simulate > when started from the data display. I never noticed this before. Probably > because I usually drag my data displays onto the schematic. I think we > should try and find a workaround for this since the whole idea of the tuner > was to see the diagrams change 'live' and it shouldn't matter wheter they > are on their own display or on the schematic. > > Regards > > Kevin |
From: Kevin V. <kev...@gm...> - 2015-04-28 07:51:50
|
Hi Claudio, Vadim I agree with your suggestion about supporting both simulations started from data display and from schematic. I think this can be quite easily implemented. What I find more difficult is the showing of messages. The reason I'm hiding the window messages is because currently Qucs is configured to show a new simulation window for each simulation. This is quite annoying when tuning! If you accidentally step over a 100 points you will have 100 simulation windows. I could not immediately find a way to edit this behavior so I'm hiding the simulation windows... Regarding the default simulation, since the tuner uses the slotSimulate function I think this behavior will follow the 'current' Qucs behavior. Meaning a AC simulation will trigger a DC simulation if applicable, etc. When both an AC/Transient/S-parameter simulation is present Qucs will perform all three by default. I see two ways to solve this: 1) Only run 1 simulation when tuning --> give property to tuner which simulation to run 2) Run all simulations on the schematic which have a 'Tuner' Property. 1 is less work I think then 2 but I don't know the properties code all the well for schematic objects Regards Kevin On Mon, Apr 27, 2015 at 9:03 PM, Claudio Girardi < cla...@vi...> wrote: > Hello Vadim and Kevin, > IMHO, the best way will be that the Tuner dialog remembers the schematic > that was active when it was opened and runs a simulation always of that > schematic. In this way a Data Display will be opened when the simulation is > finished (if the schematic is so configured) and any subsequent simulation > does not require the user to go back to the original schematic. This will > allow to handle schematics with embedded diagrams and the ones with a > separate Data Display, so it will work with any existing schematic without > forcing the user to have diagrams on the schematic only. Might need to > rewrite/extend slotSimulate() to achieve this, maybe by passing which > document to simulate and simulate the current one if called with Null. > Moreover, I think the the Tuner Dialog should show the Qucs Simulation > Messages window, since the user will see any error messages that might > appear and can monitor the progress if the simulation is not so quick and > also there will be a possibility to abort the simulator in case of issues > or too long simulation. Main disadvantage is that there will be one more > window open... > We should think also at how to select which simulator to use as default > for the simulation, it will be needed when the qucs4spice branch will be > integrated :); should we add a property to the schematic ? > > > Regards, > Claudio > > > ----Messaggio originale---- > Da: ra...@gm... > Data: 27-apr-2015 18.45 > A: <quc...@li...> > Ogg: Re: [Qucs-devel] [Qucs] Getting selected Property of a Component > > Hello Kevin, > > I have tested your Tuner dialog. This will be a great feature. As > concerning auto-switching to display page we can solve this problem as > following. We can simply put diagram on schematic and then prevent > schematic from switching to display when Tuner dialog is active. And we > can see results directly on schematic. > > --- > Regards, > Vadim Kuznetsov > > On 27.04.2015 12:18, Kevin Voet wrote: > > Hi Claudio > > > > I applied the patch (works like a charm!) and have pushed my latest > > changes. That should help in my development as well since I was getting > > frustrated about the property selection. > > > > I have the feeling selection of properties could benefit from a crosshair > > pointer or something similar (like when drawing wires)? > > > > I just checked the Data display remark. Indeed, Qucs-GUI cannot simulate > > when started from the data display. I never noticed this before. Probably > > because I usually drag my data displays onto the schematic. I think we > > should try and find a workaround for this since the whole idea of the > tuner > > was to see the diagrams change 'live' and it shouldn't matter wheter they > > are on their own display or on the schematic. > > > > Regards > > > > Kevin > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Guilherme B. T. <gui...@gm...> - 2015-04-29 08:20:37
|
Hello, What about putting the simulator output and error messages as tabs on the lower dock? It does not have to be visible all the time. I also find annoying the pop up dialog at the end of each run. Note that the DataDisplay field in the .sch file point to its child .dpl file. In the .dpl file the field points to its parent .sch. If you use the tuner on the display tab, it should be possible to reach the parent schematic to run the simulation. Right now we only keep track of one display, however you can add as many as you want (not recorded on the .sch). Perhaps it makes sense to keep track of a list of child .dpl displays... Regards, Guilherme On 4/28/15 9:51 AM, Kevin Voet wrote: > Hi Claudio, Vadim > > I agree with your suggestion about supporting both simulations started from > data display and from schematic. I think this can be quite easily > implemented. What I find more difficult is the showing of messages. > > The reason I'm hiding the window messages is because currently Qucs is > configured to show a new simulation window for each simulation. This is > quite annoying when tuning! If you accidentally step over a 100 points you > will have 100 simulation windows. I could not immediately find a way to > edit this behavior so I'm hiding the simulation windows... > > Regarding the default simulation, since the tuner uses the slotSimulate > function I think this behavior will follow the 'current' Qucs behavior. > Meaning a AC simulation will trigger a DC simulation if applicable, etc. > When both an AC/Transient/S-parameter simulation is present Qucs will > perform all three by default. > I see two ways to solve this: > > 1) Only run 1 simulation when tuning --> give property to tuner which > simulation to run > 2) Run all simulations on the schematic which have a 'Tuner' Property. > > 1 is less work I think then 2 but I don't know the properties code all the > well for schematic objects > > Regards > > Kevin > > On Mon, Apr 27, 2015 at 9:03 PM, Claudio Girardi < > cla...@vi...> wrote: > >> Hello Vadim and Kevin, >> IMHO, the best way will be that the Tuner dialog remembers the schematic >> that was active when it was opened and runs a simulation always of that >> schematic. In this way a Data Display will be opened when the simulation is >> finished (if the schematic is so configured) and any subsequent simulation >> does not require the user to go back to the original schematic. This will >> allow to handle schematics with embedded diagrams and the ones with a >> separate Data Display, so it will work with any existing schematic without >> forcing the user to have diagrams on the schematic only. Might need to >> rewrite/extend slotSimulate() to achieve this, maybe by passing which >> document to simulate and simulate the current one if called with Null. >> Moreover, I think the the Tuner Dialog should show the Qucs Simulation >> Messages window, since the user will see any error messages that might >> appear and can monitor the progress if the simulation is not so quick and >> also there will be a possibility to abort the simulator in case of issues >> or too long simulation. Main disadvantage is that there will be one more >> window open... >> We should think also at how to select which simulator to use as default >> for the simulation, it will be needed when the qucs4spice branch will be >> integrated :); should we add a property to the schematic ? >> >> >> Regards, >> Claudio >> >> >> ----Messaggio originale---- >> Da: ra...@gm... >> Data: 27-apr-2015 18.45 >> A: <quc...@li...> >> Ogg: Re: [Qucs-devel] [Qucs] Getting selected Property of a Component >> >> Hello Kevin, >> >> I have tested your Tuner dialog. This will be a great feature. As >> concerning auto-switching to display page we can solve this problem as >> following. We can simply put diagram on schematic and then prevent >> schematic from switching to display when Tuner dialog is active. And we >> can see results directly on schematic. >> >> --- >> Regards, >> Vadim Kuznetsov >> >> On 27.04.2015 12:18, Kevin Voet wrote: >>> Hi Claudio >>> >>> I applied the patch (works like a charm!) and have pushed my latest >>> changes. That should help in my development as well since I was getting >>> frustrated about the property selection. >>> >>> I have the feeling selection of properties could benefit from a crosshair >>> pointer or something similar (like when drawing wires)? >>> >>> I just checked the Data display remark. Indeed, Qucs-GUI cannot simulate >>> when started from the data display. I never noticed this before. Probably >>> because I usually drag my data displays onto the schematic. I think we >>> should try and find a workaround for this since the whole idea of the >> tuner >>> was to see the diagrams change 'live' and it shouldn't matter wheter they >>> are on their own display or on the schematic. >>> >>> Regards >>> >>> Kevin >> |
From: Kevin V. <kev...@gm...> - 2015-04-11 06:12:10
|
Hi Claudio that helped, thanks. My tuner dialog is now complete ready for some first tests. I've been building/debugging with QtCreator so far without much issues. I'd like to build using make from command line. I've added my files to CMakelists.txt (was also need for QtCreator), yet the build failes while trying to link to my new objects. What do I have to do to add files to the build? Kevin On Wed, Apr 8, 2015 at 9:36 PM, Claudio Girardi <cla...@vi... > wrote: > Hello Kevin, > nice work on the tuner dialog, will be a great addition to Qucs. > If I understood correctly, you would like to know on which property of a > component in a schematic the user clicked, as one does usually to change it. > In the current code this is handled by the Component::getTextSelected() > function, which compares the mouse pointer position with the component > properties position, tries to find the one under the cursor when the user > clicked and return the corresponding property index. > A typical gdb backtrace showing all the functions involved when clicking > on a property is this: > > #0 Component::getTextSelected (this=0x89e0248, x_=31, y_=29, > Corr=0.0514725037) at component.cpp:171 > #1 0x080ccd8a in Schematic::selectElement (this=0x89daff0, fX=119.19519, > fY=233.992416, flag=false, > index=0xbfffe370) at schematic_element.cpp:1137 > #2 0x0806a2ff in MouseActions::MPressSelect (this=0x85af1a8, > Doc=0x89daff0, Event=0xbfffe428, > fX=119.19519, fY=233.992416) at mouseactions.cpp:907 > #3 0x080bf108 in Schematic::contentsMousePressEvent (this=0x89daff0, > Event=0xbfffe428) > at schematic.cpp:575 > #4 0xb6ebe7b5 in Q3ScrollView::viewportMousePressEvent(QMouseEvent*) () > > Hope this helps, > Claudio > > > ----Messaggio originale---- > Da: kev...@gm... > Data: 8-apr-2015 19.50 > A: <quc...@li...> > Ogg: [Qucs-devel] Getting selected Property of a Component > > > Hi all > > I'm currently working on some personal extensions to Qucs which I would > eventually like to share with the group. > > I'm working on a tuner dialog window which will update component values and > restart the simulation (for example S-parameter). That way you could > finetune L and C values of a filter for example without sweeping over the > values and see the effect of component changes realtime. (Just take a look > at AWR or ADS, Genesys, etc...). > > My tuner window is already OK, I can click a component and add a widget to > my dialog but now I'm trying to figure out a way to determine which > property of a component the user selected. > > For example in a microstrip you might want to edit the length and width > parameter. Currently my code is setup so that when the user clicks a > component an event fires. I was trying to look at the MPressSelect action > and found a way to know that propertyText is selected with the > focusElement->Type. Now I just need to know which exact property the user > clicked. > > Is something like this already implemented? > > Kind Regards > > Kevin > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > |
From: Vadim K. <ra...@gm...> - 2015-04-11 08:20:28
|
Hello Kevin, Qucs uses two independent build systems: CMake (experimantal) and Autotools (main). You can use CMake with QtCreator. I use it. To build qucs with make without cmake you need to add your new files to Autotools build systems. You need add sources and headers to Makefile.am If you have added new subdirectories you need to place your own Makefile.am in it. Subdirectories also should be specified in the top Makefile.am and configure.ac To build with autotools use biuld instructions from Qucs Readme on Github. Regards, Vadim Kuznetsov On 11.04.2015 09:11, Kevin Voet wrote: > Hi Claudio > > that helped, thanks. My tuner dialog is now complete ready for some first > tests. > I've been building/debugging with QtCreator so far without much issues. > > I'd like to build using make from command line. > I've added my files to CMakelists.txt (was also need for QtCreator), yet > the build failes while trying to link to my new objects. > > What do I have to do to add files to the build? > > Kevin > > On Wed, Apr 8, 2015 at 9:36 PM, Claudio Girardi <cla...@vi... >> wrote: >> Hello Kevin, >> nice work on the tuner dialog, will be a great addition to Qucs. >> If I understood correctly, you would like to know on which property of a >> component in a schematic the user clicked, as one does usually to change it. >> In the current code this is handled by the Component::getTextSelected() >> function, which compares the mouse pointer position with the component >> properties position, tries to find the one under the cursor when the user >> clicked and return the corresponding property index. >> A typical gdb backtrace showing all the functions involved when clicking >> on a property is this: >> >> #0 Component::getTextSelected (this=0x89e0248, x_=31, y_=29, >> Corr=0.0514725037) at component.cpp:171 >> #1 0x080ccd8a in Schematic::selectElement (this=0x89daff0, fX=119.19519, >> fY=233.992416, flag=false, >> index=0xbfffe370) at schematic_element.cpp:1137 >> #2 0x0806a2ff in MouseActions::MPressSelect (this=0x85af1a8, >> Doc=0x89daff0, Event=0xbfffe428, >> fX=119.19519, fY=233.992416) at mouseactions.cpp:907 >> #3 0x080bf108 in Schematic::contentsMousePressEvent (this=0x89daff0, >> Event=0xbfffe428) >> at schematic.cpp:575 >> #4 0xb6ebe7b5 in Q3ScrollView::viewportMousePressEvent(QMouseEvent*) () >> >> Hope this helps, >> Claudio >> >> >> ----Messaggio originale---- >> Da: kev...@gm... >> Data: 8-apr-2015 19.50 >> A: <quc...@li...> >> Ogg: [Qucs-devel] Getting selected Property of a Component >> >> >> Hi all >> >> I'm currently working on some personal extensions to Qucs which I would >> eventually like to share with the group. >> >> I'm working on a tuner dialog window which will update component values and >> restart the simulation (for example S-parameter). That way you could >> finetune L and C values of a filter for example without sweeping over the >> values and see the effect of component changes realtime. (Just take a look >> at AWR or ADS, Genesys, etc...). >> >> My tuner window is already OK, I can click a component and add a widget to >> my dialog but now I'm trying to figure out a way to determine which >> property of a component the user selected. >> >> For example in a microstrip you might want to edit the length and width >> parameter. Currently my code is setup so that when the user clicks a >> component an event fires. I was trying to look at the MPressSelect action >> and found a way to know that propertyText is selected with the >> focusElement->Type. Now I just need to know which exact property the user >> clicked. >> >> Is something like this already implemented? >> >> Kind Regards >> >> Kevin >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live >> exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> Qucs-devel mailing list >> Quc...@li... >> https://lists.sourceforge.net/lists/listinfo/qucs-devel >> >> >> > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Kevin V. <kev...@gm...> - 2015-04-11 08:56:45
|
Hi Vadim that did it. I had to adjust the Makefile.am file and now everything builds fine. I've created a local branch after checking out. What is the best way forward? Fork or can I create a seperate branch on the master? I'm used to working with mercurial so git is kinda new to me Regards, Kevin On Sat, Apr 11, 2015 at 10:19 AM, Vadim Kuznetsov <ra...@gm...> wrote: > Hello Kevin, > > Qucs uses two independent build systems: CMake (experimantal) and > Autotools (main). You can use CMake with QtCreator. I use it. > > To build qucs with make without cmake you need to add your new files to > Autotools build systems. You need add sources and headers to Makefile.am > If you have added new subdirectories you need to place your own > Makefile.am in it. Subdirectories also should be specified in the top > Makefile.am and configure.ac > > To build with autotools use biuld instructions from Qucs Readme on Github. > > Regards, > Vadim Kuznetsov > > On 11.04.2015 09:11, Kevin Voet wrote: > > Hi Claudio > > > > that helped, thanks. My tuner dialog is now complete ready for some first > > tests. > > I've been building/debugging with QtCreator so far without much issues. > > > > I'd like to build using make from command line. > > I've added my files to CMakelists.txt (was also need for QtCreator), yet > > the build failes while trying to link to my new objects. > > > > What do I have to do to add files to the build? > > > > Kevin > > > > On Wed, Apr 8, 2015 at 9:36 PM, Claudio Girardi < > cla...@vi... > >> wrote: > >> Hello Kevin, > >> nice work on the tuner dialog, will be a great addition to Qucs. > >> If I understood correctly, you would like to know on which property of a > >> component in a schematic the user clicked, as one does usually to > change it. > >> In the current code this is handled by the Component::getTextSelected() > >> function, which compares the mouse pointer position with the component > >> properties position, tries to find the one under the cursor when the > user > >> clicked and return the corresponding property index. > >> A typical gdb backtrace showing all the functions involved when clicking > >> on a property is this: > >> > >> #0 Component::getTextSelected (this=0x89e0248, x_=31, y_=29, > >> Corr=0.0514725037) at component.cpp:171 > >> #1 0x080ccd8a in Schematic::selectElement (this=0x89daff0, > fX=119.19519, > >> fY=233.992416, flag=false, > >> index=0xbfffe370) at schematic_element.cpp:1137 > >> #2 0x0806a2ff in MouseActions::MPressSelect (this=0x85af1a8, > >> Doc=0x89daff0, Event=0xbfffe428, > >> fX=119.19519, fY=233.992416) at mouseactions.cpp:907 > >> #3 0x080bf108 in Schematic::contentsMousePressEvent (this=0x89daff0, > >> Event=0xbfffe428) > >> at schematic.cpp:575 > >> #4 0xb6ebe7b5 in Q3ScrollView::viewportMousePressEvent(QMouseEvent*) () > >> > >> Hope this helps, > >> Claudio > >> > >> > >> ----Messaggio originale---- > >> Da: kev...@gm... > >> Data: 8-apr-2015 19.50 > >> A: <quc...@li...> > >> Ogg: [Qucs-devel] Getting selected Property of a Component > >> > >> > >> Hi all > >> > >> I'm currently working on some personal extensions to Qucs which I would > >> eventually like to share with the group. > >> > >> I'm working on a tuner dialog window which will update component values > and > >> restart the simulation (for example S-parameter). That way you could > >> finetune L and C values of a filter for example without sweeping over > the > >> values and see the effect of component changes realtime. (Just take a > look > >> at AWR or ADS, Genesys, etc...). > >> > >> My tuner window is already OK, I can click a component and add a widget > to > >> my dialog but now I'm trying to figure out a way to determine which > >> property of a component the user selected. > >> > >> For example in a microstrip you might want to edit the length and width > >> parameter. Currently my code is setup so that when the user clicks a > >> component an event fires. I was trying to look at the MPressSelect > action > >> and found a way to know that propertyText is selected with the > >> focusElement->Type. Now I just need to know which exact property the > user > >> clicked. > >> > >> Is something like this already implemented? > >> > >> Kind Regards > >> > >> Kevin > >> > >> > ------------------------------------------------------------------------------ > >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > >> Develop your own process in accordance with the BPMN 2 standard > >> Learn Process modeling best practices with Bonita BPM through live > >> exercises > >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > >> event?utm_ > >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > >> _______________________________________________ > >> Qucs-devel mailing list > >> Quc...@li... > >> https://lists.sourceforge.net/lists/listinfo/qucs-devel > >> > >> > >> > > > ------------------------------------------------------------------------------ > > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > > Develop your own process in accordance with the BPMN 2 standard > > Learn Process modeling best practices with Bonita BPM through live > exercises > > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > _______________________________________________ > > Qucs-devel mailing list > > Quc...@li... > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |