Re: [Qucs-devel] Software development

[Felix S. <fe...@sa...>]

On Fri, Apr 10, 2020 at 04:29:27PM -0300, Guilherme Brondani Torri wrote:
> I suggest you take a look at  the "qt-19"  branch I just pushed to the main
> repo.

Hi Guilherme.

I have looked at qt5-19. My main issue remains the switch from Element
to QGraphicsItem. I think what we really should not do is entangle the
library with Qt even more. This is going to backfire just like Q3Ptr is
backfiring right now. We already have a bug that breaks netlist
generation without starting the QtUI. I suggest to use a GraphicsElement
class for the graphics and to only touch as little of the legacy code as
possible.  This is perfectly feasible, and also serves as an
intermediate between data and manipulators.

Merging the various schematic containers into a big one looks like a
regression to me (do I read the code correctly?). There is maybe no
technical reason (except performance) to keep different objects
separate, but there is little code overhead in doing so, and i'd rather
not change it. I have separated out the schematics containers and made
them fit for the Qt5 drawing widgets. (To those not familiar with qt4
vs qt5: Qt now does a lot more, but in a different way. Qt5 drops the
support for the "old" way.)

There are many seemingly random or stylistic changes in qt5-19, such as

-    QStringList lst2;
-    lst2<<tr("Butterworth")
+    QStringList strlist2;
+    strlist2<<tr("Butterworth")

that will conflict with other work. Do we need this? Similarly,
some implementation details are changed in every single component file +
header file. It is better to touch component files as little as
possible, as there are so many (plus many outside of the repo, waiting
for inclusion). All we need in the components is some reorganisation (at
some point), so others can be added later, without friction.

In refactor+qt5, the Qt5 independent refactoring is in the first
commits, and is open to discussion, it does not just remove code
fragments. Historically, I tried to not break qt4 while preparing the
switch to qt5, and there is some friction now. However, this work
includes the revised essential parts from qt5-6, which is now a
precursor of qt5-19.

> It received a recent merge from develop branch.
> I will not do big rebases, too many things diverged and I am got tired of
> resolving conflicts.

It would be really useful to get some of the refactoring into develop. I
suggest to linearise it, and merge those commits that we need, put the
non-essential ones aside or postpone or even discard.

If we want help from others, we should to do it one by one. Ideally we
dont remove all code that does not work with Qt5 as a first step.

Derek suggested to remove the Qt3 support dependency as a start. I had a
PR on this years ago, and Claudio had half(?) reviewed it. It has become
a part of my refactoring, but it's still there. The difficult bit
(Q3PtrList) is fixed with an additional header (who is the author? You
should get the credit), that does not conflict much with anything else.
Q3PtrList usage could be refactored one by one, or slowly moved to
optional code. This is a side track, and the Qt5 port (mostly) does not
depend on it.

A steeper start... reimplement the mouse actions and undo stack.  This
is clearly possible in either branch, but easier after some refactoring,
some of which I have done. We need to isolate, review and merge it.
Merge everything that we manage to agree on.

thanks
felix