Created attachment 24743 [details] [review]
Patch to allow Help Button to work

The patch is small, but I haven't tested it for bad interactions with
other code (argument parsing or finding program directories are two
things that need to be verified to work correctly.)

The patch touches src/Makefile.am so you'd need to run the auto* tools
again afterwards.

There may also be a better way to do this than the make defines I
create in src/Makefile.am.  Since there already were path related
define's there, it seemed to fit but it could probably go in configure
instead (Not sure about that.  Just an idea if you don't like the way
the patch works.)

The call to gnome_program_init should be happening in src/cong-app.c
(function cong_app_new) rather than in main

Please can you rework your patch accordingly.  

I tried to do this, but it didn't work for me - help files are in
/usr/local/share/conglomerate/doc/C, but I get the error message:
WARNING **: Unable to find the help files in either
/usr/local/share/conglomerate/gnome/help/conglomerate/ or
/usr/share/gnome/help/.  Please check your installation

From bugreport 128544:

I think got lost on the DATADIR to PKGDATADIR switch. ( bug 121676 )

*** Bug 128544 has been marked as a duplicate of this bug. ***

Hmmm... Trying to rework my patch into cong-app.c in the cvs version
instead of 0.7.11 and I'm having a bunch of problems.  It may take me
a couple days to figure out why I was able to get the original working
but not this combination of things.

Okay.  I have had no luck getting my patch workable in cong-app.c  But
I've been looking around the libgnome documentation and I think that
I've spotted a basic misunderstanding.  I think that
GNOME_PARAM_APP_DATADIR takes a directory that's the top level of a
hierarchy that mirrors GNOME_PARAM_GNOME_DATADIR.  So it should be
assigned to DATADIR (as in /usr/share or /usr/local/share), not
PKGDATADIR.  Your code can then create a subdirectory under DATADIR
(pkgdatadir) and place the files you want in there.

I've looked over bug #121676 and think that the patch that went in
there is wrong WRT this premise.  It should be reverted except for this:
--- conglomerate-0.7.4.orig/pixmaps/Makefile.am
+++ conglomerate-0.7.4/pixmaps/Makefile.am
@@ -1,11 +1,9 @@
+## desk top icon
 dtidir = $(datadir)/pixmaps
 dti_DATA = conglomerate-icon-16.png
 
-##appiconsdir = $(pkgdatadir)/icons
-##appiconsdir = $(datadir)/conglomerate/icons
-## this is work in progress by GSt
 # application icons
-appiconsdir = $(datadir)/pixmaps
+appiconsdir = $(datadir)/conglomerate/pixmaps
 appicons_DATA = \
 	cong-docbook-set-16.png \
 	cong-docbook-book-16.png \

Please note that all Makefile.am entries in that patch should work as
either $(datadir)/conglomerate or $(pkgdatadir) -- I lean towards
$(datadir)/coglomerate as it is one less variable to depend on being
defined right.

I can work up a patch based on this instead of my earlier attempt but
I'd like someone to confirm that my core premise is correct (and clue
me in if there's going to be other possible breakage).  I read the
libgnome::gnome-program section and browsed some other projects on
cvs.gnome.org to come to this conclusion.

I have seen the update.

Went ahead and started patching the code to work with DATADIR instead
of PKGDATADIR again.  I have something that works with everything
except pixmaps.  I'll upload it as a "what I have so far patch."

My problem with pixmaps is this:  I think the non-desktop-icon pixmaps
belong in @DATADIR@/pixmaps/conglomerate rather than
@DATADIR/conglomerate/pixmaps.  I can implement either one (Either
gnome_file_lookup GNOME_FILE_DOMAIN_PIXMAP conglomerate/image.png or
gnome_file_lookup GNOME_FILE_DOMAIN_DATADIR
conglomerate/pixmap/image.png) so in a way it's a value judgement.  My
research into it is:
1) on my Fedora Core system, 5 gnome programs place files into
/usr/share/<APP>/pixmaps while 19 (merging all gnome-games into one
package) place them in /usr/share/pixmaps/<APP>.
2) GNOME_FILE_DOMAIN_PIXMAP points to DATADIR/pixmaps for a reason.

