Re: GTK_MODULE (G)Option breakage & init ordering ...



On 2/7/06, michael meeks <michael meeks novell com> wrote:
>
> On Tue, 2006-02-07 at 09:24 -0500, Matthias Clasen wrote:
> > >         Unfortunately - the introduction of GOption clobbered all GtkModule
> > > argument passing; and ensures that no GtkModule gets anything but a
> > > 0/NULL argc/argv cf.
> >
> > Looks like this is a bug that got introduced when we first switched to
> > GOption, and never discovered. Surprising that nobody noticed it before.
>
>         Right ;-) of course, there could be a 3rd bug somewhere that's
> revealing this suddenly.
>
> > I'll look into it, we may just have to do the argv-duping earlier.
>
>         Well - IMHO it'd be better to re-work that -slightly- to dlopen the
> gtk_modules earlier (since that has to be done anyway) and hooking some
> GOption info out of them - so they can have a crack at parsing the args
> themselves [ no idea if that'll work though ;-) perhaps a double parse
> is necessary to get the --gtk-modules= flag out first ].
>
>         That'd IMHO add a clean / generic way to allow modules to register
> arguments I suppose.
>

I'm not sure sure that thats easily possible. Currently, we are a)
delaying the dlopening of some modules until the display is opened,
and b) modules  can be specified on the command line, so it is hard to
make them contribute to the parsing of that command line...

Unfortunately, fixing the current code is not possible without an api
addition to GOption.
The reason for this is that we allow to initialize gtk by just getting
the gtk option group,
and use g_option_context_parse() yourself. And currently, there is no
way to get hold of the argument vector from the option group
callbacks. So, a fix along these lines would require
us to add another post-parse hook to GOptionGroup which would receive
the leftover arguments.

Matthias



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]