Preprocessor directives and gettext - patch for pidgin-mtn/pidgin/gtkmain.c
damailings at mcbf.net
Thu Sep 20 09:37:36 EDT 2007
On 9/20/07, Etan Reisner <pidgin at unreliablesource.net> wrote:
> On Wed, Sep 19, 2007 at 10:18:21PM -0600, David Mohr wrote:
> > On 9/19/07, Etan Reisner <pidgin at unreliablesource.net> wrote:
> > > On Wed, Sep 19, 2007 at 08:18:24PM -0600, David Mohr wrote:
> > > > A simpler workaround would be to just use
> > > > " --display=DISPLAY X display to use (Unix only)\n",
> > > > and have it be displayed under Windows as well. Then it could be
> > > > translated as one string again.
> > > >
> > > > ~David
> > >
> > > And an even better solution would be to not have to have pidgin simply
> > > ignore the --display option. Is --display even the right syntax for GTK+?
> > > Have they fallen that far from the X 'standards'? (Given a quick test with
> > > gtk-demo it would seem that it is.)
> > What do you mean by not ignoring it? Under Linux gtk handles it, and
> > is there even a similar way of specifying displays under Windows?
> > --display is the correct syntax these days. Can I ask what it used to be?
> 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
> 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 .
> > > 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.
More information about the Devel