Age | Commit message (Collapse) | Author | Files | Lines |
|
That literal %s was irritating.
Change-Id: I2925b26b1f3d1c101106ca616d18b24b41210c72
|
|
Change-Id: I882c04fd3a255f55511b1884157de26e7574e6db
Reviewed-on: https://gerrit.libreoffice.org/18262
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifbd87e59fa91241dd5852f7dc6b63e65d8ca6bad
|
|
Work in progress to allow integration of LO with
<https://wiki.gnome.org/Projects/FleetCommander>.
During configuration, dconf support is implicitly enabled when available on the
host (which is presumably only available on Linux). It is explicitly disabled
for TDF Linux builds for now, though, to avoid accidental dependencies of the
distributed installation sets on system dconf libraries.
A dconf layer is represented in the CONFIGURATION_LAYERS bootstrap variable with
type "dconf" and an empty URL. See the comment at the top of
configmgr/source/readdconflayer.cxx for the encoding of component-data in dconf.
All of this is still subject to change.
Change-Id: I2d08d81c8ea43ba4a99040a8882ae75b91bcfdb9
Reviewed-on: https://gerrit.libreoffice.org/16848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia3cd8a2f0979f2312a70b8ee169fe9d6eef85c81
|
|
Change-Id: I1c76d4ce91d1f22d88106918ab139b17f6f017f0
|
|
...for a 32-bit build, similar to what ee11e221d2108212619e1bbe7f029e7d9afdba32
"tdf#43157: Fix format string violations in OSL_TRACE etc." did for a 64-bit
build
Change-Id: I05dd79ede3e66cb9ab7a33792319eb34b34c82dd
|
|
When a file's time is epoch (1970-01-01 00:00:00, i.e., TimeValue temp is all
zero) and the TZ is UTC or westward, osl_getLocalTimeFromSystemTime returns
false and leaves myLocalTime uninitialized. That e.g. confuses getModuleByUrl
(scripting/source/pyprov/pythonscript.py), potentially re-loading a Python
script with epoch time (as happens e.g. for the share/Scripts/python/ files in
an xdg-app installation of LO) every time it is accessed, falsely assuming it
has changed on disk since last load.
Change-Id: I8d4228feb28e2697a7021e3488ae2c09e8439ed8
|
|
Work in progress. The selection not used for anything yet.
Change-Id: Ia86fa0f59dcfee8e9d332a028a3fad37f4019fe0
|
|
Change-Id: Id9bfb3886e4a9cbc15a7bf7ef3aefa73bd160e3b
|
|
Change-Id: Ic9cda5259db81dd921dd3fa891b1289b8283bf27
|
|
Change-Id: Ia0a4834987ae040a31e19276ece20b74b59ca445
|
|
Change-Id: Ib1ec1ae009115dcc8f50ca3038bc9a35b7cb09a9
|
|
guess we'll need them more often..
Change-Id: I0ef149fc5edceee765419764bf0efa571ba9d977
|
|
Change-Id: I129f3dc1597035664e4ff284276cb0d49a560ab5
|
|
after paint"
(and its later fixup)
This reverts commits
e8a68c1f50f32a0f9d8bcdf16c1270c319910baa
e60b589952985edff12b1a28392ce6fa0ca8d9be
It was a work-around for the real underlying issue, which was that the
result of dbaccess::ResultSet::isFirst() et al were clobbered by moves
made by its clones.
The BrowseBox has two different cursors:
1) One for data to edit (which is kept on the current/active row)
2) One for data to *paint*
The second is a clone of the first.
The real underlying issue is fixed by:
commit d7c9a1d9d65fe8b1a56c5c280d2ca6640a549d2f
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date: Thu Jan 22 10:49:42 2015 +0100
fdo#88475 RowSetBase: reposition cache before interrogating it
Change-Id: I28d62673fdf10ee6507d38bb7c79c08e4b40902f
|
|
OSL_ENSURE does not execute in non-debug builds (and is deprecated).
Do not try to seek back if paint did not seek.
This happens in particular when there is no data source attached (and thus trying to seek fails).
Change-Id: I3f4908c4dcae2bb120bf58c1218e3386c40d5721
|
|
Change-Id: Ia6c178dd9390bf75a08c0d53e6505582a7f5ab4f
|
|
Change-Id: I37e507226e676ee797e6911a0b3da1d1823e750a
|
|
Change-Id: Ic76ccc49b9291fe82c56974eb6237cd3b85d91c8
|
|
Change-Id: I9c879cc16de0d5353a5ab8ce4c8a8cd7f000a170
|
|
Change-Id: I3339324ec99bbed56f81f2aa4e6cf54edcbec8e6
|
|
Change-Id: I26fa823b987b2edfbb1be054a5f4d03bbe95a308
|
|
Change-Id: I0e2b38ab8e7fae483539e02e93d25d2532bd70ef
|
|
OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients
have just a start and end colour, plus an optional uniformly coloured border
(on the "start" side). In addition, LibreOffice has the "axial" gradient mode,
which means the gradient is reflected in the middle.
It is thus obviously impossible in general to losslessly map OOXML gradients
to LibreOffice ones. But let's try a bit harder than earlier to get visually
more similar result, in at least some simple sample cases.
We look for the widest gradient segment and use that for the start and end
colours of the LibreOffice gradient.
Also, map an OOXML gradient to an axial LibreOffice gradient only if it is
symmetrical. Also, use the border property when suitable. In general, look for
the widest OOXML gradient segment (once a segment corresponding to the
LibreOffice gradient border, if any, has been accounted for) and use that as
the LibreOffice gradient.
Possibly some perceptionally better heuristic should be used... Like, if we
have a three-segment gradient, with a wide gradient segment between two
visually very similar colours (for example, two shades of red), and a narrower
segment ending with a visually very different colour (for example, yellow), it
probably would be best to represent that in LibreOffice as a gradient from the
first red shade to yellow, instead of as a gradient between the two shades of
red. Or even, if a first or last gradient segment is between very similar
colours, equalize those start and end colours, thus using a border colour in
LibreOffice instead. The possibilities for bikeshedding are endless.
I am sure there are instances where the old code (by accident?) produced
visually more pleasing results... But hopefully this works more pleasingly and
consistently in a larger number of cases.
Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
|
|
Change-Id: I885acc9b4a52835fa256c2ecd1b8da917b4f7ba7
|
|
Change-Id: If7704edc5baa9759abc680b8d2040b9cdfe92317
|
|
Change-Id: Ia5fbdfd83971ac946de6d022be55d5a286a1bf5a
|
|
Change-Id: Ia3fe1ff0075434d0b6903bf978c16499e07d699d
|
|
Change-Id: Ie60e0b64a2d9d8a045cb3c59fc781d6f9b2808a0
|
|
While at it, make it use SAL_INFO instead of fprintf.
Change-Id: Id4018819f8f790bef219e5aca3b6bbb5f6acd6aa
|
|
Change-Id: Ife10cae3f0bd7dd294c74799412528f2596369c8
|
|
Change-Id: Ic3e2a5ed247b35b4e6d80a4ad824bc9b535783fb
|
|
Change-Id: I2bad7938ddd02da8aa7191aebbd9221220fb303e
|
|
Use avmedia.opengl to be more explicit.
Change-Id: I07878c3648de2e4786bf8a5144ef0c1fbb5530f1
|
|
Change-Id: Ia89a2dce799c7ba90bcd19919195bfd2c7a4a180
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7362c843ae7abae74e82b330832cb007478d853c
|
|
It was already possible to dump a PropertyMap as code, but not as data.
The plan here is that if we dump the customshape preset definitions as
data, then once there is a parser for it, we can get rid of the ugly
generated code.
Change-Id: If596941fedf71693e5d0bff436446ac0855c4c84
|
|
Change-Id: I6f4ed9a816c13d35b92059c68132d90fe532b321
|
|
Change-Id: Ib7b19a53fe6b523b302276d5123c070eb46a4737
|
|
Change-Id: Iaca31b4e12c258b762b3d88fbad0fb08b4f1fc16
Reviewed-on: https://gerrit.libreoffice.org/8832
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Conflicts:
include/sal/log-areas.dox
Change-Id: I770b8b9fb82f873ccb88dc26ac05206f703ddf33
Reviewed-on: https://gerrit.libreoffice.org/8805
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Store them under /Model/<json_file_name_without_extension>/
modeltools: functions for handling 3D models inside avmedia
Change-Id: Ia2bdad6064db372e1c946b6ab02c434545d1ed45
|
|
One would think there would exist some kind of shim library that would
automatically provide such traces, hmm.
Change-Id: I568d02a2ac70078dee0280d1feb3eab7bbd43030
|
|
Change-Id: Iaf2de623c0893b0f500d54ce6558bf40af6e655b
|
|
Change-Id: Iaaf36d012e353f73f083c9c0ebbbb6d0953b16c8
|
|
Change-Id: I3773f5432ff4e2a005e0c67d9c65fdb00de6f16b
|
|
Change-Id: I9c809cae0420e73d2e4a447b9d8a3a03e42dc723
|
|
This reverts commit 04b70c682e2cdc52b144961a83d05fd203de6884.
The OpenGLRender is not abstract enough for vcl. Leave it in chart2.
Conflicts:
chart2/source/view/inc/DummyXShape.hxx
chart2/source/view/main/OpenGLRender.hxx
vcl/Library_vclopengl.mk
Change-Id: I5392c8ee34462ff49059126ca2284d8ebe1eb379
|
|
Change-Id: I6383ae3f94fc18aec92596b9d857d3fde5869dd6
|