luke
/
klayout
mirror of https://github.com/KLayout/klayout.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
klayout/testdata/pymod/import_QtUiTools.py

44 lines
1.4 KiB
Python
Raw Permalink Normal View History

#730: providing a new Qt module named QtUiTools for QUiLoader class s… (#735) * #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>
2021-02-25 21:29:21 +01:00
# KLayout Layout Viewer
Updating copyright to 2025
2025-01-04 19:28:56 +01:00
# Copyright (C) 2006-2025 Matthias Koefferlein
#730: providing a new Qt module named QtUiTools for QUiLoader class s… (#735) * #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>
2021-02-25 21:29:21 +01:00
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Attempt to mitigate the effects of bpo-36085 in Python 3.8+ on Windows - need to add DLL search paths explicitly.
2021-04-18 10:43:34 +02:00
import testprep
#730: providing a new Qt module named QtUiTools for QUiLoader class s… (#735) * #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>
2021-02-25 21:29:21 +01:00
import klayout.QtCore as QtCore
import klayout.QtUiTools as QtUiTools
import unittest
import sys
# Tests the basic abilities of the module
class BasicTest(unittest.TestCase):
def test_1(self):
self.assertEqual("QUiLoader" in QtUiTools.__all__, True)
def test_2(self):
app = QtCore.QCoreApplication([ "appname" ])
q = QtUiTools.QUiLoader()
# run unit tests
if __name__ == '__main__':
suite = unittest.TestSuite()
suite = unittest.TestLoader().loadTestsFromTestCase(BasicTest)
if not unittest.TextTestRunner(verbosity = 1).run(suite).wasSuccessful():
sys.exit(1)