It's going to take me some time to wrap my head around all
those names and strings and figure out where these paths are
supposed to be, and whether #2 is possible. I've got no more
time to think about this until at least the weekend, if not
next week.

All my code is up-to-date in the main repository (no changes in
the past week; no pending pull requests). If someone wants to
jump in and produce the simplest fix before I can, they're
welcome to do so.


On Wed, Oct 8, 2014, at 04:11, Jaap Karssenberg wrote:


One step back; of course the default shipped plugins are in the
python library path. They are installed as part of the program,
and the user will not easily remove them. The XDG_DATA folders
are used for extra user installed plugins that do not ship with
the default install.

XDG_DATA contains the user data folder but also the system data
folders. Yes it is reasonable for the user to mess around with
the user data folder, but we should be able to use the system
data folder for files included in the installer. This is the
same "data" folder is used by the installer for the manual,
templates & images. So I think there is no harm in using it for
plugins as well.

Problem is that for the executable the default plugins are
compiled into the executable, so we can no longer scan the
files to get an index of them.

Previously the work around has been to ship a copy of the
plugins outside of the executable. This work around now broke.

Two ways to fix that:
1. Fix the work around by putting the files in the right folder
2. Fix the issue by somehow making sure we can list the plugin
files even when compiled into an executable

Fix in #1 is real easy, just move the files you install now to
"zim/plugins" to "data/zim/plugins".

Most simple version of #2 would be to patch the
"PluginManager.list_installed_plugins()" function with a hard
coded list when compiling to executable.

Would that work for you?


Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to