We don't really have any way of telling the client that the file didn't
exist yet though, so not very useful so far.
Change-Id: I1db386781b88b345f3e9cb4f37838ca1d95f92f9
Recreating Office instances after destruction (when still
within the same process) currently fails, hence we need
to do all tests at once for now.
Change-Id: Ic7652c909e1cd970fe1ee76995e61fb6aae8f96c
It looks like the cleanest method of getting lok_init into
a LibreOfficeKitInit.h header (in a c89 compatible way) is to
have it as a static function.
(inline is only available in C99 or later -- this is actually
available on Linux which is the only place that we can actually
use lok_init anyways currently, however given we have to keep
c89 for the C code (for MSVC) compatibility, selectively enabling
c99 would likely be more messy.)
Change-Id: I0493e7a68ed5397479220bb6ba8c3db870b6dd32
There seems to be a maximum size that gdk's pixbuf
can handle, however I have been unable to find any
documentatation. Seeing as the current implementation
isn't realistically useable anyway, we might as well
set a hard limit here (in practice we'd have much smaller
tiles + compositing).
Specifically extras/source/shellnew/soffice.ods will fail
without this patch.
Change-Id: I6ac495adca8e15878989375ef8b2de472788279a
The use of VisPortChgd ensures that the tiles all render as
expected, i.e. that the pixels match 1:1 irrespective of actual tile
size (for identical zoom factors and document areas).
Change-Id: Ib1e1df4f8257546c2f7993a8160c309a52037d8b
If the lock file still exists when running this test, LOK will fail
resulting in "documentLoad failed: unknown load failure"
(the actual error is that the lock file dialog cannot be confirmed
by the user in headless mode, resulting in loading failure, however
this is then hidden by multiple layers of exception redirection
in sfx2).
Change-Id: I025ea6187c3d17805f25ab6f756eae9646f2c7c8
This allows for easier visual comparisons (i.e. currently the test
would be failing for some tiles).
Change-Id: I5b174375b57ffe0edd2700fdec411a83669e4a34
Seeing as this is only a test program, probably easiest just to disable
this for gtk < 2.24, and rely on devs wanting to use it isntalling a new
enough gtk version.
I.e. we render the same area as one larger tile, and then
as 4 sub-tiles (which, when put together, should be identical
to the larger tile). However currently only the top-left sub-tile
actually matches the larger tile, so we have to disable the test
for the remaining sub-tiles.
Change-Id: If1130022b43898e20fefff3e9f592102da3e413a
Same as
"LOK DocView: only rerender on zoom if we have a document open."
but for our quad-tiled test widget.
Change-Id: I6c1b946cc9d576d1dcc4687048339d9f0b3e6eff
Otherwise we would segfault, and it's perfectly valid to set a zoom
level _before_ opening a document (as that would e.g. save the document
first being rendered on opening if the client wants to immediately
render at a non-standard zoom level).
Change-Id: Ide261b09f4aab8dc3b552f6c3bf55f78ffd7870c
I.e. we subdivide the document into 4 tiles: one at 100% scaling,
one at 200%, one at 50%, one at 25% -- these are then post-scaled
in gdk) and assembled to show as one document again.
This is specifically a test only widget, primarily to be able to quickly
spot any tile positioning/border-transition issues.
We could theoretically make this widget inherit from the original widget,
however that would mean having to introduce virtual methods etc., which
is not something that we'd want in production -- in the longer run
that widget will hopefully be extended to have proper tile composition etc.,
which would then break this widget too if it were inheriting from there.
Change-Id: Ib880a1614f89724135e753013cf91aec25973e39
Otherwise lock files etc. aren't cleaned up, which isn't particularly
nice should when then opening the file in normal LibreOffice.
Change-Id: I822b6fb582473674371a4c1d403d5a05adb7ea6b
Seems to be a gtk bug which we need to work around. The assertions
don't actually seem to cause any harm (they just print a bunch of
"Gtk-CRITICAL **: IA__gtk_range_get_adjustment: assertion `GTK_IS_RANGE (range)' failed"
but probably best to avoid them.
Change-Id: I5d1bb20bd5c0569c6d023a6148123208a15b9de2
