Plugin Development

[KevinH]

But then which version (the one inside Sigil Prefs) or the one inside the app folder would take precedence?

I am thinking you are very right in that this would have to be thought through very very carefully. How exactly could updates be done?

If we had a github repo for just the "official" plugins, we could create symlinks to individual developers github pages for plugins (similar to how you set up the libxml fix).

I guess we could add an update checker of some sort to Sigil to examine just those linked github sites for new releases and then some internal installer to put them inside the right place in the app folder itself.

Needless to say this is not easy.

[KevinH]

I will look to see if we can assign a keyboard shortcut when we dynamically create the plugin menus. It should be possible (I hope).

Kevin

Originally Posted by DiapDealer

I thought a big part of the reason we created the Quick Launch plugin buttons was because it was the only way we could launch plugins with keyboard shortcuts.

[DiapDealer]

Originally Posted by KevinH

But then which version (the one inside Sigil Prefs) or the one inside the app folder would take precedence?

I'd forgotten about that.

[BetterRed]

If you assign the keyboard shortcuts dynamically can you please ensure that you don't clash with existing keyboard shortcut customisations already created by the user.

That's happened to me at least once and maybe twice in the past with Sigil. I've not reported it because its easily fixed at my end, hence I can't recall the details. I just find what took it (by sorting on the shortcut) and change it, normally to nothing, and reinstate my original usage of the shortcut.

Sigil's not the only program that's done this to me, but its 'sort by shortcut' feature makes it less onerous to fix than some other programs, and I'm thankful for that. In another instance I had to sweet-talk a plug-in developer into adding a blade to his swiss army knife gadget, the extra blade creates a CSV file of keyboard shortcuts I can use to find the clashes

BR

[KevinH]

Hi All,

It seems tk does not like svg images and for Access-Aide_v030.zip I will need to create a scaled png from any .svg images used the epub.

To do that for tkinter I either need heavy svg related code such as librsvg, librsvg2, cairo, and etc just to rasterize an svg.

Instead of those huge libraries, I found a very nice little project called nanosvg on github. This c code is actually in the form of headers that can be easily compiled to create a nano svg2png command line program I wrote called nsvg2png.

Please see the attached Access-Aide_v031.zip and unzip it and look inside the src/ directory.

I can compile the nsvg2png.c using a very simple one-line compile command on osx and all of this works just fine.

kbhend$ unzip Access-Aide_v031.zip
Archive:  Access-Aide_v031.zip
   creating: Access-Aide/
  inflating: Access-Aide/accessgui.py  
  inflating: Access-Aide/missing_image.png  
   creating: Access-Aide/osx/
  inflating: Access-Aide/osx/nsvg2png  
  inflating: Access-Aide/plugin.png  
  inflating: Access-Aide/plugin.py   
  inflating: Access-Aide/plugin.py.keep  
  inflating: Access-Aide/plugin.xml  
   creating: Access-Aide/src/
  inflating: Access-Aide/src/BUILD.TXT  
  inflating: Access-Aide/src/LICENSE.txt  
  inflating: Access-Aide/src/nanosvg.h  
  inflating: Access-Aide/src/nanosvgrast.h  
  inflating: Access-Aide/src/nsvg2png.c  
  inflating: Access-Aide/src/stb_image_write.h  
   creating: Access-Aide/unx32/
   creating: Access-Aide/unx64/
   creating: Access-Aide/win32/
   creating: Access-Aide/win64/

kbhend$ cd Access-Aide

kbhend$ cd src

kbhend$ ls
BUILD.TXT		LICENSE.txt		nanosvg.h		nanosvgrast.h		nsvg2png.c		stb_image_write.h


kbhend$ # compiling it is very easy

kbhend$ gcc -Wall -O2 -I. -o nsvg2png nsvg2png.c

kbhend$ ls -al
total 456
drwxr-xr-x   9 kbhend  staff    306 15 Feb 13:12 .
drwxr-xr-x  14 kbhend  staff    476 15 Feb 11:55 ..
-rw-r--r--   1 kbhend  staff     94 15 Feb 11:33 BUILD.TXT
-rw-r--r--   1 kbhend  staff    880 15 Feb 11:25 LICENSE.txt
-rw-r--r--   1 kbhend  staff  77806 15 Feb 11:24 nanosvg.h
-rw-r--r--   1 kbhend  staff  38111 15 Feb 11:24 nanosvgrast.h
-rwxr-xr-x   1 kbhend  staff  78068 15 Feb 13:12 nsvg2png
-rw-r--r--   1 kbhend  staff   2825 15 Feb 11:31 nsvg2png.c
-rw-r--r--   1 kbhend  staff  18599 15 Feb 11:24 stb_image_write.h

