okular: Unable to open (Drawing|Annotating)Tools XML when being run via nix-shell

[flokli]

Issue description

When starting Okular via nix-shell (without okular installed in the environment), it prints above two error messages, and annotation features don't work.

strace tells me it is searching for drawingtools.xml and tools.xml in the following directories and order:

$USER/.local/share/okular/
/run/opengl-driver/share/okular/
/etc/per-user-pkgs/$USER/share/okular/
$USER/.nix-profile/share/okular/
/nix/var/nix/profiles/default/share/okular/
/run/current-system/sw/share/okular/

Steps to reproduce

nix-shell -p okular --run okular
On a system without okular being currently installed.

Technical details

• System: NixOS 18.03.git.5c35db3 (Impala)
• Nix version: 1.11.15
• Nixpkgs version: 5c35db3
• Sandboxing enabled: true

/cc @ttuegel

[flokli]

might be related to #24472 (although I can't find the mentioned wrapProgramsHook branch), and also on how okular stores annotations (in the internal local data folder, instead of next to the PDF).

[ttuegel]

Qt applications are not expected to work from nix-shell, they should be installed into an environment.

[flokli]

@ttuegel Didn't know that, and also didn't find it in the documentation. ;-)

Is this something that should be fixed (and already tracked in an issue)? Or something that most likely can't be fixed?

[ttuegel]

Is this something that should be fixed (and already tracked in an issue)? Or something that most likely can't be fixed?

That is tricky. I don't know how to fix it without breaking Qt plugins. For example, many KDE programs provide Qt plugins for interoperability; this is how you get a Konsole (terminal) window inside a Dolphin (file manager) window if Konsole is installed (and otherwise not). This type of integration seems like a core feature of desktop applications and I really don't want to do that.

Having said that, most likely it CAN be fixed, but so far I don't know how.

[flokli]

@ttuegel Just a quick thought, (maybe needs some more time to think about it):

Couldn't we construct a QT_PLUGIN_PATH of all buildInputs providing Qt plugins, similar to how it's done with PYTHONPATH, and additionally add a path containing links to "cooperating Qt plugins of the same environment" (not sure if QTDIR/plugins is scoped enough)?

In that way, discovery of non-essential plugins (no buildInputs) should still be possible using the "shared QT_PLUGIN_PATH", and essential plugins will be found due to them being buildInputs anyways.

Of course, this would mean some Qt applications relying on plugins might need to be wrapped if it's not possible to set QT_PLUGIN_PATH/QCoreApplication::{set,add}LibraryPaths() during configure phase.

[CMCDragonkai]

@ttuegel I think there should be an issue to track Qt application problems so we don't get so many of these issues on Github each time, an issue that links into this issue, and also my issue with masterpdfeditor.

[ttuegel]

Couldn't we construct a QT_PLUGIN_PATH of all buildInputs providing Qt plugins, similar to how it's done with PYTHONPATH, and additionally add a path containing links to "cooperating Qt plugins of the same environment" (not sure if QTDIR/plugins is scoped enough)?

Yes, we used to do it this way, but...

In that way, discovery of non-essential plugins (no buildInputs) should still be possible using the "shared QT_PLUGIN_PATH", and essential plugins will be found due to them being buildInputs anyways.

...this actually compounds the problem. Recall, all dynamic linking takes place in a single namespace. If we have some hardcoded plugins and some runtime-detected plugins, this raises the possibility that they will want different versions of the same library (either different Nix hash, or different soversion).

I am increasingly in favor of disabling all runtime plugin detection and hardcoding everything with wrappers. It would at least turn all these inexplicable problems into simple missing-dependency problems. I may address that in the future, but at the moment I have a different Qt feature branch I am trying to merge.

Of course, this would mean some Qt applications relying on plugins might need to be wrapped if it's not possible to set QT_PLUGIN_PATH/QCoreApplication::{set,add}LibraryPaths() during configure phase.

All Qt applications would need to be wrapped, similar to wrapGAppsHook.

[timor]

@ttuegel I run into the same problem, but with okular included in environment.systemPackages. Is that also not considered an environment? What is the proper way to install okular system-wide, then?

[ttuegel]

I run into the same problem, but with okular included in environment.systemPackages. Is that also not considered an environment? What is the proper way to install okular system-wide, then?

That is the correct way to install Okular system-wide, but I cannot reproduce the problem. Could you point me to your configuration.nix?

[oleks]

I have a similar issue, and unless I also list the package breeze-icons in my configuration.nix, I get all of the below errors:

Unable to open DrawingTools XML definition
Unable to open AnnotatingTools XML definition
Icon theme "breeze" not found.
Icon theme "breeze" not found.
Error: standard icon theme "breeze" not found!
Icon theme "breeze" not found.
Icon theme "breeze" not found.
Error: standard icon theme "breeze" not found!