Re: [Qucs-devel] Software development

[Guilherme B. T. <gui...@gm...>]

Hello Felix,

On Sat, Apr 11, 2020 at 5:08 AM Felix Salfelder <fe...@sa...> wrote:

> 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.
>

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.
Well, objects derived from QGprahicsItem are needed if we want to benefit
front the QGraphics framework.
Q3Ptr is remaining in very few spots. I prefer to port it forward to QList
instead of having to rewrite, retest and maintain deprecated Q3 code.
The issue with QtUI being required while in command mode should be fixed
now.
The problem was that the View tab and the old Canvas required the QucsApp
as parent. Therefore loading schematics and doing the netlist was only
possible if App was launched.
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.
Note, I chose to separate the code where it looked natural to me. Certainly
it can be further refined.



> 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.)
>

Legacy code was crippling performance. It would keep one list for each item
time and paint them one-by-one in custom loop.
If you had more then a few hundred items the UI would already suffer do
redraw.
This is particularly bad for the Diagrams. In the legacy code, points on
the graphs would be drawn one by one.
The loop issue should be fixed with qt5, however the graphs need to be
ported to polygons which are much faster to draw.

With the QGraphics it is more convenient to just add items (an manipulate
then) directly on the Scene. The Scene is the model.
When different objects are needed, retrieve items from the Scene filtered
by type. I added a template function for that.
Performance bottlenecks will arise with millions of items, which is anyway
impossible to work with on the legacy code.
I don't see it as a regression. If really needed, extra bookkeeping can be
introduced, but at the moment, things seem to still work.
Load, save and netlist are partially working with the above method.
Partially because some bits are commented out because refactor is pending.


> There are many seemingly random or stylistic changes in qt5-19, such as
>
> -    QStringList lst2;
> -    lst2<<tr("Butterworth")
> +    QStringList strlist2;
> +    strlist2<<tr("Butterworth")
>

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.


> 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.
>

Maybe a few things seem random or stylistic. I apologize for that. I am
trying to touch as little as possible component legacy code.
I read you and I am aware that this can cause conflicts down the line.
Are you talking about qucs-s components? These should be relatively easy to
integrate later on.
What others in other repos?

I would rather say that the component modules and library management should
be rewritten to *eliminate* friction.
Most components are plain data, they can be machine converted to a suitable
format and can be loaded on demand. There is no need for them to be
compiled in the first place.
Only the ones that are parametric would need some special handling.
This implies a series of changes to components, file formats, library
manager, user workflow and porting existing projects forward.
IMHO what is needed is to create a library/cell/view libraries which is the
standard in the industry. Create an API to manipulate and access the
libraries.
When this point is reached, text files or even a Python scripts could be
used to create cells and views (symbol, schematic, netlist). Porting legacy
projects should be relatively easy.
Anyway, this is a bit OT for the moment.


> 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.
>

I noticed you tried to keep qt4 going. For that reason I said there should
be conflicts already.
The refactor part should be easy to port forward once the qt5 code settles.


>
> > 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.
>

I don't think that removing the remaining Qt3 in develop is the best
strategy.
The problem is that long sections of code used for mouse actions and
view/scene (move, distribute, copy, paste) are all based on custom code
that are much simplified when using QGraphics.
If you port this sections now, they will be removed later. I think this is
not the best use of our time.
There are just a few remaining Qt3PtrList used in qt5-19, mostly in boring
for-loops I skipped for now.
I'm biased, but I think qt5-19 is closer to completion.

I have a detailed list of tasks, unfortunately I am not at home with my
development PC and I am having issues to mount my ext4 backup drive on the
Windows box I have available.

This is what I remember now:

   - SchematicScene
      - fix distribute horizontal, vertical, ... (easy start to get other
      things going)
      - fix delete selection
      - fix move selection up, down, left, right
      - fix mouse actions to draw wires, connect wires, ...
      - fix place item and split wires, add nodes
   - SchemaicView
      - define ownership of grid, page, view box,...
   - SchematicFile
      - test the file open, save
      - add CLI command to perform round-trip open/save .sch files
      - plug test into qucs-test
   - Undostack
      - implement SchematicScene command counter parts.
   - SymbolView and Scene
   - implement dedicated SymbolView, SymbolScene (possibly rename and
      inherit from current SchematicView/Scene as this as base for all
schematic
      related things)
   - QucsApp
      -   fix print to file and PDF
   - Diagrams
      - only the basic frame is being drawn, bounding box is not correct
      - fix issues with fonts
      - fix issues with plotting the graphs, use PolyLine, Polygon
      - figure out hierarchy and ownership of the composed GraphicItem.




> 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.
>

I also added the basics for the undo stack. Undo and redo should be working
for components inserted.
This goes hand in hand with the refactor of the SchematicScene code.
The same is true for the mouse actions. In fact the mouse actions could be
rewritten by an action manager (some sort of unified state-machine), but
not strictly necessary now.
Mouse actions might be trickier to get right, but in Qt5 many things are
simplified by the framework, like checking for overlaps, collision, hover.
Once you draw a wire with 3 nodes all required things should be figured out.

I must say that I did read the code from Caneda. I refrained from copying
and porting the code back over because I want to understand what is going
on and simplify a few things.
There are certainly many good ideas in their code and are can be mapped
well back to the Qucs codebase.

Regards,
Guilherme