Age | Commit message (Collapse) | Author |
|
Change-Id: I8636102554a76f2ba3f6297219b40761473a4489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137285
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ief9949fd4252de9e33df172af07aa7ed097b5520
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136560
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I8bc30a218b67d165d1a8ae3d663e5482a8113aa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137118
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I145ce892e101ba4e8906cbdb0d32a52a4c655d43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137151
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
pController is always empty since commit
ac1aefd5174258d9bcb41465ce566ed1a0819f3d
("Extend ToolBarManager to build weld::Toolbar").
But even before that it did nothing, as it was set
only for controllers created by the sfx2 legacy
factory, but neither .uno:SwitchXFormsDesignMode nor
.uno:ViewDataSourceBrowser had such controllers (It
did however work in the past for some other commands
before commit fb60217569b0fb5bc949c58b054da71992fe2582
("tdf#83320 Hide vertical text commands early"). Also,
searching the codebase for SfxVisibilityItem reveals
more commands that set visibility, and I'm not sure
if hardcoding all of them here is a good approach in
general.
Change-Id: Id8c22e729d2402837de0598fa8ca4d41160804c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137150
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
sfx2::sidebar::ControllerFactory::CreateToolBoxController
only supports creating controllers using the uno factory,
or GenericToolbarController as a fallback. Given that we
already handle the uno factory case in
ToolBarManager::CreateControllers, all this complexity is
really just for creating GenericToolbarController with a
different ctor, which we can do locally as well.
Change-Id: I3a5a3cda95a6c5db97615286e93630214f76cbfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137149
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Ie706797e1bda4d1cd279fa68e93fb15beabb6a2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137077
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Starting directly to Writer (i.e. with "--writer") will attempt
to create VclStatusListeners for .uno:ImageOrientation before
the frame is activated, causing the dispatcher to not be found.
Also defer that stuff to after a toolbar is filled, so we get a
correct initial state for toolbars which shown when the current
paragraph is rtl already. (There is a similar problem with the
NB, but it isn't handled in this patch.)
Change-Id: Ie482007c10a4014b4a2fd4d53f05d433777ecfb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137014
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
By default Rectangle uses closed interval, if we really want to use half
open intervals then we should specifically say as such in the name.
Change-Id: Id7a91120ba1a1a4bc330014216b73a692dbf03a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136575
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The usual approach of setting the respective property
in *Commands.xcu won't work here, as that works with
the paragraph direction, which doesn't have to be the
same as the table direction.
Change-Id: I9c4d49a5c553a8a74e7760d257167a0be42c89c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136818
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
This is a follow-up to 2446fdba3ec4a81d6e3b619a1d9e91b3c6dcbd54
("tdf#134887 Rework last item handling in NewToolbarController").
We should better get the information on what is going to be
executed from the entity that will actually execute it, instead
of guessing on our own. This makes a difference for at least
XML Form Document, where CTRL+N used to be shown next to the
"XML Form Document" entry, although pressing that shortcut
will open a regular writer doc.
Change-Id: Ib9b58ea2fb83a6cfe9a603af6be97fb36a25ddc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136554
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
This isn't a meaningful context, but a way to represent
a lack of context. Typically it's a temporary state,
followed by a proper context being set. The problem
becomes apparent when a context deactivation is caused
by switching to another document window, as the further
activation will happen only when the former window is
focused again. This makes the contextual controls
disappear in the meantime.
Change-Id: I96c8356acb2434c579dc74407043b55eb5374a0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136010
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I442fada34e10fe13e68987abba34969a8ab50bc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135958
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
also when there are active UNO connections.
(Behavior was different when there were active UNO connections)
Change-Id: Ief37b0f362b7e2a47eccbec985ee3017c475046c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135905
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
See tdf#42949 for motivation.
Change-Id: I157b331195cc8262e6bd1dcc536cb653587fc45f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This patch modifies the "Standard (Single Mode)" toolbar
to have an optional context-aware section, given that a
corresponding singlemode-<context-name>.xml files exist.
This is a lot like the "Contextual Single" NB, except
that it's implemented with regular toolbars, so docking/
customization/extensions/uno api etc. are all working.
In addition, the "Single Toolbar" mode was modified to
not show any other contextual toolbar. (But of course the
single mode toolbar itself is perfectly usable outside of
this mode.)
Change-Id: Id746d9df59340a81962a8689b132941deea54b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135591
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I024653154c51389bb27f3e94b422ff7fc1c9b46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135296
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...when iterating over the enumerators of enum Image_XML_Entry
Change-Id: Ic59da7543a41f8b498d6f89e48faafcdf40c6873
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135194
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
make an owner for the PropertyMapEntries
Change-Id: Ie915a8a312f2b24488566814ad67fdeef89b5941
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135123
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
As reported by Julien, once the mediawiki extension is installed, the
xHandler in framework::DispatchProvider::implts_searchProtocolHandler()
points to an UNO component implemented in Java, and we crash in
dynamic_cast<>(), at least on Linux with gcc 7.5 and libstdc++.
This dynamic_cast<>() call was added in commit
c0fa456436947a5c167c652d19a884064b43c03d (tdf#149261 sdext: fix crash on
starting the presenter console for the 2nd time, 2022-05-26), to allow
the presenter console to opt out from protocol handler caching. It was
expected that the proxy object created for a Java UNO component would
simply return nullptr when we try to dynamic_cast<>() it down to a C++
interface.
Fix the problem by moving the interface to an UNO one: this side-steps
the dynamic_cast<>() crash at the price of introducing an UNO interface,
which is not meant to be part of the public UNO API (but at least it's
not published).
It may still make sense to improve the bridges/ code at some stage to
not crash in dynamic_cast<>() on generated Java proxy objects.
Change-Id: Iaac44515339e0dc15dddc3be45ef7dee7331e47a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135114
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
There is a non-obvious difference in error handling when opening the
file read/write for type-detection fails in
utl::MediaDescriptor::impl_openStreamWithURL() - if ReadOnly=false is
given, it will abort the file loading, whereas without any ReadOnly it
will fall-back to a read-only opening of the file for type detection.
At this point a StillReadWriteInteraction is used, so the user is never
notified of the failure.
(regression from commit 404c51f3664ffd4f7e2c1c8bb8a12ac70954fec2)
Change-Id: I8c06fe23cc0bc0767df83f680a1a59e3700bbbbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135045
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
This started with commit 3f768cddd28a2f04eb1ffa30bed4474deb6fbfc4
(framework: avoid re-creating protocol handler instances all the time,
2022-05-02). In case there are 2 monitors, then one monitor shows the
slideshow, the other shows the presenter console. The presenter
console's protocol handler in
sdext::presenter::PresenterProtocolHandler::Dispatch::Dispatch() has
mpPresenterController->GetWindowManager() as an empty reference on the
2nd time the presentation starts.
The above commit started to cache protocol handler instances at a frame
level for performance reasons, and this is meant to be safe in general,
but the presenter console's window manager is re-created between
slideshow runs, so it depends on framework/ code to re-create the
protocol handler all the time, which is problematic here.
Fix the problem by introducing a framework::CacheInfo interface that
allows protocol handler implementations to signal if they want to avoid
being cached.
This should be good enough for now, but if later it turns out that there
are too many broken protocol handlers out there, then we can consider
flipping the default and only cache handlers which explicitly opt in for
this behavior. This is not done in this commit.
Change-Id: Ic159813b1b339540bc8c4e780c4d6d7d2d4d2445
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135020
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ib86933ef564b0d27c47dbbaddaa55f03b8426c7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Autorecovery information was saved in every 10 minutes,
regardless of the "Save Autorecovery information every" setting.
Change-Id: I1a52da2fa5febb53c270a8db7472e9a8c0e4c426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134642
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Iadd73477bf3b0edaa0fb7db10f9ffca88fe737e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134476
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
file by asking password re-typing unstoppably. Instead
of this, skip recovery file saving, if the document
contains password hashes which haven't been supported
by the "calc8" filter of the recovery file (which
triggered the "Re-type password" dialog).
Solved problems:
– Asking for passwords during a non-interactive
background process.
– A single Cancel didn't close the "Re-type password" dialog
window, only pressing three times at least (according to the
value of RETRY_STORE_ON_MIGHT_FULL_DISC_USEFULL), but
waiting for the password for a while could result a
frozen "Re-type password" dialog, where only retyping or
removing the password(s) were the escape routes.
– Re-typing the password required the password (but modifying
the original document doesn't require this).
– Removing the password resulted in loss of the protection
after saving the original XLSX document.
Add a UI test to keep the "Re-type password" dialog during Save As.
Note: because of the regression reported in tdf#145757, it needs
to wait 10 min for saving the recovery file, yet, despite the
changed time in Tools->Options->Load/Save->General.
Change-Id: Icc6ee4d67048cdf15ab75ef8e2ee8f1709cdd4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134409
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I8a1c8e8ccec8ca64cc4f615ea8e9e415a343996d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134396
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If3087253a75a1cba16f69eecccbaf845ed0b12bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134344
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
shaves 2% off load time
Change-Id: I5bd4eabf61205df21a27d2822acd2676a7732a3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134315
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2e876f0bff180e569394e2fe3c102b658a55d170
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134309
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
where instantiating and allocating a whole map just to extract a single
key is way inefficient
Change-Id: I55248bc71a9e8826cab9b76fa6916bfa888efa0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134226
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id70349e0e8f7d79bad693663ec3dc2963e0834b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134205
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
include/osl/mutex.hxx:196: void osl::ClearableGuard<T>::clear() [with T = comphelper::SolarMutex]: Assertion `pT' failed.
because clear() was called, then an exception was thrown and reset() was
omitted.
Change-Id: Iaa6d26e23261c2426eb3cc465b212752c4f454e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134195
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
...when iterating over the enumerators of enum StatusBar_XML_Entry resp. enum
ToolBox_XML_Entry
Change-Id: I11904e941e98e0ffb96cf1ba4e61c91382944813
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Regression from b099da78a6f0b3e120f706714003b05d84d11e70
we didn't update linked OLE document after document reload
Change-Id: I8e52f6430f454b276cb43449c6f7a3b0e07e909f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130692
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I6908dc61cbd6e6e4d11c52dfface1d863cd7e5c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133977
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I34cdb5ce7e9e5b3c3d8f985057bb7ff09f2b7f68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133978
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id93086be1224b6f6bf0bdaa1d50b4f289099027e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133876
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by inspecting call sites of OUString::getToken
Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9f4990cf58cc794408dd70cd7fbfb2a8effa138c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133806
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Once you install an extension that adds its own protocol handlers (e.g.
<https://github.com/niocs/ProtocolHandlerExtension>), DispatchProvider
re-creates this protocol handler every time the custom menu gets opened
or a command gets dispatched.
This allows the dispatch provider to avoid managing the lifecycle of
those protocol handler instances, but in case the constructor of those
handlers is expensive, this leads to performance problems.
Introduce a map of handler instances in DispatchProvider to avoid
unnecessary re-creation and re-initialization: these instances get the
same XFrame anyway (the DispatchProvider is owned by the frame), so this
is meant to be safe.
No testcase for this -- the problem is only visible if you have an UNO
service registered in the global UNO service registry, but by the time
our cppunit tests run, that is already a fixed list, so this would be
hard to test from code.
Change-Id: I6d69906a795a2d5a67706002d635b6cb3091b856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133706
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Esp. "Edit Macros" was missing here - it's available in the other apps.
Change-Id: I807e9c35da42729d3c3838266736fdfa5be23fcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133434
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
found by examining uses of OUString::copy() for likely places
Change-Id: I6ff20e7b273ad6005410b82719183c1122f8c018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add Office::Histories::HistoryItem::ReadOnly flag to configuration so
that a document that was opened read-only isn't opened as editable from
recent documents.
Change-Id: I6985da287d3337a53a7e41e8e500421038eedb91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133385
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Introduced in commit 2d01ed9e8be543460e41e009fa992103a7c8d4c0
Author Muhammet Kara <muhammet.kara@collabora.com>
Date Mon Nov 25 21:55:31 2019 +0300
tdf#94288: Show chart props sidebar on activation
The problem was that ChartController::attachFrame, that called
SelectionChangeHandler::selectionChanged notification, did that
*prior* to setting its m_xFrame - and the notification failed
in ContextChangeEventMultiplexer::NotifyContextChange, that
checks the frame first. That prevented the proper context (with
correct application and context names) to arrive to listeners,
and the sidebar didn't update properly.
Changing the order of the calls should fix the original problem.
Change-Id: I9da8465af2ee4ed1f8eabed1c65d1c318f81a3f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133326
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
which converts to std::string_view::substr()
Change-Id: I3f42213b41a97e77ddcc79d84d512f49d68ca559
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|