| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Those require a lot of patching (and other efforts), but it does not
seem possible to write this kind of thing as an integration test:
https://www.riverbankcomputing.com/pipermail/pyqt/2022-June/044733.html
https://www.riverbankcomputing.com/pipermail/pyqt/2022-June/044734.html
|
|
The decision in a64c3d0dfc000cbd1a0b1f0f0afda783be245880 to return from
_verify_message() when there is a non-fatal error (later expanded to
more than just NoReply) was a poor one:
While the error signal indeed takes care of swapping out the faulty
adapter, the direct caller of _verify_message generally expects the
message to be in the verified shape (e.g. having 4 arguments, or an int
as argument, etc.). Thus, every caller would have to handle this
situation, yet none of them did!
With the restructured code, we now *always* raise an exception. It's
still the callers responsibility to deal with that happening, but that's
much less tricky than just pretending we validated the data when we did
not.
Thankfully, most caller already handle the situation, or don't need to:
- _get_server_info() and _fetch_capabilities() get called from __init__,
where any notification.Error is already handled by
NotificationBridgePresenter.
- _handle_close() and _handle_action() get called as DBus signals by Qt.
It's hard to imagine how they would ever get an error reply, as the
caller is the other side (the notification server), not us!
This only leaves present(), which now handles this case: If it gets a
fatal exception it still gets raised, but for any non-fatal ones, we now
emit the error signal there and return a dummy value.
|
|
|
|
Fixes #7160
|
|
|
|
|
|
|
|
Closes #7237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See #7245
|
|
Needed for #7245
|
|
Needed for #7245 and also seems like cleaner code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Based on https://github.com/pyinstaller/pyinstaller/issues/6612
Might help with #6771.
|
|
pathlib, type annotations, modern syntax, dataclasses
|
|
The patching was originally introduced back in 2017 in #3055, when
PyInstaller only supported very basic Info.plist operations.
This changed in 2018 (!) however, with PyInstaller 3.4:
https://pyinstaller.org/en/stable/CHANGES-3.html#id8
https://github.com/pyinstaller/pyinstaller/pull/3532
Thus, let's move this back to PyInstaller. This produces exactly the
same Info.plist as before.
Fixes #7251
|
|
|
|
Fixes #7254
|
|
https://github.com/python/cpython/issues/93010 has now been fixed, but https://github.com/python/cpython/issues/87112 is still broken.
|
|
|
|
|
|
- Added a nuance of blue instead of white, as a background for light
color scheme
- Deleted some unused CSS
|
|
README.asciidoc: avoid HTML redirect for luakit website
|
|
It seems that, now, the luakit homepage is at https://luakit.github.io/
and https://luakit.github.io/luakit/ is just an HTML redirect to it.
Let's avoid the annoying redirect.
|
|
|
|
|
|
|
|
If we have a error message followed by an info message with the same text, they
should both be shown, not replaced automatically.
|
|
See #7246
|
|
Closes #7246
|
|
Preparation for #7246
|
|
|
|
|
|
|
|
Better to have positive rather than negated names. Still keeping the user-facing part though, to keep the default.
|
|
|
|
As well as:
- replace external links with internal links for changelog and
quickstart
- remove unused class names
- use already existing logo
- replace `url` with `_url` to mark it unused
|
