Ticket #9344 (confirmed enhancement)

Opened 4 years ago

Last modified 20 months ago

Cross-platform Flash control

Reported by: pmineault Owned by:
Priority: normal Milestone:
Component: GUI-all Version:
Keywords: Cc: pmineault, kollivier, yaou.li@…
Blocked By: Patch: no
Blocking:

Description

The ActiveX Flash control is quite cool, however it
would be nice if there was a cross-platform Flash
control available for wxPython. I understand that this
is quite the request, however there have been some
research done on the subject that shows this is not
entirely impossible. The major challenge is to find a
replacement for an ActiveX control on Mac and Linux.
The Flash plugin on Mac and Linux is based on the
Netscape API and can be loaded using a XUL module, as
far as I know. There is some info on how this can be
done here:

 http://www.darronschall.com/weblog/archives/000108.cfm

Now I don't think it's reasonable to actually embed XUL
in wxPython, however perhaps one could extract the
plugin module of the wxMozilla project. This would not
only Flash to be embedded cross-platform, but all of
the other various plugins that are available on a bunch
of platforms, for example Acrobat and Quicktime. As far
as scripting the Flash control, the current ActiveX
control does not take advantage of the most recent
possibilities in Flash control scripting, called
ExternelInterface. Basically it's a means to
transparently send/receive Flash/LanguageX variables
while maintaining typing. This is done by wrapping
requests in an XML string containing type information.
More info is available here:

 http://osflash.org/pipermail/osflash_osflash.org/2005-August/002274.html

I definitely think this would make wxPython the
platform of choice for Flash developers looking to make
offline applications.

Change History

Changed 4 years ago by kollivier

Hi,

XUL is an XML language for specifying user interfaces, so unfortunately it will
not do anything to help provide a 'bridge' between Flash and wxWidgets. ;-/

To do what you propose, two things are needed:

1) Implementation of the Netscape Plugin API. Apparently a preliminary
implementation exists in <wxSrc>/utils/nplugin, but last I checked I don't
think it even built.

2) A way to discover and use the Flash plugin on various platforms.

This is actually on my long-term TODO list. It may be some time before it's
implemented though, particularly as Flash allows you to create full-flegded
applications on Mac and Windows. You'd only want to use wxWidgets if you
want completely native interfaces, and if you want completely native
interfaces, why are you using Flash (which has its own cross-platform UI
components)?

Regards,

Kevin

Changed 4 years ago by pmineault

Sorry if I wasn't clear on XUL. What I meant is that XUL
implements an html:embed tag, and thus that means that the
NSPlugin architecture is supported by XUL and its embedded
Gecko engine. All it means is that there is an NSPlugin
implementation in wxMozilla, which is, I believe, half the
battle.

Now as for Flash allowing you to create full-feldged
cross-platform applications, that's quite a bit of an
overstatement. What the Flash IDE offers as far as
executable wrapping is basically an executable version of
the plugin/ActiveX control with an appended swf file, which
is set to run automatically. These executable wrappers run
the swf files exactly as they would in a browser, meaning
they run in a sandbox, and therefore they can't do stuff
standard desktop applications can, for example, save and
read files, connect to a database, encode jpgs, have a
custom status bar and menus, etc.

To be able to create apps that have access to these
functions with Flash, you need an external projector
application, like MDM Zinc or Screenweaver. Many of these
are one-platform only. A few of these tools have APIs for
Mac, but support for Mac is generally not as good as for PC
(for example, Zinc has 300 Windows commands but only about
100 for Mac). These projector applications work by entering
special commands in the ActionScript of a Flash file. Once
the swf file is compiled, you then run the swf through the
projector wrapper and it detects these special calls and
routes it to its internal execution routine. In the case of
Zinc, it adds a global object called _global.mdm, with
functions such as prompt, loadfromfile, and the like.

Now this doesn't make Flash into a full-fledged desktop
application language. For example, database support is
sketchy; debugging these apps is a major pain; and more
advanced functions are a no-go. Last year I worked on a
kiosk application which had a connected magentic card
reader. None of these projector wrappers have support for
reading input from such a device. However, the manufacturer
has Python bindings for the device. What we had to do in the
end to communicate between the card reader and the Flash
user interface is create a Python app which connected to the
card reader and opened a socket, sending strings whenever it
encountered a signal. Flash then connected to it using the
XMLSocket object. As you can see, it's a bit of an
over-the-top solution for a fairly simple problem.

A lot of apps these days are really thin wrappers on an HTML
browser; for example, the Windows CHM help system, the new
Napster, etc. The advantage is that HTML content is easy to
create compared to desktop app controls, so to present
content, it is an attractive solution. In the same manner,
Flash is good to create 'flashy' interfaces, play sound,
video in a cross-platform environment, run simple games,
create drag-and-drop functionality, and a bunch of other
things. However, its cross-platform UI components are good,
but they are not native-looking, they are slow as hell, they
don't support the right-button, they are non-standard, etc.
etc. However Flash is really good for creating custom
interfaces, for example the kiosk application I talked about
earlier had a pretty cool interface that would have been
impossible to make in anything but Flash or DirectX or OpenGL.

So really, I can see Python, wxPython, and Flash as
complementary components that would allow really cool apps.
Python for a robust cross-platform scripting language,
wxPython for cross-platform UI interfaces, and Flash for
cross-platform multimedia.

Changed 4 years ago by kollivier

As for wxMozilla, yes, you can use Flash in Mozilla just as you can from wxIE
and wxWebKit (on Mac). (XUL's html:embed basically = <embed>) If that's all
you need, then you're in good shape.

Otherwise, we're back to implementing Netscape plugins, which just needs
someone to do it. :-) (I'll have to sooner or later, but probably closer to later at
this point.)

Changed 4 years ago by vadz

As much as I dislike the (over)use of Flash in the web
pages, I have to agree that it would be great to be able to
embed SWF animations in wx applications portably. I don't
think using XUL is necessarily the best way to do it though,
maybe we could find a way to render SWF directly instead.
Also, maybe using SVG could be an alternative, although it
would be for pure animation and not a substitute for "Flash
programming", of course.

In any case, once again, I think it would be nice to have
some way to show Flash-like animations in wx applications
portably, but this is a complicated task and we'd probably
need outside help with this.

Changed 2 years ago by vadz

  • cc vadz removed
  • priority changed from high to normal
  • status changed from new to confirmed
  • component set to GUI-all

Changed 21 months ago by yaou

  • cc yaou.li@… added

hi,

I have the same situation here. I see a nplugin folder in wx_2.8's source while it is removed in the trunk.
Is that mean the work of NPAPI implementation is abandoned or there is another alternative way for current ticket?

Regards,

Yaou

Changed 20 months ago by vadz

Actually the current wxActiveXContainer seems to support the use of Flash just fine, see r58114 for a working example of embedding Flash in wxWidgets under Windows only which allows you to exchange data between the application and Flash and be notified about Flash events in C++ code.

Now "just" the NPAPI part remains to be done to make this work under the other platforms. Unfortunately I don't have plans to do it any time soon but I'd still welcome any outside contributions.

Note: See TracTickets for help on using tickets.