changing fcitx to be implemented as a wrapper in order to use plugins#4713
Closed
cdepillabout wants to merge 1 commit intoNixOS:masterfrom
Closed
changing fcitx to be implemented as a wrapper in order to use plugins#4713cdepillabout wants to merge 1 commit intoNixOS:masterfrom
cdepillabout wants to merge 1 commit intoNixOS:masterfrom
Conversation
The plugin system in fctix is not very nice to work with. Plugins are distributed as separate packages, but they must be installed into the same directory path as fcitx itself. fcitx doesn't have any sort of option to look in a different directory path for it's plugins. For instance, if you install plugins separately like below, there is no way to tell fcitx where to look for them. /nix/store/xxxxxxxx-plugin1/lib/fcitx/plugin1.so /nix/store/xxxxxxxx-plugin2/lib/fcitx/plugin2.so The only solution is to install the plugins with fcitx itself. This commit creates a wrapper fcitx package that makes it possible to enable or disable plugins. A user can enable plugins for fcitx much like enabling plugins for firefox or chrome. There are also two default fcitx packages available, one with no plugins and one will all plugins enabled. This should provide binary packages for users that don't want to compile fcitx (but still may want to use plugins). Currently the only plugin available is the anthy plugin.
cdepillabout
force-pushed
the
fcitx-with-plugins
branch
from
5e59528 to
76d89e0
Compare
Member
Author
|
The travis CI build appears to be failing because it exceeds 50 minutes. |
Fuuzetsu
added
the
0.kind: enhancement
Member
Author
|
On the nix mailing list, Damien gave an example of how to do this in a cleaner way, so I will try to implement it that way instead. http://lists.science.uu.nl/pipermail/nix-dev/2014-October/014801.html |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The plugin system in fctix is not very nice to work with. Plugins are distributed as separate packages, but they must be installed into the same directory path as fcitx itself. fcitx doesn't have any sort of
option to look in a different directory path for it's plugins.
For instance, if you install plugins separately like below, there is no way to tell fcitx where to look for them:
/nix/store/xxxxxxxx-plugin1/lib/fcitx/plugin1.so/nix/store/xxxxxxxx-plugin2/lib/fcitx/plugin2.soThe only solution is to install the plugins with fcitx itself. This commit creates a wrapper fcitx package that makes it possible to enable or disable plugins. A user can enable plugins for fcitx much like
enabling plugins for firefox or chrome.
There are also two default fcitx packages available, one with no plugins and one will all plugins enabled. This should provide binary packages for users that don't want to compile fcitx (but still may want to use
plugins).
Currently the only plugin available is the anthy plugin.
This fixes the issue at #4550. The issue was raised upstream at fcitx/fcitx#179, but the author doesn't seem to have any desire to fix this problem.