summaryrefslogtreecommitdiff
path: root/desktop/source
AgeCommit message (Collapse)Author
2017-11-03Replace remaining lists by deques (desktop)Julien Nabet
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-01Replace some lists by vectors in deployment/registry (desktop)Julien Nabet
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 Grandin
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 Nabet
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 Kant
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 Bergmann
Change-Id: I245c58a3d97eb0d60e7063e9c34c77d33739801d
2017-10-27...and one more fix for DbusIpcThread,Stephan Bergmann
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 Stahl
Insert constructor everywhere, except a couple places that apparently want to compare GetMapUnit(). Change-Id: I1910deb60562e5e949203435e827057f70a3f988
2017-10-25iOS, soffice not needed for iOSjan Iversen
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 Bergmann
...after 38081c0884b64ed1132047973b4dccc42d548c89 "Avoid race between DbusIpcThread::close and DbusIpcThread::execute" Change-Id: I812f53525f4c2c051781321dac7096e3bf0d7054
2017-10-24Avoid race between DbusIpcThread::close and DbusIpcThread::executeStephan Bergmann
...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 Iversen
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 Bergmann
Change-Id: I2dacb21cd0c9618dadb49912e0f09c9ab576f9b0
2017-10-23overload std::hash for OUString and OStringNoel Grandin
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 McNamara
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 Stahl
Change-Id: I0f6e284d232388019bfa33f07a4afc864e0040a9
2017-10-18set parent of extension file dialogCaolán McNamara
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 McNamara
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 Glogowski
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 Nouws
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 Kaganski
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 Grandin
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 Bergmann
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 Kaganski
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 Holesovsky
Change-Id: Iab3c142cd85ca54bf3c37a0710ce7da7a5d77a35
2017-10-03LOK: getSpellLanguages() is not necessary in comphelper in the end.Jan Holesovsky
Change-Id: If81cd3d4508ba3f44304a9ec9b643bf771e8930c
2017-10-03new loplugin:blockblockNoel Grandin
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>
2017-10-03lok: use getCommandValues to obtain a list of languagesHenry Castro
Change-Id: I4a1f04b9dfe9e3ebbc174380db93c332e958ccfa Reviewed-on: https://gerrit.libreoffice.org/43060 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-10-02tdf#44497 run LicenseDialog with SolarMutex lockedJan-Marek Glogowski
Before commit 3840aede596e6fc24f7ed7df9100fb028134aac6 releasing an unlocked SolarMutex was simply ignored, but now it aborts. So run the LicenseDialog GUI code holding the SolarMutex, as required. Change-Id: Id9f5f6146cdfe2b21b68a2cdffc9dd4a527b551c Reviewed-on: https://gerrit.libreoffice.org/42951 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-02Change CB_DIALOG_INVALIDATE to CB_DIALOGPranav Kant
We can specify whether it is an invalidation or something else in the payload. Change-Id: I95c5fc0a0a88b5277eaa93c8d1f9b937bddce7b3
2017-10-02lokdialog: Mouse events for dialog floating child windowsPranav Kant
Change-Id: I06a081835d246f752e57f8cc289162ed31fc91d4
2017-10-02lokdialog: Support for rendering floating window dialog widgetsPranav Kant
Now gtktiledviewer can show floating window dialog widgets when user clicks any of such widget in the dialog. Change-Id: I13d756f236379bc8b2041ed41cb7b502f7fd9b24
2017-10-02lokdialog: Set up intial posting mouse events to dialogsPranav Kant
Events from the dialog in GTV are forwarded correctly, but the events are still not processed by the dialog in core. Change-Id: Ib95ac0a3cd23f6cc2763c21425a67402b15f2de2
2017-10-02lokdialog: Suppress duplicate callbacks in flush handlerPranav Kant
Change-Id: I94578b9e9c7fc2e6a9d14effe456d821768a0bcb
2017-10-02lokdialog: Set dialog painting flags while paintingPranav Kant
These are used to supress any dialog invalidations emitted while painting the dialog. We are not interested in any such invalidations. Change-Id: I2a7b018124af501bce18adbff0f5db85adf5fce2
2017-10-02lokdialog: Better dialog rendering APIPranav Kant
After painting the dialog, also write width and height of the rendered dialog. The dialog is rendered always on the top left of the given canvas, so client can crop the canvas accordingly. Change-Id: If052058a6db8a85d4e28ec88cffcca05564b17f0
2017-10-02Add IDialogRenderable interface for rendering of dialogsTomaž Vajngerl
Change-Id: I1d85729a1ac1a99d33ea2bde1b50ccf4c05ca9a9
2017-10-02lok: handle .uno:LanguageStatus commandHenry Castro
Change-Id: I3828113bce3b7d32e90e461a299986e363115a83 Reviewed-on: https://gerrit.libreoffice.org/43002 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-09-30Use explicit function names for fooA/fooW WinAPI; prefer fooWMike Kaganski
We should only use generic foo function name when it takes params that are also dependent on UNICODE define, like LoadCursor( nullptr, IDC_ARROW ) where IDC_ARROW is defined in MSVC headers synchronised with LoadCursor definition. We should always use Unicode API for any file paths operations, because otherwise we will get "?" for any character in path that is not in current non-unicode codepage, which will result in failed file operations. Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633 Reviewed-on: https://gerrit.libreoffice.org/42935 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-29check for unnecessary DLLPUBLIC annotationsNoel Grandin
on classes which are fully defined in a header file Rename the dllprivate plugin to dllmacro and add the functionality there. Change-Id: I4581d551c46a8f61213d95973f323359d08278d8
2017-09-29loplugin:flatten check for throw in then clauseNoel Grandin
also make the plugin ignore the case where we have var decl's in the clause we want to flatten, which could lead to problematic extension of variable lifetime Change-Id: I3061f7104e8c6a460bf74f5eac325a516ec50c59 Reviewed-on: https://gerrit.libreoffice.org/42889 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-25Fix typosAndrea Gelmini
Change-Id: I879a52820d78d9151ef64dd21612379f617f66e2 Reviewed-on: https://gerrit.libreoffice.org/42726 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-09-25Rename GetSelectEntryData -> GetSelectedEntryDataSamuel Mehrbrodt
Change-Id: Ia6402f6d2c978cbd5557052a43e9728ca9e11173 Reviewed-on: https://gerrit.libreoffice.org/42285 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2017-09-22Windows: avoid dependence on UNICODE define; prefer W functionsMike Kaganski
Change-Id: I95b90128e93f0d88ed73601bcc5a7ca9279d4cf1 Reviewed-on: https://gerrit.libreoffice.org/42560 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-21loplugin:flatten in connectivity..desktopNoel Grandin
Change-Id: Iff59d3049ba40b4338ef8eec67d08a96b0834d2b Reviewed-on: https://gerrit.libreoffice.org/42578 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-09-21Rename GetSelectEntryPos -> GetSelectedEntryPosSamuel Mehrbrodt
Change-Id: I0bd4cb463575af843c72d9c8aaf91742203532a4 Reviewed-on: https://gerrit.libreoffice.org/42283 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2017-09-20lok: Expose the automatic spell checking state in the UI.Jan Holesovsky
Change-Id: I5c22ff70d3895b0f4a86eb8be85dde971604874a Reviewed-on: https://gerrit.libreoffice.org/42480 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2017-09-18Some more WIN32_LEAN_AND_MEANMike Kaganski
Change-Id: Iadb0ebb66809c192fb817b8c7cf2f8cdb4d0b874 Reviewed-on: https://gerrit.libreoffice.org/42419 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-14Pre-load dictionaries for online.Michael Meeks
Change-Id: Ied81f20900060ff6a78704fa9195320b8fb86e45 Reviewed-on: https://gerrit.libreoffice.org/42269 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2017-09-14[API CHANGE] lok: Don't use 'bool' and 'uint64_t' in the stable API.Jan Holesovsky
This is a f70e0ec6b3c61a7c7caa469949b0ac8016c89854 follow-up. Change-Id: I4acf00a6da85ed14be4ed0ca20d541a9441736e7 Reviewed-on: https://gerrit.libreoffice.org/42266 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>