commit 2a8a2d228d
Author: Matthias Koefferlein <matthias@koefferlein.de>
Date: Fri Feb 26 23:54:08 2021 +0100
One more fix.
commit 8c4d76505c
Author: Matthias Koefferlein <matthias@koefferlein.de>
Date: Fri Feb 26 23:03:07 2021 +0100
More patches for uitools-less build for CentOS 8
commit 2ac28292b8
Author: Matthias Koefferlein <matthias@koefferlein.de>
Date: Fri Feb 26 22:52:27 2021 +0100
First steps for fixing build on CentOS 8 without uitools
* #730: providing a new Qt module named QtUiTools for QUiLoader class support.
* Fixed a compile error on Mac
* Added QtUiTools to some more places
* Fixed a linker issue in the QtUiTools Python lib
* On occasion fixed a infinite recursion problem in the debugger
The recursion happened because by mistake I instantiated a
QApplication inside an in-application Python script. This
crashed the debugger due to infinite recursion. This is not
a real use case but to prevent similar issues, a recursion
sentinel was added.
* Removed QCoreApplication#notify from script bindings
Reasoning: "notify" made standalone scripts using QApplication and
QUiLoader virtually impossible.
Problem description:
- When a QApplication object is instantiated, e.g. in Python, the Qt binding
will install reimplementation hooks as the object may be dynamically
extended.
- A notify is virtual this means the *every* "notify" call in the application
is routed through the interpreter.
- For one thing this will slow down the application
- But as "notify" is called a zillion times this has more than this side effect.
- Specifically "notify" is called from within the QWidget constructor to
indicate a new widget. Then, if a QDialog for example is instatiated, it's
base class constructor will call "notify" when the object isn't ready yet.
- This has another severe side effect: as the object isn't ready yet, it gets
registered in the Python space with the wrong class and QDialog is not visible
as such.
To mitigate these problems, the most efficient solution is to disable "notify"
in general. There is hardly any use case in a script environment (in C++,
apart from hacking the only reasonable use case is exception handling, but
this does not apply to scripts). For providing the call functionality of
"notify" you should better use "postEvent" or "sendEvent" anyway.
So farewell QCoreApplication.notify ...
* Fixed python test for QtUiTools module
* Fixed UiTools test on Qt4 - QUiLoader needs an application object
Co-authored-by: Kazunari Sekigawa <kazunari.sekigawa@gmail.com>
In addition, the "destroyed" and "objectNameChanged" signals
were added (specifically to QObject).
The API binding for Qt5 was updated which adds some events.
* Fixed#501 (more Qt ownership management) - this commit contains some more changes because I had to regenerate the Qt binding sources.
* Fixed#501 (Qt object ownership transfer) - repairs, added tests
* Updated Jenkinsfile to not publish a PR build
* Update Jenkinsfile - exclude PR's from build
Reason: a reference to a temporary object was passed
to a function. This happened for a default value.
The solution is to create a heap object to such default values.
- All platforms support native hash values for long long etc.
with the TR1 containers
- Use non-static, function symbols to force linking.
- Debian package is picky about dates so give them some
in Changelog.
- The deferred method scheduler is now automatically created
when required and when there is a QApplication
- QApplication and related have argv constructors
Reason: klayout_QtCore needs to be linked with QtGui so it's
GSI declarations become available. The reason is only
QSignalMapper which is in QtCore and has a QWidget argument.
1.) Startup issue:
This is solved by making sure templates with virtual functions
are made visible in the DSO. This way, dynamic_cast is possible
across DSO's.
Scary: clang/MacOS wants the forward declarations be declared visible as well.
2.) Menu issue:
The best solution is to have only one QMenuBar. The navigator
now gets a synthetic menu bar composed of QToolButtons.
The problem is caused by an implementation detail:
To monitor the lifetime of Qt objects, a monitoring
object is attached to them. This used to happen through
child objects but attaching such issues QChildEvents
which - if routed over script objects - will itself
required objects to be attached a monitoring object.
The solution is to attach monitoring objects through
QObject dynamic properties.
- Qt5 binding was not properly including bindings for special types
- Macro editor: forward button wasn't autoRaise like the others
- DRC engine: gave deprecation warnings for Ruby 2.4 because Fixnum
became deprecated. Now the implementation is more generic.
- Fixed some #includes for Qt5
* The solution consists of attaching a bridge object
to QObjects. If the host object is destroyed, the
bridge object will notify the script client
* The bridge object attachment is optimized so it
only happens if required (but still too often ...)
* The child object of QChildEvent gets a special
handling since this object is almost dead in case
of remove. This special handling consists of
a special, stripped class which is used to
only represent QObject in that particular case.
Matthias Koefferlein
matthias