summaryrefslogtreecommitdiff
path: root/desktop
AgeCommit message (Collapse)AuthorFilesLines
2017-12-21Revert the incomplete dialog tunneling, the API has changed completely.Jan Holesovsky1-285/+0
Change-Id: I50fb8c83365cefb8c8e76096fe257d31970a68b4 Reviewed-on: https://gerrit.libreoffice.org/46927 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2017-11-25LOK: provide user feedback while preloading.Michael Meeks1-3/+6
Problems are hard enough to debug in a jailed kit process inside a docker image; provide some visual feedback via stderr. Change-Id: I54b0a21c1375be2acc9da0bbacf959a419471b08 Reviewed-on: https://gerrit.libreoffice.org/45256 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2017-11-24Remove redundant callPranav Kant1-2/+0
This call, which sets the DialogCancelMode to fatal is superceded by another call which resets the DialogCancelMode back to Silent, as follows. 0 0x00007fffc8c1ece3 in Application::SetDialogCancelMode(Application::DialogCancelMode) (mode=Application::DialogCancelMode::Silent) 1 0x00007fffc8c1f1fc in Application::EnableHeadlessMode(bool) (dialogsAreFatal=false) 2 0x00007fffdd3824af in desktop::Desktop::RegisterServices(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) 3 0x00007fffdd361eeb in desktop::Desktop::Main() (this=0x7fffde919950) 4 0x00007fffc8c261f3 in ImplSVMain() 5 0x00007fffc8c2635c in SVMain() Change-Id: I30efe63932e98309f4d6ac609d09b08378076007
2017-11-23tdf#90794 Position of progress bar on high res screensheiko tietze1-3/+16
Introduced two new consts Change-Id: I15e01eabe9fd3225c36d06cbb59310a07a30f2c1 Reviewed-on: https://gerrit.libreoffice.org/45105 Reviewed-by: Heiko Tietze <tietze.heiko@googlemail.com> Tested-by: Heiko Tietze <tietze.heiko@googlemail.com>
2017-11-23tdf#112689 Replace chained O(U)StringBuffer::append with operator+Timotej Lazar1-93/+40
Change-Id: Iea9a6e2104966bd47f09a82df9b01f065f678d17 Reviewed-on: https://gerrit.libreoffice.org/45079 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Muhammet Kara <muhammet.kara@pardus.org.tr> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-21Various loplugin warnings in --enable-online-update=marStephan Bergmann1-9/+9
Change-Id: I5dabd5b65420d30b8d5b631de4d755ecf385b762 Reviewed-on: https://gerrit.libreoffice.org/45027 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-21fix fallout from orcus upgrageDavid Tardon1-16/+16
Change-Id: I79a9988c24d04b9c6a9369653a60b2324465b1d8
2017-11-13Fix typosAndrea Gelmini1-1/+1
Change-Id: Ia544298334364ece3b3963a4adc00c5e01189b91 Reviewed-on: https://gerrit.libreoffice.org/44654 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mark Page <aptitude@btconnect.com>
2017-11-12iOS, make sure SfxApplication::GetOrCreate() is calledjan Iversen1-0/+1
For some reason SfxApplication::GetOrCreate() was never called, this leads to problems when opening documents (reference to shared pointer). Adding dummy call to SfxApplication::GetOrCreate() to make sure the list contains at least one entry. Change-Id: Ic8848c17efae5a0a38c9e9f7299a5f36f69aef31
2017-11-10Upgrade these SAL_WARNs to INFOPranav Kant1-27/+25
These are very common occurrences. Let's not flood the warning output. Also ressurrect some helpful looking commented out SAL_INFOs Change-Id: I3368fb46b27b72edd8ba1f52e2a145a661c40477
2017-11-09lokdialog: Compress invalidation callbacks in Callback flush handlerPranav Kant1-0/+133
Change-Id: Id76bde54395611f509a5d4be6bb2ac9b7f6ed1c0 Reviewed-on: https://gerrit.libreoffice.org/44474 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-09lokdialog: Move getting dialog information in separate LOK callPranav Kant1-15/+31
Using outparameters to get the dialog information with the paintDialog call was quite confusing. Change-Id: Ief331b251dc66e66084b827ce5b025ba6c9ce7d2 Reviewed-on: https://gerrit.libreoffice.org/44473 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-09lokdialog: Support painting parts of the dialogPranav Kant1-3/+10
Pass the dimensions of the region to the paintDialog call to paint only that much of the region in the dialog. The DIALOG_INVALIDATE callback also returns a 'rectangle' field now in the payload that tells the region of the dialog invalidated. It can be used in combination with the new paintDialog call then to paint only the invalidated region in the dialog. Change-Id: Iebb228865c71684e0f75dd01271b71ae41a0f906 Reviewed-on: https://gerrit.libreoffice.org/44472 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-08sw lok: add Accept/Reject All tracked changes, tdf#101977Henry Castro1-1/+3
Change-Id: I04d747343e24cb498a621c965d034d0791411d83 Reviewed-on: https://gerrit.libreoffice.org/44311 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-11-06loplugin:finalclasses in dbaccessNoel Grandin2-4/+3
Change-Id: I7cbc786407ee798950a7fdc98f43aee0845ff862 Reviewed-on: https://gerrit.libreoffice.org/44347 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-06Finally make DbusIpcThread terminateStephan Bergmann1-105/+61
...by directly calling shutdown(3) on the underlying socket, to make dbus_connection_read_write fall out of its internal poll(3) call blocked on POLLIN (upon which it returns false). (dbus_connection_close only calls close(3), so calling it from DbusIpcThread::close would merely decrement the socket file descriptor's reference count.) This removes the need for the sent- to-self "Close" command (whose processing turned out to be too brittle in parallel with closing the connection down, witness my previous three fruitless commits in this area). There appears to be no need to explicitly call dbus_bus_release_name, as the session bus apparently takes care of releasing the name as soon as the associated connection is closed. Also there should be no need to call dbus_connection_read_write_dispatch instead of just dbus_connection_read_write, and dbus_message_pop_message should probably be called in a loop, until all queued messages are processed. Change-Id: I13f30b6676a531f349e953329e910c1ff45ee53e
2017-11-06loplugin:constparams in various(2)Noel Grandin2-2/+2
Change-Id: I533a7eb724b15e168a28dc92cd5962a39bc96e7c Reviewed-on: https://gerrit.libreoffice.org/44313 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-05Remove GetNextSubset and create GetSubsetMapJulien Nabet1-2/+2
To avoid to store an iterator and simplify loops Change-Id: I9b160714125176841961a56905d81dcb876c68b6 Reviewed-on: https://gerrit.libreoffice.org/44326 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-04Related: tdf#113160 set parent of warning dialogs during loadCaolán McNamara1-4/+79
to the new window frame being constructed that (may) contain the progress bar, that way such modal dialogs affect the loading document window and not whatever window happens to be active Change-Id: I1c7d3185e47fa316eef003b80d18b31d341b79d6 Reviewed-on: https://gerrit.libreoffice.org/44269 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-11-04Make Windows error reporting more robustMike Kaganski2-6/+5
https://msdn.microsoft.com/en-us/library/ms679351 describes that "it is unsafe to take an arbitrary system error code returned from an API and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS" Previously in case when an error string would contain inserts, function returned error, so the error message wasn't shown (at least it didn't crash, thanks to nullptr as the function's last argument). As the function may fail, we now pre-nullify the buffer pointer to avoid dereferencing uninitialized pointer later (though at least for some Windows versions, the function nullifies the pointer in case of FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this). Also release of allocated buffer is changed to recommended use of HeapFree. The code that doesn't make use of OUString is left directly calling FormatMessage, to avoid introducing new dependencies. Where it makes sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx> Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848 Reviewed-on: https://gerrit.libreoffice.org/44206 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-11-04Following 42bfbc216474b4f60d5a5e52a88d95baded5191cJulien Nabet1-1/+1
as suggested by Stephan in comment of https://gerrit.libreoffice.org/#/c/44233/ Change-Id: Ia0a8c36441339628fd61ba862df73db11bbed302 Reviewed-on: https://gerrit.libreoffice.org/44276 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-03Replace remaining lists by deques (desktop)Julien Nabet5-43/+36
because of addToUnoRc and addToConfigmgrIni which use push_front (and no easy way to change this), I couldn't use vectors + use for range loops Change-Id: I15300122b449b3a5af7c6402a7ad4cd5a2000413 Reviewed-on: https://gerrit.libreoffice.org/44233 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-02improve constparam lopluginNoel Grandin2-6/+6
lots of little fixes to make the logic less pessimistic Change-Id: If368822984250b11b98c56f5890177a1402e8660 Reviewed-on: https://gerrit.libreoffice.org/44168 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-01Replace some lists by vectors in deployment/registry (desktop)Julien Nabet10-15/+13
Change-Id: I264a8b4d8fc90f647d5a6f1aef4a190353d494e5 Reviewed-on: https://gerrit.libreoffice.org/44143 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-01loplugin:constantparam in d*Noel Grandin3-4/+4
Change-Id: I65c395157d2b68a549a6fecf9abf1fd46446d960 Reviewed-on: https://gerrit.libreoffice.org/44109 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-30Replace some lists by vectors in desktopJulien Nabet5-25/+20
Change-Id: Ib1cd2278d1af651b96f07c8831382bba7f51aed6 Reviewed-on: https://gerrit.libreoffice.org/44037 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-10-28lokdialog: Tunnel dialog title to lokclient as outparamPranav Kant1-3/+12
Change-Id: I1beb5ab3f06debdca7ebf999af7ac879a41ea47e Reviewed-on: https://gerrit.libreoffice.org/43959 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-10-27loplugin:includeform: desktop (Windows)Stephan Bergmann1-3/+3
Change-Id: I245c58a3d97eb0d60e7063e9c34c77d33739801d
2017-10-27...and one more fix for DbusIpcThread,Stephan Bergmann1-23/+4
switching back to a "Close" message-to-self without a response (as it had been before dc3ff192f3f048059cf149f416d0b237eb33b014 "Avoid further unwanted interference of DbusIpcThread::execute/close"). Especially on a first start of LO (where it restarts after creating the UserInstallation), it had been observed that DbusIpcThread::close was blocked waiting on a reply in dbus_connection_send_with_reply_and_block while DbusIpcThread::enable had already successfully (i.e., without emitting any of the SAL_WARNs) proceeded past sending the reply and was blocked on closeDone_.wait(). However that can happen---it should be clear by now that I don't understand anything at all about DBus. :( Change-Id: Id5f368a60b2d8dd8b7074308ac1ad6b6545131ff
2017-10-26vcl: make MapMode constructor explicitMichael Stahl4-5/+5
Insert constructor everywhere, except a couple places that apparently want to compare GetMapUnit(). Change-Id: I1910deb60562e5e949203435e827057f70a3f988
2017-10-25iOS, soffice not needed for iOSjan Iversen1-0/+6
Removed the IPC part of init for iOS. Lo_init() completes for iOS without errors. Change-Id: I7ce38758883bebea1de6ac149ba8768593c7cb78
2017-10-25Avoid further unwanted interference of DbusIpcThread::execute/closeStephan Bergmann1-30/+54
...after 38081c0884b64ed1132047973b4dccc42d548c89 "Avoid race between DbusIpcThread::close and DbusIpcThread::execute" Change-Id: I812f53525f4c2c051781321dac7096e3bf0d7054
2017-10-24Avoid race between DbusIpcThread::close and DbusIpcThread::executeStephan Bergmann1-35/+34
...that caused Flatpak'ed LO to sometimes not terminate properly after 243d743dae127fe11ecd7f807121da8815af8f01 "solenv/flatpak-manifest.in: incorporate upstream sandboxing improvements" had removed --socket=session-bus and thus introduced flatpak-dbus-proxy into the mix: > Oct 24 15:25:16 <sberg_> I'm not sure who's at fault there; on the LO side I > have a thread processing incoming dbus requests (DbusIpcThread::execute, > <https://opengrok.libreoffice.org/xref/core/desktop/source/app/officeipcthread.cxx#552>); > that thread is typically waiting within dbus_connection_read_write_dispatch > for new messages; if LO wants to close, it needs to get that thread out of > dbus_connection_read_write_dispatch, and the only way I found back then is > what's in DbusIpcThread::close (just following DbusIpcThread::execute), with > a big "this apparently needs a more DBus-y design anyway" testament to my > cluelesness re dbus; it calls dbus_bus_get_private to connect to itself, and > send a Close message that'll cause DbusIpcThread::execute to fall out of the > loop; the dbus_bus_get_private leads to a flatpak_proxy_incoming in the > proxy, which returns TRUE, and after that I see no further activity in the > proxy (but not sure what functions I should all put breakpoints on), and the > LO side is hung in dbus_bus_release_name a few lines futher down > Oct 24 15:26:20 <alexlarsson> sberg_: i ran this: > https://github.com/sgh/dbus-examples/blob/master/dbus-signal.c > Oct 24 15:26:27 <alexlarsson> sberg_: which calls dbus_bus_release_name > Oct 24 15:26:30 <alexlarsson> and it seems to work for me > Oct 24 15:26:39 <alexlarsson> If i --own-name=org.DBusTest.SignalTest > Oct 24 15:27:50 <sberg_> so maybe it's related to my unorthodox way of trying > to quit the dbus loop there; if anybody with a clue about dbus would be > willing to help me with the above, I'd be very grateful :) > Oct 24 15:28:06 <alexlarsson> I don't see how the proxy should affect it tho > Oct 24 15:28:11 <alexlarsson> other than maybe timing? > Oct 24 15:29:06 <sberg_> maybe; I think I've seen things actually succeed once > when I stepped through the proxy somewhat manually > Oct 24 15:31:01 <alexlarsson> sberg_: eeeentresting > Oct 24 15:31:07 <alexlarsson> sberg_: so, it does an own-call > Oct 24 15:31:13 <alexlarsson> sberg_: maybe that is what breaks? > Oct 24 15:31:33 <sberg_> yeah, that's my dumb speculation > Oct 24 15:34:38 <alexlarsson> So, you send the close from another thread, not > waiting for the reply > Oct 24 15:34:56 <alexlarsson> then you start working on the main connection > immediately > Oct 24 15:35:02 <alexlarsson> shouldn > Oct 24 15:35:25 <alexlarsson> shouldn't you grab the mutex after that? > Oct 24 15:36:35 <alexlarsson> This whole thing smells racy > Oct 24 15:38:18 <alexlarsson> My guess is that with regular dbus, the flush > call will schedule dbus daemon which sends back the message, waking up the > other thread before continuing > Oct 24 15:38:22 <sberg_> alexlarsson, ah, yeah, I see; apparently didn't > occur to me back then that I mustn't call dbus_bus_release_name when the > execute loop may still be busy > Oct 24 15:38:25 <alexlarsson> But now you have two context switches > Oct 24 15:38:37 <alexlarsson> so we continue before we get the reply > Oct 24 15:38:44 <alexlarsson> eh, not reply > Oct 24 15:38:46 <alexlarsson> the close message > Oct 24 15:38:52 <alexlarsson> and then you race > Oct 24 15:39:11 <alexlarsson> Honestly i don't remember the exact rules for > dbus threadedness > Oct 24 15:39:58 <sberg_> ...so looks like something that can be corrected on > the LO side after all; I'll give it a try > Oct 24 15:40:17 <alexlarsson> you're calling dbus_threads_init_default(), so > it should be nominally threadsafe > Oct 24 15:40:29 <alexlarsson> still, I imagine it can still deadlock > Oct 24 15:43:12 <alexlarsson> sberg_: i still don't see the exact deadlock > though > Oct 24 15:43:32 <alexlarsson> i imagine working on the separate private > connection is threadsafe > Oct 24 15:43:35 <alexlarsson> and we flush that > Oct 24 15:44:08 <alexlarsson> then we call dbus_bus_release_name, which i > imagine would block if the dbus thread is in read_write_dispatch > Oct 24 15:44:35 <alexlarsson> The question is, why is the close message not > delivered? > Oct 24 15:44:44 <alexlarsson> I mean, we flushed it... > Oct 24 15:45:48 <alexlarsson> sberg_: oh, i think i know > Oct 24 15:45:53 <alexlarsson> sberg_: release_name probably sent some message, > but then the other thread pop:ed the reply > Oct 24 15:46:04 <alexlarsson> sberg_: queue very long wait > Oct 24 15:51:53 <sberg_> alexlarsson, yeah, sounds plausible; thanks! > Oct 24 15:52:14 <sberg_> (now that I want to reproduce it, closing succeeds > cleanly every time I try, of course...) > Oct 24 15:54:48 <alexlarsson> sberg_: obviously > Oct 24 15:55:30 <alexlarsson> sberg_: that just makes the race theory more > valid tho > Oct 24 15:57:31 <sberg_> alexlarsson, yup, after stopping the unrelated > background LO build that had put the machine under full load, I see it hang > again in release_name, while the execute loop is still happily running too; > that nicely confirms your theory > Oct 24 15:58:28 <alexlarsson> sberg_: alternatively you could tell your users > to always build LO in the background > Oct 24 15:59:04 <sberg_> I'll try to put that into the release notes; lets > see... Change-Id: I2a8a58f9259d2854f42f4aa3db5bb232cf70845d
2017-10-24iOS, updated desktop/source/lib/init.cxxjan Iversen1-0/+7
InitVCL() needs to be called for iOS, even though it runs without desktop, since that function fills structures like mpDefInst Change-Id: Icebd4a4111881b46a8abc1e1988921a19e5e4527
2017-10-23loplugin:includeform: desktopStephan Bergmann81-224/+224
Change-Id: I2dacb21cd0c9618dadb49912e0f09c9ab576f9b0
2017-10-23overload std::hash for OUString and OStringNoel Grandin9-15/+9
no need to explicitly specify it anymore Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec Reviewed-on: https://gerrit.libreoffice.org/43567 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-22oss-fuzz: drop our own afl related hackeryCaolán McNamara2-23/+1
Change-Id: Ia6a498c07fffd1790ad433287ef4d1cf82085887 Reviewed-on: https://gerrit.libreoffice.org/43695 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-20tdf#113311 disable CppunitTest_libreofficekit_tiledrendering for nowMichael Stahl1-0/+2
Change-Id: I0f6e284d232388019bfa33f07a4afc864e0040a9
2017-10-20drmemory: fix small leakCaolán McNamara1-0/+3
Change-Id: Ib7f6beb52dc832ee570e21ac5ab65d25946b622f Reviewed-on: https://gerrit.libreoffice.org/43597 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-18set parent of extension file dialogCaolán McNamara1-3/+3
Change-Id: I9791fceb975ca9d0a0ca0ae61c0890826d06c564 Reviewed-on: https://gerrit.libreoffice.org/43510 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-18Resolves: tdf#112891 give restart dialog a parentCaolán McNamara2-3/+6
Change-Id: Iaeb0060f390035bb214b9d1d8d090e7b933c9f77 Reviewed-on: https://gerrit.libreoffice.org/43509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-13Log found extension updatesJan-Marek Glogowski1-10/+11
The OSL_ASSERT doesn't make any sense, if you don't know what it compares. So simply log all found updates. Change-Id: I002b65cf4a658036916a217a89d0df7f0168ee70
2017-10-12EPUB export: add simple example to command line helpCor Nouws1-1/+2
Change-Id: Ia1a03f324e9b66dc36abadc326843b88b33ed249 Reviewed-on: https://gerrit.libreoffice.org/43348 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-10-05Rename and move SAL_U/W to o3tl::toU/WMike Kaganski1-1/+2
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b) it was expected to gradually remove SAL_U/W usage in Windows code by replacing with reinterpret_cast or changing to some bettertypes. But as it's useful to make use of fact that LibreOffice and Windows use compatible representation of strings, this commit puts these functions to a better-suited o3tl, and recommends that the functions be consistently used throughout Windows-specific code to reflect the compatibility and keep the casts safe. Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6 Reviewed-on: https://gerrit.libreoffice.org/43150 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-10-04add << operator for css::uno::ExceptionNoel Grandin21-53/+41
Change-Id: Ia23dafd07133779144965682df3b7125a3214235 Reviewed-on: https://gerrit.libreoffice.org/43046 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-04Revert "check for unnecessary DLLPUBLIC annotations"Stephan Bergmann1-1/+1
This reverts commit a599eeab786ecbe1b5b6509e3c792e5c1ba31248, plus follow-up fa4431449d0306e8179f53a2a69c549800bd24bd "Avoid bogus loplugin:dllmacro 'unnecessary *DLLPUBLIC declaration ...'". See (abandoned) <https://gerrit.libreoffice.org/#/c/42983/> "loplugin:dllmacro: Handle implicit member functions" how this would have needed to be extended to give consistent results across Linux and macOS, but then would have started to remove DLLPUBLIC from entities that apparently need to at least have default type visibility on macOS and started to make tests fail.
2017-10-03Replace more reinterpret_cast with SAL_W/SAL_UMike Kaganski1-2/+1
Change-Id: Ia632e4083222ad9e7f17c2ad0d0825f189c700cc Reviewed-on: https://gerrit.libreoffice.org/43071 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-10-03lok: Fix declaration of ‘xContext’ shadows a global declaration.Jan Holesovsky1-5/+14
Change-Id: Iab3c142cd85ca54bf3c37a0710ce7da7a5d77a35
2017-10-03LOK: getSpellLanguages() is not necessary in comphelper in the end.Jan Holesovsky1-1/+5
Change-Id: If81cd3d4508ba3f44304a9ec9b643bf771e8930c
2017-10-03new loplugin:blockblockNoel Grandin1-7/+5
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd Reviewed-on: https://gerrit.libreoffice.org/43025 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-14 23:50:41 +0000