Open cognition9144 opened 4 years ago
Calibre supports only Qt libraries provided on their own.
If you mean vanilla Qt + 1 patch here, yes.
I have verified that if I build the SDK with QT_FEATURE_zstd=OFF
, the undefined symbol: qt_resourceFeatureZstd
error disappears. However, it may not be a good idea to limit the default feature at the SDK level. The better approach is to
org.kde.KStyle.Adwaita
from source here with QT_FEATURE_zstd=OFF
; or@kovidgoyal Is it acceptable that we add zstd
as a calibre build dependency? Zstd is enabled by default in Qt as long as the library is present on the build machine.
You want me to add zstd to the sources.json as a calibre dependency? There's already pyzstd so including zstd as a separate library should be fine, one will need to make pyzstd build against it.
You want me to add zstd to the sources.json as a calibre dependency?
Yes. Since Qt has zstd enabled by default, most distributions build Qt with zstd enabled, some dynamically linked libraries with zstd enabled are called by the statically linked libraries bundled with Calibre, it's error-prone to build Calibre without zstd.
one will need to make pyzstd build against it.
Pyzstd bundles their version of zstd. Although the version does not matter, until the library is installed on the build machine, it cannot be used by Qt (the current setup). So you'll probably need to add an entry in https://github.com/kovidgoyal/calibre/blob/master/bypy/sources.json.
I think bringing ztsd to calibre is orthogonal to the issue - it won't change anything without additional user hacks.
The real fix would be to add adwaita-qt
and QGnomePlatform
to calibre. That should fix app look in gnome.
Flatpak package ships pristine calibre releases from upstream with all its benefits and drawbacks.
The real fix would be to add
adwaita-qt
andQGnomePlatform
to calibre. That should fix app look in gnome.
I'm certainly open to that approach, as long as it's acceptable in the Calibre upstream. What I'm trying to do is reduce user hacks to a level that the upstream and the maintainers of this repository can agree on.
I am definitely not going to be shipping GNOME or Adwaita with calibre binaries.
I am definitely not going to be shipping GNOME or Adwaita with calibre binaries.
I expect that. But not fixing the zstd issue means even kde users can't opt in the system theming. They have to use the legacy Fusion theme. So I believe that's the baseline that all of us can accept.
Technically libadwaitaqt6 doesn't depend on anything GNOME.
QGnomePlatform uses private Qt abi so its compatibility between runtime Qt and calibre Qt can be only accidental.
Generally there is no support for switching runtime so making calibre supporting unsupported case doesn't make sense to me when supporting theming by calibre was ruled out.
supporting theming by calibre was ruled out
My understanding is that upstream support only ends when you enter the flatpak realm. They are open to fixing the problem that a bare-metal installation may encounter (i.e., including zstd as a build dependency). Thus, upstream's lack of support for the special circumstances of flatpak is not an excuse for whether we should support this feature in flatpak.
QGnomePlatform uses private Qt abi so its compatibility between runtime Qt and calibre Qt can be only accidental.
Not quite true, unless "accidental" means highly likely. Calibre is built against a slightly patched (only 1 aforementioned irrelevant patch) Qt. Or maybe it's true in the sense that any software not built from source against the flatpak runtime is accidentally compatible. If such an imperfection bothers you, why not build Calibre from source here?
https://github.com/flathub/com.calibre_ebook.calibre/issues/17#issuecomment-765907403 says
Tagging this issue as wontfix since upstream distribution and internals makes building from source quite difficult.
So the reason for not building it from source is purely pragmatic. Why not apply such a principle here? That is, provide support for approaching the behavior as if it were built from source, at least at a minimum level, as long as there's a real user need?
The Qt compatibility problem isn't specific to flapak, same thing occurs with distro Qt.
Not quite true, unless "accidental" means highly likely
Upstream states This library will have to be recompiled with every Qt update. It's only pure coincidence that Calibre will use exact same Qt version as flatpak or bare-meal distro and with exact same features enabled. Today it's zstd tomorrow it will be something else. It's cat and mouse game. Only calibre supporting theming itself can guarantee things will work in the future.
That is, provide support for approaching the behavior as if it were built from source, at least at a minimum level, as long as there's a real user need?
For 99% users adding zstd doesn't change theming situation at all. I wouldn't call this support.
Well, I agree that the upstream should bundle (statically link) every library used, since they have statically linked Qt, whose compatibility with any system-provided libraries is unstable. This is our best approach.
But if the upstream doesn't want to do this for some reason, we can still achieve a degree of perfection by building Calibre from source in flatpak. Since all downloads are listed in this file , I think it's now possible to build from source, unlike before.
You can see how complicated source build is here. This needs manual intervention for every update. Right now you can have flatpak calibre update the day after it's released. With source build it would be months (assuming someone would want to maintain it at all).
You can see how complicated source build is here. This needs manual intervention for every update. Right now you can have flatpak calibre update the day after it's released. With source build it would be months (assuming someone would want to maintain it at all).
Have a look at the "Updating this Flatpak" section specifically. Unless some serious efforts are spent to fully automate translation of upstream's manifest to Flatpak, manual intervention will result in slower update cycles and potential human mistakes in the process. As a maintainer of Electron-based Flatpak packages, I have been facing this issue many times.
So far we have favored practicality and speed (and our sanity :sweat_smile:) by repacking upstream binaries, at the expense of a few integration gotchas.
Good morning. I am trying to get Calibre to respect the QT style that I have installed, but for some reason I am not really able to get it to do so. I am probably doing something wrong, so feel free to let me know if I am getting of track or if there is a simple way to do this with system themes that are not in flatpak.
To preface, I am on wayland via Sway 1.7 and Pop OS! 22.04.
To start I set export CALIBRE_USE_SYSTEM_THEME=true
in my profile to have it trickle down into the calibre flatpak (if that is not enough I also added the override to calibre via flatpak override --env=CALIBRE_USE_SYSTEM_THEME=true
). This does not seem to have any effect on the styling in the calibre flatpak.
So I did the following:
org.kde.KStyle.Kvantu org.kde.KStyle.Kvantum
)qt5-style-kvantum
and qt5-style-kvantum-themes
kvantummanager
and installed my theme (in this case it was the catpuccin theme for qt5ct and set it to the default theme.export QT_QPA_PLATFORMTHEME=kvantum
flatpak override --filesystem="$HOME/.config/Kvantum"
However I am not seeing calibre respect the catppuccin theme or an option to set the theme to catppuccin under the apprearance settings.
I have also tried setting export QT_STYLE_OVERRIDE=kvantum
in my bash profile and I get a message saying:
QApplication: invalid style override 'kvantum' passed, ignoring it.
Available styles: Windows, Fusion
I am not sure why it would ignore kvantum since it is an installed flatpak and it has access to the kvantum configs.
Is there something I am doing wrong here? I am newer to how to style QT apps, so it would be great if I could get some pointers on steps to debug things like this. Thanks for all the help and work that has been put into this!
In general this issue is about theming being unsupported. There are hacks which may or may not work for you.
In general this issue is about theming being unsupported. There are hacks which may or may not work for you.
I think I am a bit lost. From what I read in this thread, setting CALIBRE_USE_SYSTEM_THEME=true
supposedly does allow the use of system theming from the docs and the discussion here. However it does not seem to do so in my case, which seems to be a trend here.
Is there a specific version of qt that I need to account for with the theming (i.e. qt6 or qt5)? I ask because my understanding is that qt6
is not yet available on most package managers which would make styling for it pretty hard since that would require manually building the tools in question. Any tips on debugging this myself or a better place to ask this if this is not the place to do so?
Thanks for taking the time to help me better understand where I need to go from here!
Using host color schemes will work but qt themes not.
In flatpak qt themes are tied to org.kde.Platform//xx
runtime but since calibre bundles its own qt it uses org.freedesktop.Platform//xx
runtime instead. The bundled qt version is changed with its own pace so using matching runtime version is cat & mouse game.
I think calibre right now uses qt 6.4 so you would need to install org.kde.Platform//6.4
(it's EOL on flathub) then install relevant theme matching 6.4 branch then running:
flatpak run --env=CALIBRE_USE_SYSTEM_THEME=true --runtime=org.kde.Platform --runtime-version=6.4 com.calibre_ebook.calibre
each time.
Thanks for the fast response. I see that you are differentiating between host color schemes and qt themes. Is there a place to read up on that difference? I believe that qt themes are generally used by KDE while GTK themes are used by Gnome. I would assume that on a Gnome Sway setup that means GTK is the host color scheme, but I am not seeing that actually happen in calibre with use system theme set.
Edit: I have exposed the GTK settings to calibre and see no changes.
Calibre is qt app so gtk settings shouldn't matter for it. I'm on kde with default theme breeze and when I set any color scheme in system settings calibre will follow it without additional setup. Buttons and decorations are slightly different but for me it's hardly noticeable.
I guess for other desktop environments even the color schemes may not work without additional setup.
Thanks for the help with understanding this! I will have to see about testing some things around this.
As explained in #2, calibre doesn't really use the system theme but use the built-in one which is not good-looking.
There are definitely differences. Below are examples. The upper ones respect system's Adwaita theme whereas the lower ones use the built-in theme.
Main window
Edit metadata
It's trivial to add
CALIBRE_USE_SYSTEM_THEME=true
env variable but makes Calibre look much better.