Re: GdkLibrary

Sven Neumann <sven gimp org> writes:

> Hi,
> Owen Taylor <otaylor redhat com> writes:
> > > while you are changing this part of GDK anyway, would it hurt to to
> > > allow GDK backends to modify the argv array just like gtk_init() and
> > > gdk_init()? This would remove the need for some patching we had to do
> > > to integrate DirectFBInit (int *argc, char **argv[]).
> > > 
> > > I haven't found the time to look at the HEAD branch, but if you think
> > > this makes sense, I could try to come up with a patch soon.
> > 
> > Did you miss the _gdk_windowing_args[] functionality? The only
> > reason that wouldn't work is if the directfb support is taking
> > arguments that don't match that format of the rest of the
> > GTK+ args. (which seems like a bad idea to me.)
> I didn't miss it but I didn't want to add all DirectFB command-line
> options by hand since there are a _lot_ of them. In case you're
> interested, I'm posting the patch we use at the moment.  It adds the
> new type GDK_ARG_WINDOWING_OPTION which is detected by matching the
> start of the argument string against a backend supplied prefix. This
> works well for DirectFB since all our command-line arguments are
> prefixed with 'dfb:' but I don't consider this hack overly nice and
> would prefer if _gdk_windowing_init_check() would be able to
> manipulate its arguments just like gtk_init() and gdk_init().

I'm still missing something; _gdk_windowing_args[] is meant to
_avoid_ doing options by hand.  You mean it's harder to write

static GdkArgDesc _gdk_windowing_args[] = {
  { "dfb:foo" ,    GDK_ARG_CALLBACK, NULL, set_foo    },
  { "dfb:bar" ,    GDK_ARG_CALLBACK, NULL, set_bar    },
  { "dfb:baz" ,    GDK_ARG_CALLBACK, &baz, NULL       }

Then to write some big complex error prone switch statement
with lots of manual string manipulation?


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