Refactor+qt5 WIP

[felix-salfelder]

• [x] tests
  • [x] library/unit tests
  • [x] netlist
  • [ ] simulate
• [x] move to QGraphicsScene
  • [x] draw symbols (#592)
  • [x] scroll
  • [x] snaptogrid
  • [ ] zoom
  • [x] component text
  • [x] draw properly
  • [ ] position
  • [ ] edit
  • [ ] print pdf
• [ ] diagrams (cf #774)
  • [x] load/save callbacks
  • [x] support QWidget based diagrams
  • [ ] access to data
  • [ ] markers
• [ ] (undoable) mouse actions
  • [x] move, delete, insert
  • [x] mirror & rotate
  • [x] insert element
  • [x] wiring
  • [x] release-select
  • [x] insert new wires
  • [x] "optimize" wires
  • [x] maintain connectivity
  • [ ] labels
• [x] nets and wires
• [ ] CMake (#1007)
  • [x] MakeLists
  • [x] build library
  • [x] build executables
  • [ ] build plugins
• [x] split repo
  • [x] qucsator (#1015 ..)
  • [x] qucs gui

[XVilka]

Is this PR abandoned?

[felix-salfelder]

On Mon, May 27, 2019 at 09:28:38AM -0700, Anton Kochkov wrote:

Is this PR abandoned?

no.

[XVilka]

Then it requires to rebase. Qt4 was removed from many distributions, thus qucs packages as well:

https://repology.org/project/qucs/versions

Hopefully, back to distributions again after this one.

[felix-salfelder]

On Sun, Feb 16, 2020 at 06:45:13PM -0800, Anton Kochkov wrote:

Then it requires to rebase. Qt4 was removed from many distributions, thus qucs packages as well:

https://repology.org/project/qucs/versions

Hopefully, back to distributions again after this one.

That's the plan. but a rebase is the least difficult i'm afraid.

Some of the commits are only transition/preparation/refactor and cleanup. the rest breaks with qt4. with both parts squashed into one commit each, it might get easier.

It remains to decide how useful Qt4 is. It could all go into the first part, but that will be more work.

[felix-salfelder]

Then it requires to rebase.

Done for now. I will rebase as often as needed. (This is actually about the refactor+qt5-$revision branches in the main repo, currently revision==12).

It remains to decide how useful Qt4 is

I am not trying to make it work with multiple Qts here (would have to be done in develop, if at all, and it requires more work).

[frhun]

Does this compile on your machine? If so, what are the steps you go through to compile from a fresh git clone?

[felix-salfelder]

On Sun, Aug 23, 2020 at 01:28:43PM +0000, frhun wrote:

Does this compile on your machine? If so, what are the steps you go through to compile from a fresh git clone?

Thanks for trying, apparently CI is not set up properly. I built from a fresh clone on Debian.

$ git checkout 8fa2504c2bb2eb # please fetch, a file was missing $ cd qucs $ ./bootstrap $ mkdir bd $ cd bd $ ../configure --enable-debug --with-qt-name=Qt5 $ make $ main/qucs -i ../examples/bandpass.sch

(please don't expect anything near usable yet)

[frhun]

i only get ../../qucs/element_graphics.h:112:25: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:113:41: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:121:18: error: cannot convert 'ItemEvent*' to 'QEvent*' ../../qucs/element_graphics.cpp:125:11: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:129:11: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:173:4: error: type 'QEvent' is not a direct base of 'ItemEvent' with Qt 5.15

[felix-salfelder]

On Mon, Aug 24, 2020 at 06:31:26AM -0700, frhun wrote:

i only get ../../qucs/element_graphics.h:112:25: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:113:41: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:121:18: error: cannot convert 'ItemEvent*' to 'QEvent*' ../../qucs/element_graphics.cpp:125:11: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:129:11: error: invalid use of incomplete type 'class QEvent' ../../qucs/element_graphics.cpp:173:4: error: type 'QEvent' is not a direct base of 'ItemEvent' with Qt 5.15

I could reproduce this after an upgrade to Qt 5.14.2+dfsg-5. This is fixed now.

Thanks!

[frhun]

also #include <QPainterPath> is missing from viewpainter.cpp

[frhun]

For hidpi support, when wanted

#include <QCoreApplication>
 ...
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);

should probably be applied in the main functions of the individual executables. This is obviously quite a task for the main application, but for the little tools it shouldn't be a problem. According to the qt documentation it might also not be that big of a problem "Typically, most applications work with device independent pixels; except for OpenGL and code for raster graphics.".

[felix-salfelder]

On Mon, Aug 24, 2020 at 07:17:25AM -0700, frhun wrote:

also #include <QPainterPath> is missing from viewpainter.cpp

thanks.

[felix-salfelder]

On Mon, Aug 24, 2020 at 07:43:08AM -0700, frhun wrote:

For hidpi support, when wanted

#include <QCoreApplication>
 ...
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);

should probably be applied in the main functions of the individual executables.

thanks!

from main.cpp you can run arbitrary code through optional plugins. currently this is implemented as a command line option, later version will use an .rc file (or so).

it seems to work, see ad961fc4fca.

[frhun]

Nice, that is good for testing, as it sometimes messes with rendering. Once validated that it works properly i think it should be the other way around though, with hidpi support being enabled by default, and only inhibited when the user specifically asks for it.

Edit: And it has no effect on the helper tools, which also need it enabled individually in the main

[felix-salfelder]

On Tue, Aug 25, 2020 at 11:57:29AM -0700, frhun wrote:

Nice, that is good for testing, as it sometimes messes with rendering. Once validated that it works properly i think it should be the other way around though, with hidpi support being enabled by default, and only inhibited when the user specifically asks for it.

It seems that an environment variable also controls hidpi. is it necessary to make any choices?

Some layout issues have been discussed in #562. But the hidpi option also breaks the undo stack, and it's not clear to me why.

I will certainly try to make this work. please send patches or just hints.

[frhun]

Setting hidpi support to enabled is what applications that are aware that they do work on hidpi should do. Not setting it is just the default state for legacy code that isn't really sure about it. All the scaling issues you see time and time again (for example in #562) come from the UI Framework using the system font size, but not adjusting everything around it, or only changing some things. All that behavior is only there for legacy support. The scaling setting in windows for example is explicitly only a legacy support option that makes everything blurry. Enabling hidpi support is just a way for the application to tell the system that it doesn't need all those terrible little hacks. It in no way interferes with the non hidpi experience. When you are touching the rendering code anyways, it would be a waste of effort not to consider hidpi while doing so.

As for the undo stack being broken, if the undo data involves coordinates they could be scaled if they are tied to rendering. I noticed that when opening the example project, the view port is only half way across to where it should be horizontally (on 2x scale). So even though there shouldn't be, there seems to be some code that accidentally works with device independent pixels, and passes them somewhere where they are interpreted as actual device pixels.

[frhun]

In general, to avoid these problems, it is probably best to handle data in structures/objects that are passed to ui code as write only. Then, if there are any situations where something doesn't scale right, just apply the scaling factor you get from qt manually, and because you don't use the scaled data again you avoid scaling the same data multiple times or having mismatches.

[frhun]

For hidpi testing i can recommend testing with: QT_SCREEN_SCALE_FACTORS="1;1.5;2" main/qucs -i ../examples/bandpass.sch -a hidpi that is the scaling factor set to 1 on display one, to 1.5 on display two and 3 on display three. (obviously assuming you have 3 displays. If the code works that way, it is rock solid. (i know that is a lot, but considering that this code does not need to work with GL or pixmaps, QT should handle all the scaling logic as long as you are careful. (i.e. only using QReal to pass coordinates, according to the docs)

[felix-salfelder]

On Mon, Aug 31, 2020 at 04:03:53PM -0700, frhun wrote:

As for the undo stack being broken, if the undo data involves coordinates they could be scaled if they are tied to rendering.

Thanks.

I get the implications on coordinates. Not sure how this relates to undo/redo. the undo/redo buttons are simply greyed out when running in hidpi mode, on my machine.

I noticed that when opening the example project, the view port is only half way across to where it should be horizontally (on 2x scale). So even though there shouldn't be, there seems to be some code that accidentally works with device independent pixels, and passes them somewhere where they are interpreted as actual device pixels.

Some of the code is simply missing. I will have a look, could be anything really.

[frhun]

the undo/redo buttons are simply greyed out when running in hidpi mode, on my machine.

Oh, then ignore what i said.

[felix-salfelder]

On Tue, Sep 01, 2020 at 11:10:34AM -0700, frhun wrote:

Oh, then ignore what i said.

nevermind. this is sort of fixed/postponed. I wonder how hidpi interfered with this at all. Different shades of uninitialised memory.

[Rmano]

@felix-salfelder thanks for all the work on this. I am now on 20.04, no qt4 around, and using my AppImage for day-to-day, so if you need somebody to help check things, I'll try to help with it when I have time.

[felix-salfelder]

On Mon, Oct 12, 2020 at 03:40:14AM -0700, Romano Giannetti wrote:

I am now on 20.04, no qt4 around, and using my AppImage for day-to-day, so if you need somebody to help check things, I'll try to help with it when I have time.

I have seen your image, thanks for this.

If you have time, you could try to build, try to fix CI or try and/or do anything really. I think I got past the main "mouseaction" headache, but all of it needs completion, debugging and testing.

[felix-salfelder]

this is now "modular qucs".