Sounds nice! I didn't look at the code yet, just tried it out. Here's my findings so far:

• if zeal is not installed, the icon is empty -- have a fallback icon?
• the settings page title ("zeal") is not very clear
• after enabling docsets, I have to restart kdevelop to get them to show up in the documentation view, at least when it was open before

From the user POV, it took me quite a while to figure out that I need to install zeal (which is not even in my distro's binary repos), start it up, click tools -> docsets -> download, download some docsets, then go to kdevelop's settings page and enable them there. I'm afraid you can't expect the majority of users to do that :/

Do you see a chance to get zeal's "Download" dialog into kdevelop? Or maybe we can mirror the docsets as a GHNS resource?

Anyways, great thing overall and I see this becoming very useful in the future!

• if zeal is not installed, the icon is empty -- have a fallback icon?

We can add our local icon or use fallback if system icon is missing - which way is preferable?

• after enabling docsets, I have to restart kdevelop to get them to show up in the documentation view, at least when it was open before

It's strange. When I enable/disable docsets and do "Apply", then documentation view "hides" and after manual opening contains all selected docsets.

From the user POV, it took me quite a while to figure out that I need to install zeal (which is not even in my distro's binary repos), start it up, click tools -> docsets -> download, download some docsets, then go to kdevelop's settings page and enable them there. I'm afraid you can't expect the majority of users to do that :/

Ok, you are right, UI should be fixed. Now it in "alpha" stage :)

Do you see a chance to get zeal's "Download" dialog into kdevelop? Or maybe we can mirror the docsets as a GHNS resource?

Ok, I'll try to add such dialog (from Zeal code) into our UI. It seems to be most comfortable way for users.

Anyways, great thing overall and I see this becoming very useful in the future!

Thanks :)

For a 16x16 icon, I personally think we should just ship it ourselves (but prefer the system one if it exists).

re. download dialog, where are the files hosted at the moment? We shouldn't just put that download URL into our application without asking.

re. download dialog, where are the files hosted at the moment? We shouldn't just put that download URL into our application without asking.

You mean, that we should contact with zeal's authors and ask them about using their code and site for download docsets from our plugin?

In D3424#64042, @antonanikin wrote:

re. download dialog, where are the files hosted at the moment? We shouldn't just put that download URL into our application without asking.

You mean, that we should contact with zeal's authors and ask them about using their code and site for download docsets from our plugin?

Yes

Yes, the code I wouldn't worry so much about if the license is ok (although it's certainly good style to inform them), but hard-coding (or even listing) their download URL without asking is not ok.

Could this become a kioslave that generated HTML, or a kpart, or at least have a library that can be used to build a kioslave and/or a kpart?

Any update on this? Sounds like a useful feature

In D3424#87489, @mwolff wrote:

Any update on this? Sounds like a useful feature

Hi, Milian, I have an updated version, but it not finished. The current state is:

1. If we doesn't want to provide docsets loading the plugin can be quickly adapted to current master.

2. Zeal's author doesn't provide it's infrastructure for docsets downloading :(

3. I have quick-and-dirty version of scripts which downloads docsets information from github repositories and convert them in "compressed" form, which currently hosted on my server. The docsets repo author agrees to provide it's stuff for our plugin with providing copyright information.

Now I don't know which way is better. Some peoples also suggests to provide library/kioslave for docsets support. All this possible but with different time cost. I also agree with Rene when he suggest to add ability for external-app documentation viewer, because the internal is far from ideal :(

Personally for me the ideal situation is provide "full stack" solution with our docsets information distribution server and downloading/updating docsets independently from Zeal (but if we can share docsets with Zeal it may be useful) with creating some external app (something like KDevDoc, Zeal/Dash inspired), which supports all types of documentation (Qt, man, cmake, dash docsets, etc) and provides an API to integrate it with KDevelop as internal or external viewer (user choice).

In D3424#90759, @antonanikin wrote:

In D3424#87489, @mwolff wrote:

Any update on this? Sounds like a useful feature

Hi, Milian, I have an updated version, but it not finished. The current state is:

1. If we doesn't want to provide docsets loading the plugin can be quickly adapted to current master.
2. Zeal's author doesn't provide it's infrastructure for docsets downloading :(
3. I have quick-and-dirty version of scripts which downloads docsets information from github repositories and convert them in "compressed" form, which currently hosted on my server. The docsets repo author agrees to provide it's stuff for our plugin with providing copyright information.
   
   Now I don't know which way is better. Some peoples also suggests to provide library/kioslave for docsets support. All this possible but with different time cost. I also agree with Rene when he suggest to add ability for external-app documentation viewer, because the internal is far from ideal :(
   
   Personally for me the ideal situation is provide "full stack" solution with our docsets information distribution server and downloading/updating docsets independently from Zeal (but if we can share docsets with Zeal it may be useful) with creating some external app (something like KDevDoc, Zeal/Dash inspired), which supports all types of documentation (Qt, man, cmake, dash docsets, etc) and provides an API to integrate it with KDevelop as internal or external viewer (user choice).

Any new on this? I have created a merge request here with some small code changes so it can be compiled.