GNOME Bugzilla – Bug 509338
Devhelp library split
Last modified: 2017-06-29 15:54:35 UTC
I'm trying to develop a gedit plugin that use the devhelp search. I've tried to use libdevhelp but depends on gecko. Can you split the devhelp UI and the internal library? The internal library must not depends on gecko because gecko is only the presentation. An external application could use libdevhelp to search in the API like the devhelp application without depends on gecko. Is this possible?
Hm... perhaps we could do this, but then the other users of the library probably would have to change too (like anjuta). It does sound like a good idea to me though.
About anjuta. I think it is not a problem because we want implement that stuff in anjuta too and we can't with the current library.
For anjuta it shouldn't a big deal in case you version everything correctly. Because currently we have about twenty #ifdes just to treat all version of libdevhelp. So this could probably be libdevhelp-2.0 and libdevhelp-ui-2.0. In that case you should also please try to abstract more between the underlying browser engine. Hopefully gtk+ will provide a html widget sometime soon.
There is someone working on it? Can I help you to do the split? I think this is a very util feature for other application that want to use the power of devhelp.
Ping... If you want I can help you to do this. It is very important for all. We need to use the API documentation in other applications like anjuta, gedit, openldev etc. If you don't want to change the library please, tell us and I try to reimplement a new library to read the .devhelp books. If you want, I can help you to split devhelp. Tell me what code I must to change (the trunk, a branch etc.) and I will try to split devhelp. Thanks
I don't have really strong feelings about this. I would prefer not to have people use devhelp as a library at all, but it's too late for that ;) However, if we do split the library, I don't think it's really feasible to have a parallel installable version as described above as it would require the entire app to be parallel installable. If someone wants to work on this, and sorts out any issues that might happen to existing users of the current library, I'm fine with it.
Actually we though about moving the anjuta devhelp plugin into the devhelp sources (like the gedit plugin) but I am not sure if you like this idea. It would impose an optional dependency on libanjuta-1.0 in devhelp but would remove the need to distribute the library.
(In reply to comment #7) > Actually we though about moving the anjuta devhelp plugin into the devhelp > sources (like the gedit plugin) but I am not sure if you like this idea. It > would impose an optional dependency on libanjuta-1.0 in devhelp but would > remove the need to distribute the library. I don't think that is a good idea. The gedit case is different as it doesn't add a build dependency.
This bug talks about the gecko dependency, so it's a bit obsolete (Devhelp now uses the WebKitGTK+ library). I've filed bug #784351 with a similar idea, so I think we can close this one as a duplicate. *** This bug has been marked as a duplicate of bug 784351 ***