Support docsets

[Varemenos]

Dash and Zeal use a documentation file format called "docset" and these 2 apps already support quite a few documentations. It would be really great if devhelp could support docsets and therefore expand it's documentation listings

[roman (romankashicin)]

I like that idea very much.
Actually, I discovered DevHelp accidentally when I was trying to build a GNOME-specific Zeal analogue (since Zeal code base is really hard to work with, and the application is quite unstable). I've even started development of a portable C-library to work with docsets. So I think I can help with the feature development since I really interested in it and the DevHelp code base looks very mature.

However, I think we should contact Kapeli regarding this feature

http://kapeli.com/docset_links
"These docsets are available for personal use only, to be used with Dash or Zeal. If you'd like to use these docsets to build an app or tool (commercial or free), please contact me first."

[Varemenos (aklp08)]

There is no devdocs.io as well, maybe we can use their data.

https://github.com/Thibaut/devdocs

[roman (romankashicin)]

I've contacted the Kapeli developer and he thinks it will be great to
support docsets in DevHelp or to have a docset->devhelp2 converter.

However, it's not allowed to silently download docsets from the Kapeli
web site. We can either instruct user to download and install the
docsets himself in a user manual or to provide a link to Kapeli web
site inside the DevHelp application.

[roman (romankashicin)]

I've implemented some very basic docset support on my local machine.

The main problem I've encountered is a significant startup slowdown when there are huge docsets in the books directory. For example, the Java_SE7 docset has about 50,000 tokens which are loaded into memory by the DevHelp on startup. The startup time with Java docset enabled is about 15 seconds on my laptop with a Core i7 CPU and an SSD disk. The search is still quite fast. As I can see, it's not so easy to avoid this problem at the moment. Zeal, for example, uses the sqlite database directly to not load all the symbols into memory.

I still can improve my first draft a little bit and prepare a pull request in a few days. But a more efficient approach is obviously required.

[roman (romankashicin)]

I've spent some time profiling and it looks like the issue cause is not the docsets model construction but the tree widget rendering (I can't say for sure without debug symbols). So I suppose I'll limit the tree construction to specific token types (like Guide or Package). Constructing and rendering the whole token tree is too time consuming.

[roman (romankashicin)]

I've prepared a pull request:
https://github.com/GNOME/devhelp/pull/2

Unfortunately, it's not so easy to build the devhelp with docset support yet. The docset functionality is located in another shared library because:
- I started writing it before I found the DevHelp application
- It could be implemented with only a couple of external dependencies
- I want to reuse it in some (future) console applications

Currently I just build a debian package libdocset0 from github sources (https://github.com/roman-kashitsyn/libdocset) and install it directly with dpkg.

You should place (or simlink) docset bundles in a books directory (I use ~/.local/share/devhelp/books) in order DevHelp to see them.

[roman (romankashicin)]

Please see Bugzilla ticket for the further discussion: https://bugzilla.gnome.org/show_bug.cgi?id=723533