Re: [Gnash-dev] multiple GUIs

[Rob Savoye]

strk wrote:

> Agreed, --gui=<gui> --renderer=<renderer> --sound-handler=<sound> would
> be the cleanest way to this, and yes, we do need better interfaces too.

  Actually after the next release I was considering loading things using
an optional shared library interface. But adding multiple GUIs will
bloat out the executable. For an embedded target, you'd want only just
one, the FB gui and AGG. But I think we're taking this too far. I'd
actually like to drop the use of SDL, so for the desktop, we should
support either GTK or QT/KDE. For an embedded target, we'd support FB or
maybe FLTK, which I prefer to SDL. SDL has zero support for menus, and
it's event handling sucks performance wise.

  I also dislike having multiple names for the executable, as it'll make
life difficult. For one thing any time the executable is referred to,
like say from a GNOME menu item, the executable it'll have to refer to
won't be consistent. Most people other than Gnash developers will run
Gnash as a plugin, or via a desktop action, and never even know what the
executable is called.

  I'd rather see a single executable that would have two behaviors. The
default is to use the configured choices as the default --enable-gui),
and to build the others if the development packages are installed. Maybe
we allow --enable-gui to be overloaded like --enable-gui=gtk,sdl. It
should be possible to have the gnash executable look at argv[0] to see
how it was invoked, so the other optional names would be just symbolic
links.

>> MG>   Maybe it is too late to kill off the name "klash" but mapping it
>> MG> internally into "gnash --gui=kde" by inspecting argv[0] or by the fact
>> MG> that the klash executable is built with a single gui is ok though.

  The "klash" package depends on the kde_parts to run Gnash. It's that
code that calls the executable, so if the name of the executable is
changed, the package name wouldn't unless we plan to build the Konqueror
 plugin and the GTK plugin as part of the same "Gnash" package.

  Looking at from the perspective of a package maintainer for a
distribution, they'll want to build Gnash just once to get a plugin and
executable that'll support both GNOME and KDE (the behavior of the last
release). That's how most people will be running Gnash in the future,
it'll be part of their distribution. At that point the "klash" package
can die, and just be Gnash with KDE support.

        - rob -