After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344043 - Bug with DevHelp 0.11 installed
Bug with DevHelp 0.11 installed
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-06-06 17:53 UTC by Tristan Van Berkom
Modified: 2007-12-04 19:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tristan Van Berkom 2006-06-06 17:53:53 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.
Comment 1 Tristan Van Berkom 2006-06-06 17:57:08 UTC
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.
Comment 2 Vincent Geddes 2006-07-12 22:21:11 UTC
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
Comment 3 Tristan Van Berkom 2006-07-13 03:15:32 UTC
   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.
Comment 4 Vincent Geddes 2006-07-13 17:55:45 UTC
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?
Comment 5 Vincent Geddes 2006-07-15 15:50:15 UTC
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
Comment 6 Tristan Van Berkom 2006-07-15 17:03:15 UTC
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)
Comment 7 Tristan Van Berkom 2006-07-20 04:13:11 UTC
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 ?
Comment 8 Ivan Baldo 2007-12-04 15:43:17 UTC
I guess this bug can be closed.
Comment 9 Tristan Van Berkom 2007-12-04 19:50:16 UTC
Good call, this one is history.