https://bugs.documentfoundation.org/show_bug.cgi?id=160275

--- Comment #6 from Huanyu Liu <[email protected]> ---
(In reply to Michael Weghorn from comment #5)

> Can you try whether starting LO with environment variable
> SAL_USE_VCLPLUGIN=gtk3 works in a KDE Plasma session as well (please
> double-check that "Help" -> "About LibreOffice" says "VCL: gtk3" then.

With the environment variable SAL_USE_VCLPLUGIN=gtk3, LO does not crash anymore
and everything works as expected.

By the way, in a previous version (half a month ago) of LO, setting it to kf6
will make any component of LO unable to save anything as a new file, so I set
it to kf5 as a workaround. Now it seems that this bug has been fixed. However,
setting it kf6 will also cause the crash described here.

> Thanks. It's somehow not offered for me in the virtual keyboard section in
> KDE system settings, but what works for me is to kill ibus, start fcitx, and
> start LO with environment variable QT_IM_MODULE=fcitx set.
> Still no crash for me when switching to mozc then (now also using a
> customized Super+Space shortcut), and typing Japanese characters also works
> fine.
> 
> What version of fcitx are you using? The one I tested is Debian package with
> version 1:4.2.9.9-1 (i.e. major version 4), but there's also a fcitx5
> package (version 5.1.7-1) available that I haven't tried so far.

I'm using fcitx5 with version 5.1.8-1 in the Arch Linux repository. It seems
that fcitx4 (no suffix in the package name) has been discontinued, but not
removed from the repository.

> Does that mean you still get the crash the same way as before, but there's
> no backtrace or is the behavior already different earlier?

LO Calc still crashes with return code 255, but doesn't leave any backtrace.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to