| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Change-Id: I94cb5a7dab97cff3591bac534228bfd3e3ad5938
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For short the new features:
- there is a qApp in QtCore, QtGui and QtWidgets for compatibility,
and also in __builtins__ for a true macro-like experience.
- if you delete any qApp variable, the Q*Application is reset and you can
start over.
Long description:
There is a qApp macro in Qt5 which is equivalent to Q*Application.instance() .
Python does not have macros. Both PyQt5 and PySide2 have an
according structure in QtWidgets. In the case of PySide2, the qApp
variable is first initialized to None and later to QApplication().
This does not reflect the original sense of the qApp macro, because
- it only handles QApplication,
- it does not handle destruction.
This "macro" should live in QtCore, but both PyQt5 and PySide2 decided
to put this in QtWidgets. As a compromize, I propose to put qApp into
all three modules, and into __builtins__ as well, so wherever you
create an application, you find this "macro" in place.
While changing the code, I stumbled over the template
set_qapp_parent_for_orphan. I tried to make sense out of it and finally
removed it. There were no side effects but bug PYSIDE-85 is gone, now.
With some extra effort, I created a singleton qApp that changes itself.
This way, a true macro was simulated. Note that this was not possible
with a garbage collected variable, and I had to make shiboken aware of this.
As the final optimization, I turned qApp also into a fuse variable:
Delete any qApp variable and Q*Application will finish when there is
no extra reference.
Task-number: PYSIDE-85
Task-number: PYSIDE-571
Change-Id: I7a56b19858f63349c98b95778759a6a6de856938
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Q*Application had PySequence as Parameter, although
only QStringList is accepted. That resulted in an implausible error
message when a list of, say, Integers was given.
This patch
- replaces PySequence by QStringList (one more tuple layer),
- fixes QCoreApplication to give the same kind of error messages,
- renames the shiboken function sequenceToArgcArgv to listToArgcArgv
and changes it to only allow list descendents.
We also changed signature.typing in one line to display List[str] correctly.
I think this belongs more to PySide-331, a fixed qApp.
Task-number: PYSIDE-510
Task-number: PYSIDE-331
Change-Id: Ib256c6a2db05a3db826454e1bf1b4729d59a240b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
| |
| |
| |
| |
| | |
Task-number: PYSIDE-487
Change-Id: I5902ce37ad40b8180b6710b3e7cd091925ad392d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| | |
Task-number: PYSIDE-487
Change-Id: I0106d87418c757d14c2dd7dd9fd1ab9d0c66a449
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove comments, add test. The claimed cyclic dependency apparently
disappeared when porting to Clang.
Task-number: PYSIDE-487
Change-Id: I44556fb5de92d83bd9471a41a03db9f6eeff0a31
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
They are used for GLint64. Amends
4ec9cfa3c6b895c0cf50227c189cfa542de88b64.
Task-number: PYSIDE-516
Change-Id: I0be5d1302629ea156fb3dde07dd810f5730b064e
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
|\|
| |
| |
| | |
Change-Id: Iddee2cf511ee0f0896a04a76e5b5b8bd44d1d6f1
|
| |
| |
| |
| |
| |
| | |
Task-number: PYSIDE-487
Change-Id: I9a2c19c6b8415e3f608531b315a6841eb3de55f5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
| |
in preparation for a subtree merge.
this should not be necessary to do in a separate commit, but git is a
tad stupid about following history correctly without it.
|
|
|
|
|
|
| |
Task-number: PYSIDE-487
Change-Id: I742d0fe52da22a06ca04069b6e0094d1913cc187
Reviewed-by: Christian Tismer <tismer@stackless.com>
|
|
in preparation for a subtree merge.
this should not be necessary to do in a separate commit, but git is a
tad stupid about following history correctly without it.
|