Preprocessor directives and gettext - patch for pidgin-mtn/pidgin/gtkmain.c

[Etan Reisner]

On Thu, Sep 20, 2007 at 07:37:36AM -0600, David Mohr wrote:
> On 9/20/07, Etan Reisner <pidgin at unreliablesource.net> wrote:
<snip>
> > The reason the --display line was added to pidgin at all is because pidgin
> > currently bails out if it encounters any arguments that it does not
> > recognize. As such an explicit ignoring of --display was necessary to
> > allow it to be passed to the gtk_init_check call that happens later (which
> > handles actually using the argument and its value). We used to parse
> > pidgin options after giving argv to gtk_init_check but that broke setting
> > certain options that needed to be set before GTK+ initializes.
>
> Hm, makes sense. So then using the g_context_* functions to parse
> command line options would not help either, because AFAIK that also
> initializes gtk.

Assuming you mean the g_option_context_* functions, they aren't an option
at all because they are much too new. The oldest parts appear to have been
added in GTK+ 2.6, with many parts not having been added until 2.12 (and
even 2.14 for some). To use them pidgin would need to include wholesale
the .c and .h files for them because pidgin attempts to build and work
with GTK+ versions all the way back to 2.0.

> > X applications have always used -display (and -longoption in general), try
> > running 'xterm --display :0.1' versus 'xterm -display :0.1' and you'll see
> > what I mean. Also try 'xterm -help'. The same goes for all the older X
> > apps, but apparently not for the new ones.
>
> Ah, I see. Well I think the new --longoption syntax comes from the GNU
> people, who standardized on -'one letter options' and --longoption .

I fully understand why new applications use the -shortoption and
--longoption syntax, I just happen to think using the --longoption syntax
for things like -display which have (as far as I've ever known) been the X
standard is unfortunate.

> > > > Doing this correctly just requires two passes at the argument list once
> > > > before we initialize GTK+ and once afterwards (assuming we want to keep
> > > > the die-on-unrecognized-options behaviour we have now). If we don't mind
> > > > just ignoring unknown options it becomes easier, we just set opterr to 0
> > > > instead of 1.
> > >
> > > Glib has functions to completely handle the command line parsing. If
> > > that was used, then it would be handled in one shot, because that
> > > function also initializes gtk.
> >
> > We use gtk_init_check we don't use its ability to handle a set of
> > arguments because starting pidgin dies before we get there, like I said
> > before this is the entire reason the --display stuff under discussion was
> > just added to pidgin recently.
>
> I know, I was the one to submit the patch.

To clarify, we do use the GTK+ ability to handle arguments, we just don't
ever let it see any arguments that we don't explicitely list ourselves as
supporting, which is why your --display hack was needed.

Thinking about this again, if we simply set opterr to 0 (so getopt stops
bailing on unknown arguments for us) and then check to see if anything is
left in argv/argc after we call gtk_init_check I *think* we can only parse
arguments once ourselves, let GTK+ options propagate to GTK+, and keep our
current die-on-unrecognized-arguments behaviour. That is of course
assuming that both getopt and GTK+ remove arguments that they have
handled, which I know is the case for GTK+ but I am unsure about for
getopt.

> ~David

	-Etan