Anyhow, I'm going to start work on making things work that way and
then submit a new in toto patch unless someone shouts please implement
it the other way 'round.

Created attachment 25070 [details] [review]
Patch changing PKGDATADIR references to DATADIR (pixmaps need fixing in addition to this.)

Seen the patch.
However, I have other ideas about fixing this problem.
I have scheduled some time for it on thursday march 4.

Created attachment 25106 [details] [review]
Complete pkgdatadir->datadir patch

Great!  I'll cvs update sometime next week and try it out. 

(Finished my patch up last night so I uploaded it just for completeness.)

Created bug 136178 for the DATADIR/conglomerate/pixmaps/ or
DATADIR/pixmaps/conglomerate/ question.

from /usr/include/libgnome-2.0/libgnome/gnome-program.h
comes this:
/* If you have your auto* define PREFIX, SYSCONFDIR, DATADIR and LIBDIR,
 * Use this macro in your init code. */
#define GNOME_PROGRAM_STANDARD_PROPERTIES \
        GNOME_PARAM_APP_PREFIX, PREFIX,         \
        GNOME_PARAM_APP_SYSCONFDIR, SYSCONFDIR, \
        GNOME_PARAM_APP_DATADIR, DATADIR,       \
        GNOME_PARAM_APP_LIBDIR, LIBDIR
 
now I understand why reverting the PKGDATA change.

However the problem is missing help.
Next step the line
        gnome_help_display("conglomerate.xml", NULL, &error);
from cong-menus.c

Don't know how much you've already sunk your hands into the code, but
the answer to missing help files is obtainable via strace.

gnome_file_locate and gnome_help_display check two directories for
their files.  The values in GNOME_FILE_DOMAIN_*
GNOME_FILE_DOMAIN_APP_*.  I think that GNOME_FILE_DOMAIN_* is set in
the gnome library files to point to the gnome installation so there's
no changing it.  GNOME_FILE_DOMAIN_APP_* is derived from
GNOME_PARAM_APP_DATADIR.

When GNOME_PARAM_DATADIR is set to @DATADIR@/conglomerate (aka
PKGDATADIR) the gnome library decides to search for the app specific
files in the path DATADIR/conglomerate/gnome/help/conglomerate/.  This
is the wrong place for help files to be.  They should be in (and
conglomerate installs them to) DATADIR/gnome/help/conglomerate.

Setting GNOME_PARAM_APP_DATADIR = DATADIR makes the library search the
correct directory.  I used the gnome standard macro
GNOME_PROGRAM_STANDARD_PROPERTIES to achieve this.  In setting
GNOME_PARAM_APP_DATADIR correctly, I had to revert the
PKGDATADIR=>DATADIR changes.

As I found, there are a few programs which put pixmaps into
DATADIR/PROGRAM/pixmaps, but by and large they seem to go into
DATADIR/pixmaps/PROGRAM.  This follows logically from the setting of
GNOME_FILE_DOMAIN_APP_PIXMAPS so it makes sense in two different ways.
 Not hard to change, if you're attached to DATADIR/PROGRAM/PIXMAPS,
though.  Instead of using gnome_locate_file with
FILE_DOMAIN_APP_PIXMAPS, use FILE_DOMAIN_APP_DATADIR.  I think it's
non-standard, but there are some other programs doing that.  [As
opposed to none for locating help in a non-standard place.]

PS -- strace also told me that gnome_help_display tries to use its
first argument as a directory even though the libgnome documentation
says 'filename'.  It's able to cope because it strips the extension
off the argument and tries again after it fails to find a directory
named conglomerate.xml.  It's more efficient to use 'conglomerate'
rather than 'conglomerate.xml' but I'm not sure if it's a programming
or documentation bug. (Posted to libgnome bugzilla as Bug #136242)

Created attachment 25210 [details] [review]
only changes in src directory version of the patch

I still don't know how the gnome_help_display functions works,
but it works with the patch that is based on Toshio Kuramoti's work.