Age | Commit message (Collapse) | Author | Files | Lines |
|
Use the original URI of the file when setting a default for the saved
file. This is an improvement over using the document title or the
temporary file name from the browser. As a bonus, this avoids the
deprecated ev_backends_manager_get_document_type_info API from evince.
|
|
|
|
|
|
It was assumed that gtk was already initialized, but there's no harm in
initializing it again and avoids the deprecation warnings from
g_thread_init.
|
|
When GtkPlug is in the same process as GtkSocket, a complicated pile of
code is invoked to remove the plug from the socket when the socket is
being destroyed. This leads to the plug being in some dicey intermediate
states where it is changing back to a toplevel and critical warnings are
thrown from its contained widgets. Workaround this by just destroying
the contained widget (the viewer) as soon as the plug removal can be
detected.
|
|
Without referencing the objects, the lifetimes of the plug and viewer
were difficult to manage and the pointers could become invalid
unexpectedly.
|
|
For some reason, Epiphany (WebKitGtk) likes to send a last SetWindow
even as it's in the process of destroying the widget. Check whether the
plug is still a GtkWindow before telling it to resize to the Window
we're being told about.
|
|
Until now, the forked plug process was hanging around in the main loop
because nothing was forcing it to quit. Watch for the plug widget to be
destroyed and quit the main loop to exit.
|
|
When the socket is destroyed upon removing the plug, gtk tends to hit
some critical warnings. Instead, keep the socket from being immediately
destroyed and instead destroy it with the toplevel window.
|
|
When the Quit button was clicked, the main loop was being quit
immediately without destroying the window. This makes sure the window is
destroyed like when it's deleted so the same cleanup code is exercised.
|
|
There are a few bugs in the usage of GtkPlug that cause critical
warnings and crashes. Using our own class to override methods might give
a chance to workaround these issues.
|
|
Print the document from the toolbar or via Ctrl-p using the
ev-print-operation backend. This is different than the Print dialog from
the browser, which has a NPAPI interface to pass back a block of
PostScript. That doesn't seem to be working from firefox, but this usage
is probably what people typically want anyway (print the document rather
than just what appears on the web page).
|
|
Out-of-process GtkPlug seems to work fine, so let's reserve this hack
only for when it's needed.
|
|
GtkPlug behaves differently in each instance, so we need to keep track
of how the plugin is being run.
|
|
Quoting the BROWSER variable is nice to protect against spaces in the
filename, but it keeps multiple arguments from passing through. The
latter is more useful as it allows you to do things like
BROWSER="gdb --args epiphany" ./test/browser.sh.
|
|
This ensures that it doesn't open with the same (failed) tabs as last
time.
|
|
|
|
Prior to 3.4, evince would allocate EvTypeInfo's in
ev_backends_manager_get_all_types_info(), but now it just returns
pointers into its own table.
|
|
|
|
g_signal_connect_object has been finally fixed in recent versions of
glib, so the signal is disconnected when the object is disposed. However
we are manually disconnecting the signal handler, which gives a runtime
warning with recent glib versions because the signal has already been
disconnected. Use g_signal_connect() and keep disocnnecting the signal
manually to make sure it still works with previous versions of glib.
This is upstream evince commit 30f23d6.
|
|
GtkSocket/GtkPlug behave differently when the plug is embedded in the
same process rather than running in a separate process. It seems that
epiphany does the former while firefox does the latter and that might be
causing some of the behavioral differences.
When the previewer is run without options, the plug is embedded in the
same proceess. When executed with the -f/--fork option, the plug is run
from a separate process.
|
|
When the plug is out of process, it doesn't get appropriate allocations
from the socket. Firefox seems to handle this fine, but let's just make
use of the size information it's provided us.
|
|
The EvbpViewer widget normally works fine, and the forced resizing only
seems to be needed on Epiphany.
|
|
Epiphany seems to like to call SetWindow a lot and depends on the plugin
resizing its window appropriately. If the plug already exists, resize it
to the requested dimensions rather than just returning even if the
dimensions are the same.
|
|
|
|
|
|
Previously the GtkPlug was being implicitly destroyed when the
EvbpViewer object was destroyed. This worked fine under firefox where
the plugin code jumped through hoops to make sure the GtkPlug was
disconnected before destroying its GtkSocket, but other browsers may not
perform this trick for us.
|
|
This is our toplevel widget and we really need to keep tabs on its
interactions with the embedder.
|
|
Doing this upon opening a new document in epiphany ensures the widget is
the correct size and is scrollable.
|
|
On newer glib, G_MESSAGES_DEBUG controls which domains get their debug
messages printed. Set this in addition to the local EVBP_DEBUG setup so
that debug messages are received on older and newer glib.
|
|
Instead of hardcoding the test script to use firefox only, make it more
flexible so that other epiphany and other Mozilla browsers can be
started.
|
|
Mozilla browsers allow starting a totally separate instance when a
profile is specified and -no-remote is passed on the command line. This
allows much easier testing without killing any currently running
browsers.
|
|
Apparently NPPVpluginWantsAllNetworkStreams is always queried, so tell
the browser that we don't need all the network streams.
|
|
To load the plugin only NP_Initialize and friends are needed. After that
the NPPluginFuncs vtable is used to call into the plugin. This keeps the
symbols from the viewer widget and mime code from being visible outside
of the plugin.
|
|
Add README and AUTHORS files describing the project a bit more.
Distribute them by removing the foreign option from automake. This also
distributes the INSTALL file, but automake will give us a stock one if
none is in the directory.
|
|
Instead of always putting the plugins into ${libdir}/mozilla/plugins,
allow the directories to be specified by --with-gtk2-plugindir and
--with-gtk3-plugindir. This also changes the default for the gtk3 plugin
to ${libdir}/epiphany/plugins until the mozilla based browsers can
support gtk3 plugins.
|
|
If Epiphany is installed it's likely people would want to use the plugin
with it. Turn on the gtk3 build in that case. This can still be
configured explicitly with --enable/disable-gtk3.
|
|
To make things more useful for GNOME/epiphany, which is squarely in gtk3
land, allow building both the gtk2 and gtk3 versions of the plugin. I'm
not sure what will happen when both plugin's are in the browser's path.
A subsequent patch will allow finer grained control of the installation
directory.
|
|
This plugs a big hole in the previewer test app where the widget was
used differently than in the browser. Now they both get instantiated
through GtkSocket/GtkPlug.
|
|
|
|
|
|
The current not ideal situation for NPAPI plugins is that only gtk2 is
supported on mozilla browsers and only gtk3 is supported on epiphany.
Thus, a choice needs to be made whether to link in one gtk version or
the other depending on the intended usage.
The viewer code is entirely compatible with gtk3 and evince3, but
GtkPlug needs a little adjustment. However, the plugin immediately
crashes on firefox since it's still running gtk2 and our plugin is in
the same address space. To use gtk3 unconditionally we'll either need to
run the plugin in a separate process like totem or just wait patiently
for gtk3 to be supported by firefox. I choose the latter for now and
default to gtk2 since firefox is by far the more popular browser.
|
|
This is a little more in line with other NPAPI plugins and more
descriptive than libevbp.
|
|
Rather than build all the EvbpViewer sources twice, make a convience
library for the tests to link to. This does add the unfortunate effect
of relinking libevbp-viewer.la and libevbp.la every time there's a
change in the source, though.
|
|
When we try to construct the filename from the document title, use the
mime type mappings to get a suffix.
|
|
|
|
There are many, many features available in Evince that I have no
intention of supporting here. The purpose of this plugin is to display
documents simply in the browser. Add a button to launch the current file
in the full Evince viewer.
|
|
Allow the user to save a copy of the current document. The initial
directory is the XDG Downloads directory. The initial filename is the
document title since the current filename is likely some temporary thing
from the browser. It then falls back to the current filename, though.
|
|
|
|
This is cobbled together from Xorg and gtk. Seems to work through
distcheck.
|