From: 李祐棠 <lc...@gm...> - 2015-04-15 07:22:09
|
Hello developers: Actually if you looks at the branch, it just remove the Schematic from qucs. The main target of the rewrite is to rewrite Schematic, which uses Qt3Scrollview right now. Since component, diagrams, painting are highly related to Schematic, so I have to remove them from build system if I want to remove current Schematic version. The goal is quite defined: *Rewrite Qucs in a good code structure, and achieve same function like current version.* I think maybe the word 'rewrite' is too provocative. You can view it as a refactor on Schematic (I will still use rewrite below). Due to the strongly coupling between Schematic and other elements, the refactor will inevitably change a lot of code. Actually even Guiherme's port to Qt4 is complete, it's also largely diverged with current version. As I suggest, the rewrite target is to write a new schematic, and gradually re-apply the old elements - components, diagrams, paintings to it. I'm not intend to rewrite whole GUI interface, which is a bad idea I agreed. In the end of rewrite, we should get a Qucs that achieves same function as current version, and we can merge it back to master. Here is the steps we need to take: * Add schematic file back with Qt4 QGraphicsview. ** Re-structure the component hierarchy and gradually put them back. We can discuss this in refactor proposal[1], though it seems hanging there. ** Re-apply the diagrams and painting. * Add file management * Add component management * Rewrite QucsSetting. ... There are a lot of things we need to do, I just mention what I can think of now. I know that rewrite is a large goal, but this is also a step we need to take to make Qucs's source code easier to trace, maintain, and extend. Regards yodalee 20150415 |
From: 李祐棠 <lc...@gm...> - 2015-04-16 10:13:19
|
Hello developers: Let me explain my consideration about rewrite. The top priority mission of qucs is remove the Qt3 component, and migrate to Qt4. After everyone's contribution, the remaining files depend on Qt3 are the following (I omit the file extensions): * Schematic, Schematic_element, Schematic_file * mouseaction -> since it interact with Schematic's elements, which store in Qt3 data structure. * qucs, qucs_init, qucs_action -> since it directly control Schematic's Qt3 object Obviously the Schematic is the root of all Qt3 dependency, which itself is an inheritance of Qt3 object. The schematic is strongly bind to mouseaction, qucs, diagram, component, and some dialogs, especially Mouseaction, qucs. These files, schematic, qucs and mouseactaion, are thousands line of source code, mutual depends to each other. It become very difficult to maintain and extend the function of Schematic. To make the program more easily to maintain and extend, we need to break down the strong binding in Schematic to other parts, and make it more structural. Unfortunately, it lead to "rewrite qucs", since qucs is already connect to Schematic deeply. The difficulty to rewrite a new Schematic while maintain the program work become so high. This is what I do in the branch "rewrite-qucs". In the branch, only the main window layout of qucs in preserved. The old schematic is removed along with most of function implementation of qucs that depends on schematic, and yes, so many functions depend on it. Now we have to do is: 1. Implement the new Schematic w/o Qt3 object. 2. Put it back to qucs main program, re-implement those functions related to it. 3. Re-assess all the function in qucs, make it more structural. 4. Put back schematic functions in current version. 5. Test components, diagrams, paintings with new schematic. During the process, we will put back functions while keep it structural. Our mission is get a new Schematic that act identical to current version. The spec of new version is old version. After the branch become good enough, we can merge it back to master, replacing the old version You can consider my "rewrite qucs" as "refactor on schematic", though it affect so widely that makes it more like "rewrite". To someone's question, why not first remove Qt3, but rewrite qucs? Since the current version of Schematic is the remaining part of Qt3. As I mention it strongly interact with each others and makes migration to Qt4 a difficult work. It's inevitable to suspend some function first to migration. You can see the direct migration done by Mr. Guitorri (it's really hard work OAO) in his port branch: https://github.com/Qucs/qucs/compare/master...guitorri:QGraphicView-port-exploration The second commit 70e7b43 <https://github.com/Qucs/qucs/commit/70e7b439bf224a485170469f064fe3141ef5c733> comment out most function in schematic and qucs to make it compile. What is the disadvantage of this kind directly migration? 1. It only migrates: The code doesn't become more structural. You just get a qucs w/o Qt3 while inside is still a soup of codes. In some day the code become too difficult to maintain, we still have to rewrite the code. This is the main consideration. 2. It cannot cooperate: Due to the binding and dependency. The migration cannot be done by everyone's contribution, there will be too many conflicts to resolve. Also, during the migration, the development on qucsator will not stop. These two are independent. If there is great modification on master branch, we can apply them to 'rewrite-qucs' by patches. Also the direct migration branch of Mr. Guitorri will provide many useful patch on the function of QGraphicsView. We can also apply them to 'rewrite-qucs' In conclusion, the direct migration to Qt4 will get a same qucs, but that is not enough. The current complex structure makes it more and more difficult to maintain, like a road that becomes narrow. In the end, the cost of maintain will become too high and too error-prone. Qucs is a great free software and we need to make it better, so it can keep growing up. Above is my consideration toward rewrite qucs, hope everyone can understand. If you got any opinions, questions, or any refactor plans. I'm welcome to discuss. Regards yodalee 20140416 |
From: Guilherme B. T. <gui...@gm...> - 2015-04-19 13:16:00
|
Hi Yodalee, Indeed the only major Qt3 components remaining refer to the changes: 1) Q3PtrlList --> QList 2) Q3ScrollView --> QGraphics framework, and a bunch of other things cascading from there... Obviously these have nothing to do with qucs-core. The issue 1) is not very difficult, but very boring and error prone. It has to be done in small increments to be able to test it thoroughly, ease bisection and avoid wasting someone else's time (such as issue 216, sorry Claudio!). There is an added problem, the remaining Qt3 data structures are mixed with code in the issue 2). Thing need to be tested manually... The issue 2) is more challenging. It is a different API. Of course there will be lots of changes. The point is to keep the same functionality, it is the only way to test the changes. This is called refactoring: keep the same behavior, no matter how much code you change. The whole point is to have one version as reference and try to reproduce the same behavior on the next iteration (or iterations). I find your approach of taking everything down to add them piece by piece problematic, these are a few reasons: * Losing history. You are creating new files with no history attached to them, that is bad. Removing the previous authors copyright is also bad. * Losing context. If the code had good documentation it would be another story, but there is not enough info to recreate the content. You can add the pieces back, but you will never be able to see how things are supposed to interact on a smaller mockup. Refactoring tools (IDEs such as QtCreator, or Ctags) cannot be used to traverse or grep the original code. * It will take too long to become functional. Quite a lot of time and effort is needed before you can test it with existing schematics. * What is the final structure that you are going after? The work on my branch 'QGraphicView-port-exploration', is my personal exploration. I am (was) trying to go deep and see what is really needed to make the port work. Clearly I had to comment out chunks of code because they make no sense on the new API (it doesn't help if you take just one commit out of context). I added back a few things while trying to find a pattern. I kept the old code around to be able to port them forward. In my opinion porting out of Qt3 is the first and most urgent thing to do. Small structural changes are inevitable, but we should really be focusing on the port, nothing else. The next Qt4 release is said to be the last of this series. We have to prepare for Qt5 regardless of the current code structure. I would support a large scale refactoring if there was a clear goal, an API for instance. Rewrite Large scale rewrite and redesign from scratch is a recipe for disaster. Read some more references if that is not yet clear [1,2,3]. There are also books on the subject. I am not a programer by training, but from the random stuff that I did and read, you should never trash the original implementation. I don't have a reference for this, but in my mind a major refactoring would involve the following steps (more or less in order): - stabilize the codebase (freeze if necessary) - agree upon and implement a C++ code style - document things thoroughly - remove duplicated code - split methods doing multiple things - define boundaries, modules, interfaces - define namespaces - collect related things into proper namespaces - refactor methods locally for readability/performance - (unit) test in between each of the previous steps These things need to be agreed upon among all developers. We can't rush these things. In the end of the day, users do not care how the code looks like, only if the code works as expected. So far we have managed to fix bugs and add new features. I afraid that right now we don't have the manpower to undergo a 'cleanup' just for the sake of doing it... One last thing. Why are you using the issue tracker for your rewrite-qucs branch? Please don't do that. You have been advised by 3 people against the rewrite. Use your fork to track your own development. Regards, Guilherme [1] http://www.joelonsoftware.com/articles/fog0000000069.html [2] http://stackoverflow.com/questions/9647147/process-or-steps-to-refactor-god-class-in-a-c-legacy-application [3] http://programmers.stackexchange.com/questions/211755/to-rewrite-or-slowly-refactor-old-c-project On 4/16/15 12:13 PM, 李祐棠 wrote: > Hello developers: > > Let me explain my consideration about rewrite. > > The top priority mission of qucs is remove the Qt3 component, and migrate > to Qt4. After everyone's contribution, the remaining files depend on Qt3 > are the following (I omit the file extensions): > * Schematic, Schematic_element, Schematic_file > * mouseaction -> since it interact with Schematic's elements, which store > in Qt3 data structure. > * qucs, qucs_init, qucs_action -> since it directly control Schematic's Qt3 > object > > Obviously the Schematic is the root of all Qt3 dependency, which itself is > an inheritance of Qt3 object. The schematic is strongly bind to > mouseaction, qucs, diagram, component, and some dialogs, especially > Mouseaction, qucs. These files, schematic, qucs and mouseactaion, are > thousands line of source code, mutual depends to each other. It become very > difficult to maintain and extend the function of Schematic. > > To make the program more easily to maintain and extend, we need to break > down the strong binding in Schematic to other parts, and make it more > structural. Unfortunately, it lead to "rewrite qucs", since qucs is already > connect to Schematic deeply. The difficulty to rewrite a new Schematic > while maintain the program work become so high. > > This is what I do in the branch "rewrite-qucs". > In the branch, only the main window layout of qucs in preserved. The old > schematic is removed along with most of function implementation of qucs > that depends on schematic, and yes, so many functions depend on it. > Now we have to do is: > 1. Implement the new Schematic w/o Qt3 object. > 2. Put it back to qucs main program, re-implement those functions related > to it. > 3. Re-assess all the function in qucs, make it more structural. > 4. Put back schematic functions in current version. > 5. Test components, diagrams, paintings with new schematic. > During the process, we will put back functions while keep it structural. > Our mission is get a new Schematic that act identical to current version. > The spec of new version is old version. After the branch become good > enough, we can merge it back to master, replacing the old version > You can consider my "rewrite qucs" as "refactor on schematic", though it > affect so widely that makes it more like "rewrite". > > To someone's question, why not first remove Qt3, but rewrite qucs? > Since the current version of Schematic is the remaining part of Qt3. As I > mention it strongly interact with each others and makes migration to Qt4 a > difficult work. It's inevitable to suspend some function first to > migration. You can see the direct migration done by Mr. Guitorri (it's > really hard work OAO) in his port branch: > https://github.com/Qucs/qucs/compare/master...guitorri:QGraphicView-port-exploration > The second commit 70e7b43 > <https://github.com/Qucs/qucs/commit/70e7b439bf224a485170469f064fe3141ef5c733> > comment > out most function in schematic and qucs to make it compile. > What is the disadvantage of this kind directly migration? > 1. It only migrates: The code doesn't become more structural. You just get > a qucs w/o Qt3 while inside is still a soup of codes. In some day the code > become too difficult to maintain, we still have to rewrite the code. This > is the main consideration. > 2. It cannot cooperate: Due to the binding and dependency. The migration > cannot be done by everyone's contribution, there will be too many conflicts > to resolve. > > Also, during the migration, the development on qucsator will not stop. > These two are independent. If there is great modification on master branch, > we can apply them to 'rewrite-qucs' by patches. Also the direct migration > branch of Mr. Guitorri will provide many useful patch on the function of > QGraphicsView. We can also apply them to 'rewrite-qucs' > > In conclusion, the direct migration to Qt4 will get a same qucs, but that > is not enough. The current complex structure makes it more and more > difficult to maintain, like a road that becomes narrow. In the end, the > cost of maintain will become too high and too error-prone. > Qucs is a great free software and we need to make it better, so it can keep > growing up. > > Above is my consideration toward rewrite qucs, hope everyone can understand. > If you got any opinions, questions, or any refactor plans. I'm welcome to > discuss. > > Regards > yodalee > 20140416 > |
From: Vadim K. <ra...@gm...> - 2015-04-19 14:36:51
|
Hello YodaLee, I am agreed with Guilherme that we should prefer porting to Qt4. You stop your work with rewriting from the scratch. If you really want to help, contact with Guilherme and ask what help he needed in porting to Qt4. I have one question. What do you want to extend in Schematic? Current Schematic and components classes are sufficiently easy to be extended. Taking into account your last outstanding bugs in https://github.com/Qucs/qucs/issues/228 , honestly I don't believe that you can propose a better solution that existing Schematic. Also you said that you are rarely use Qucs. It is also not in your favor in such task. Summarizing all above, we should follow Guilherme's way in remaining porting of Qucs to Qt4. Please take into account my and Guilhelme's arguments. --- Regards, Vadim Kuznetsov On 16.04.2015 13:13, 李祐棠 wrote: > Hello developers: > > Let me explain my consideration about rewrite. > > The top priority mission of qucs is remove the Qt3 component, and migrate > to Qt4. After everyone's contribution, the remaining files depend on Qt3 > are the following (I omit the file extensions): > * Schematic, Schematic_element, Schematic_file > * mouseaction -> since it interact with Schematic's elements, which store > in Qt3 data structure. > * qucs, qucs_init, qucs_action -> since it directly control Schematic's Qt3 > object > > Obviously the Schematic is the root of all Qt3 dependency, which itself is > an inheritance of Qt3 object. The schematic is strongly bind to > mouseaction, qucs, diagram, component, and some dialogs, especially > Mouseaction, qucs. These files, schematic, qucs and mouseactaion, are > thousands line of source code, mutual depends to each other. It become very > difficult to maintain and extend the function of Schematic. > > To make the program more easily to maintain and extend, we need to break > down the strong binding in Schematic to other parts, and make it more > structural. Unfortunately, it lead to "rewrite qucs", since qucs is already > connect to Schematic deeply. The difficulty to rewrite a new Schematic > while maintain the program work become so high. > > This is what I do in the branch "rewrite-qucs". > In the branch, only the main window layout of qucs in preserved. The old > schematic is removed along with most of function implementation of qucs > that depends on schematic, and yes, so many functions depend on it. > Now we have to do is: > 1. Implement the new Schematic w/o Qt3 object. > 2. Put it back to qucs main program, re-implement those functions related > to it. > 3. Re-assess all the function in qucs, make it more structural. > 4. Put back schematic functions in current version. > 5. Test components, diagrams, paintings with new schematic. > During the process, we will put back functions while keep it structural. > Our mission is get a new Schematic that act identical to current version. > The spec of new version is old version. After the branch become good > enough, we can merge it back to master, replacing the old version > You can consider my "rewrite qucs" as "refactor on schematic", though it > affect so widely that makes it more like "rewrite". > > To someone's question, why not first remove Qt3, but rewrite qucs? > Since the current version of Schematic is the remaining part of Qt3. As I > mention it strongly interact with each others and makes migration to Qt4 a > difficult work. It's inevitable to suspend some function first to > migration. You can see the direct migration done by Mr. Guitorri (it's > really hard work OAO) in his port branch: > https://github.com/Qucs/qucs/compare/master...guitorri:QGraphicView-port-exploration > The second commit 70e7b43 > <https://github.com/Qucs/qucs/commit/70e7b439bf224a485170469f064fe3141ef5c733> > comment > out most function in schematic and qucs to make it compile. > What is the disadvantage of this kind directly migration? > 1. It only migrates: The code doesn't become more structural. You just get > a qucs w/o Qt3 while inside is still a soup of codes. In some day the code > become too difficult to maintain, we still have to rewrite the code. This > is the main consideration. > 2. It cannot cooperate: Due to the binding and dependency. The migration > cannot be done by everyone's contribution, there will be too many conflicts > to resolve. > > Also, during the migration, the development on qucsator will not stop. > These two are independent. If there is great modification on master branch, > we can apply them to 'rewrite-qucs' by patches. Also the direct migration > branch of Mr. Guitorri will provide many useful patch on the function of > QGraphicsView. We can also apply them to 'rewrite-qucs' > > In conclusion, the direct migration to Qt4 will get a same qucs, but that > is not enough. The current complex structure makes it more and more > difficult to maintain, like a road that becomes narrow. In the end, the > cost of maintain will become too high and too error-prone. > Qucs is a great free software and we need to make it better, so it can keep > growing up. > > Above is my consideration toward rewrite qucs, hope everyone can understand. > If you got any opinions, questions, or any refactor plans. I'm welcome to > discuss. > > Regards > yodalee > 20140416 > ------------------------------------------------------------------------------ > 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: 李祐棠 <lc...@gm...> - 2015-04-19 15:27:29
|
Hello Guiherme: In the letter below, I will use `rewrite` to call my rewrite proposal, though I can say it as a `refactor on Schematic`. The first question: why do you need to remove Qt3? In your word: user doesn't care about how we implement it, then why porting Qt4, or even Qt5? The current version is the best right? Even Trolltech stop supporting Qt4, we can still get the last Qt3 version online, and why bother? We just need new features. But you still want to port Qt4, why? User don't care. But my answer is no, we need to make the program better for extending, modification and better structural. We need use new Qt so we can use new function and API, also get the bugfixes from Trolltech. I believe you want to achieve same goal, our difference is only the mean, I propose refactor the schematic file totally, you propose replace Qt3 with Qt4 object directly. I already explain why I consider rewrite is better, and here is my answer to your doubt. As I said, the goal is simple and clear: Get a new Schematic that achieve same function as the old one (master, v18 release, etc). Isn't that clear? In the beginning, of course, there will be nothing to test the function, but we will make it grow up, and pass tests gradually. That is every program came from. It's "small increment" right? To issue 1) Yes, it's error-prone, then we have to ask: WHY? The answer, as you said, the old codes mix too many things. Changing to Qt4 doesn't solve this problem. Your porting will even deteriorate it. Since the different API may not work perfectly with old one, and you just trying to put them in the same box. In this kind large-scale refactoring, keep all tests passed while refactor is nearly impossible. This is why your issue 2) apply to my rewrite also your testing porting. Even your porting cannot pass all tests in most commits. The important is get same functionality in the end. What I did is not different to yours, only I change the file name and restart from blank. I do so since it -make developers not fluent at Git can see the old things easily. We can refer to old code in Schematic and do same thing in structural way in SchematicView and other files. I also cannot understand your reasons against rewrite. * Losing history. Then how about the other new files? How about those new components added? How about the vtab object we remove? Remove in this commit: https://github.com/Qucs/qucs/commit/ddb02ade0de8ff2de9f4ca2a9e7705e218a3ab1d Code will grow up, add new features, remove old code. This is normal process. If the author message is important, we can add them to new schematic file too. Is this really an issue? Not to mention we use VCS, their contribution will never lost. * I cannot understand what "Losing context" is talking about. The rewrite process is trackable, we can see how small pieces build up, and before we finish the new one the old one will still be there. * Take too long? You can ask yourself about your porting? How long have it been take? How long will it complete? Take long is not a bad thing. The bad thing is we spend a lot of time and get a similar thing. That is wasting time. That's why I cannot support your porting plan. I use issue tracker to record my proposal on rewrite so everyone can see it. Also, that's why we use github and sourceforge: to collaborate. Why don't you push your porting work to main github like branch `Replace Qt3Scrollview`, so everyone can review and help you? This is the reason we use VCS, github, and sourceforge. You always say manpower is not enough, but the truth is you never let them try to help you. You can open issue like "porting component to QGraphicItem" and everyone can pick up items they want to port, you just need to review their contribution. But you don't. Even your github fork is readonly, and others cannot open issue to warn your porting. Collaboration is very powerful, depend on how do you use it. I push my rewrite branch and open issue to it, because I believe the collaboration. There are many contributors out there, you just open issues, someone will take care of them. Maybe I should wait everyone agree on removing Qt3 object. That is my fault. I just remove those issues and the rewrite branch on Github. Before everyone agree to port Qt4, I will just stop developing qucs. Regards, Yodalee 20150419 |
From: Guilherme B. T. <gui...@gm...> - 2015-04-19 19:09:39
|
On 4/19/15 5:27 PM, 李祐棠 wrote: > Hello Guiherme: > > In the letter below, I will use `rewrite` to call my rewrite proposal, > though I can say it as a `refactor on Schematic`. > > The first question: why do you need to remove Qt3? > In your word: user doesn't care about how we implement it, then why porting > Qt4, or even Qt5? The current version is the best right? Even Trolltech > stop supporting Qt4, we can still get the last Qt3 version online, and why > bother? We just need new features. Please don't put words in my mouth. When I joined the project, it was nearly impossible to get Qt3. The last Qt3 had to be patched left and right because it was already dropped from major distributions. Take a look on the log to see the pain Frans went thru to make the code functional with Qt3Support+Qt4. If I only cared about new features I would not have wasted years removing deprecated code... Don't be silly. > But you still want to port Qt4, why? User don't care. I want to port because *I* care. The current schematic is terribly slow because of the legacy code. > But my answer is no, we need to make the program better for extending, > modification and better structural. > We need use new Qt so we can use new function and API, also get the > bugfixes from Trolltech. > I believe you want to achieve same goal, our difference is only the mean, I > propose refactor the schematic file totally, you propose replace Qt3 with > Qt4 object directly. I already explain why I consider rewrite is better, > and here is my answer to your doubt. So you want to move straight to Qt5? Want to rewrite things in QML also? Doable, but lots of users won't get Qucs because their platform is no longer supported in Qt5. I would rather make a release that depends only on Qt4 to give people a chance to back-port patches and then move on to Qt5 completely. I care about Qucs as a user and as a developer, but I care more about the users that are *not* developers... You nailed it, I am against a complete refactor of the schematic under your terms. It is reported everywhere that you should not take everything down and rebuild from the pieces. It seems to me a clear lesson learned by many people experienced in refactoring legacy code. > > As I said, the goal is simple and clear: Get a new Schematic that achieve > same function as the old one (master, v18 release, etc). > Isn't that clear? > In the beginning, of course, there will be nothing to test the function, > but we will make it grow up, and pass tests gradually. That is every > program came from. It's "small increment" right? Yes, then they become a large system no single person can understand it completely. The point is that you want to start from scratch, that is wrong! > To issue 1) Yes, it's error-prone, then we have to ask: WHY? > The answer, as you said, the old codes mix too many things. Changing to Qt4 > doesn't solve this problem. Your porting will even deteriorate it. Since > the different API may not work perfectly with old one, and you just trying > to put them in the same box. Don't tell me it "may not work". I know it works. The QGraphics API is compatible with the Q3PtrList. The issues are related to how things were handled. For instance on a mouse drag/move of several items, the list of selected components is iterated on mouse release to update the position of these components. This is deprecated with the new API, Components become QGraphicsItems and they can update themselves. Many things will be simplified. Most of the work is required on the mouse interactions, zoom and fine tuning the look and feel. This can all be done with minimal changes in structure. Structure can be refactored later. > In this kind large-scale refactoring, keep all tests passed while refactor > is nearly impossible. You are right, there are no tests! Everything needs to be tested manually... > This is why your issue 2) apply to my rewrite also > your testing porting. Even your porting cannot pass all tests in most > commits. The important is get same functionality in the end. As I said, I was exploring the options, did not propose it as the final solution. I was learning from it. > What I did is > not different to yours, only I change the file name and restart from blank. > I do so since it -make developers not fluent at Git can see the old things > easily. We can refer to old code in Schematic and do same thing in > structural way in SchematicView and other files. I actually agree that we can split the view and the scene, but I don't find it sane to remove everything else as you did. > I also cannot understand your reasons against rewrite. > * Losing history. Then how about the other new files? How about those new > components added? How about the vtab object we remove? > Remove in this commit: > https://github.com/Qucs/qucs/commit/ddb02ade0de8ff2de9f4ca2a9e7705e218a3ab1d > Code will grow up, add new features, remove old code. This is normal > process. If the author message is important, we can add them to new > schematic file too. Is this really an issue? Not to mention we use VCS, > their contribution will never lost. Because you deleted the whole content, and added yourself as the sole author I thought it was a new file. Not a continuation from the old code. The vtab was dead code... > * I cannot understand what "Losing context" is talking about. The rewrite > process is trackable, we can see how small pieces build up, and before we > finish the new one the old one will still be there. If you take everything down to the minimum, you cannot see or test the current ramifications of the code. You will find yourself fixing things over and over as you add them back. In QtCreator you can easily traverse the caller and callees, check all the locations where the objects are used. The global view is useful in refactoring. > * Take too long? You can ask yourself about your porting? How long have it > been take? How long will it complete? > Take long is not a bad thing. The bad thing is we spend a lot of time and > get a similar thing. That is wasting time. I started the port because I wanted to understand the situation before proposing a course of action. Wasting time is something I can no longer afford... > That's why I cannot support your porting plan. My initial proposal is to do the port of the QGraphics first, then Q3PtrList and restructure later (in multiple passes). You want to remove everything to do the port and restructuring at the same time. In my book it is just crazy. It is not my opinion, your proposal goes against everything I ever read about refactoring legacy code. > > I use issue tracker to record my proposal on rewrite so everyone can see > it. Also, that's why we use github and sourceforge: to collaborate. There is no collaboration without agreement. How many more issues you would create to record your proposal? A wiki page is a better place for that, write everything down and we can discuss about it. > Why don't you push your porting work to main github like branch `Replace > Qt3Scrollview`, so everyone can review and help you? This is the reason we > use VCS, github, and sourceforge. Because I am not satisfied with it and I don't want it to be followed as is. As I said, if you are interested I can try to clean it up. I won't be able to work on it right now. > You always say manpower is not enough, but the truth is you never let them > try to help you. You can open issue like "porting component to > QGraphicItem" and everyone can pick up items they want to port, you just > need to review their contribution. But you don't. Even your github fork is > readonly, and others cannot open issue to warn your porting. Collaboration > is very powerful, depend on how do you use it. How can you say that?? Almost every week I receive emails from people offering themselves to join the development. I give them instructions: join the mailing-lists, build from source, find something to fix, ..., etc. Many of them end up successfully building from source. But few come up with patches. Are you complaining because I did not ask for help on my own fork? You can also contact me to check about the status of things... You know that you can send me a pull request to *my* fork. The code is public, but it is *my* fork. Why should it not be readonly?? Tell me about collaboration. For your information I was the one who setup the GitHub organization for Qucs... I also invited you as a collaborator... As I said, I wanted to explore the code in my port, then propose a course of action. I don't have the time right now to do any of the above. I should not even be responding to this thread... > I push my rewrite branch and open issue to it, because I believe the > collaboration. There are many contributors out there, you just open issues, > someone will take care of them. Well, you should first seek the collaboration of your peer developers that were maintaining the very code you want to turn upside down. I will open issues when there are issues, and when I have time for that. The magic of GitHub that 'someone will take care' of the issues also cost us time, we have to check it before merging. As I did with your first patches... > Maybe I should wait everyone agree on removing Qt3 object. That is my > fault. I just remove those issues and the rewrite branch on Github. Before > everyone agree to port Qt4, I will just stop developing qucs. Look, this is not personal. I just think that your current approach is wrong. > Regards, > Yodalee > 20150419 > Regards, Guilherme |
From: 李祐棠 <lc...@gm...> - 2015-04-20 06:37:22
|
Hello Guilherme: Ahhh, As I already explain, it's rewrite, or refactor, any word you like, Schematic in Qt4. I'm not intend to jump to Qt5 directly. That doesn't make sense. My proposal is clear and simple. Write Schematic in Qt4, using QGraphics new API. In the same time, make Qucs main program more structural. It's true that first commit remove many things, that is because Schematic affects so vast, much vast than it should be. But forget it. No matter what it is. It's suspend forever. So I think the quarrel is over too. Regards Yodalee 20150420 |
From: Guilherme B. T. <gui...@gm...> - 2015-04-20 11:51:50
|
Hi, It is not about the word I like. Rewrite and refactor are different things. Please read this [1], including the comments. Your last proposal of a (partial) rewrite of QGraphics is fine, but what bothers me is that you started by taking everything down. This looks like a global rewrite and I must advise against. To be continued another day... Regards, Guilherme [1] http://www.targetprocess.com/blog/2009/11/refactoring-vs-rewrite.html On Mon, Apr 20, 2015 at 8:37 AM, 李祐棠 <lc...@gm...> wrote: > Hello Guilherme: > > Ahhh, As I already explain, it's rewrite, or refactor, any word you like, > Schematic in Qt4. I'm not intend to jump to Qt5 directly. That doesn't make > sense. > My proposal is clear and simple. Write Schematic in Qt4, using QGraphics > new API. In the same time, make Qucs main program more structural. > It's true that first commit remove many things, that is because Schematic > affects so vast, much vast than it should be. > > But forget it. > No matter what it is. It's suspend forever. So I think the quarrel is over > too. > > Regards > Yodalee > 20150420 > > ------------------------------------------------------------------------------ > 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: Richard C. <r.c...@ed...> - 2015-04-15 07:29:18
|
On 15/04/15 08:22, 李祐棠 wrote: > Hello developers: > > Actually if you looks at the branch, it just remove the Schematic from > qucs. The main target of the rewrite is to rewrite Schematic, which uses > Qt3Scrollview right now. Since component, diagrams, painting are highly > related to Schematic, so I have to remove them from build system if I want > to remove current Schematic version. > ok, it's still a big effort, but sounds more reasonable! Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |