Hello Martin,
Monday, November 27, 2006, 2:08:59 PM, you wrote:
Flash developers actually *concerned* because of Gnash. They fear
having different players will make development more difficult. With a
single Flash player one can be sure that a movie works everywhere.
MG Right, so following
On Wed, Nov 29, 2006 at 02:20:24PM +0100, Udo Giacomozzi wrote:
Flash _invites_ the developer to create sophisticated animations. No
Flash developer has to think about will it work on this or that
player. He thinks does the specification allow me to do
I think this is exactly where we
Hello strk,
Wednesday, November 29, 2006, 3:46:43 PM, you wrote:
s One of our goal should be providing
s a *free* and *high quality* specification for Flash applications.
Agree, although this in my opinion still means that Adobe dictates the
specification.
s That should be aimed at becoming
Udo Giacomozzi wrote:
Agree, although this in my opinion still means that Adobe dictates the
specification.
We'll be following Adobe's spec, but we'll be developing our own
documentation about the spec, including the differences between subtle
implementation issues. There are actually quite
On Tue, Nov 28, 2006 at 09:41:32AM -0700, Rob Savoye wrote:
Martin Guy wrote:
2006/11/27, Rob Savoye [EMAIL PROTECTED]:
linked in at compile time vs what gets loaded dynamically. Loading a
plugin is pretty fast though, as all I do is find the *_class_init
function and call it.
Indeed, but
Martin Guy wrote:
2006/11/27, Rob Savoye [EMAIL PROTECTED]:
Lovely idea. I am only worried about slower startup or lumpy playback.
It's a situation analogous to static linking vs shared library loading, and
a quick test between bash and bash-static shows bash, which only has 4
Since the
Hello John,
Monday, November 27, 2006, 12:53:40 PM, you wrote:
JG To avoid a lot of startup overhead on every gnash startup, I suggest
JG only looking for these extensions if or when someone invokes a class
JG that isn't already defined. I.e. turn an error into a look for
JG extensions.
What
John Gilmore wrote:
To avoid a lot of startup overhead on every gnash startup, I suggest
only looking for these extensions if or when someone invokes a class
that isn't already defined. I.e. turn an error into a look for
extensions.
That's the plan. Currently I scan the directory for just
Hello Rob,
Monday, November 27, 2006, 4:10:38 PM, you wrote:
RS Personally, any flash developer scared of Gnash should just ignore us,
RS and live in their tightly closed world. I've read some of same blogs,
RS and if this attitude prevailed, we wouldn't have projects like Firefox,
RS
On Thu, Nov 23, 2006 at 10:55:06AM -0700, Rob Savoye wrote:
Right now I install a Gnash extension in $prefix/lib/gnash/plugins, and
Not related to your issue, but I think it would be better in
$libdir/gnash/plugins
such that gnash is still multilib.
--
Pat
On Sat, Nov 25, 2006 at 08:28:23AM -0700, Rob Savoye wrote:
Patrice Dumas wrote:
On Thu, Nov 23, 2006 at 10:55:06AM -0700, Rob Savoye wrote:
Not related to your issue, but I think it would be better in
$libdir/gnash/plugins such that gnash is still multilib.
You're probably right.
Patrice Dumas wrote:
On Sat, Nov 25, 2006 at 08:28:23AM -0700, Rob Savoye wrote:
Also it may be more convenient to define that directory in configure.ac
if it's going to be used in many Makefile.am (and maybe later a --with
could be added).
You're right again. :-) I mostly checked this
I've just gotten an extension mechanism for Gnash working, where any
ActionScript class can be a plugin that gets dynamically loaded. This
can also be used to create your own custom ActionScript classes. My
current test class is a DejaGnu one, so it'll be possible to have
testing support built in.
Rob Savoye wrote:
I optionally use GNASH_PLUGINS to set the path, so for debugging, this
could manually be set, but would only get one plugin directory at a time.
Since lists.gnu.org has been down a few days, I figured this out
already. It turns out you can specify a colon separated list of
14 matches
Mail list logo
