| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I058af7ba2d6a7c8851cf0da97793d053d6390f07
|
|
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95
Reviewed-on: https://gerrit.libreoffice.org/64102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
This improves the Doxygen-generated documentation for the class at
https://docs.libreoffice.org.
Also remove objdlg.cxx and objdlg.hxx files from clang-format blacklist.
Change-Id: I2299e225892a4d5db638a519bdab51a5d0c72c4d
Reviewed-on: https://gerrit.libreoffice.org/63610
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This change solves the non-linear World-To-View trans-
formation that calc uses due to it's screen rendering
as good as currently possible (AFAIK).
Calcv view is layouted on pixel base (due to better
homogen distances and full pixel lines between cells),
but this leads to having a non-linear transformation
between discrete units (pixels, view) and model coordinates
(World). In principle, each cell has it's own (so called)
ViewTransformation -> the position on screen depends on
the mappings of all cells top/left from it. This is
obvioulsly non-linear and can sometimes be seen by
producing 'offset' errors when many cells (small and thin)
are shown in low zoom stages.
No better solution for this comes to mind easily. The
extremes are - on the one hand AntiAliasing the whole
calc edit view and accept 'unsharp/AAed' lines - on the
other hand what we have now.
Maybe a future solution could find a mapping that gets
close to linear mapping for the full view. On the long
run this state is hard to keep correct. Even with this
extended solution the mapping of SdrObjects spawning
mutiple cells is assumed 'linear' in that area - which
is in reality currently not the case (!)
Note: This is only true for the screen visualization,
print and/or PDF export do not do that pixel-based
layouting.
Note2: This mechanism is general in DrawingLayer (look
for '.*GridOffset.*'. If it is deactivated by providing
no offsets, the result is the unchanged, linear mapping.
First step: Add interfaces to get a possible GridOffset
at ViewObjectContact. There it belongs, we have a view-
dependent offset per object and view. Add mechanisms to
create on-demand and reach back to the view (aka calc's
derivation of it).
Second step: Implement the on-demand creation, adapt to
use it in ViewObjectContact::getPrimitive2DSequence, add
stuff to reset on zoom change, disable temporarily old
mechanism -> paint already works. Need to adapt the
places from old mechanism where the GridOffset was used,
but no longer the geometry creations.
Third step: Isolated and disabled old mechanism (by
already removing SetGridOffset). Marked all places that
possibly need change with '//Z' tag. Main work now will
be to adapt in the SdrView implementations in svx to know
about having a SdrObject-dependent ViewTransformation
at all (currently not known, was hard-coded at some places
from the old code, ViewTransformation set as MapMode at
a target OutputDevice, not member at SdrView at all...).
Fourth step: Adapt the Handles and OverlayObjects to
use an evtl. existing GridOffset. The mechanism is that
the SdrHdl(s) can be seen as 'Model-Objects', these get
converted to OverlayObjects in the ::CreateB2dIAObject()
implementations, for all SdrMarkView and SdrPageView,
so this is the place where the ObjectContact is known
(the SdrPageWindow *is* a ObjectContact) and the view-
dependent GridOffset can be calculated per SdrObject.
I modified OverlayObject to be able to work with a
set Offset that embeds the created visualization using
this additionally.
Handles get now correctly set and have a working HitTest
(due to that already using the primitives). Some inter-
action stuff already working, some will need more
adaption. We simply have no concept for this stuff...
Refactored to not get dependencies to SdrObject in
ObjectContact.
Fifth Step: Make HitTest work by adding the View-And-
Object dependent GridOffset in the View when HitTest
is triggered. This is in SdrMarkView::CheckSingleSdrObjectHit
where pObj->GetCurrentBoundRect() is used that gets the
view-independent form. To make HitTest work, add a possible
GridOffset.
Since this will be necessary more often in SdrView hierarchy,
added a tooling method (getPossibleGridOffsetForSdrObject)
at that level after checking that at that level will be
reachable at all potential spots.
Inside that method the correct ObjectContact will be identified
and the object-specific offset requested there.
Sixth Step: Adaptions and started some cleanups. Still some
adaptions needed:
- After creation of new object, need to relocate from
used GridOffset setting to WorldCoordinates
- Interactions, e.g. start with dragging handles or full
object/points
Seventh Step: React on EndCreateObj. Here, the created
SdrObject is in model coordinates and needs to be adapted
to evtl. GridOffset. This is 'tricky' due to calculating
the possible offset based on new coordinates 'close'
to the target position, but may be in the wrong cell.
Nonetheless this is the best we can do here.
Last (hopefully) missing are now all interaction
viszualizations. They already work and are applied
correctly, but wrong visualized.
Have taken the time to unify adding OverlayObjects for
selection visualization to OverlayManager, see
handleNewOverlayObject. This does all needed when adding
OverlayObjects in one place where the GridOffset can
also be handled. It makles things more safe - not possible
to forget one of the three steps for others.
Eighth Step: Do the same unification for creating the
OverlayGeometry, also rename methods to make usage more
clear. We now have
SdrHdl::insertNewlyCreatedOverlayObjectForSdrHdl
SdrDragMethod::insertNewlyCreatedOverlayObjectForSdrDragMethod
which can do the needed GridOffset changes centralized.
Needed to get a ObjectContact for this at SdrDragMethod,
so adapted ::CreateOverlayGeometry implementations
accordingly. Missing is now the implementation in
insertNewlyCreatedOverlayObjectForSdrDragMethod to add
the GridOffset - if used. This has no SdrObject at this
time, so we will need a fallback to do the same using a
Range (Rectangle). The stuff doing this for SdrObject
already has a fallback and is based on using the Rectangle
from the SdrObject anyways, so this will be possible.
Ninth Step: Cleanup of old stuff (no more //Z), adapted
some usages of OverlayObject creations to use
getViewIndependentPrimitive2DContainer instead of the
view dependent parts so that offset applied to
drag-overlays is correct and not already added. Adapted
insertNewlyCreatedOverlayObjectForSdrDragMethod to use
calculateGridOffsetForB2DRange. Use now that instead of
SdrObject-based approach in calc - is more generic.
Getting closer, but still not complete - there is an
error with dragging the grepped handle somehow - the
offset for drag is somehow wrong.
Tenth Step: Corrected that offset error. Of course at
interaction start and progress (move) the coordinates
are in GrifOffset coordinates and need to be corrected
to Model coordinates. Done that at ::BegDragObj and
::MovDragObj, works well.
Of course there are exceptions for the crop-handles, so
needed to add setting the correct parameters at SdrHdl
when these got created, then all works as expected.
The strategy is to *not* change the model data itself
in any way, instead do all changes/adaptions in the
view-only code. This has minimal impact and is needed
due to having a 1:n relationship between model and
views anyways.
There are two directions: All visualizations are adapted
to take the GridOffset into account (SdrObjects, overlay,
handles, InteractionObjects, ...). In the other direction
input like MousePosition is in principle in calc EditView
in 'GridOffset'-coordinates and needs to be mapped back
before usage.
Change-Id: I2ecdd409def96a7248a26a65a22e59eb962880a0
Reviewed-on: https://gerrit.libreoffice.org/64057
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
At least on tinderbox MacOSX-x86_64@49-TDF the sed appears to ignore the
literal newline character, which is unfortunate, particularly since it
worked on the Jenkins builder.
Blind fix to replace this with a tr invocation that already appears to
work in Zip.mk.
Change-Id: I7a77e69774b050a018b12c73ddd9eff849c33a86
|
|
Change-Id: I99b7c2ec397829c2f7ceb7ec18ae24195b9781e2
Reviewed-on: https://gerrit.libreoffice.org/61800
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
macOS's linker can take a -filelist argument, in place of taking the
list of object files to link on the command line. This is a more limited
version of "response files" as used elsewhere in the code base, and by
using it we make it far less likely that a linker invocation will hit
ARG_MAX.
A standard LibreOffice build probably won't hit ARG_MAX on macOS just
yet, but it's not far off - some LDFLAGS are enough to tip it over the
edge, which is what prompted me to fix the issue. If not fixed, a few
more object files will probably break LibreOffice builds on macOS! An
example of another large program that has encountered this issue is
Thunderbird, which implemented the same fix[1].
The changes I've made to use -filelist are adapted from the code
elsewhere in gbuild that creates response files, but this is slightly
different because -filelist files are a bit different - they can only
contain object files, as opposed to arbitrary linker arguments, and
arguments are separated by newlines rather than spaces.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=837618
Change-Id: I01b9126aad95056c3dc82f941dea4fd43f95d0f2
Reviewed-on: https://gerrit.libreoffice.org/64010
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
This obsoletes <https://gerrit.libreoffice.org/plugins/gitiles/lode/+/
b82e0a9d26ef4c81046c053ff831dccfc84c56be%5E!> "For linux_gcc_release_64, don't
let ccache strip comments" and fixes ccache for all builds using (recent) GCC.
Change-Id: I5fd20b2565f57073c545fe5d3a9639c2c0583a74
Reviewed-on: https://gerrit.libreoffice.org/63979
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 55b9706bea5aa9b654ab39bc7d56339422e17087, which is obsoleted
by b4f666f2e677b05cab8395fe7972b45b15f60c3f "Bump Xcode baseline to 9.3".
Change-Id: Id2240351ed9495e311d55887b8e34f2aa776ae06
Reviewed-on: https://gerrit.libreoffice.org/63896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I12f868611860867df26bd29474aa19189c2b9a96
Reviewed-on: https://gerrit.libreoffice.org/63818
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Seems that the code in SwGlossaries::GetGlosDoc() expects subdirs
to exist in user config, and would otherwise fail miserably.
Change-Id: I2da6bca46ae5e0d9d90bc23eb710396dbede37f4
Reviewed-on: https://gerrit.libreoffice.org/63798
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
...not only CppunitTests, as had been changed with
d5ed903618f200456feed9b410b7bd1ed8daeb62 "Set CppunitTest-related env vars only
during CppunitTest". Despite those env vars having been deceptively set up
in solenv/gbuild/CppunitTest.mk, at least some of them may also be useful during
other tests, and may actually have been relied upon by other tests in the past.
Change-Id: I854dfb1786bb5e9e2de5fd77cb6323299320b544
Reviewed-on: https://gerrit.libreoffice.org/63784
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and put back original SvTreeListBox a11y factory use
Change-Id: I4ad8ce29d8fed6ec5d44e9a1d641919a89226b79
Reviewed-on: https://gerrit.libreoffice.org/63501
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...and not for every target's recipe, once solenv/gbuild/CppunitTest.mk is
included
Change-Id: I710160def23fae5f93c5a67ab25e03fdaa008e00
Reviewed-on: https://gerrit.libreoffice.org/63655
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
add some unit tests, and improve the heuristics
Change-Id: I95aa97a87e178ce8d506bd245710d0ae66ad08a4
Reviewed-on: https://gerrit.libreoffice.org/63647
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...(ExprWithCleanups around the CXXConstructExpr in initializers for members of
O[U]String type, with older Clang, as used in
compilerplugins/clang/test/staticconstfield.cxx), and thus revert
e3e8d52625c2dc7a277a955d4ae2ad10c60c5f1b "Temporarily disable
compilerplugins/clang/test/staticconstfield" again.
Change-Id: Ic5fcdd1a26e4a6810369e4f9d909200d25feb12e
Reviewed-on: https://gerrit.libreoffice.org/63628
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This fixes OSX "make debugrun" by dropping VCL_HIDE_WINDOWS
handling and removing the internal GetPseudoHeadless() API.
While at it moves the DialogCancelMode enum out of Application.
Change-Id: I4876e752ddbfc39dd44faa673fb0e97810089a75
Reviewed-on: https://gerrit.libreoffice.org/61598
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Of the "Gerrit Linux clang/dbgutil" build nodes, one (tb79-pollux) has done the
lode update to use Clang 3.9.1, while the other two nodes (tb75-lilith and
tb76-maggie) are still at the old Clang 3.8.0. When building Gerrit changes for
master, tb79-pollux started to fail in
compilerplugins/clang/test/staticconstfield now
(<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/20247/> and
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/20252/>) while such
builds on the other two nodes still succeed. So it looks like Clang 3.9.1 has
some issue with that loplugin, which will need further inspection. For now, to
not break Gerrit/Jenkins builds, disable that test.
Change-Id: I1bd380fb98d3b9a411dd04578a5620cdb27cd35b
|
|
Change-Id: I5debe51f2dd44ed659c6e1a358d236303c4b9a4b
|
|
a) use GtkTreeStores for GtkTreeViews
b) ironically can't store GtkTreeStore contents in .ui apparently
c) set show_expanders for all non-trees and unconverted cases
d) on-demand subtrees
Change-Id: I3c1036a222daba2c129b1a22ffeb3fe35005ae31
Reviewed-on: https://gerrit.libreoffice.org/63336
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0c966f517e337caa340526b48fa62b9910ce0a3e
Reviewed-on: https://gerrit.libreoffice.org/63504
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3bc720e44f5ea15749e6bc0f0fada3a17a783e23
Reviewed-on: https://gerrit.libreoffice.org/63463
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If6dd8033daf2103a81c3a7c3a44cf1e38d0a3744
Reviewed-on: https://gerrit.libreoffice.org/63466
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which seems a bit excessive
Change-Id: If0ab5a33bfbbd399e270f3e140c9d44d843985aa
Reviewed-on: https://gerrit.libreoffice.org/63422
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie48a779958a393b68dea613c3bcc17113165f065
Reviewed-on: https://gerrit.libreoffice.org/63443
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
b96180cb9bbec90b0faaf61c78c71bd4f6499e40 "uitest: set en_US.UTF8 for the
LibreOffice instance" had made UITest use the en_US.UTF-8 locale (passed from
LIBO_LANG to LC_ALL when starting soffice in uitest/libreoffice/connection.py),
for unstated reasons.
The mail sub-thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2018-October/081318.html>
"Re: master build problems with en_US.utf8 locale" now argues that support for
an en_US.UTF-8 locale in the OS should not be necessary when building LO. While
absence of OS-support for en_US.UTF-8 apparently doesn't break the UITests (see
<https://lists.freedesktop.org/archives/libreoffice/2018-November/081375.html>
"Re: master build problems with en_US.utf8 locale"), it feels better to make
these tests not use the en_US.UTF-8 locale at all. At least for me, the tests
ran fine when using the C locale instead.
Change-Id: I23eb2ce540bb40a7b7d13c2a396e313966f03f6e
Reviewed-on: https://gerrit.libreoffice.org/63360
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...where (according to a request by buovjaga) in instdir/help/*/bookmarks.js,
lines mentioning "/shared/explorer/database/" should appear with app:"BASE"
instead of app:"SHARED".
That change will come in a follow-up commit to the helpcontent2 repo.
Change-Id: I7c99e5f89e001d1e507f283d16e2ee264f3ab33a
Reviewed-on: https://gerrit.libreoffice.org/63364
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic3f4388ea2ca92d9e97d4a9e066eea07c7de79e5
Reviewed-on: https://gerrit.libreoffice.org/63363
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This had manual consistent formatting. Recently it was broken, so bring
back consisency by using clang-format.
(And move the "if conversion fails" comment above
CPPUNIT_ASSERT_MESSAGE() to avoid the need for an over-indented
comment.)
Change-Id: Id6a9231c044d7282c84a21152ffdfdcb8af3690d
Reviewed-on: https://gerrit.libreoffice.org/63327
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
checking for casting to void* turns out to mask useful stuff, so
remove that and just deal with a few extra false+
Change-Id: Id9700d7ceda90ba8fdb38aa870f13a7ca3acb668
Reviewed-on: https://gerrit.libreoffice.org/63145
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib3c4d2301bf5e68b7c02590a8947ea3a502e7087
Reviewed-on: https://gerrit.libreoffice.org/63325
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Move the xmlsec helper methods to comphelper so that we can use them in cui
Change-Id: If9b10cfff5f5abd6b16e48f043af7959edbb1142
Reviewed-on: https://gerrit.libreoffice.org/63198
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: If3efa54c5d0ce7ffee3bf3f4ecb1de5ff7e4267d
|
|
Change-Id: Ic189aecf092b9cffd800e410d2d6e88016c43052
|
|
Change-Id: I22823323e0b4e15dbd6ea5f7efd35301995315bf
|
|
Change-Id: I555e01ede3d8ce2a08f67c3ce6fc686861ea6519
Reviewed-on: https://gerrit.libreoffice.org/63139
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I96623f6d87ec2f380b37a2de51a089e0a4d59136
Reviewed-on: https://gerrit.libreoffice.org/63134
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Splits gb_JunitTest_set_unoapi_test_class_and_jars into two
separate defines as:
- gb_JunitTest_use_unoapi_jars
- gb_JunitTest_use_unoapi_test_class
Then replaces many of the gb_JunitTest_use_jars lists with the
new gb_JunitTest_use_unoapi_jars to fix the JUH dependencies.
This probably adds some unneeded JUH dependencies to some Java
tests, but that shouldn't be a problem.
Change-Id: I0c4fce6b50f7c6eb8d62bfb2c50f056b97584794
Reviewed-on: https://gerrit.libreoffice.org/63119
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Originally I just wanted to add the juh.jar to the list of jars
of the UNO API tests, but this became tedious work, so after the
first few files I decided to replace the similiar makefiles with
a common define for the *_unoapi* tests.
This patch adds two new make defines to be used used by Java UNO
and UNO API tests:
- gb_JunitTest_set_unoapi_test_defaults
- gb_JunitTest_set_unoapi_test_class_and_jars
The first one will deduce most defaults from the test name, but
still allows to optionally override most settings.
If a test doesn't match the default at all, the 2nd define still
shares the common jar files and the main Java UNO class, so the
second define adds these to your makefile.
The real fix is to add juh.jar to gb_JunitTest_use_jars.
Change-Id: I4342fdac5e31f85ea18fb4268e13c287a7adc2b7
Reviewed-on: https://gerrit.libreoffice.org/63118
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I350c71f50fdb8f0602badd7a7ad13b3a7c2c85e0
Reviewed-on: https://gerrit.libreoffice.org/63083
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I04a146d3d8a428ac1678827dc883525c40240a44
Reviewed-on: https://gerrit.libreoffice.org/62787
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I188d9e9b53e00acfbae3c7acd54de28f084c4b3f
Reviewed-on: https://gerrit.libreoffice.org/62985
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I27e822ac2432eb2746ed9181cee158012e54252e
|
|
Use that function in the dialog builder instead of having explicit
code in there to check the names.
For now this simply uses a manually curated list of custom widgets. I
used some command line tools to extract the names of custom widgets
used in our .ui files, and then filtered out some I guess (hope) will
not be needed in a mobile app.
For this to work the custom widgets need to have unique names.
Currently that is not the case. Unless I did some mistake, there is
just one case of duplicate name, NotebookbarTabControl, which exists
both in the sfx and vcl libraries. (I simply filtered out that one,
too, for now.)
Change-Id: I29bbf6dfef2b3bde03acfc322495d051a7f275a8
|
|
Look for nested if statements with relatively small conditions, where
they can be collapsed into one if statement.
Change-Id: I7d5d4e418d0ce928991a3308fc88969c00c0d0f2
Reviewed-on: https://gerrit.libreoffice.org/62898
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id5489f3e8f1d3ced3d57b56f8d3a7a4818af0fca
Reviewed-on: https://gerrit.libreoffice.org/62377
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
This change packages all SVG based icon sets in seperate zip
files. It automatically generates the SVGs links.txt from
the non-SVG version, if it doesn't exists by 's/\.png/\.svg/g'.
Same for the _dark version, but this just copies it.
This would also work for a _dark_svg version, if needed.
The patch explicitly does't package sifr_svg and tango_svg.
Change-Id: I8d7fda42d0ff9a2108ba8406bd4e82af4c54ff0c
Reviewed-on: https://gerrit.libreoffice.org/62706
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: If3f5f3872b4d97c4832f302cc63cd9f1601ca22a
Reviewed-on: https://gerrit.libreoffice.org/62709
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This had (consistent) manual formatting before, but recently I broke it.
Change-Id: Ifd925797c5599aa55852b2e2fb7d16c5812cd159
Reviewed-on: https://gerrit.libreoffice.org/62673
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
