Created attachment 26653 [details] [review]
fix for bug #140035

ok to commit ?

I'm not sure it's a good idea to hardcode the datadir and friends to the
directories used by pygtk. Say that you'd like to have your program installed in
a different prefix from pygtk? Or if the end user wants to change it.

well, its not hardcoded, they are picked up from the $(datadir) etc. Also -
these are where Gnome expects files to be found so shouldn't that be part of the
gnome install ?

The bug observed in pygtk that i also encountered:
http://www.mail-archive.com/pygtk@daa.com.au/msg05827.html

The bug i got the fix from: 
http://mail.gnome.org/archives/desktop-devel-list/2003-January/msg00265.html

and the response i got from mark mcloughlin:

Hi,	
Those defines are used by GNOME_PROGRAM_STANDARD_PROPERTIES macro which you can
use with gnome_program_init. So, if the Mono/Python bindings call
gnome_program_init they shoulddefine those pre-processor defines and use the
macro withgnome_program_init().

There are many gnome_program_init() properties to specify datadir, libdir, etc.
 The real problem is that gnome.init() does not handle properties yet.

OK, so we're not going to have generic property support in gnome.init any time
soon, due to problems in the C API.
In the mean time, we should support at least a specific list of properties.  I'm
thinking about adding support for an additional optional argument containing a
dictionary of properties.  Example:
gnome.init("foo", "bar", sys.argv, properties={ 'prefix': '/opt', 'gnome-path':
'/opt:/usr' })

  Unfortunately, each of those properties have to be supported specifically in
the code, and we need to come up with sane defaults for all of them.  For that
reason, we should not support properties that can be specified from the command
line, such as "enable-sound" vs --enable-sound, otherwise we risk that our
default will override the command-line option.

  I'll get to work on this next saturday, if no one beast me to it.

If all we care about are string arguments, I had an idea about how this could be
done.

gnome_program_init() is a vararg function, and stops processing its arguments
when it hits a NULL argument that should represent a property name.  There is
nothing to stop us passing it more arguments.  Here is some pseudo code that
might help:

char *propnames[] = { "prefix", "gnome-path", ...}
char* propargs[20] = { NULL, }; /* length >= len(propnames)*2 + 1 */
int index = 0;

for (i = 0; i < G_N_ELEMENTS(propnames); i++) {
  if (PyDict_HasAttrString(kwargs, propnames[i])) {
    propargs[index++] = propnames[i];
    propargs[index++] = PyString_AsString(PyDict_GetAttrString(kwargs,
                                                               propnames[i]));
  }
}
...
gnome_program_init(..., propargs[0], propargs[1], ..., propargs[19]);

This gives a level of type safety, since it would only support certain known
property names, and should hopefully be enough.

I still hate GnomeProgram though ...

Funny that I was talking to kiko today (in real life!) and he suggested the
exact same thing.
To decided whether or not supporting only string properties, here is the full
list that GnomeProgram currently supports:

popt-table: pointer (construct)
popt-flags: int (construct)
popt-context: pointer (read)
human-readable-name: string (construct, read)
gnome-path: string (construct, read)
app-id: string (read)
app-version: string (read)
gnome-prefix: string (construct, read)
gnome-libdir: string (construct, read)
gnome-datadir: string (construct, read)
gnome-sysconfdir: string (construct, read)
app-prefix: string (write, read)
app-libdir: string (write, read)
app-datadir: string (write, read)
app-sysconfdir: string (write, read)
create-directories: boolean (construct, read)
enable-sound: boolean (construct, read)
espeaker: string (construct, read)

The popt-arguments alread have custom support.  That leaves us with string and
boolean arguments.  But I have some doubts on the usefulness of the boolean
arguments, so I'm planning on following James' (and kiko's) strategy and support
only the string properties.  Support for boolean properties can be added at a
later stage if anyone cares.

BTW, according to Havoc's plan, libgnome* should become deprecated in gnome 2.8
and disappear in gnome 2.10.

The boolean and int arguments would be difficult.  gboolean is a synonym for
"int", which is not necessarily the same size as a pointer (it won't be on any
LP64 platforms such as IA64 or x86-64, for instance).

Passing a popt table should be doable though since a (char *) pointer is going
to be the same size as any other pointer, so it could be handled like this
pretty easily.

I don't think libgnome will be going away any time soon, unfortunately. 
Remember that libbonoboui depends on it.  I think the plan was to make
libgnomeui obsolete though.

Fixed in HEAD, using James' (and Kiko's) suggestion.