Age | Commit message (Collapse) | Author | Files | Lines |
|
When it's built with gtk3, firefox plugin-container will use some
LD_PRELOAD hack in order to be able to load the gtk2 flash plugin.
However, this LD_PRELOAD'ed .so will cause gtk3 remote-viewer to crash
when it's started by spice-xpi
This commit just cleans up the unwanted LD_PRELOAD variable from the
environment before starting remote-viewer.
|
|
Do not try again if the unix socket is already connected, but fail
immediately.
https://bugzilla.redhat.com/show_bug.cgi?id=1073461
|
|
Currently, with 10 tries, it takes up to n(n+1)/2 = 55s before
returning failure.
The default firefox plugin timeout is 45s, passed that time, the plugin
is killed. 10s should be enough in normal usage for the client to setup
the unix socket.
https://bugzilla.redhat.com/show_bug.cgi?id=1073461
|
|
The Debian package of spice-xpi failed to build on powerpc and sparc in
Debian, failing with this error message:
make[6]: Entering directory `/«PKGBUILDDIR»/SpiceXPI/src/plugin'
CXX libnsISpicec_la-controller.lo
controller.cpp: In destructor 'SpiceController::~SpiceController()':
controller.cpp:73:5: error: format not a string literal and no format
arguments [-Werror=format-security]
cc1plus: some warnings being treated as errors
The error is in a call to g_debug(G_STRFUNC). As this is a constant string,
we can just replace the call with g_debug("%s", G_STRFUNC).
|
|
|
|
|
|
|
|
|
|
|
|
Generator::generateConnectVars() output
|
|
|
|
Python is needed to generate nsISpicec.h and nsISpicec.xpt from
nsISpicec.idl.
|
|
The nsISpicec -> npSpiceConsole rename was not propagated there.
|
|
The plugin binary name was changed from libnsISpice to npSpiceConsole,
but the Makefile.am rule optionnally building SpiceXpi.xpi was not
changed to take this rename into account.
|
|
As it's not very convenient to get logging output from the plugin
while firefox is running, this commit adds a dumb glib logging
implementation that writes the logging information to a file.
As this is not efficient at all, it's disabled by default unless
the SPICE_XPI_LOG_TO_FILE environment variable is set.
|
|
This class implements the controller interface for Windows/mingw.
|
|
NPAPI plugins only need to have 3 symbols exported, make that
explicit. This is also required when building Windows plugins
as these symbols *must* be explicitly exported.
|
|
Windows Firefox expects the plugin filename to start with 'np'
otherwise it won't pick it up as a plugin.
|
|
Based on a patch from Nerijus Baliunas <nerijus@users.sourceforge.net>
|
|
It contains all the generic code, then platform-specific controller
implementations will inherit from it and overload the non-generic parts
abstract methods.
|
|
g_usleep is more portable than sleep()
|
|
The SPICE client paths will be different on Windows and Unix so add
a helper function returning the paths to use to spawn the clients.
|
|
Communication with the client is done differently on Windows and
Linux (named pipe VS unix socket), so move this platform-specific
setup to a distinct method.
|
|
This removes quite a lot of OS-specific code.
|
|
This is platform specific, and is related to starting the
receiver of controller messages, so let's move it with the rest
of the platform-specific code.
|
|
It's only used internally, external code calls Connect(int retries)
|
|
|
|
|
|
It mostly contain low-level controller/plugin communication code,
and this is mainly non-portable code, let's rename this file to
make this explicit. We will then add a controller.cpp file
containing the generic code, and a controller-win.cpp file
with the Windows specific code.
|
|
This has the big advantage of being portable, in addition to removing
some code. Big disadvantage is that this adds a dependency on gio.
|
|
This makes it more readable, and moves OS-specific code to separate
functions.
|
|
Now that we switched to using the headers from npapi-sdk to build
the spice-xpi plugin, the only reason we are depending on xulrunner
is to build an xpi package for the plugin for easier installation
in firefox. However, this .xpi is not installed by default nor
packaged by distributions, so it's not in wide use.
This commit makes its build optional as this has the side-effect
on making the xulrunner dependency optional as well, which is a
good thing as xulrunner is huge and not necessarily available
on all platforms we'd like to build spice-xpi on.
|
|
The main reason for us depending on xulrunner/libxul is to get
the 4 headers defining NPAPI. Standalone headers are maintained
at http://code.google.com/p/npapi-sdk/ , using them allows to drop
a huge dependency on firefox code. This will make it easier to
build spice-xpi on other platforms.
|
|
The xpidl binary is no longer available in xulrunner 10, so we no longer
need the Makefile magic using xpidl now that we require it. We'll always
directly use header.py/typelib.py instead.
|
|
Even RHEL5 has at least xulrunner 10 these days, so no need to keep that
compat code around.
|
|
AC_ARG_ENABLE 3rd argument is what to do when the argument is
specified and the 4th arg is what to do when the argument is
not specified. Using [enable_generator=true] as the 3rd argument
is wrong as this would enable the generator when using
--disable-generator.
|
|
Nothing sets $red_target anymore
|
|
The only thing from nspr we use are typedef for bool, int32_t and
definitions of TRUE/FALSE. Any decent C/C++ compiler should provide
all of these. If this proves to be an issue, the NPAPI headers
we use to build the plugin have a nptypes.h header with the needed
defines for bool/true/false and int32_t.
|
|
They were hardcoded in CPPFLAGS in Makefile.am, having them in
configure.ac makes things more obvious and more flexible.
|
|
They are only used on non-Unix platforms, and we are only building
the plugin for Unix at the moment. As we are trying to remove
our dependencies on xulrunner, let's just remove these.
|
|
We are not dlopening anything.
|
|
|
|
We include some files from the XUL SDK which gives the impression
that we are depending on some features from them, however they are
actually not used at all, so let's remove them.
|
|
|
|
Set SPICE_PROXY environment variable accordingly.
|
|
Quoting GLib:
Environment variable handling in UNIX is not thread-safe, and your
program may crash if one thread calls g_setenv() while another thread
is calling getenv(). (And note that many functions, such as gettext(),
call getenv() internally.) This function is only safe to use at the
very start of your program, before creating any other threads (or
creating objects that create worker threads of their own).
If you need to set up the environment for a child process, you can use
g_get_environ() to get an environment array, modify that with
g_environ_setenv() and g_environ_unsetenv(), and then pass that array
directly to execvpe(), g_spawn_async(), or the like.
|
|
|
|
|
|
|
|
|