From: Clemens N. <cl...@fa...> - 2014-03-13 13:45:51
|
Hi, in the meantime, a lot of Qt3Support classes in the gui cdoe have been replaced with more modern qt4 classes. One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - looking at the source, it seems to allow editing subcircuit parameters (based on the data contained in the ID_Text class). Strangely, I'm not able to "use" this dialog in qucs; no matter which menu / context menu I click, this dialog dialog never appears. Also the user manual, workbook etc don't seem to mention / show the dialog. So, maybe this is some "lost code" since it is not used (or is has been included as a possible future extension)? Perhaps someone on the list can point me in the right direction... Second point is the use of Q3PtrList - there is a dedicated branch (remove_Qt3PtrList) for this and - if ok with you - I would like to start merging some changes into master. The branch is somewhat old & a lot of work has happened on master, so this will involve some manual merging (maybe of single commits). The wiki states that some parts are not ported (yet) because they will become obsolete by the QGraphicsFramework - I'll start with the "other" parts. Regards - Clemens |
From: Frans S. <fra...@gm...> - 2014-03-13 13:50:49
|
Hi Clemens, About the remove_Qt3PtrList branch, I would not like to merge this one back before releasing a next stable version of qucs. Maybe we should even start over again, because it contains a lot of bugs. I don't know about the ID_Dialog, maybe we could try commenting out the code and see where the compile fails. Frans On 03/13/2014 02:19 PM, Clemens Novak wrote: > Hi, > > in the meantime, a lot of Qt3Support classes in the gui cdoe have been > replaced with more modern qt4 classes. > > One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - > looking at the source, it seems to allow editing subcircuit parameters > (based on the data contained in the ID_Text class). > > Strangely, I'm not able to "use" this dialog in qucs; no matter which > menu / context menu I click, this dialog dialog never appears. Also the > user manual, workbook etc don't seem to mention / show the dialog. So, > maybe this is some "lost code" since it is not used (or is has been > included as a possible future extension)? Perhaps someone on the list > can point me in the right direction... > > Second point is the use of Q3PtrList - there is a dedicated branch > (remove_Qt3PtrList) for this and - if ok with you - I would like to > start merging some changes into master. The branch is somewhat old & a > lot of work has happened on master, so this will involve some manual > merging (maybe of single commits). The wiki states that some parts are > not ported (yet) because they will become obsolete by the > QGraphicsFramework - I'll start with the "other" parts. > > Regards - Clemens > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Guilherme B. T. <gui...@gm...> - 2014-03-13 15:21:18
|
On 13/03/14 14:19, Clemens Novak wrote: > Hi, Hi! > in the meantime, a lot of Qt3Support classes in the gui cdoe have been > replaced with more modern qt4 classes. > > One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - > looking at the source, it seems to allow editing subcircuit parameters > (based on the data contained in the ID_Text class). > > Strangely, I'm not able to "use" this dialog in qucs; no matter which > menu / context menu I click, this dialog dialog never appears. Also the > user manual, workbook etc don't seem to mention / show the dialog. So, > maybe this is some "lost code" since it is not used (or is has been > included as a possible future extension)? Perhaps someone on the list > can point me in the right direction... Hum, it looks like dead code... But it is not! :) It opens when you edit the properties of a subcircuit. See the dialog for the text symbol properties on the verilog-a components (attach)... > Second point is the use of Q3PtrList - there is a dedicated branch > (remove_Qt3PtrList) for this and - if ok with you - I would like to > start merging some changes into master. The branch is somewhat old & a > lot of work has happened on master, so this will involve some manual > merging (maybe of single commits). The wiki states that some parts are > not ported (yet) because they will become obsolete by the > QGraphicsFramework - I'll start with the "other" parts. I agree with Frans, very dangerous to merge back anything from `remove_Qt3PtrlList`. I took sort of a brute force aproach on the `remove_Qt3PtrlList`. So now I am also scratching my head on how to proceed with that. It could be extremely laborious to even cherry-pick patches from that branch as I was not really careful to separate changes. The history is a mess, and I apologize for that. I was learning my way with Git. Basically I replaced Qt3PtrlList wherever I could, the remaing parts were commented out. The commented out sections include are all the mouse interaction, drag, drop, insertion of items into the schematic. All this has to be replaced by QGraphics anyway. I got blocked not knowing which kind of objects have to be put into the QLists that keep track of the stuff on the schematic... To make sure the QLists are sort of working, I tried to fix it so that I could at least open existing schematics. This part is done (mostly). All the schematics I had at the time could be rendered. Well some diagrams (like cartesian, smith) are still broken... In the current status the Qt3PtrlList were all either removed or commented out. The code loads and renders (some) schematics. That is more ore less the status. My intention was to create another branch to implement just the QGraphics and them merge into the `remove_Qt3PtrlList`. Now I believe it is better if we rebase `remove_Qt3PtrlList` on master, resolve conflicts and continue working out the QGraphics incrementally from there. This way we have the chance to improve and refactor the GUI, which would be more difficult if we just cherry-pick from `remove_Qt3PtrlList`. Let us take a further look and try to coordinate the efforts. Hopefully we can use the stuff already there instead of starting over. I believe we should think about ways of testing the GUI against MASTER. By the time we are ready to merge pack we should make sure we do not introduce major regressions. Merges to MASTER should not break anything (in theory)... :) I won't have time to look at it till next weekend. If want to give it a try please let me know how it goes ;) > Regards - Clemens > Regards, Guilherme |
From: Clemens N. <cl...@fa...> - 2014-03-17 16:12:24
|
On 2014-03-13 16:21, Guilherme Brondani Torri wrote: > On 13/03/14 14:19, Clemens Novak wrote: >> Hi, > > Hi! >> in the meantime, a lot of Qt3Support classes in the gui cdoe have been >> replaced with more modern qt4 classes. >> >> One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - >> looking at the source, it seems to allow editing subcircuit parameters >> (based on the data contained in the ID_Text class). >> >> Strangely, I'm not able to "use" this dialog in qucs; no matter which >> menu / context menu I click, this dialog dialog never appears. Also >> the >> user manual, workbook etc don't seem to mention / show the dialog. So, >> maybe this is some "lost code" since it is not used (or is has been >> included as a possible future extension)? Perhaps someone on the list >> can point me in the right direction... > > Hum, it looks like dead code... But it is not! :) > It opens when you edit the properties of a subcircuit. > See the dialog for the text symbol properties on the verilog-a > components (attach)... >> Second point is the use of Q3PtrList - there is a dedicated branch >> (remove_Qt3PtrList) for this and - if ok with you - I would like to >> start merging some changes into master. The branch is somewhat old & a >> lot of work has happened on master, so this will involve some manual >> merging (maybe of single commits). The wiki states that some parts are >> not ported (yet) because they will become obsolete by the >> QGraphicsFramework - I'll start with the "other" parts. > > I agree with Frans, very dangerous to merge back anything from > `remove_Qt3PtrlList`. > I took sort of a brute force aproach on the `remove_Qt3PtrlList`. So > now I am also scratching my head on how to proceed with that. It could > be extremely laborious to even cherry-pick patches from that branch as > I was not really careful to separate changes. The history is a mess, > and I apologize for that. I was learning my way with Git. > > Basically I replaced Qt3PtrlList wherever I could, the remaing parts > were commented out. The commented out sections include are all the > mouse interaction, drag, drop, insertion of items into the schematic. > All this has to be replaced by QGraphics anyway. I got blocked not > knowing which kind of objects have to be put into the QLists that keep > track of the stuff on the schematic... > > To make sure the QLists are sort of working, I tried to fix it so that > I could at least open existing schematics. This part is done (mostly). > All the schematics I had at the time could be rendered. Well some > diagrams (like cartesian, smith) are still broken... > > In the current status the Qt3PtrlList were all either removed or > commented out. The code loads and renders (some) schematics. That is > more ore less the status. > > My intention was to create another branch to implement just the > QGraphics and them merge into the `remove_Qt3PtrlList`. Now I believe > it is better if we rebase `remove_Qt3PtrlList` on master, resolve > conflicts and continue working out the QGraphics incrementally from > there. This way we have the chance to improve and refactor the GUI, > which would be more difficult if we just cherry-pick from > `remove_Qt3PtrlList`. > > Let us take a further look and try to coordinate the efforts. > Hopefully we can use the stuff already there instead of starting over. > > I believe we should think about ways of testing the GUI against > MASTER. By the time we are ready to merge pack we should make sure we > do not introduce major regressions. Merges to MASTER should not break > anything (in theory)... :) > > I won't have time to look at it till next weekend. If want to give it > a try please let me know how it goes ;) >> Regards - Clemens >> > > Regards, > Guilherme Hi, thanks for pointing me to ID_Dialog - I'll try to open the dialog on my system as well... Thanks for the status update regarding the Qt3PtrlList. In my opinion one can distinguish between (i) usage as part of the drawing routines & (ii) else (e.g. Q3PtrList<DataX> cPointsX; in diagrams/graph.h). I fully agree that we shouldn't touch anything related to (i) as this will be changed when moving to QGraphics anyway. Nevertheless, there may be some cases, where the Qt3PtrlList could be already ported (mostly the (ii) cases) as these wouldn't be touched by the transition to QGraphics. But this would mean cherry-picking commits and / or manual porting of partial commits. I've been playing around with my QGraphics "proof of concept" and made some progress which I'd like to present to the ML later this week. Nevertheless - in my opinion - porting to QGraphics will be a major effort, touching most of the existing code base (the drawing routines make up a large part of the codebase & are tighlty integrated). Seen in this light, maybe we should put QGraphics first? Let's see how my proof of concept works & what you think of it. Maybe we can make up some kind of plan based on your feedback... Regards - Clemens |
From: Guilherme B. T. <gui...@gm...> - 2014-03-17 20:47:36
|
On 17/03/14 17:12, Clemens Novak wrote: > On 2014-03-13 16:21, Guilherme Brondani Torri wrote: >> On 13/03/14 14:19, Clemens Novak wrote: >>> Hi, >> Hi! >>> in the meantime, a lot of Qt3Support classes in the gui cdoe have been >>> replaced with more modern qt4 classes. >>> >>> One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - >>> looking at the source, it seems to allow editing subcircuit parameters >>> (based on the data contained in the ID_Text class). >>> >>> Strangely, I'm not able to "use" this dialog in qucs; no matter which >>> menu / context menu I click, this dialog dialog never appears. Also >>> the >>> user manual, workbook etc don't seem to mention / show the dialog. So, >>> maybe this is some "lost code" since it is not used (or is has been >>> included as a possible future extension)? Perhaps someone on the list >>> can point me in the right direction... >> Hum, it looks like dead code... But it is not! :) >> It opens when you edit the properties of a subcircuit. >> See the dialog for the text symbol properties on the verilog-a >> components (attach)... >>> Second point is the use of Q3PtrList - there is a dedicated branch >>> (remove_Qt3PtrList) for this and - if ok with you - I would like to >>> start merging some changes into master. The branch is somewhat old & a >>> lot of work has happened on master, so this will involve some manual >>> merging (maybe of single commits). The wiki states that some parts are >>> not ported (yet) because they will become obsolete by the >>> QGraphicsFramework - I'll start with the "other" parts. >> I agree with Frans, very dangerous to merge back anything from >> `remove_Qt3PtrlList`. >> I took sort of a brute force aproach on the `remove_Qt3PtrlList`. So >> now I am also scratching my head on how to proceed with that. It could >> be extremely laborious to even cherry-pick patches from that branch as >> I was not really careful to separate changes. The history is a mess, >> and I apologize for that. I was learning my way with Git. >> >> Basically I replaced Qt3PtrlList wherever I could, the remaing parts >> were commented out. The commented out sections include are all the >> mouse interaction, drag, drop, insertion of items into the schematic. >> All this has to be replaced by QGraphics anyway. I got blocked not >> knowing which kind of objects have to be put into the QLists that keep >> track of the stuff on the schematic... >> >> To make sure the QLists are sort of working, I tried to fix it so that >> I could at least open existing schematics. This part is done (mostly). >> All the schematics I had at the time could be rendered. Well some >> diagrams (like cartesian, smith) are still broken... >> >> In the current status the Qt3PtrlList were all either removed or >> commented out. The code loads and renders (some) schematics. That is >> more ore less the status. >> >> My intention was to create another branch to implement just the >> QGraphics and them merge into the `remove_Qt3PtrlList`. Now I believe >> it is better if we rebase `remove_Qt3PtrlList` on master, resolve >> conflicts and continue working out the QGraphics incrementally from >> there. This way we have the chance to improve and refactor the GUI, >> which would be more difficult if we just cherry-pick from >> `remove_Qt3PtrlList`. >> >> Let us take a further look and try to coordinate the efforts. >> Hopefully we can use the stuff already there instead of starting over. >> >> I believe we should think about ways of testing the GUI against >> MASTER. By the time we are ready to merge pack we should make sure we >> do not introduce major regressions. Merges to MASTER should not break >> anything (in theory)... :) >> >> I won't have time to look at it till next weekend. If want to give it >> a try please let me know how it goes ;) >>> Regards - Clemens >>> >> Regards, >> Guilherme > Hi, Hello Clemens, > thanks for pointing me to ID_Dialog - I'll try to open the dialog on my > system as well... > > Thanks for the status update regarding the Qt3PtrlList. In my opinion > one can distinguish between (i) usage as part of the drawing routines & > (ii) else (e.g. Q3PtrList<DataX> cPointsX; in diagrams/graph.h). I > fully agree that we shouldn't touch anything related to (i) as this will > be changed when moving to QGraphics anyway. > > Nevertheless, there may be some cases, where the Qt3PtrlList could be > already ported (mostly the (ii) cases) as these wouldn't be touched by > the transition to QGraphics. But this would mean cherry-picking commits > and / or manual porting of partial commits. You are totally right. I had another look at the `remove_Qt3PtrlList` branch. Maybe it is not as bad as I had in mind. However the branch got polluted with some bad merges I did. Give a few days and I will pick out the relevant commits into a new branch. It should make our life easier on picking up useful commits. But I think your next point is more important. We should focus on QGraphics... > > I've been playing around with my QGraphics "proof of concept" and made > some progress which I'd like to present to the ML later this week. > Nevertheless - in my opinion - porting to QGraphics will be a major > effort, touching most of the existing code base (the drawing routines > make up a large part of the codebase & are tighlty integrated). Seen in > this light, maybe we should put QGraphics first? So, it seems that you are agreeing with the idea of 'meeting in the middle'. At this point we need to figure out our way towards the QGraphics stuff. The Qt3PtrList removal is mostly solved and we can incorporate that later on or as needed. I had a look at one of your prototypes some time ago. They looked really nice. I remember that you suggested to subclass `Component` from `QGraphicsItem`. You can find some initial steps in here: https://github.com/guitorri/qucs/commits/GraphicsView Please have a look on the commits after this: 471c9cef17854606 get to compile with schematic as QGraphicsView Let me check it first but the branch https://github.com/Qucs/qucs/commits/new_GraphicsView should be removed/ignored. It did not use the above inheritance, which led to lots of unnecessary changes. > > Let's see how my proof of concept works & what you think of it. Maybe we > can make up some kind of plan based on your feedback... Looking forward to have a look at your code. In any case in my opinion we should first try to give some attention to the bug tracker, clean it up and do another release. After that we focus on getting started (and finished!!) with QGraphics. Best regards, Guilherme |
From: Guilherme B. T. <gui...@gm...> - 2014-03-17 23:36:52
|
On 17/03/14 21:47, Guilherme Brondani Torri wrote: > On 17/03/14 17:12, Clemens Novak wrote: >> On 2014-03-13 16:21, Guilherme Brondani Torri wrote: >>> On 13/03/14 14:19, Clemens Novak wrote: >>>> Hi, >>> Hi! >>>> in the meantime, a lot of Qt3Support classes in the gui cdoe have been >>>> replaced with more modern qt4 classes. >>>> >>>> One of the remainders is the ID_Dialog in paintings/id_dialog.cpp - >>>> looking at the source, it seems to allow editing subcircuit parameters >>>> (based on the data contained in the ID_Text class). >>>> >>>> Strangely, I'm not able to "use" this dialog in qucs; no matter which >>>> menu / context menu I click, this dialog dialog never appears. Also >>>> the >>>> user manual, workbook etc don't seem to mention / show the dialog. So, >>>> maybe this is some "lost code" since it is not used (or is has been >>>> included as a possible future extension)? Perhaps someone on the list >>>> can point me in the right direction... >>> Hum, it looks like dead code... But it is not! :) >>> It opens when you edit the properties of a subcircuit. >>> See the dialog for the text symbol properties on the verilog-a >>> components (attach)... >>>> Second point is the use of Q3PtrList - there is a dedicated branch >>>> (remove_Qt3PtrList) for this and - if ok with you - I would like to >>>> start merging some changes into master. The branch is somewhat old & a >>>> lot of work has happened on master, so this will involve some manual >>>> merging (maybe of single commits). The wiki states that some parts are >>>> not ported (yet) because they will become obsolete by the >>>> QGraphicsFramework - I'll start with the "other" parts. >>> I agree with Frans, very dangerous to merge back anything from >>> `remove_Qt3PtrlList`. >>> I took sort of a brute force aproach on the `remove_Qt3PtrlList`. So >>> now I am also scratching my head on how to proceed with that. It could >>> be extremely laborious to even cherry-pick patches from that branch as >>> I was not really careful to separate changes. The history is a mess, >>> and I apologize for that. I was learning my way with Git. >>> >>> Basically I replaced Qt3PtrlList wherever I could, the remaing parts >>> were commented out. The commented out sections include are all the >>> mouse interaction, drag, drop, insertion of items into the schematic. >>> All this has to be replaced by QGraphics anyway. I got blocked not >>> knowing which kind of objects have to be put into the QLists that keep >>> track of the stuff on the schematic... >>> >>> To make sure the QLists are sort of working, I tried to fix it so that >>> I could at least open existing schematics. This part is done (mostly). >>> All the schematics I had at the time could be rendered. Well some >>> diagrams (like cartesian, smith) are still broken... >>> >>> In the current status the Qt3PtrlList were all either removed or >>> commented out. The code loads and renders (some) schematics. That is >>> more ore less the status. >>> >>> My intention was to create another branch to implement just the >>> QGraphics and them merge into the `remove_Qt3PtrlList`. Now I believe >>> it is better if we rebase `remove_Qt3PtrlList` on master, resolve >>> conflicts and continue working out the QGraphics incrementally from >>> there. This way we have the chance to improve and refactor the GUI, >>> which would be more difficult if we just cherry-pick from >>> `remove_Qt3PtrlList`. >>> >>> Let us take a further look and try to coordinate the efforts. >>> Hopefully we can use the stuff already there instead of starting over. >>> >>> I believe we should think about ways of testing the GUI against >>> MASTER. By the time we are ready to merge pack we should make sure we >>> do not introduce major regressions. Merges to MASTER should not break >>> anything (in theory)... :) >>> >>> I won't have time to look at it till next weekend. If want to give it >>> a try please let me know how it goes ;) >>>> Regards - Clemens >>>> >>> Regards, >>> Guilherme >> Hi, > > Hello Clemens, > >> thanks for pointing me to ID_Dialog - I'll try to open the dialog on my >> system as well... >> >> Thanks for the status update regarding the Qt3PtrlList. In my opinion >> one can distinguish between (i) usage as part of the drawing routines & >> (ii) else (e.g. Q3PtrList<DataX> cPointsX; in diagrams/graph.h). I >> fully agree that we shouldn't touch anything related to (i) as this will >> be changed when moving to QGraphics anyway. >> >> Nevertheless, there may be some cases, where the Qt3PtrlList could be >> already ported (mostly the (ii) cases) as these wouldn't be touched by >> the transition to QGraphics. But this would mean cherry-picking commits >> and / or manual porting of partial commits. > > You are totally right. I had another look at the `remove_Qt3PtrlList` > branch. > Maybe it is not as bad as I had in mind. However the branch got > polluted with some bad merges I did. > Give a few days and I will pick out the relevant commits into a new > branch. It should make our life easier on picking up useful commits. > But I think your next point is more important. We should focus on > QGraphics... > >> >> I've been playing around with my QGraphics "proof of concept" and made >> some progress which I'd like to present to the ML later this week. >> Nevertheless - in my opinion - porting to QGraphics will be a major >> effort, touching most of the existing code base (the drawing routines >> make up a large part of the codebase & are tighlty integrated). Seen in >> this light, maybe we should put QGraphics first? > > So, it seems that you are agreeing with the idea of 'meeting in the > middle'. At this point we need to figure out our way towards the > QGraphics stuff. The Qt3PtrList removal is mostly solved and we can > incorporate that later on or as needed. > > I had a look at one of your prototypes some time ago. They looked > really nice. > > I remember that you suggested to subclass `Component` from > `QGraphicsItem`. > You can find some initial steps in here: > https://github.com/guitorri/qucs/commits/GraphicsView > Please have a look on the commits after this: > 471c9cef17854606 get to compile with schematic as QGraphicsView > > Let me check it first but the branch > https://github.com/Qucs/qucs/commits/new_GraphicsView should be > removed/ignored. It did not use the above inheritance, which led to > lots of unnecessary changes. >> >> Let's see how my proof of concept works & what you think of it. Maybe we >> can make up some kind of plan based on your feedback... > > Looking forward to have a look at your code. > In any case in my opinion we should first try to give some attention > to the bug tracker, clean it up and do another release. > After that we focus on getting started (and finished!!) with QGraphics. > > Best regards, > Guilherme > Hi, Quick followup, I created a new branch with commits relevant for QGraphics (rebased on current master). Please have a look at the wiki, I also added a screenshot to show how it looks like right now: https://github.com/Qucs/qucs.github.io/wiki/QGraphicsFramework I will do a similar cherry-pick with `remove_Qt3PtrlList` in the following days. Regards, Guilherme |