Re: [Qucs-devel] A qucs rewrite branch on github

[Vadim K. <ra...@gm...>]

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