Plugin Development

[Doitsu]

@KevinH: I've got a related question. Currently, the only way to position a cursor in an .html file is to use a validation plugin. Would it be possible to add a generic bk.setoffset(manifest_id, offset) function without major code changes?

[KevinH]

So you are looking for a way for an edit plugin on exit to control and set a single active tab with focus and with a cursor position?

If so what is the use case? Effectively, validators provide a list of files and offsets which the user can easily use to navigate to each after the plugin completes within the validation ui. Why can't you use that as your interface?

So how would setting a cursor position in a specific tab be useful bcause as soon as the user just clicks someplace, the new cursor position is lost.

Why not instead use a simple Py Qt text edit widget and let the user make text changes directly inside the plugin in which you control cursor positioning completely.

As it stands, inside Sigil we would have to clone the validation ui to make something more generic and then extend the plugin result xml and the plugin interface itself. So a pretty major overhaul.

[Doitsu]

Originally Posted by KevinH

So a pretty major overhaul.

In that case, forget about it. I'll simply use a custom edit widget.

[KevinH]

We have almost 50 Sigil plugins now. I am really happy with the range of plugins and would like to thank all the plugin authors for their great work!

When we designed the plugin interface, I was hoping it would bring the simplicity and power of python to help spur growth and developer interest in Sigil. I think we have achieved that!

So what are your feelings about pre-packaging/installing a small number of plugins into Sigil itself as sort of "official" plugins? The idea here is that they would still be plugins but whose code (not preferences) would come pre-installed and live inside the Sigil application directory someplace and not have to be downloaded and installed by every user. Plugin preferences would still be specific to the local user.

Ideas for official pre-packaged plugins might include one for docx input, one for kindle input, FolderIn/FolderOut, FlightCrew, epubcheck, font subsetting, css checking, and whatever else most people would find useful.

We would bring these into an official plugins tree on github open to plugin developers or something along those lines, and when the release apps are done these would be included in the main installer package or maybe in a single secondary installer. Making them official would allow us to free up those quicklaunch plugins with official icons while still allowing 5 additional user installed quicklaunch plugins.

Obviously if any plugins include 3rd party code they would have to have compatible licenses if they were to be included in an official tree.

Or is all of this just a waste of time and we simply stick to what we have now?

All comments welcome ....

[BeckyEbook]

Yes, yes, yes! Pre-installed plugins + five selected by user.

The most popular plugins should be added as default, and the user should choose five additional ones as icons on the toolbar.

On the pre-installed list I see EpubCheck, FlightCrew and others as per the discretion. It's a difficult choice, but I was thinking about the same idea all the time.

[BeckyEbook]

BTW:

Originally Posted by KevinH

The plugin dynamically generated menus can be assigned key accelerators for all plugins, which can make launching the plugins as easy or even easier than using the quicklaunch icons on the toolbar.

How to do it?

In keyboard shortcuts are only options for five plugins, which also have icons on the toolbar.

Run Plugin 1 - Run Plugin 2 - Run Plugin 3 - Run Plugin 4 - Run Plugin 5

If I could assign a keyboard shortcut to any plugin, I probably would not mention 10 icons for plugins.

[KevinH]

Whoops, I thought we implemented that but it looks like we haven't yet. All of the main menus (dynamic or not) should allow for shortcut assignments. I will look into that.

[DiapDealer]

Originally Posted by KevinH

Whoops, I thought we implemented that but it looks like we haven't yet. All of the main menus (dynamic or not) should allow for shortcut assignments. I will look into that.

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]

I like the idea of including some official plugins, but there's a lot of things I think we'd need to get worked out ahead of time.

Mainly a way for the plugin dev to easily update his integral plugin without needing to wait on a new Sigil release. If their plugin becomes a part of Sigil's codebase, they're almost going to have to use github and utilize pull requests to maintain their plugin.

I think we'd also need to eliminate any code from integral plugins that checks with external sites for updates and such. I almost envision a need for some sort of official Sigil plugin update channel. Whatever that might entail.

Nothing insurmountable, but I think it's going to take some mapping out.

[DiapDealer]

The EpubCheck plugin requires Java. As much I use the plugin and think it's worthy of being built-in, I'm not sure having a potentially non-functional plugin distributed with Sigil (and the ensuing support it might take to help a new user get it up and running) is the best idea.

Ideally, I think good built-in plugin candidates should have no external requirements. And they need to be compatible with the three main platforms Sigil supports.

[BetterRed]

I thought the objective of plugins was to keep the underlying program lean and mean and let the user decide which additional features they need. That approach is also more conducive to the creation of alternative plugins with similar functionality. It also means plugin bug fixes and enhancements can be delivered independently of the core - in a matter of hours, rather than waiting for the next release of the core.

How will you decide which will be in the core, if you exclude plugins that reference external resources, that will eliminate one of the docx import plugins (the one that uses Mammoth) - it could be that that's the one most widely used.

Originally Posted by KevinH

[ . . . ]

Or is all of this just a waste of time and we simply stick to what we have now?

[ . . . ]

That would be my 'philosophical' view. However I would not suggest you take much notice of that.

---

What would be useful would be the means to get hold of earlier versions of plugins so that one can easily revert when something goes wrong.

And a notification mechanism when Sigil starts that advises of new plugins and new versions of installed plugins. As I understand it, it's when one uses a plugin that one will be informed of a new version. But that is probably not the best time to be considering updating the plugin you were just about to use.

BR

[DiapDealer]

Originally Posted by BetterRed

How will you decide which will be in the core, if you exclude plugins that reference external resources, that will eliminate one of the docx import plugins (the one that uses Mammoth) - it could be that that's the one most widely used.

You misunderstood me, I think. Mammoth is delivered with that plugin. It's an internal part of the plugin. It's license allows it. By external resources, I meant something that has to be installed separately to make the plugin work (usually because it can't easily be delivered with the plugin). Like Java with the EpubCheck plugin. Java must be installed on the the system and on the PATH for that plugin to function.

[BetterRed]

Originally Posted by DiapDealer

You misunderstood me, I think. Mammoth is delivered with that plugin. It's an internal part of the plugin. It's license allows it. By external resources, I meant something that has to be installed separately to make the plugin work (usually because it can't easily be delivered with the plugin). Like Java with the EpubCheck plugin. Java must be installed on the the system and on the PATH for that plugin to function.

I was thinking 'rules' rather than 'maps' so I may have been muddling the DOCXImport and Language Tool plugins. That, and I did download Mammoth, in part to satisfy my curiosity, and to gain more insight into setting up the mapping.

I noticed there's a new version of Mammoth (1.4), although I'm not sure what changed. How is that eventuality currently handled by the DocxImport plugin, do you have to release a new version of the plugin or...; since we outsourced my old job of converting documents into ebook formats I've stopped using it.

BR

[DiapDealer]

Originally Posted by BetterRed

I noticed there's a new version of Mammoth (1.4), although I'm not sure what changed. How is that eventuality currently handled by the DocxImport plugin, do you have to release a new version of the plugin or...; since we outsourced my old job of converting documents into ebook formats I've stopped using it.

I haven't checked Mammoth in a while. I'll see what the 1.4 brings to the table. I've modified Mammoth slightly for the plugin's needs, but I'll probably incorporate the changes in the new version at some point.

EDIT: the processing of paragraph indents from 1.4.4 looks interesting.

[DiapDealer]

It occurs to me that I may be overthinking the potential update process for built-in plugins. Devs could always maintain beta/development versions of their plugins that install via the normal Plugin Manager interface if they want.