kbhend$ cp ../../drawing.svg ./

kbhend$ ./nsvg2png ./drawing.svg

parsing ./drawing.svg
Rasterizing image 1000 x 1000

kbhend$ ls
BUILD.TXT		drawing.svg		nanosvg.h		nsvg2png		stb_image_write.h
LICENSE.txt		drawing.svg.png		nanosvgrast.h		nsvg2png.c

So if someone has access to an old linux box and compile nsvg2png for 32 and 64 bit executables and can compile it for win32 and win64 and make those builds available to me it would be wonderful!

That way I could add them to Access-Aide plugin (similar to how flightcrew is done).

I have added a zip with sample svg images and a very simple test.epub to test Access-Aide with once you have added the nsvg2png exectuable to the right place.

Thanks in advance for any help.

KevinH

[DiapDealer]

I'll take a look. The Windows binaries should probably be created with MinGW if possible. That way it won't be dependent on VS runtime that Sigil is dependent upon (in case it changes in the future).

[KevinH]

Does a pure c program still need a full VS runtime? I thought only libc which was built in for c code and the extra runtime for c++ (cpp) code?

Either way, I will have to change plugin.py code to work with windows path separators which I did not handle when passing in the path to nsvg2png. I will try and fix.

[DiapDealer]

You're right, it shouldn't matter with pure c. I was thinking of the problem I ran into with the Flightcrew plugin.

[KevinH]

Hi DiapDealer,

The python urllib.parse routine when passed in a href or url will parse it into the network, scheme, path, and etc.

On Windows does it properly create a windows style path (with backslash separators) or does it create a url style path that always uses the forward slash?

Every where else I use os.path.join but I was unsure what the output looked like on Windows


Update:

I checked the code inside Python source tree and it seems to leave as a network local path (forward slash) and not a backwards Windows path.

So I have added a workaround to hopefully fix this to my previous post:

Access-Aide_v031.zip should hopefully work on Windows too once the nsvg2png is added.

[Doitsu]

@KevinH: I've successfully built and tested the 32bit and 64bit Linux nsvg2png binaries. BTW, I had to add -lm to the command line parameters that you recommended, but that might be a quirk of my machine. (The binaries definitely worked with the 3 test .svg images.)

I also checked both files with the file command and got the following results:

file /home/doitsu/.local/share/sigil-ebook/sigil/plugins/Access-Aide/unx32/nsvg2png
/home/doitsu/.local/share/sigil-ebook/sigil/plugins/Access-Aide/unx32/nsvg2png: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e2309b524a7caec90581847754e55e89b5b7763b, not stripped

file /home/doitsu/.local/share/sigil-ebook/sigil/plugins/Access-Aide/unx64/nsvg2png
/home/doitsu/.local/share/sigil-ebook/sigil/plugins/Access-Aide/unx64/nsvg2png: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7db3d8360e90dee017a1138a71c0b6ce4c62f38f, not stripped

[KevinH]

Wonderful! Thank you Doitsu!

Kevin

[DiapDealer]

What version of gcc/libc was used? An older version would be best to ensure the widest range of compliance with different libc versions.

[DiapDealer]

A quick test of the 64-bit Windows binary dropped into the plugin seemed to work as expected. I'll test the 32-bit version and get them uploaded shortly.

[DiapDealer]

These Windows binaries seem to test out OK.

I cross-compiled these binaries with MinGW on Linux, but I built and tested using Visual Studio 2015 as well (VS2015 is a minimum requirement due to some of those nano include files), and all seemed to work OK either way. I just get much smaller binaries cross-compiling with MinGW.

I updated the BUILD instructions with the commands I used for both MinGW and VS2015.

You'll need to rename the exes, I didn't put them in their own folders in the zip, so I needed to differentiate.

[KevinH]

Hi DiapDealer,
Great work! Thank you!

I will download them tomorrow and rebuild the Access-Aide plugin with them so that the same plugin will work for all platforms. I will then add your preferences support to allow the user to control the width of the thumbnail images if they want them smaller or larger.

After adding in support for epub2, I will post them.

Originally Posted by DiapDealer

These Windows binaries seem to test out OK.

I cross-compiled these binaries with MinGW on Linux, but I built and tested using Visual Studio 2015 as well (VS2015 is a minimum requirement due to some of those nano include files), and all seemed to work OK either way. I just get much smaller binaries cross-compiling with MinGW.

I updated the BUILD instructions with the commands I used I used for both MinGW and VS2015.

You'll need to rename the exes, I didn't put them in their own folders in the zip, so I needed to differentiate.