Re: [Qucs-devel] Software development

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

On Mon, Apr 13, 2020 at 05:10:33PM -0300, Guilherme Brondani Torri wrote:
> I see your point. I am trying to touch as little as possible the legacy
> code for the Element classes. I just want to have them working as-is as
> quickly and easily as possible.

Hi Guilherme.

Thanks for your summary. Changing the baseclass is not "touch as little
as possible" as far as I am concerned. It entangles payload with Qt
internals (what will happen in qt6?) and will fundamentally interfere
with attempts to add/load other Elements further down the line. We must
establish an interface to Elements (or just stick to it!) but should not
change the implementation details in obsolete instances.  Who cares if
people will use the legacy symbols, or those from qucs-s, or gEDA, or
those from a much better and very efficient database later on? I am not
against another more efficient database later on. But the key will be to
support any of those. A first attempt at a database will not fit
everyones needs anyway. The code is not far off, and it might as well
have been written for this purpose.

We have a QEP ([1], Fredo Erxleben, 2014) about code structure, I
recommend the introductory words. The QEP addresses issues with the
Design, such as the following.

"""
Model and representation are completely merged. They should be strictly
seperated from each other. Currently, the model is derived from the
visual layout of the schematic. Classes often represent things in the
model and the view at the same time and the different aspects are merged
together into a incomprehensible design. To counter this, a new class
structure with strictly defined responsibilities needs to be defined.
"""

This resembles what I did in the refactor branch (among other things
listed in that QEP). If that structure was already complete, we could
have a basis for everybody to try new stuff. Such as loading components
from a database, as you suggest. Or just try and switch to Qt5, i.e.
rewrite the user interactions.

> Well, objects derived from QGprahicsItem are needed if we want to benefit
> [from] the QGraphics framework.

Could you please expand on this? The QGraphics framework is working
perfectly well for me, and it does not require collapsing the class
hierarchy, nor does it require much change in the legacy code. The
responsibility of the QGraphics is to do drawing and user interaction.
The Element carries data, with an interface suitable for the
application. And the UI objects are used to manipulate data.

There is no magic in the new framework. The reason for the higher
efficiency of the new scene is the visibility tracking, not having
everything in one class. Every Element carries a bounding box rectangle,
and only those Elements with the bounding box exposed to the screen are
drawn. This is very close to what we have, except that the rectangle is
not used in determining what to visit. In addition to that, we need to
get rid of the (hard to debug) delete/allocate/copy cycles in the UI,
and instead leave the objects where they are. To some extent, Qt5 forces
us to do this (and we should follow), but Qt3 does not keep us from
doing it properly, either.

I wouldn't hesitate to join you with your approach given that a path
towards refactoring or establishing interfaces remains viable, and can
be tested. We need interfaces as much as anything to achieve
interoperability, and we should not sacrifice those interfaces that
already exist or even work.

> With qt5-19 you can just instantiate the SchematicScene and use the
> SchematicFile methods to load stuff items into it. I believe this is
> already working on the CLI. The UI should not be needed.

Why would the CLI instanciate a SchematicScene at all? The
SchematicScene is used for displaying schematics. Please have a look at
the SchematicModel class, which owns and manages the model data. It
keeps track of wire connections and connected components ("nets"). These
are required for netlisting, and similar things. Loading stuff is done
by a separate class, using an interface for adding elements to a Model.
This is all working (with or without a SchematicScene) in refactor+qt5,
whatever schematic language is used. None of these are new "features",
but merely a consequence of moving code fragments around, into the right
place. Conceptually this is much older than the Qt5 work.  But then, i
have polished it some more when moving to Qt5.

How hard will it be to use a SchematicModel class in qt5-19? Will it
make other things easier? We could immediately test it, even before the
qt5 port is fully complete.

Similar issues arise in Schematic tab vs SymbolEdit tab. Currently the
latter is hacked in diagonally, not something anybody could possibly
work with. In my branch, those are two separate classes, i.e. the three
"tabs" text editor, the schematic view and the symbol editor have become
independent of each other. This is a matter of moving the code into the
right place, in order confuse less.

> The lst2 is declared somewhere in the mingw-Windows headers. It was
> creating a name collision and borking the compiler.
> The easier to me was to rename this temp string instead of messing with the
> preprocessor. My bad if it was not clearly stated in the commit message.

If this is the case, would you object against having it in develop?
Together with all the other changes of this kind. It has been done many
times, by multiple contributors, and it is going nowhere.  Rebase is
cheap in comparison.  I have looked at the diff against develop, not at
the commit messages, my bad really. I was looking for changes that
relate to Qt5. With the commits linearised, and those tangential commits
coming early, I (anybody, really) could help with review, testing and
merge.

People keep offering help, and we should start pointing them to
subproblems. I have got plenty of them. There is a lot of work to do
that does not immediatly depend on Qt5, but is required for going
further, whichever direction. I know that my branch does some cleanup
that is orthogonal or unessential, I wouldn't really mind postponing
these bits.

Let's find a way out of this..

cheers
felix

[1] https://github.com/Qucs/qucs/wiki/QEP%3A-Enhancement-of-code-structure-and-software-design