Also, the source package directory structure has changed a bit. A number of files that were top level have been put into a docs subdirectory. Further, the source zip package is now putting the everything in a Sigil-x.y.z/ subdirectory.
Saturday, September 27, 2014
I'm pleased to announce the availability of Sigil version 0.8.0! The download location has changed sine the last release. This is because Google Code has stopped providing or allowing new downloads. Existing downloads will eventually be removed from the service completely.
It has been nearly a year since the last release of Sigil. This long delay is due to Sigil having and mainly is a one man operation. I don't have the time I did in the past to work on Sigil so I'm mainly relying on contributions to keep Sigil current. For quite a while no one was willing or able to help. Recently Kevin Hendricks has had time and motivation to contribute and Sigil has progressed quite a bit with his help.
There have been a handful of fixes and minor improvements but that's typical for a new release. This is a major release which means major new features...
The big new feature Kevin has spearheaded is plugin support. This has been long requested and it's finally here.
Plugins support is a revision one at this point. We have plans to expand it out in the future. The system is designed to be flexible and allow for a lot of new features. Plugins are standalone and don't hook directly into Sigil in term of UI changes. They're mainly for advanced processing at this point.
Currently Python 2 and 3 are the only supported languages for Plugins. The system is designed to be able to add other languages in the future quite easily. The decision to focus on Python for this release is due to the amount of existing Python code for ebook manipulation that is currently available.
Sigil does not currently bundle Python but relies on Python being installed (this could change in the future). In preferences you'll need to specify the Python executable location. If you're on OS X it's already installed with the OS and you just need to use the auto button to have it auto detected. Linux can also use the auto button. Most likely it's already installed if you use Linux. For Windows user's you'll want to install something like Active State's ActivePython (community edition is free).
Again, plugins are standalone. What happens is Sigil will call the interpreter (Python in this case) with an internal launcher script as the target. A few bits of info along with the target plugin are passed to the launcher which manages running the plugin. This allows for some really cool stuff like separation of plugins from Sigil's internals and easy recovery if a plugin crashes.
Sigil itself is Open Source and is licensed under the GNU GPLv3. The plugin system was written in a way that allows plugins to be released under any license the plugin author wants. A plugin author isn't forced to use the the GPLv3. Plugin authors aren't required to release their plugins as open source either. They are free to release commercial closed source plugins.
The licensing allowance is not due to a licensing exception but due to how plugins are called. Plugins are run via the plugin launcher as a separate process. The launcher itself is licensed under a 2 clause BSD license. The plugin architecture is standardized and not dependent on Sigil. It is entirely possible to use a Sigil plugin in another application if that application implements the launcher interface. The idea is plugin authors write to the launcher API and Sigil implements that API.
The plugin API is very similar to calibre's API. We have actually tested some cailbre plugins in Sigil with little or no modification of the plugin itself.
Does This Mean Sigil is Going Closed Source?
The idea is to allow people to extend Sigil without putting restrictions on them. Again, there is a lot of existing ebook manipulation code out there that this allows Sigil to take advantage of.
Allowing permissive licensing allows existing non-GPLv3 licensed code to be used with Sigil without forcing that code to be relicensed. Think about small publishing houses that have their own internal tools. They can integrate those tools with Sigil without having to worry about any licensing issues or worry about needing to relicense.
The motivation is code reuse and allowing users to expand Sigil. This is no different than the "open with" feature which allows external editors to be used in conjunction with Sigil. Think about images which Sigil doesn't currently support editing. Users can use "open with" to edit an image using another tool and allow Sigil to use those changes.
Let me be very clear, I have no intention of withholding features from Sigil in order to make them into pay only and proprietary licensed plugins. I fully believe that this is not Kevin's intention either (he's contributed quite a bit of code to various places all open source).
Not right now. There isn't enough man power right now for this. We also don't know how popular this feature will become or how many plugins will be created. It's possible it will be very popular but only a handful of plugins will ever be made and used. I'm not willing to put resources toward this until it's necessary.
This is a big release but it's a first step release. There is a lot that can be done with plugins in the future. We haven't even scratched the surface of all of our ideas. It just takes time.
Sunday, September 21, 2014
As I've said in previous posts Sigil isn't dead. It's recently had a lack of contributors making development stalled. As long as people are willing to contribute to Sigil it will continue to evolve and move forward.
As for contributing myself I simply don't have 20-30 hours a week to devote to writing code for Sigil. That doesn't mean I've stopped writing code for Sigil and as I've said previously I'm willing to provide guidance to anyone who wants to contribute.
Basically, one year go the there were no outside contributors. So for one year not much has happened. A small maintenance release happened. Bug fixes were committed but few and far between. Nothing major feature wise.
Now that all changed about a month ago when Kevin Hendricks decided to invest his time in some bug fixes. Then he decided to start working on a plugin framework for Sigil. He's been spearheading the effort to get this feature implemented. It's not ready yet but it's coming a long nicely.
I know I don't want to see it die but there is only so much one person can do alone. So the moral of the story is, Sigil isn't dead and as long as there are contributors it won't die and it hasn't yet.
Sunday, February 9, 2014
At this point Sigil is no longer being actively developed. Moving development to Github has netted a few contributions but they were one offs and fairly minor. With Sigil development being stalled, Kovid (of calibre) starting making the tweak epub functionality in calibre into a full editor.
calibre's editor at this point is stable and has many of the features, though not all (yet), that are present in Sigil. Like Sigil, calibre's editor is open source and unlike Sigil is being actively developed. I've known Kovid for quite some time (though calibre) and I'm confident that the calibre editor is the way forward.
For people using Sigil, keep using it as long as it works for you. If you find it's not meeting your needs or if you want to see what else is out there I recommend checking out cailbre's editor. While it doesn't use any of Sigil's code I consider it Sigil's spiritual successor.
Sunday, October 27, 2013
This is a small maintenance release of Sigil. Books with an invalid doctype should open as they did in version prior to 0.7.3. Also, this release has a build for OS X using Qt 5.2.0 Beta 1. This release should support Mavericks though it has not been tested on Mavericks.
I've disabled the issue tracker on both Google Code and GitHub. The issue tracker has become people posting the same few items which are not issues over and over again. I spend more time closing invalid issues than doing anything else with Sigil. If you're having a problem with Sigil of some sort try searching Google. FYI, if you're using OS X chances are either the version you're using isn't supported or isn't supported at this time due to components Sigil depends on being broken on that version.
Sunday, September 15, 2013
Sigil is not dead but it's development has slowed considerably to the point it's not being developed very much at this point. The best way I can describe it is Sigil is on life support.
When I took over Sigil from Strahinja I was not planning on taking an active development role. As part of my taking over Sigil my involvement was planned as project management. I was going to manage the web presence, review patches, provide guidance, made releases and at most minor bug fixes. However, that's not what ended up happening. Instead I ended up taking a very active development role. This was never my intention and not something I can continue. I do not plan on ending my affiliation with Sigil; I'm going to go back to what my involvement was supposed to be. Project management.
Since I've been management Sigil there have been about four major contributors (code). These people have been a huge help and a huge benefit and I've very thankful for their help. Ultimately even with all their help I'd estimate half of all code since I took over has been written by me. Due to this and myself not writing code like I was development will slow considerably.
Also, the contributors were never permanent members of the project. This is by their choice. They saw ways Sigil could be improved (mostly something they wanted it to do for their benefit) and helped to make it happen. As they've completed what they were interested in they've left and moved onto other things. Thus Sigil has zero outside contributors as of now. This combined with my decision to focus on project management means there is no one actively developing Sigil at this time.
To help with gaining contributors I've decided to move the project to GitHub. The new source repo is available at https://github.com/user-none/Sigil. This is something I'd been thinking about for some time now. A few reasons behind the change:
Google Code has poor support for working with and merging forks. So much so that most contributors ended up emailing patches instead of wanting to deal with Google Code.
Google Code's issue tracker is terrible. The search feature is useless. The way it displays issues is terrible and hard to understand. The majority of issues posted at least 99% are not real issues but duplicates of issues that are deemed not issues. The most common issue opened is Sigil does not run on OS X 10.6 which for technical reasons is not possible. Sigil not running on an OS version that is not supported, not intended to run on and an OS version that is EOL by the OS vendor is not a bug.
Personally, I believe the issue tracker should be used for code discussion and contribution. That's not happening. So moving to GitHub means it's more likely that that will happen because people will need a GitHub account to open an issue and typically only developers will have a GitHub account. I'm not saying I don't want people reporting issues but when reporting issues means me closing 99% of them as either dup of not supported or not supported makes the issue tracker less than worthless.
Google Code has decided to disable downloads. Existing projects were given an extension but as of next year Google Code can't be used to host binary builds of Sigil. This makes Google Code less useful.
- Calibre moved to GitHub and while Kovid has told me it hasn't increased the number of major contributors it has increased the number of one off contributions. I'm hoping that if calibre moving to GitHub has increased code contributions the same will happen with Sigil.
That's pretty much where Sigil is a this point. I can't say where it will go in the future but my hope is more people will contribute with the move to GitHub and Sigil will continue to grow.