GNOME Bugzilla – Bug 344043
Bug with DevHelp 0.11 installed
Last modified: 2007-12-04 19:50:16 UTC
Currently we are trying to envoke `devhelp --version` to check if we have the correct version of devhelp installed... in version 0.11 there is no --version argument; this causes devhelp to be spawned at the beginning of every glade3 session.
Now that I think about it... enough to file the bug, I see how it can be fixed. First I will parse the output of `devhelp --help' and search for the "--version" string... if "--version" is not present then devhelp is <= 0.11, otherwise parse the version output.
Well, we could really solve this by providing an explicit '--enable-gnome' build for glade3. For that build, libdevhelp-2.12 will be a dependency. Since devhelp indirectly pulls in GNOME as a dependency, only those people who are using the gnome build should be able to use devhelp anyway. Of course, I have an hidden agenda in this suggestion ;). A build that supports GNOME would also be needed to integrate a possible user manual with GNOME's help system (which would be cool). There's also lots of other ways we can integrate glade3 with GNOME, which would definitely increase it's appeal to Gnomies. Obviously, this would have implications for Gustavho's debian packages, so maybe we should talk about this only after the 3.0 release. cheers
What I think it boils down to, is that investing an effort into a gnome frontend to glade3 is taking away from the user experience on any platform other than the gnome platform. The fact that glade3 is portable is a big big thing, it means that people can easily use glade to write thier gtk+ applications on any platform (hopefully this will increase the appeal of GTK+ to all ui app developers). I also should say that at first sight the idea of maintaining a dual ui or cluttering the code base with #ifdef USE_GNOME, is seriously disinteresting. That would also infer that distributions of the core libgladeui library would probably have to either come in two flavors of have some sort of added support; all for what seems at first sight to be just UI crack... which I think is more appropriate for a program like anjuta for example.
hmm, ok I see your point. It would be counter-productive and hard to manage. Then maybe as an alternative, we could investigate a "plugin" system for glade instead. Each plugin would be a dynamic module that would have it's own set of symbol dependencies (eg yelp, libgnome, libdevhelp, etc). Come to think of it, I think this is a much better than having dual builds. what do you think?
Back to devhelp bug ... In light of our discussion about plugin modules, maybe it would be prudent to the make the devhelp feature a plugin. I understand that the devhelp executable is launched using g_spawn_async(), and that the devhelp executable itself depends on libdevhelp-2.12. So idea I am getting to is that the optional plugin module will have a build dependency on libdevhelp-2.12. The actual plugin implementation will only call g_spawn_async(), and will not actually use libdevhelp directly. Needless to say, only those users who have the required libdevhelp-2.12 will be able to use or install the plugin. cheers
In the cvs history, glade-devhelp.c was a plugin that implemented a "devhelp widget", that could in turn be easily embedded into the app. This was causing bugs to occur on platforms with certain gecko setups, the only safe way to link is to hardcode the path to the site's gecko in a real executable (it must be there before main() gets run or something similar). So my next idea, was to continue building the plugin but building it as an executable, to be spawned with g_spawn_async_with_pipes and use the pipes for an ipc... and use GtkPlug/GtkSocket for the window embedding... this is kinda sour because plug/socket isnt available, everywhere, not to mention its a hell of a workaround in glade-3 for an issue in the gecko linking stratagy in general. This was the rationale of finally choosing to simply spawn devhelp as is, and leave the fancy stuff to fancy ide apps. So the question I think is: is it really worth the time, effort and extra bloat in glade3 to workaround this bug with a certain version of devhelp... or shall we just say that devhelp 0.12 and glade3 3.0 will be "current software" come the next gnome release in september ? (meaning the bug will just obsolete itself)
maybe a simple main() program that forwards command line options to devhelp, and that program is just a dependancy hack to depend on devhelp 0.12 ?
I guess this bug can be closed.
Good call, this one is history.